Ransomware en ESXi: Análisis de Campañas Reales que Paralizan Infraestructuras

ESXi: el target de máximo impacto

Un servidor ESXi típico en una empresa mediana aloja 20-50 máquinas virtuales: servidores de archivos, bases de datos, controladores de dominio, servidores web, email. Cifrar un solo ESXi equivale a cifrar toda esa infraestructura de golpe.

Los grupos de ransomware lo saben. Desde 2020, desarrollar una variante ESXi/Linux es un requisito implícito para cualquier programa RaaS serio. El patrón de ataque es consistente: comprometer la red Windows (phishing, exploit, credenciales), escalar a Domain Admin, pivotar al segmento de virtualización, y desplegar el ransomware Linux directamente en los hosts ESXi.

Vectores de acceso a ESXi

Vulnerabilidades en ESXi/vCenter

CVE	Producto	Descripción	Campañas
CVE-2021-21974	ESXi OpenSLP	Heap overflow en OpenSLP, RCE sin autenticación	ESXiArgs (2023)
CVE-2024-37085	vCenter Server	Authentication bypass en Active Directory integration	Múltiples grupos 2024
CVE-2022-31696	ESXi	Heap overflow en USB controller	PoC público
CVE-2023-34048	vCenter Server	Out-of-bounds write, RCE	Explotado in-the-wild

Acceso via red corporativa comprometida

El vector más común no es un exploit en ESXi sino movimiento lateral desde la red Windows:

1. Compromiso inicial de red Windows (phishing, VPN exploit)
2. Escalada a Domain Admin
3. Identificar vCenter/ESXi en la red (nmap, credenciales en Veeam)
4. Login en vCenter con credenciales de AD (si integrado)
5. Habilitar SSH en ESXi via vCenter
6. SCP del ransomware binario al host ESXi
7. Ejecutar el ransomware via SSH

SSH con credenciales débiles

ESXi tiene SSH deshabilitado por defecto, pero muchos administradores lo habilitan para gestión. Si la contraseña de root es débil o compartida con cuentas de AD comprometidas, el acceso es trivial.

Anatomía del ataque: qué hace el ransomware en ESXi

Secuencia de ejecución típica

# 1. Enumerar VMs en ejecucion
esxcli vm process list

# 2. Detener todas las VMs (imprescindible para cifrar VMDKs que estan en uso)
for vmid in $(vim-cmd vmsvc/getallvms | awk '{print $1}' | tail -n+2); do
    vim-cmd vmsvc/power.off $vmid
done
# Alternativa brutal:
esxcli vm process kill --type=force --world-id=[ID]

# 3. Cifrar archivos VMDK, VMEM, VSWP, VMX, VMSN
./ransomware_binary --path /vmfs/volumes/ --ext vmdk,vmem,vswp,vmx,vmsn

# 4. Dejar nota de rescate
echo "Your VMs have been encrypted..." > /vmfs/volumes/datastore1/README_TO_RESTORE.txt

# 5. Modificar MOTD/pagina web de ESXi
# Algunos modifican /etc/motd o la pagina HTML del ESXi web client

Archivos objetivo

Extensión	Contenido	Impacto si se cifra
.vmdk	Disco virtual (Virtual Machine Disk)	VM completamente inutilizable
.vmx	Configuración de la VM	VM no puede arrancarse
.vmem	Memoria de VM suspendida	Datos en memoria perdidos
.vswp	Swap de la VM	Datos de swap perdidos
.vmsn	Snapshot de la VM	Snapshots inutilizables
.nvram	BIOS/UEFI settings de la VM	Configuración de boot perdida
.vmsd	Metadata de snapshots	Árbol de snapshots perdido
-flat.vmdk	Extensión del dato real del disco	Contenido real del disco virtual

Cifrado parcial en ESXi

Muchas familias usan cifrado parcial para maximizar velocidad:

Archivo VMDK de 500 GB:
- Cifrado completo: ~30 minutos (dependiendo de I/O)
- Cifrado parcial (primeros 1 MB): ~1 segundo

