Apagaron el EDR con un reinicio, y el cifrado falló por falta de memoria

A las 06:29:21 UTC del 4 de agosto, alguien que llevaba dentro desde las cuatro menos cuarto de la mañana abrió msconfig.exe y forzó un reinicio. La máquina volvió en Modo seguro con funciones de red, que es un arranque donde Windows no carga los servicios de terceros. El agente de EDR se quedó fuera. Defender apuntó su propio error, 0x8007043c: «este servicio no puede iniciarse en Modo seguro».

El caso lo publicó Huntress el 12 de agosto, y hay algo que conviene decir de entrada: el agente que se quedó apagado era el suyo. Lo cuentan igual, con los identificadores de evento y las horas. Nosotros gestionamos EDR/MDR en parques informáticos ajenos y atendemos guardias, así que el informe se lee desde aquí como una lista de lo que teníamos que haber visto.

La cronología, con las horas que hay y las que no

Todo lo que sigue va en UTC, que es como lo publica Huntress. Dos fases del ataque no llevan hora en el informe, y aquí tampoco se la vamos a poner.

Una hora y cuarenta y un minutos, no diez

Parte de la cobertura del caso sitúa la ventana sin EDR en diez minutos. Esa cifra está en el informe, pero mide otra cosa: Huntress dice que la sesión de AnyDesk, incluido el reinicio en Modo seguro que la precede, duró menos de diez minutos. La ventana ciega es otra frase, dos párrafos más arriba: durante toda la ventana de Modo seguro, el host no tuvo EDR funcionando y el antivirus estaba cegado.

Lo que detuvo el cifrado fue la memoria

El Modo seguro arranca con un entorno recortado y con memoria virtual limitada. Huntress lo formula con cuidado y nosotros vamos a copiarles la cautela: el árbol de procesos de Akira parece haberla agotado, y el cuadro de «memoria virtual agotada» encaja exactamente con el momento en que el binario intentó ponerse a trabajar. Su frase sobre esto va entera, porque la segunda mitad es la que importa: «un efecto secundario afortunado del error del propio atacante en estas circunstancias, no una defensa con la que se pueda contar».

Y añaden el detalle que remata el argumento: un host con más memoria física o con un fichero de paginación mayor podría haberle dado a akira.exe memoria virtual suficiente para cifrar en Modo seguro. La misma intrusión, en un servidor con 256 GB, termina en otro sitio. Así que el resumen honesto de este incidente incluye la palabra suerte, y esa palabra nunca describe al incidente: describe al programa de seguridad que había debajo.

Los ficheros se fueron antes del reinicio

El informe no fecha la exfiltración, pero sí la ordena: WinRAR sobre las comparticiones mapeadas y subida con s5cmd antes del reinicio de las 06:29:21, que a su vez es anterior al cifrador de las 06:34:29. Cuando el atacante toca el binario, los ficheros ya están en un bucket que no es tuyo. Doble extorsión de libro: el cifrado sirve para meter prisa a quien ya ha perdido los datos.

Conviene decirlo aunque nos deje peor: una copia de seguridad impecable no habría cambiado nada de lo que pasó ese día. Te devuelve los ficheros y deja intacta la palanca del chantaje. Vendemos backup gestionado y aun así el orden correcto de este post es el acceso primero, la vigilancia después y la copia como red de seguridad de abajo. Si además tu servidor de copias vive dentro del mismo dominio que acaban de volcar entero con Get-ADComputer, eso ya es otro problema que escribimos aparte.

En Modo seguro tu agente no es imprescindible para Windows

No hubo exploit, ni driver vulnerable firmado, ni trucos de kernel. Hubo un msconfig.exe y un reinicio, y el resto lo puso el diseño del sistema operativo: el conjunto mínimo de drivers y servicios excluye por definición a los productos de seguridad de terceros. MITRE tiene ficha para esto, la T1688, y Huntress recuerda que familias como Snatch y AvosLocker llevan años haciéndolo. Lo que ellos ven por primera vez es a Akira usándolo.

Encaja con lo que se ve en el trimestre. En su informe del segundo trimestre de 2026, Halcyon contó 1.988 ataques reivindicados públicamente y 89 grupos activos, con Akira cuarto por volumen con 119. Infosecurity abría su pieza sobre ese informe resumiéndolo así: apagar las herramientas de detección antes de empezar a cifrar se ha convertido en procedimiento habitual en todo el ecosistema del ransomware.

