Se sospecha que los actores de amenazas de habla china utilizaron un dispositivo VPN SonicWall comprometido como vector de acceso inicial para implementar un exploit de VMware ESXi que podría haberse desarrollado ya en febrero de 2024.
La firma 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 provocado un ataque de ransomware.
En particular, se cree que el ataque explotó tres vulnerabilidades de VMware que Broadcom divulgó 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 satisfactoria de este problema podría permitir a un actor malintencionado con privilegios de administrador perder memoria del proceso ejecutable de máquinas virtuales (VMX) o ejecutar código como el proceso VMX.
Ese mismo mes, la Agencia de Seguridad de Infraestructura y Ciberseguridad de los Estados Unidos (CISA) añadió la falla al catálogo de vulnerabilidades explotadas conocidas (KEV), citando pruebas 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 '----' (traducido: 'Todas las versiones escapan: entrega'), y pruebas que sugieren que se creó 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 que un desarrollador con muchos recursos probablemente opere 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 un arma las tres deficiencias de VMware se basa en el comportamiento del exploit, su uso del sistema de archivos host-huésped (HGFS) para filtrar información, la interfaz de comunicación de máquinas virtuales (VMCI) para dañar la memoria y el código shell que se escapa al núcleo, añadió la empresa.
El kit de herramientas incluye varios componentes, entre los que destaca "exploit.exe" (también conocido como MAESTRO), que actúa como el orquestador de todo el escape de la máquina virtual (VM) mediante el uso de los siguientes archivos binarios incrustados:
- devcon.exe, para deshabilitar los controladores VMCI del lado invitado de VMware
- MyDriver.sys, un controlador de núcleo sin firmar que contiene el exploit que se carga en la memoria del núcleo mediante una herramienta de código abierto llamada Kernel Driver Utility ( KDU ), tras 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, permitirá al atacante escribir tres cargas útiles directamente en la memoria de VMX -
- Shellcode de fase 1, para preparar el entorno para el escape del sandbox de VMX
- Código de shell de fase 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 CALCETÍN Puerto 10000 (sockets virtuales)
«Tras escribir las cargas útiles, el exploit sobrescribe un puntero de función dentro de VMX», explica Huntress. «Primero guarda el valor original del puntero y, a continuación, lo sobrescribe con la dirección del código de shell. A continuación, el exploit envía un mensaje de VMCI al host para activar VMX».
|
| Protocolo de comunicación VSOCK entre client.exe y VSockPuppet |
«Cuando VMX gestiona el mensaje, sigue el puntero dañado y pasa al shellcode del atacante en lugar de al código legítimo. Esta fase final corresponde a la CVE-2025-22225, que VMware describe como una «vulnerabilidad de escritura arbitraria» que permite «escapar del entorno limitado».
Como 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 se puede utilizar desde cualquier máquina virtual Windows invitada del host comprometido y enviar comandos de vuelta al ESXi comprometido e interactuar con la puerta trasera. La ruta PDB integrada en el binario revela que es posible que se haya desarrollado en noviembre de 2023.
El cliente admite la capacidad de descargar archivos de ESXi a la máquina virtual, cargar archivos de la máquina virtual a ESXi y ejecutar comandos de shell en el hipervisor. Curiosamente, el complemento GetShell se instala en la máquina virtual de Windows en forma de archivo ZIP (» Binary.zip «), que también incluye un archivo README con instrucciones de uso, lo que proporciona información sobre 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 del chino simplificado, junto con la sofisticación de la cadena de ataque y el abuso de las vulnerabilidades de día cero meses antes de su divulgación pública, probablemente apunten a que un desarrollador con muchos recursos opera en una región de habla china, teorizó Huntress.
«Esta intrusión demuestra una cadena de ataques sofisticada y de varias etapas diseñada para escapar del aislamiento de las máquinas virtuales y comprometer el hipervisor ESXi subyacente», añadió la empresa. «Al encadenar una fuga de información, dañar la memoria y escapar de un entorno aislado, el actor de la amenaza logró lo que todo administrador de máquinas virtuales teme: tener el control total del hipervisor desde una máquina virtual 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».
Post generado automaticamente, fuente oficial de la información: THEHACKERNEWS