Imagen ilustrativa generada con IA
Akira deshabilita EDR y antivirus en modo seguro, pero falla al cifrar
Un afiliado del grupo de ransomware Akira comprometió una red corporativa tras obtener acceso a un dispositivo SonicWall VPN expuesto a Internet y sin
Texto generado por inteligencia artificial, publicado sin revisión humana. Transparencia IA
El acceso inicial parte de una VPN sin MFA
Un afiliado del grupo de ransomware Akira comprometió una red corporativa tras obtener acceso a un dispositivo SonicWall VPN expuesto a Internet y sin autenticación multifactor.
El incidente ocurrió el 4 de agosto de 2026. La reconstrucción publicada el 13 de agosto de 2026 muestra una cadena de ataque completada en menos de cinco horas, aunque la fase de cifrado de archivos no tuvo éxito.
La ausencia de MFA permitió al atacante superar el primer control utilizando credenciales válidas. No se sabe cómo obtuvo dichas credenciales, pero la operación incluyó actividades compatibles con el reconocimiento y el posible abuso de cuentas corporativas.
Aproximadamente dos horas después de iniciar sesión en la VPN, el intruso alcanzó el controlador de dominio mediante RDP. Desde allí enumeró los usuarios y equipos presentes en Active Directory, recopilando información útil para el movimiento lateral hacia un servidor de aplicaciones.
Active Directory, RDP y herramientas legítimas para preparar el ataque
La actividad no se limitó al acceso inicial. El atacante utilizó la información obtenida de Active Directory para desplazarse por la red e identificar sistemas y recursos compartidos de interés.
En un sistema comprometido instaló AnyDesk, utilizándolo tanto para el acceso remoto como para mantener una forma de persistencia. El software, empleado normalmente para asistencia técnica, se integró en la configuración de inicio del modo seguro de Windows.
Para recopilar los datos, el afiliado utilizó WinRAR para archivar recursos compartidos de red asignados. Después transfirió los archivos con s5cmd, un cliente para gestionar almacenamiento compatible con Amazon S3, hacia un bucket controlado por el atacante.
La secuencia combina herramientas administrativas y aplicaciones legítimas: RDP para el control remoto, herramientas de Active Directory para el reconocimiento, WinRAR para la recopilación y s5cmd para la exfiltración. Esto reduce la dependencia de malware personalizado y puede dificultar la detección basada exclusivamente en firmas.
El reinicio en modo seguro suspende Huntress y Defender
La parte más relevante del ataque fue el uso de Safe Mode with Networking para dejar temporalmente ineficaces las defensas del endpoint.
A través de AnyDesk, los atacantes reiniciaron el sistema en modo seguro y modificaron el registro asociado a los servicios de este modo. De esta manera, AnyDesk se iniciaba automáticamente después del reinicio, garantizando de nuevo el acceso remoto del atacante.
Durante el procedimiento se deshabilitaron:
- el agente Huntress MDR/EDR;
- la protección en tiempo real de Microsoft Defender.
El equipo permaneció aproximadamente 10 minutos sin un agente EDR operativo y sin protección antivirus en tiempo real. El modo seguro reduce el número de servicios y controladores cargados, lo que puede impedir el inicio de los controles de seguridad que normalmente están activos.
Sin embargo, no se trató de una desactivación permanente. Un análisis programado de Defender detectó el archivo akira.exe, pero no pudo eliminarlo mientras el sistema continuaba en modo seguro.
Tras volver al modo normal, Defender restauró la protección en tiempo real y puso la carga maliciosa en cuarentena.
El ransomware no cifra los archivos, pero el robo basta para extorsionar a la víctima
La carga maliciosa de Akira se ejecutó mediante AnyDesk en modo seguro. Su ejecución falló debido a problemas de memoria virtual, errores out-of-memory y errores relacionados con PowerShell.
El fallo de ejecución impidió cifrar los archivos, pero no anuló el impacto de la intrusión.
Antes del intento de cifrado, el atacante ya había comprometido credenciales, explorado Active Directory, accedido a otros sistemas y transferido datos a una infraestructura S3 bajo su control. Por tanto, el material sustraído puede utilizarse para amenazar con su publicación u otras formas de extorsión, incluso sin completar el bloqueo de archivos.
El caso confirma un modelo ya habitual en las operaciones de ransomware: el cifrado es solo una de las palancas disponibles. El robo de datos, el acceso persistente y la toma de control de cuentas pueden generar consecuencias concretas aunque el ransomware no consiga completar su cometido.
Según los datos promocionales del Blue Report 2026, las defensas lograrían bloquear el 37 % de las acciones cuando los atacantes utilizan credenciales válidas. El porcentaje procede de 338 millones de simulaciones realizadas en entornos de producción de clientes. El dato no describe necesariamente este incidente concreto, pero ayuda a contextualizar la ventaja obtenida por el atacante en la fase inicial.
La técnica es nueva para Akira, no para el ransomware
Huntress describió este episodio como la primera observación de la técnica de deshabilitación de defensas mediante el modo seguro en un ataque atribuido a Akira.
Sin embargo, el método no es nuevo en el sector. Familias de ransomware como Snatch y AvosLocker ya lo habrían utilizado durante años para impedir la carga de agentes EDR y protecciones antimalware durante el arranque del sistema.
En el caso de Akira, esta etapa añade una técnica de evasión a una cadena que ya incluía acceso VPN, uso de credenciales, RDP, movimiento lateral y exfiltración. El fallo técnico de la carga limitó el daño operativo, pero no impidió el robo de datos.
No se han divulgado las versiones exactas de los productos implicados.
Controles que aplicar y señales que buscar
La medida prioritaria es habilitar la MFA en todas las cuentas VPN, sin excepciones para usuarios considerados internos o privilegiados. También es necesario implementar detecciones contra el credential spraying, especialmente en servicios expuestos y portales de acceso remoto.
Los equipos de seguridad deberían supervisar:
- reinicios inusuales en Safe Mode with Networking;
- modificaciones del registro de los servicios cargados en modo seguro;
- incorporación o inicio de AnyDesk en esa configuración;
- deshabilitación del agente Huntress o de la protección en tiempo real de Defender;
- conexiones RDP hacia los controladores de dominio;
- enumeración anómala de usuarios y equipos en Active Directory;
- uso de WinRAR para crear archivos de gran tamaño;
- ejecución de s5cmd;
- transferencias hacia buckets de Amazon S3 no autorizados;
- presencia o ejecución de akira.exe.
La correlación entre estos eventos es más útil que una alerta aislada. Un reinicio en modo seguro puede tener una justificación legítima; el mismo evento asociado con la instalación de AnyDesk, una sesión RDP en el controlador de dominio y transferencias a S3 constituye una señal de compromiso de alta prioridad.
Fuentes
Este artículo es una reelaboración original basada en las siguientes fuentes.
