Borraron las copias en los dos centros de datos

Borraron las copias de seguridad en el centro de datos principal. Y en el de recuperación. Antes de lanzar el cifrado y otra vez después. Que la segunda sede estuviera lejos no la salvó de nada, y esa es la parte que conviene mirar despacio.

El 10 de agosto de 2026, seis agencias —el FBI, CISA, la NSA, el centro de delitos informáticos del Departamento de Defensa estadounidense, el Servicio Secreto de Estados Unidos y la policía nacional de Corea del Sur— publicaron el aviso conjunto AA26-222A sobre el ransomware Gunra. Es un documento de los que se hojean en diagonal: técnicas, indicadores, recomendaciones, la estructura de siempre. La frase que nos hizo parar está en el apartado de impacto y viene con su acotación puesta: «contra una víctima de Gunra, los actores borraron datos de copia y de archivo almacenados en la infraestructura de copia tanto en el centro de datos principal como en el centro de recuperación ante desastres, antes y después» del despliegue del cifrador. En la tabla de técnicas lo vuelve a acotar igual: «en un caso».

Antes y después. Eso no es rabia, es método. Se borra antes para que no puedas restaurar mientras negocias, y se vuelve después a por lo que hayas creado durante el incidente, que es justo cuando todo el mundo se acuerda de hacer una copia. El aviso lo documenta en un solo caso, y con uno basta para lo que nos interesa: la maniobra ya está descrita, con su hora y su orden, en un documento público que puede leer cualquiera.

Cuando la sede de recuperación no es una sede distinta

Un centro de recuperación existe para que un desastre en el principal no se lleve la empresa por delante. Y funciona: contra el incendio, la inundación, el corte eléctrico largo o la excavadora que parte la fibra de la calle, la distancia es exactamente la defensa correcta. El problema es el desastre para el que no se diseñó. Contra alguien que entra con una credencial válida, los kilómetros que separan las dos salas se recorren en el tiempo que tarda en abrirse una sesión.

En otro apartado, el mismo aviso cuenta cómo este actor se hizo con un juego de llaves de ese calibre. Desde un escritorio virtual ya comprometido, los actores accedieron por SSH a un servidor de control de accesos —el aviso lo identifica como un equipo Hiware— y robaron una clave de cifrado simétrica guardada en él. Con esa clave descifraron las contraseñas de las cuentas de servidor de toda la empresa que había en su base de datos. No una contraseña: el cajón entero, y la llave del cajón.

El camino, paso a paso, y lo poco exótico que es

Merece la pena verlo entero, porque no hay ni una sola pieza que no puedas tener tú:

1. La puerta. Dos evasiones de autenticación en FortiOS y FortiProxy: CVE-2024-55591 y CVE-2025-24472. Las dos tienen parche desde principios de 2025.
2. La cuña. Los dos fallos permiten abusar de las tareas programadas del cortafuegos para crearse una cuenta de superusuario persistente, con contraseña fija y nombre de lo más tranquilizador: forticloud-sync. Persistente quiere decir que parchear no la borra. Si la buscas hoy en tus equipos y no la encuentras, enhorabuena; si nunca la has buscado, ese es el trabajo de mañana por la mañana.
3. Las credenciales. secretsdump.py, de la suite Impacket, contra varios controladores de dominio, para extraer los hashes de las cuentas de los ficheros NTDS. Del mismo juego de herramientas salen psexec.py y smbclient.py, que es con lo que se movieron de máquina en máquina.
4. El segundo factor. Modificaron el procesamiento de autenticación del portal VDI corporativo para que una contraseña de un solo uso, elegida por ellos, valiera siempre. El MFA seguía puesto. Seguía pidiendo el código. Y ellos tenían un código que nunca caducaba.
5. El llavero. El servidor de control de accesos, por SSH desde un escritorio virtual comprometido, y su clave simétrica.
6. La salida. Datos comprimidos y subidos a MEGA, y un ejecutable propio, main.exe, para llevarse lo que había en OneDrive y SharePoint.

Ni una sola línea de este recorrido necesita un día cero. Necesita un cortafuegos con dos parches de hace año y medio sin poner, un directorio del que se pueden extraer hashes y un sitio donde estén guardadas las contraseñas de todo lo demás. Nosotros entramos a auditar infraestructuras ajenas con cierta frecuencia, y esas tres cosas juntas aparecen mucho más a menudo de lo que nadie admitiría en una reunión.

Dos sedes que aceptan la misma credencial son una sede

Aquí está la idea que nos llevamos, que no es del aviso sino la lectura que hacemos nosotros —y no somos los únicos que la estamos haciendo estas semanas—. Cuando dibujas la redundancia, dibujas cajas y cables. Dos salas, dos cabinas, dos enlaces, una flecha de replicación entre ellas. Lo que casi nunca se dibuja es quién puede entrar en cada caja, y esa es la capa donde de verdad se decide si tienes dos sitios o uno.

Lo decimos siempre igual: el fallo es inevitable, la avería es una decisión de diseño. Un disco que se muere en un sistema con réplica es papeleo de mantenimiento; el mismo disco en un sistema sin ella es un día de cierre. Con las credenciales pasa exactamente lo mismo, solo que el «disco» aquí es una persona que ya no trabaja contigo, o un cortafuegos sin parchear. Si la cuenta que administra la sede A también administra la sede B, has replicado los datos y has replicado también el punto único de fallo. Es la versión geográfica de la pregunta de quién puede apagar tus servidores.

