Se sospecha que los actores de amenazas de habla china han utilizado 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 observó la actividad en diciembre de 2025 y la detuvo antes de que pudiera llegar a la etapa final, dijo que pudo haber sido un ataque de ransomware.
Específicamente, se cree que el ataque aprovechó tres vulnerabilidades de VMware reveladas por Broadcom como vulnerabilidades de día 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 administrativos pierda memoria del proceso ejecutable de la máquina virtual (VMX) o ejecute código como un proceso VMX.
Ese mismo mes, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) añadió la falla al catálogo de vulnerabilidades explotadas conocidas (KEV), citando evidencia de explotación activa.
“El kit de herramientas analizado (…) también contiene cadenas de chino simplificadas en sus rutas de desarrollo, incluida una carpeta llamada '全版本逃逸–交付' (traducida: 'Todas las versiones escaparon – entrega'), e indicaciones de que pudo haber sido creado como un exploit de día cero más de un año antes de que VMware lo lanzara, lo que sugiere que un desarrollador con buenos recursos probablemente estaba operando 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 las tres fallas de VMware en un arma se basa en el comportamiento del exploit, su uso del sistema de archivos Host-Guest (HGFS) para fugas de información, la interfaz de comunicación de máquina virtual (VMCI) para corrupción de memoria y el código shell que ingresa al kernel, agregó la compañía.
El kit de herramientas incluye varios componentes, en particular exploit.exe (también conocido como MAESTRO), que actúa como orquestador para todo el escape de la máquina virtual (VM) aprovechando 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, se carga en la memoria del kernel usando una herramienta de código abierto llamada Kernel Driver Utility (KDU), que luego monitorea el estado del exploit y vuelve a habilitar los controladores VMCI.
 |
| Flujo de explotación de escape de VM |
La tarea principal 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, que en última instancia permite al atacante escribir tres cargas útiles directamente en la memoria de VMX:
- Shellcode de nivel 1 para preparar el entorno para el escape de la zona de pruebas de VMX
- Shellcode de nivel 2 para afianzarse 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 del puerto 10000 VSOCK (Virtual Sockets).
“Después de escribir la carga útil, el exploit sobrescribe un puntero de función en VMX”, explicó Huntress. “Primero almacena el valor del puntero original y 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 procesa 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 un 'escape de la zona de pruebas'”.
Debido a que VSOCK proporciona una ruta de comunicación directa entre las máquinas virtuales invitadas y el hipervisor, se descubrió que los actores de la amenaza estaban usando un “client.exe” (también conocido como complemento GetShell) que puede ser utilizado por cualquier máquina virtual invitada de Windows en el host comprometido, enviando comandos de regreso al ESXi comprometido e interactuando con la puerta trasera. La ruta PDB incrustada en el binario muestra 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 contiene un archivo README con instrucciones de uso que brindan información sobre sus capacidades 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 del lanzamiento, probablemente sugiere que se trata de un desarrollador con buenos recursos que opera en una región de habla china, sospecha Huntress.
“Esta infracción demuestra una cadena de ataque sofisticada de varias etapas diseñada para evitar el aislamiento de la máquina virtual y comprometer el hipervisor ESXi subyacente”, añadió la empresa. “Al encadenar fugas de información, corrupción de memoria y escapes de la zona de pruebas, el actor de amenazas logró lo que todo administrador de VM teme: control completo del hipervisor desde una VM invitada”.
“El uso de VSOCK para comunicaciones de puerta trasera es particularmente preocupante porque 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”.
About The Author
