Se sospecha que los actores de amenazas de habla china han aprovechado un dispositivo VPN SonicWall comprometido como vector de acceso inicial para implementar un exploit VMware ESXi que puede haberse desarrollado ya en febrero de 2024.
La empresa de ciberseguridad Huntress, que observado La actividad en diciembre de 2025 y la detuvo antes de que pudiera avanzar a la etapa final, dijo que podría haber resultado en un ataque de ransomware.
En particular, se cree que el ataque aprovechó tres vulnerabilidades de VMware que Broadcom reveló como días cero en marzo de 2025: CVE-2025-22224 (puntuación CVSS: 9,3), CVE-2025-22225 (puntuación CVSS: 8,2) y CVE-2025-22226 (puntuación CVSS: 7,1). La explotación exitosa del problema podría permitir que un actor malintencionado con privilegios de administrador pierda memoria del proceso ejecutable de la máquina virtual (VMX) o ejecute código como el proceso VMX.
Ese mismo mes, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) agregó la falla al catálogo de Vulnerabilidades Explotadas Conocidas (KEV), citando evidencia de explotación activa.
«El conjunto de herramientas analizado […] «También incluye cadenas en chino simplificado en sus rutas de desarrollo, incluida una carpeta llamada '全版本逃逸–交付' (traducida: 'Todas las versiones de escape – entrega'), y evidencia que sugiere que fue potencialmente construido como un exploit de día cero más de un año antes de la divulgación pública de VMware, lo que apunta a un desarrollador con buenos recursos que probablemente opera en una región de habla china», dijeron los investigadores Anna Pham y Matt Anderson.
La evaluación de que el kit de herramientas convierte en arma las tres deficiencias de VMware se basa en el comportamiento del exploit, su uso del sistema de archivos Host-Guest (HGFS) para la filtración de información, la interfaz de comunicación de máquina virtual (VMCI) para la corrupción de la memoria y el código shell que se escapa al kernel, añadió la compañía.
El conjunto de herramientas incluye múltiples componentes, el principal de ellos es «exploit.exe» (también conocido como MAESTRO), que actúa como orquestador para todo el escape de la máquina virtual (VM) al hacer uso de los siguientes archivos binarios integrados:
- devcon.exe, para deshabilitar los controladores VMCI del lado invitado de VMware
- MyDriver.sys, un controlador de kernel sin firmar que contiene el exploit que se carga en la memoria del kernel mediante una herramienta de código abierto llamada Kernel Driver Utility (KDU), después de lo cual se monitorea el estado del exploit y se vuelven a habilitar los controladores VMCI
 |
| Flujo de explotación de VM Escape |
La principal responsabilidad del controlador es identificar la versión exacta de ESXi que se ejecuta en el host y activar un exploit para CVE-2025-22226 y CVE-2025-22224, lo que en última instancia permite al atacante escribir tres cargas útiles directamente en la memoria de VMX.
- Shellcode de etapa 1, para preparar el entorno para el escape de la zona de pruebas de VMX
- Shellcode de etapa 2, para establecer un punto de apoyo en el host ESXi
- VSOCKpuppet, una puerta trasera ELF de 64 bits que proporciona acceso remoto persistente al host ESXi y se comunica a través de VSOCK (Enchufes virtuales) puerto 10000
«Después de escribir las cargas útiles, el exploit sobrescribe un puntero de función dentro de VMX», explicó Huntress. «Primero guarda el valor del puntero original, luego lo sobrescribe con la dirección del código shell. Luego, el exploit envía un mensaje VMCI al host para activar VMX».
 |
| Protocolo de comunicación VSOCK entre client.exe y VSOCKpuppet |
«Cuando VMX maneja el mensaje, sigue el puntero corrupto y salta al código shell del atacante en lugar del código legítimo. Esta etapa final corresponde a CVE-2025-22225, que VMware describe como una 'vulnerabilidad de escritura arbitraria' que permite 'escapar del entorno limitado'».
Debido a que VSOCK ofrece una vía de comunicación directa entre las máquinas virtuales invitadas y el hipervisor, se ha descubierto que los actores de amenazas emplean un «client.exe» (también conocido como complemento GetShell) que puede usarse desde cualquier máquina virtual Windows invitada en el host comprometido y enviar comandos de respaldo al ESXi comprometido e interactuar con la puerta trasera. La ruta PDB incrustada en el binario revela que es posible que se haya desarrollado en noviembre de 2023.
El cliente admite la capacidad de descargar archivos desde ESXi a la VM, cargar archivos desde la VM a ESXi y ejecutar comandos de shell en el hipervisor. Curiosamente, el complemento GetShell se coloca en la máquina virtual de Windows en forma de un archivo ZIP («Binary.zip»), que también incluye un archivo README con instrucciones de uso, lo que brinda una idea de sus funciones de transferencia de archivos y ejecución de comandos.
Actualmente no está claro quién está detrás del conjunto de herramientas, pero el uso de chino simplificado, junto con la sofisticación de la cadena de ataque y el abuso de vulnerabilidades de día cero meses antes de la divulgación pública, probablemente apunta a un desarrollador con buenos recursos que opera en una región de habla china, teorizó Huntress.
«Esta intrusión demuestra una cadena de ataque sofisticada de varias etapas diseñada para escapar del aislamiento de la máquina virtual y comprometer el hipervisor ESXi subyacente», añadió la compañía. «Al encadenar una fuga de información, corrupción de memoria y escape de la zona de pruebas, el actor de amenazas logró lo que todo administrador de VM teme: control total del hipervisor desde una VM invitada».
«El uso de VSOCK para la comunicación de puerta trasera es particularmente preocupante, ya que evita por completo el monitoreo de red tradicional, lo que dificulta significativamente la detección. El conjunto de herramientas también prioriza el sigilo sobre la persistencia».
Fuente