La variante doméstica de esto nos la encontramos casi todas las semanas y no hace falta tener dos centros de datos para sufrirla: el servidor de copias metido en el mismo dominio que protege, de modo que para restaurar el directorio necesitas autenticarte contra el directorio que has perdido. Ya escribimos sobre esa dependencia circular y lo que cuesta deshacerla. Es el mismo error con dos ceros menos.

La inmutabilidad protege los bloques, no la puerta

La reacción habitual a un titular así es «nosotros tenemos copias inmutables». Bien: es la medida correcta y funciona. Un bloqueo de retención bien puesto impide que un administrador con todas las credenciales del mundo borre lo que está dentro del plazo, y eso es exactamente lo que hay que tener. Pero conviene saber qué queda fuera de ese paraguas, porque no es poco: los trabajos de copia se pueden desactivar, los puntos que aún no habían entrado en la retención se pueden eliminar, un catálogo perdido convierte una restauración de una tarde en una arqueología de varios días, y las políticas futuras se pueden reescribir. Nada de eso rompe la inmutabilidad. Solo la rodea.

Por eso la recomendación del aviso no dice «ten copias inmutables» y se queda ahí. Dice: copias fuera de línea, inmutables, en una ubicación físicamente separada y segmentada, y probadas. Las cuatro condiciones, juntas, y la última es la que casi nadie cumple. Ya contamos el caso del registro de la propiedad rumano para explicar por qué la palabra que importa de verdad es «inmutable».

La prueba del llavero: seis comprobaciones para esta semana

Ninguna necesita comprar nada. Cuatro se contestan en una tarde con un folio; dos hay que ejecutarlas de verdad, y son las importantes.

1. Escribe qué credenciales abren las dos sedes. Con nombre y apellidos de cuenta, no «los del equipo de sistemas». Si la lista tiene más de tres entradas, ya tienes el trabajo de este trimestre.
2. Mira contra qué autentica el sistema de copias. Si es el mismo directorio que protege, tienes la dependencia circular. Cuenta local, aparte, que no exista en el dominio.
3. Localiza tu llavero. El gestor de contraseñas, el bastión, el servidor de control de accesos: donde estén guardadas las claves de lo demás. Ese servidor no es una herramienta de oficina; es el sistema más crítico que tienes y merece su propio segundo factor, su propia red y su propio registro de quién lo abre.
4. Intenta borrar un punto de restauración de la sede B con las credenciales de la sede A. Esta hay que hacerla, no razonarla. Tiene que fallar. Si funciona, no tienes dos copias: tienes una copia y un espejo de esa copia.
5. Comprueba que hay una copia que no se alcanza por red. Cinta que se saca, disco que se desconecta, cuenta de almacenamiento en otro proveedor con credenciales que no viven en tu directorio. Algo que, para borrarse, exija que alguien vaya a un sitio.
6. Restaura algo. Hoy. Con el cronómetro puesto. No «verificar la copia»: levantar el servicio y usarlo. Nuestro último simulacro de recuperación completa fueron catorce minutos —dato interno nuestro, una prueba y no una garantía contractual—, y ese número solo existe porque alguien lo cronometró. Si nunca has cronometrado el tuyo, tu RTO es una intención, no un número.

Lo que el aviso no dice

Somos nosotros los que hemos unido las dos frases. El documento cuenta, por un lado, que se llevaron la clave del servidor de control de accesos y, por otro, que borraron las copias en las dos sedes. No dice que lo segundo se hiciera con lo primero, ni detalla qué credencial abrió el centro de recuperación. Lo hemos puesto como hipótesis de trabajo porque es la que más veces hemos visto ser cierta, pero no es un hecho del aviso y sería deshonesto presentarlo como tal.

Tampoco se deduce de aquí que tener un segundo centro de datos no sirva. Sirve, y mucho, para aquello para lo que se construyó. Lo que no puede es cubrir dos riesgos con una sola medida sin que nadie revise si la medida vale para los dos. Y la última cosa que no se deduce: que haga falta comprar algo. Cuatro de las seis comprobaciones de arriba son papel y una conversación. Nosotros vivimos de la quinta y la sexta, así que léelo con la reserva que corresponde; pero si las haces esta semana y las respuestas te dejan tranquilo, has ganado una tarde y no nos debes nada.

Fuentes: todo lo que este post afirma sobre el ataque sale de un único documento, el aviso conjunto «#StopRansomware: Gunra Ransomware», AA26-222A, de 10 de agosto de 2026, firmado por el FBI, CISA, DC3, la NSA, el USSS y la KNPA (PDF en ic3.gov, 21 páginas, que es la copia que hemos leído). De ahí salen: el borrado de copias y archivo en el centro principal y en el de recuperación, acotado a una víctima («against one Gunra victim», y «in one instance» en la tabla de la técnica T1490); los dos CVE de FortiOS/FortiProxy y la cuenta persistente forticloud-sync creada abusando de tareas programadas (Tabla 5); secretsdump.py contra varios controladores de dominio para sacar hashes de los ficheros NTDS, y psexec.py y smbclient.py para el movimiento lateral; la modificación de los ficheros de autenticación del portal VDI para que una contraseña de un solo uso elegida por el atacante siempre funcionara (T1556.006); el acceso por SSH al servidor de control de accesos Hiware y el robo de su clave simétrica (T1555); la exfiltración a MEGA y la de OneDrive y SharePoint con main.exe; y la recomendación literal de copias «offline, immutable, stored in a physically separate, segmented location» y probadas. La traducción del inglés es nuestra. La lectura de que dos sedes con la misma credencial son una sola sede, lo que queda fuera del bloqueo de retención, las seis comprobaciones y los catorce minutos del último simulacro (dato interno nuestro, una prueba y no una garantía) son cosecha propia y no del aviso.