Akira ransomware - Métodos avanzados para eludir EDR’s
Se ha descubierto una técnica novedosa que para implementar ransomware en sistemas de hipervisor Windows Hyper-V, lo que provoca Daños importantes a las máquinas virtuales conectadas ( VM’s ) por parte del grupo Akira. Incluso cuando el hipervisor basado en Windows y las máquinas virtuales de destino cuentan con herramientas destacadas de detección y respuesta de endpoints ( EDR ), se ha observado que el actor malicioso elude la protección, creando nuevas máquinas virtuales no supervisadas en el hipervisor, desde las cuales pueden navegar por directorios en el hipervisor. Y ejecutar su ransomware.
Si bien Akira aprovecha muchas técnicas de ataque conocidas, este artículo se centra en algunos métodos destacados que hemos observado.
Acceso inicial
Se tiene conocimiento de múltiples ataques de ransomware Akira que aprovechó el acceso VPN sin autenticación multifactor ( MFA ) aplicada en el punto de acceso inicial. Cisco enfatizó esto en una publicación de blog reciente.
No está comprobado el origen de las credenciales, sin embargo, en eventos similares de ransomware por parte de otros actores, creemos que Akira normalmente obtiene acceso a través de ladrones de información y mercados de credenciales.
Intrusion
Se ha observado que Akira realiza una actividad típica de ciberextorsión después del acceso inicial, que incluye, entre otros:
- Escaneo de la red usando SoftPerfect Network Scanner (netscan.exe)
- Enumeración de datos disponibles en Active Directory a través de AdFind (AdFind.exe)
- Identificar información confidencial en recursos compartidos de archivos y servidores para exfiltrarla cargándola a través de SFTP usando FileZilla
- Instalar SystemBC y crear una tarea programada para permanecer persistente.
Hemos observado que este actor de amenazas mantiene el acceso a entornos comprometidos durante varias semanas antes de lograr sus objetivos de implementar ransomware. Si bien esperamos que tengan la intención de cifrar una red completa, también hemos observado que las herramientas EDR ralentizan su progreso hacia sus objetivos finales . Una de nuestras observaciones más interesantes ha sido que el actor de amenazas inicialmente intentó desactivar EDR utilizando un controlador vulnerable.
Atacar la capa del hipervisor
Durante otras investigaciones, se han visto a los actores ejecutar su ransomware directamente en el hipervisor, que cifrará todos los archivos, incluidas las imágenes de discos virtuales, almacenados en los distintos almacenes de datos. Sin embargo, en otras situaciones creemos que el actor de la amenaza ha visto una herramienta EDR implementada, que es claramente capaz de prevenir la ejecución de su programa malicioso e incluso su evasión EDR se ha detenido con éxito. Como resultado, hemos observado que se desvían de su manual estándar y utilizan una cuenta privilegiada para iniciar una máquina virtual nueva y limpia dentro del hipervisor.
Desde la perspectiva del actor, el beneficio es que la VM que crearon tiene todo el acceso necesario a la red y ninguno de los controles de seguridad de otro host típico en la misma red.
Después de acceder a la VM, el actor deshabilitaría Windows Defender, montaría las unidades de almacenamiento de datos en el hipervisor, detendría (apagaría) las VM para liberar archivos de imagen de disco bloqueados y luego ejecutaría el ransomware. Si bien las herramientas EDR pueden detectar que el cifrado ha comenzado, generalmente no pueden bloquearlo mientras el proceso se ejecuta en la VM, lo que afectaría a las VM en un estado apagado. Como las máquinas virtuales del atacante todavía están en ejecución, no están cifradas, lo que permitió que el análisis forense reconstruyera la investigación.
Ambientes Vmware ESXI
Se ha observado que los entornos vSphere/ESXi se ven afectados por ransomware de una manera que afectaría la recuperación. En algunos casos, los actores de amenazas aplican diferentes enfoques a diferentes hosts ESXi, incluso dentro de la misma red, incluido el cifrado mediante ransomware, el cambio de la contraseña raíz o, en algunos casos, no hacer nada con el hipervisor.
En los casos en los que el actor de la amenaza no apagaba (o quizás no podía) las máquinas virtuales, sus discos estaban bloqueados y no se cifraban; sin embargo, los archivos binarios en el host ESXi aún estaban cifrados. En estos casos, el equipo de reparación tiene la oportunidad de salvar las máquinas virtuales subyacentes, pero el análisis forense del hipervisor se vería afectado.
También observamos que recientemente se han publicado informes públicos sobre una variante de Linux del ransomware Akira.
Recomendaciones
Oportunidades recomendadas de detección y caza 1. Registro y actividades del hipervisor Hyper-V
CyberCX ha compilado la siguiente tabla de registros de eventos del hipervisor basándose en algunas pruebas de validación realizadas en Windows Server 2022. Vale la pena señalar que no se generan registros después de crear un "punto de control (instantánea)" para una VM y cuando se intenta "conectar" a una VM.
2. Registro y actividades de VMware ESXi/vSphere
La actividad de auditoría de máquinas virtuales se puede revisar iniciando sesión en el host ESXi utilizando una cuenta de administrador/raíz. La actividad se registra en el archivo "hostd.log" que se encuentra aquí:
- /var/log/hostd.log
- /var/run/log/hostd.log
A continuación se muestra un extracto de nuestra instancia de prueba que demuestra la creación de una nueva máquina virtual.
Una vez que se creó la VM, hubo un cambio de estado de VM_STATE_INITIALIZING a VM_STATE_OFF.
Al realizar análisis forenses o respuesta a incidentes, puede recopilar estos registros mediante acceso SSH directo al host o generando un "paquete de soporte" que incluye los registros necesarios de /var/log en el host.
También se debería considerar habilitar syslog para reenviar automáticamente estos eventos a un SIEM o una plataforma de agregación de registros.
3. Nombres de estaciones de trabajo de Windows estándar o predeterminadas en los registros de autenticación de Windows
Cuando se configura un nuevo punto final de Windows, el nombre de host, si la organización no lo asigna manualmente, comenzará con "WIN-" o "DESKTOP-" o "PC-" o "WORKSTATION-". La mayoría de los actores de ransomware que hemos visto utilizan estos valores predeterminados, que posteriormente terminan en registros de eventos. Una revisión de los registros de autenticación de seguridad en Windows (ID de evento 4624/4625) puede mostrar accesos intentados o exitosos. Además, si estos intentos de autenticación tienen una dirección IP de su grupo de direcciones VPN, puede indicar que hay un dispositivo no administrado conectado.
Esto también se puede observar en los registros de eventos relacionados con el recurso compartido de archivos SMB y Escritorio remoto.
Referencias
https://cybercx.com.au/blog/akira-ransomware/
.jpg)