Con 30 VMs de 500 GB cada una:
- Completo: ~15 horas
- Parcial: ~30 segundos

El cifrado parcial es la norma en ESXi.

El cifrado parcial deja la mayor parte del VMDK intacto pero el header queda corrupto, haciendo que VMware no pueda montar el disco.

Familias con variantes ESXi

Familia	Lenguaje	Cifrado	Particularidades ESXi
LockBit	C	AES-256-CTR + RSA	Muy rápido, cifrado intermitente
BlackCat/ALPHV	Rust	AES/ChaCha20 + RSA	Cross-platform nativo, configurable
Babuk	C/Go	ChaCha20 + Curve25519	Código fuente filtrado, base de muchas variantes
Hive	Go/Rust	ChaCha20 + RSA	Variante Go y Rust separadas
Royal/BlackSuit	C++	AES/ChaCha20 + RSA	Mismo binario Linux sirve para ESXi
Akira	Rust	ChaCha20 + RSA	Variante "Megazord" para ESXi
Black Basta	C++	ChaCha20	Detiene VMs con esxcli
RansomHub	Go	AES + RSA	Variante ESXi activa 2024-2025

Babuk ESXi: la madre de muchas variantes

Babuk publicó su código fuente en 2021. La variante ESXi (escrita en Go) se convirtió en la base de múltiples familias:

• Mario (basado en Babuk ESXi)
• Qilin (basado en Babuk ESXi)
• SolidBit (basado en Babuk ESXi)
• Decenas de variantes menores

Campaña ESXiArgs (febrero 2023)

Qué ocurrió

En febrero de 2023, una campaña automatizada explotó CVE-2021-21974 (vulnerabilidad en OpenSLP de ESXi) para desplegar ransomware en miles de servidores ESXi expuestos a Internet:

Aspecto	Detalle
Vulnerabilidad	CVE-2021-21974 (OpenSLP heap overflow, parcheada en febrero 2021)
Servidores afectados	Más de 3.000 en los primeros días
Automatización	Completamente automatizado (scan + exploit + deploy)
Rescate	2 BTC (~40.000 USD al momento)
Cifrado	Parcial (primeros MB de VMDKs)
Recuperación	CISA publicó script de recuperación para muchos casos

Script de recuperación de CISA

CISA publicó un script que aprovechaba el hecho de que ESXiArgs cifraba parcialmente los VMDKs:

# El script de CISA reconstruia la estructura del VMDK
# usando los datos no cifrados del flat-vmdk
# y recreando el descriptor VMDK

# Funcionaba porque ESXiArgs solo cifraba:
# 1. El descriptor VMDK (archivo .vmdk pequeno)
# 2. Los primeros bytes del flat-vmdk

# El contenido real de la VM (flat-vmdk) estaba en su mayoria intacto

La recuperación no funcionaba en todos los casos: si el VMDK estaba thin-provisioned y los primeros bloques contenían la tabla de particiones/filesystem, la VM podía no ser recuperable.

Detección de ransomware en ESXi

Indicadores en ESXi

Indicador	Método de detección
SSH habilitado inesperadamente	vCenter alerts, ESXi shell.log
Múltiples VMs apagándose simultáneamente	vCenter events, SNMP traps
Proceso desconocido consumiendo I/O	esxtop, vobd.log
Archivos con extensión nueva en datastores	Monitorización de datastores
Nota de rescate en datastores	File monitoring
MOTD o web UI modificados	Monitorización de integridad
Conexiones SSH desde IPs internas inusuales	Logs de SSH (/var/log/auth.log)

Logs relevantes en ESXi

# Logs de autenticacion
/var/log/auth.log         # SSH logins
/var/log/hostd.log        # vSphere API access
/var/log/vpxa.log         # vCenter Agent

# Logs de actividad
/var/log/shell.log        # Comandos ejecutados en ESXi shell
/var/log/vobd.log         # VMkernel observations
/var/log/vmkernel.log     # Kernel messages

