El 10 de agosto de 2026, el FBI, CISA, la NSA, el Servicio Secreto, el centro de ciberdelincuencia del Departamento de Defensa de EE. UU. y la Policía Nacional de Corea del Sur firmaron un aviso conjunto sobre el ransomware Gunra (AA26-222A). Que seis organismos de dos continentes suscriban el mismo documento ya indica la magnitud del problema. Aun así, el valor del aviso no está tanto en las firmas como en su contenido: detalle forense extraído de incidentes reales investigados por el FBI y por la policía surcoreana.
Dos hallazgos destacan. El primero: en al menos una víctima, los operadores de Gunra manipularon la autenticación de un portal de escritorios virtuales para que un código de un solo uso elegido por ellos fuera aceptado siempre. El MFA seguía activo para todos los usuarios; simplemente había dejado de proteger frente a los atacantes.
El segundo es una rareza entre las familias de ransomware: la variante para Linux genera sus claves de cifrado con un generador pseudoaleatorio tan débil que un defensor podría reconstruirlas y, en determinadas condiciones, recuperar los ficheros sin pagar.
De Conti a plataforma: cómo se ha profesionalizado Gunra
Gunra apareció en abril de 2025 como una variante de doble extorsión construida sobre el código fuente de Conti filtrado en 2022. Desde el primer momento operó un sitio de filtraciones en Tor donde lista a sus víctimas y publica lo robado. En enero de 2026 dio el salto a un programa formal de ransomware como servicio: panel de gestión para afiliados, generador configurable del cifrador, cifradores para Windows y Linux y documentación estructurada, según la disección técnica de CloudSEK.
El FBI ha observado al grupo operar bajo alias nuevos —el más visible, Golden Community— y reclutar activamente a pentesters (especialistas en pruebas de intrusión) para que actúen como intermediarios de acceso inicial a cambio de un porcentaje del rescate.
Las negociaciones arrancan con cifras deliberadamente infladas, del orden de decenas de millones de dólares, y con un plazo de cinco a siete días antes de publicar los datos. El contacto se canaliza por un portal en Tor o por qTox, una aplicación de mensajería cifrada. El FBI también ha visto correos enviados directamente a directivos de la empresa víctima, con poco éxito.
El grupo no elige sector: el aviso lista sanidad, finanzas y seguros, fabricación y construcción, transporte y logística, administraciones, energía y agua, educación, medios, comercio y servicios profesionales, con víctimas en América, Europa, Oriente Medio, África y Asia-Pacífico. En el terreno industrial, Dragos contabilizó 1.140 incidentes de ransomware contra organizaciones industriales en el segundo trimestre de 2026, un 12 % más que en el primero; al menos cuatro los atribuye a Gunra, que había sumado ocho el trimestre anterior.
Una cuestión sigue abierta: la relación con Lazarus. Dos semanas antes del aviso, The Record recogía observaciones de investigadores según las cuales parte del utillaje y de la infraestructura de Lazarus, el grupo norcoreano, se habría compartido con Gunra en ataques a organizaciones surcoreanas. Por ahora se trata de un solapamiento observado, no de una atribución.
¿Por dónde está entrando?
Vulnerabilidades conocidas en Fortinet
No hay fallos exóticos. El FBI documenta el acceso inicial mediante dos vulnerabilidades conocidas de FortiOS y FortiProxy —CVE-2024-55591 y CVE-2025-24472—, ambas de salto de autenticación, ambas con parche disponible desde comienzos de 2025 y ambas señaladas por CISA con anterioridad. La explotación deja en el cortafuegos un usuario persistente con privilegios de superusuario y un nombre pensado para pasar desapercibido: forticloud-sync.
Credenciales débiles en pasarelas expuestas
La policía surcoreana documenta la otra vía de entrada: pasarelas VPN expuestas a internet comprometidas por credenciales filtradas, por fallos de control de acceso SSH y, en un caso documentado, por las credenciales por defecto de la cuenta de administración de un equipo SSL-VPN que ni siquiera tenía bloqueo por intentos fallidos.
El patrón encaja con algo que ya hemos analizado: los dispositivos de frontera —cortafuegos, VPN, balanceadores— son el punto ciego del EDR y concentran cada vez más accesos iniciales. Si tu gestión de vulnerabilidades no prioriza estos equipos cuando entran en el catálogo KEV, está priorizando mal. Sobre cómo ordenar esa cola escribimos en KEV, EPSS y SSVC.
El caso del portal VDI: una puerta trasera dentro del MFA
El incidente más instructivo del aviso lo investigó la policía surcoreana. Los atacantes, ya con acceso al equipo de un administrador de red, entraron en la consola web del SSL-VPN e identificaron una cuenta sin uso con acceso simultáneo a la red expuesta y a la corporativa. Modificaron su configuración para esquivar el cambio de contraseña obligatorio y la convirtieron en su vía de acceso habitual.
Después manipularon el control de tráfico del equipo VPN para capturar las credenciales y la información de sesión de los usuarios que se autenticaban en el portal de escritorios virtuales (VDI). Con las cookies robadas suplantaron a usuarios legítimos —la misma lógica de secuestro de sesión que vimos en Citrix Bleed 2— y desde ahí se movieron por RDP hasta el servidor de autenticación del VDI, el controlador de Active Directory y los escritorios del personal de TI.
En ese servidor de autenticación dieron el paso más quirúrgico de la intrusión: alteraron los ficheros que procesan la validación para que un código OTP concreto, elegido por ellos, fuera aceptado siempre. Una puerta trasera dentro del MFA. Ningún panel la delata: el segundo factor sigue configurado, los usuarios siguen usándolo y las revisiones que solo comprueban que la casilla está marcada lo siguen dando por bueno.
El resto fue trabajo en serie: volcado del NTDS con secretsdump para extraer los hashes de contraseña del dominio, pass-the-hash y pass-the-ticket (reutilización de esos hashes y tickets para autenticarse sin conocer la contraseña) como vía de movimiento lateral.
El último paso fue el más dañino: desde un escritorio virtual comprometido accedieron por SSH a un servidor de control de accesos y robaron la clave simétrica que guardaba. Con ella descifraron las contraseñas de todos los servidores corporativos almacenadas en su base de datos, y con esas credenciales desplegaron el cifrador sobre bases de datos y cabinas NAS.
¿Por qué los controles habituales no lo ven?
Porque casi todo lo que hace Gunra parece administración de sistemas. Su caja de herramientas es legítima y cotidiana: Impacket, RClone, FileZilla, 7-Zip, WinRAR, AnyDesk, MobaXterm, DBeaver, incluso Visual Studio Code y Slack. Solo Sliver y Mimikatz serían piezas que un inventario de software marcaría de inmediato.
El cifrador tampoco coopera. Es autónomo, no genera tráfico de red observable —ni DNS ni HTTP—, detecta depuradores mediante la función IsDebuggerPresent y excluye del cifrado los directorios del sistema para que la máquina siga arrancando.
Los operadores trabajan cuando tú no: el aviso documenta actividad concentrada entre las 22:00 y las 06:00, con borrado sistemático de registros y del historial de comandos. Poco de esto es sofisticado; todo está elegido para pasar inadvertido.
Tampoco toda la exfiltración pasa por tu red: un ejecutable a medida (main.exe) extrae contenido directamente de OneDrive y SharePoint, y los archivos comprimidos acaban en el servicio Mega. En una víctima, el volumen llegó a decenas de terabytes.
Detección por comportamiento: qué mirar en tu telemetría
Del aviso se deducen señales concretas y fáciles de vigilar con lo que ya tienes.
En Windows
Vigila la orden WMIC shadowcopy delete (borrado de instantáneas justo antes de cifrar), los accesos anómalos al fichero NTDS.dit o las peticiones de replicación de directorio desde equipos que no son controladores de dominio, y la aparición de RClone, FileZilla o AnyDesk en servidores donde nunca habían estado.
En la frontera
Presta atención a la creación de cuentas locales en cortafuegos (el usuario forticloud-sync figura literalmente en los indicadores del aviso), a los túneles SSH salientes desde equipos de red hacia servidores desconocidos y a las sesiones administrativas fuera de horario: la franja de 22:00 a 06:00 sirve directamente de filtro para priorizar alertas de acceso privilegiado.
Marcadores tardíos
Dos señales inequívocas, aunque ya tardías: renombrado masivo de ficheros a la extensión .ENCRT y notas de rescate R3ADM3.txt en los directorios. Si aparecen, lo que queda es responder. Un servicio de threat hunting —caza proactiva de amenazas— que persiga comportamiento y no solo firmas encaja con lo que el aviso pide a los defensores; en la empresa de ciberseguridad Hard2bit lo hacemos apoyándonos en el mapeo MITRE ATT&CK que el documento trae hecho.
La variante Linux: claves que se pueden reconstruir
Trend Micro documentó en julio de 2025 la variante de Gunra para Linux. En marzo de 2026, Breakglass Intelligence documentó un fallo de diseño notable: el generador pseudoaleatorio de las claves se siembra con srand(time(NULL)), es decir, con la hora del sistema. Con las marcas de tiempo de los ficheros cifrados (extensión .GNRA), un defensor podría reconstruir las claves y, en determinadas condiciones, recuperar los datos sin pagar.
El aviso oficial se toma en serio esa vía: su guía de respuesta cita la investigación y pide expresamente preservar ficheros cifrados, marcas de tiempo, notas de rescate y registros antes de plantearse nada más. No es frecuente que una guía oficial de respuesta deje por escrito que las claves de un ransomware podrían reconstruirse; si te toca la variante Linux, esa preservación puede ser la diferencia entre restaurar y pagar.
Defensa: lo que pide el aviso y el fallo de fondo
Las mitigaciones del documento son conocidas, pero están bien jerarquizadas: parchear con prioridad los equipos expuestos —VPN y RDP en cabeza—, exigir el segundo factor en todos los servicios, revisar cuentas nuevas o sin uso en controladores y directorios, restringir la ejecución de herramientas de línea de comandos y segmentar la red para acotar el movimiento lateral.
El punto de las copias merece un apunte aparte. En una víctima, los operadores borraron las copias de seguridad y los archivos históricos tanto en el centro de datos principal como en el de recuperación, antes y después de desplegar el cifrador. Unas copias de seguridad inmutables, fuera de línea y en una ubicación segregada habrían sido aquí la única pieza del plan de recuperación que el atacante no podía tocar. Probar la restauración importa tanto como tener la copia.
La conclusión estructural apunta a otro sitio. La infraestructura de identidad —la pasarela VPN, el portal VDI, el servidor de control de accesos— se ha convertido en el objetivo real, y el segundo factor no es una casilla que marcar sino un sistema que defender, con la integridad de sus ficheros vigilada y sus accesos administrativos registrados y revisados. Si una organización no puede responder quién tocó ayer la configuración de su portal de autenticación, tiene el mismo hueco que estas víctimas.
Ante una sospecha de intrusión activa, el equipo de respuesta a incidentes de nuestra empresa de seguridad informática Hard2bit puede ayudarte a acotar el alcance y expulsar al actor antes del cifrado. Llevamos desde 2013 trabajando justo en esa fase: la que decide si la intrusión se queda en contención o acaba en crisis.
Este artículo se basa en el aviso conjunto AA26-222A (FBI, CISA, DC3, NSA, USSS y KNPA) y en investigación pública de terceros, con la información disponible a 13 de agosto de 2026. Las técnicas y los indicadores descritos pueden evolucionar. Valida cualquier medida de detección o bloqueo en un entorno de pruebas antes de llevarla a producción y adapta las recomendaciones al contexto de tu organización.