La línea que casi nadie ha citado

Está en el apartado de mitigaciones y se lee rápido: en este entorno, el agente estaba en una fracción de las máquinas que el atacante enumeró. Ahí es donde se prepara un ataque, en los hosts que nadie mira, y por eso el Get-ADComputer del principio no es una curiosidad forense: es el mapa que le dice al atacante cuáles son. Un despliegue de EDR con huecos convierte tu inventario en el inventario del otro.

Esta parte nos toca de lleno. Cuando entramos a un parque informático ajeno, el primer cálculo que hacemos en EDR/MDR gestionado es cuántos hosts hay en el directorio y cuántos tienen agente. La diferencia entre esos dos números es el ataque que todavía no ha pasado.

Las horas son UTC, y eso cambia la conversación

Huntress no dice dónde estaba la víctima, así que traducir a hora local es un ejercicio nuestro y no un dato del caso. Si esto hubiera pasado en la España peninsular, la polvorización cae a las 05:45 y el acceso válido a las 05:52 —de madrugada, sin nadie delante—, y la ventana ciega iría de las 08:29 a las 10:10. En mitad de la mañana. Con la oficina abierta.

Preferimos ese escenario al del titular fácil, porque incomoda más. Una máquina que se reinicia sola y se queda sin agente durante una hora y tres cuartos puede pasar desapercibida a las diez de la mañana de un martes, con todo el mundo en su sitio, y eso no se arregla contratando a alguien de noche. Se arregla con el soporte 24x7 conectado a la consola y con una regla que diga que un agente callado despierta a alguien, sea la hora que sea.

Siete minutos en la puerta

Todo lo anterior ocurre después. La puerta era una VPN SSL con usuario y contraseña, y se abrió en unos siete minutos de polvorización. Da igual lo bueno que sea el resto si el perímetro cede con una contraseña reutilizada, y de esto hemos escrito ya con otro traje: cuando el que falla es el propio equipo del perímetro y cuando hay caminos de autenticación que nunca llegan a pedir el segundo factor.

Las mitigaciones, en el orden en que las pone Huntress

La lista es suya y el orden también. Entre paréntesis va lo que hacemos nosotros con cada punto, que es lo único que ponemos de nuestra parte:

Lo que NO vamos a decirte

En corto

Una VPN sin segundo factor, un volcado del directorio entero, unas comparticiones empaquetadas con WinRAR y subidas a S3, y un reinicio que dejó al host una hora y cuarenta y un minutos sin agente ni antivirus. Al cifrador lo tumbó la memoria virtual del Modo seguro, y Huntress avisa de que en un host con más RAM eso no habría pasado. Todo lo demás del caso —los eventos 27, 12, 26 y 7036, la ráfaga contra la VPN, el agente que se calla— se estaba escribiendo en registros que la mayoría de los entornos ya generan.

Fuentes: cronología, marcas de tiempo, órdenes (Get-ADUser, Get-ADComputer, WinRAR, s5cmd, reg.exe add sobre SafeBoot\Network, msconfig.exe), eventos Kernel-Boot 27, Kernel-General 12, sistema 26 y Defender 3002 / 0x8007043c, detección Ransom:Win32/Akira.B!ibt con limpieza fallida 0x80004005, el agente propio afectado, la técnica T1688 con los precedentes de Snatch y AvosLocker, la cobertura parcial del EDR y las mitigaciones con su orden, además de la cita sobre el efecto secundario afortunado — Huntress, 12 de agosto de 2026, leído en su versión original y no en resúmenes. Cobertura que sitúa la ventana sin EDR en diez minutos — BleepingComputer; reproducción de la cita del efecto secundario — SC Media. Cifras del trimestre (1.988 ataques, 89 grupos, Akira cuarto con 119) y resumen de apertura sobre el apagado del EDR — informe del segundo trimestre de 2026 de Halcyon, recogido por Infosecurity Magazine. Cálculos propios: la ventana de 1 h 41 min 17 s (06:29:21 → 08:10:38) y la conversión a hora peninsular española, que Huntress no publica.