# Verificar actividad reciente
grep -i "ssh" /var/log/auth.log | tail -20
grep -i "power" /var/log/hostd.log | tail -20
cat /var/log/shell.log | tail -50

Defensa de infraestructura ESXi

Hardening ESXi

Medida	Prioridad	Implementación
Parchear ESXi regularmente	Critica	VMware Update Manager, lifecycle manager
Deshabilitar SSH cuando no se use	Critica	ESXi Advanced Settings: SSH.start = false
Deshabilitar OpenSLP	Critica	/etc/init.d/slpd stop + deshabilitar en startup
Segmentar red de virtualización	Critica	VLAN separada, firewall entre corp y vSphere
MFA en vCenter	Alta	Integración con AD + MFA (Duo, Azure MFA)
Backups de VMs offline/inmutables	Critica	Veeam con Hardened Repository
Lockdown mode	Alta	Restringe acceso directo al host ESXi
Limitar acceso al ESXi firewall	Alta	Solo IPs de gestión permitidas
vCenter separado de AD	Media	Cuenta local de admin, no depender solo de AD
Monitorización de VMs	Alta	Alertas en apagados masivos, acceso SSH

Backup de VMs

La protección más importante contra ransomware ESXi son backups inmutables de las VMs:

Veeam + Hardened Repository (Linux)
  └── Backup diario de todas las VMs
  └── Inmutable (no se puede eliminar durante retention period)
  └── En red separada del segmento de virtualización
  └── Testing trimestral de restauración

Alternativa: Veeam + S3 Object Lock (AWS/Wasabi)
  └── Backup offsite en cloud con inmutabilidad

Plan de respuesta para ESXi

1. DETECTAR: alerta de VMs apagandose masivamente
2. CONTENER: 
   - Aislar el segmento de virtualizacion del resto de la red
   - NO apagar los hosts ESXi (preservar memoria para forense)
   - Deshabilitar SSH en hosts no afectados
3. EVALUAR:
   - Cuantos hosts afectados
   - Cifrado parcial o completo
   - Backups disponibles y verificados
4. RECUPERAR:
   - Si cifrado parcial: intentar recuperacion con herramientas de reconstruccion VMDK
   - Si backups disponibles: restaurar VMs por prioridad (AD, DNS, DB, apps criticas)
   - Si ni backups ni recuperacion parcial: evaluar pago (ultimo recurso)
5. INVESTIGAR:
   - Como accedieron (credenciales, exploit, lateral)
   - Parchear vector de entrada
   - Cambiar todas las credenciales de vSphere/ESXi

Mapeo MITRE ATT&CK

Técnica	ID	Contexto ESXi
Exploit Public-Facing Application	T1190	CVE-2021-21974, CVE-2024-37085
Remote Services: SSH	T1021.004	SSH al host ESXi
Data Encrypted for Impact	T1486	Cifrado de VMDKs
Inhibit System Recovery	T1490	Eliminación de snapshots VMware
Service Stop	T1489	Apagar VMs antes de cifrar
Valid Accounts	T1078	Credenciales de vCenter/AD

---

Fuentes y referencias

• VMware. "VMSA-2021-0002: ESXi OpenSLP Vulnerability." VMware Security Advisory.
• CISA. "ESXiArgs Ransomware: Recovery Guidance." CISA Alert, February 2023.
• Mandiant. "Ransomware Targeting VMware ESXi." Mandiant Intelligence, 2024.
• CrowdStrike. "ESXi Ransomware Campaigns." 2024 Global Threat Report.
• Sophos. "ESXi Ransomware Analysis." SophosLabs, 2024.
• Trend Micro. "Linux/ESXi Ransomware Landscape." Trend Micro Research, 2024.
• MITRE ATT&CK. "Data Encrypted for Impact (T1486)." https://attack.mitre.org/techniques/T1486/
• VMware. "ESXi Security Configuration Guide." VMware Docs.