# Akira ransomware fracasó al usar Safe Mode para evadir EDR — la memoria limitada del sistema anuló el cifrado

Un afiliado del grupo logró desactivar las defensas durante diez minutos, pero el entorno reducido de Windows impidió que el encriptador completara su ejecución

El 4 de agosto, un operador de Akira ransomware ingresó a una red corporativa a través de una VPN SonicWall sin autenticación multifactor, robó credenciales y archivos compartidos, y reinició el host comprometido en Safe Mode with Networking para desactivar el EDR antes de lanzar el encriptador. La estrategia funcionó contra las defensas. No funcionó contra el propio ransomware. Huntress documentó el caso como la primera vez que observa a Akira usando Safe Mode para evadir controles de seguridad, una técnica que grupos como Snatch y AvosLocker han empleado durante años. La diferencia es que en este incidente el entorno de memoria restringida del modo seguro provocó que akira.exe agotara la memoria virtual disponible apenas 13 segundos después de ejecutarse, abortando el proceso de cifrado antes de que pudiera completarse.

Cómo el atacante preparó el sistema para sobrevivir al reinicio sin defensas

El acceso inicial por VPN se registró a las 03:52 UTC. Durante las dos horas siguientes no hubo actividad visible, hasta que el operador estableció una sesión RDP al controlador de dominio y ejecutó enumeración de PowerShell para volcar todos los usuarios y computadoras de Active Directory, deshabilitando el truncamiento para capturar cada pertenencia a grupos. Los datos se archivaron con WinRAR usando las mismas banderas documentadas en campañas previas de Akira, y se subieron a un bucket S3 controlado por los atacantes mediante s5cmd. La exfiltración ocurrió antes de cualquier intento de cifrado, lo que significa que la víctima quedó expuesta a extorsión incluso cuando el ransomware falló.

Antes de reiniciar el host, el atacante agregó AnyDesk al registro de Safe Mode. Esto garantizó que su acceso remoto sobreviviera al reinicio, mientras que el EDR y la protección en tiempo real de Windows Defender quedaron deshabilitados. Durante aproximadamente diez minutos, el sistema operó sin defensas activas. El plan era ejecutar akira.exe en ese intervalo, con el EDR fuera de línea y sin capacidad de detección en tiempo real.

Por qué Safe Mode anuló el cifrado en lugar de facilitarlo

El proceso akira.exe se ejecutó a las 06:34:29 UTC y generó sus procesos secundarios a las 06:36:21 UTC. Aproximadamente 13 segundos después del lanzamiento, el host comenzó a generar errores de memoria. Safe Mode arranca con un entorno reducido y memoria virtual limitada, y el árbol de procesos de Akira aparentemente la agotó, provocando ventanas emergentes de «Out of Virtual Memory» y una cascada de errores de PowerShell que coincidieron exactamente con el momento en que el payload intentó iniciar el cifrado.

Windows Defender detectó akira.exe como Ransom:Win32/Akira.B!ibt después de un escaneo programado, pero no pudo ponerlo en cuarentena mientras la protección en tiempo real estaba deshabilitada en Safe Mode. El archivo solo se eliminó después de que el atacante reinició el sistema de vuelta al modo normal, restaurando las protecciones de Defender. En ese punto, su propio movimiento anti-EDR se deshizo a sí mismo.

El patrón que Snatch y AvosLocker ya habían explotado durante años

Huntress señala que Snatch y AvosLocker han abusado de Safe Mode durante años, pero esta es la primera vez que la compañía observa a Akira usando la técnica. La diferencia es que esos grupos aparentemente ajustaron sus encriptadores para operar dentro de las restricciones de memoria del modo seguro, mientras que Akira no lo hizo. El caso sugiere que los desarrolladores de Akira podrían reducir la huella de memoria del payload para hacer que los lanzamientos en Safe Mode sean confiables, lo que significa que el mismo fallo afortunado no necesariamente se repetirá en futuros incidentes.

La guía de detección que Huntress proporciona es específica: alertar sobre actividad de msconfig.exe o bcdedit, monitorear Kernel-Boot Event ID 27 con una opción de carga SAFEBOOT, Kernel-General Event ID 12 con BootMode=2, y servicios de terceros deteniéndose. También recomienda vigilar herramientas de acceso remoto que se agregan al registro de servicios de Safe Mode, porque esa es la señal de que el operador planea mantener acceso a través del reinicio.

Qué significa para organizaciones en México y Brasil que dependen de VPN sin MFA

El vector de entrada en este caso fue una VPN SonicWall sin autenticación multifactor. En México y Brasil, sectores como manufactura, logística y servicios financieros operan con infraestructura de acceso remoto heredada que frecuentemente carece de MFA, especialmente en implementaciones de sucursales o plantas industriales donde la prioridad histórica fue disponibilidad sobre seguridad. El caso de Akira muestra que un solo punto de acceso sin MFA puede sostener una cadena de ataque completa, desde enumeración de Active Directory hasta exfiltración masiva, incluso si el cifrado final falla.

La exfiltración previa al cifrado es el detalle que convierte un fallo técnico en un problema de extorsión igual de grave. Los datos ya estaban en manos del atacante antes de que akira.exe intentara ejecutarse. Para organizaciones en América Latina que operan con presupuestos de seguridad ajustados y equipos pequeños, la lección es que la defensa no puede depender de que el ransomware falle por limitaciones técnicas del atacante. La ventana de diez minutos sin EDR activo fue suficiente para completar la exfiltración, y eso es lo que finalmente importa en un modelo de doble extorsión.

Nuestro análisis

Este incidente revela un patrón de adaptación táctica en el ecosistema de ransomware: Akira está adoptando técnicas que Snatch y AvosLocker ya habían refinado, pero sin el ajuste técnico necesario para que funcionen de manera confiable. La diferencia entre un fallo y un cifrado exitoso en este caso fue la cantidad de memoria virtual disponible en Safe Mode. Un host con más RAM física o un archivo de paginación más grande podría haber dado a akira.exe suficiente memoria virtual para cifrar el endpoint en modo seguro. Los desarrolladores de Akira podrían retoolear el encriptador para reducir sus demandas de memoria o hacer que su secuencia de lanzamiento en Safe Mode sea más confiable, lo que significa que el mismo fallo puede no ocurrir en una intrusión futura.

El detalle incómodo es que Safe Mode cegó los controles de seguridad, pero también pudo haber prevenido el cifrado que estaba destinado a habilitar. Eso es un efecto secundario afortunado del error del atacante en estas circunstancias, no una defensa que se pueda planificar. La detección tiene que ocurrir antes del reinicio, cuando msconfig.exe o bcdedit se ejecutan, o cuando herramientas de acceso remoto se agregan al registro de Safe Mode. Una vez que el sistema arranca en modo seguro, las defensas tradicionales ya no están operativas. ¿Qué pasaría si Akira ajusta su encriptador para operar dentro de las restricciones de memoria de Safe Mode, convirtiendo un fallo técnico en una ventaja táctica permanente?