El gran escape de VM: explotación de ESXi en el entorno real

Antecedentes 

En diciembre de 2025, Huntress observó una intrusión que condujo al despliegue de exploits de VMware ESXi.

Con base en los indicadores que observamos, incluido el nombre de la estación de trabajo desde la que operaba el actor de amenazas y otras TTP, el equipo de Respuesta Táctica de Huntress evalúa con alta confianza que el acceso inicial ocurrió a través de una VPN de SonicWall.

El kit de herramientas analizado en este reporte también incluye cadenas en chino simplificado en sus rutas de desarrollo, incluida una carpeta llamada “全版本逃逸--交付” (traducido: “Escape de todas las versiones - entrega”), y evidencia que sugiere que fue construido potencialmente como un exploit zero-day 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.

Dada la naturaleza de la explotación de ESXi, esta actividad pudo haber culminado en un ataque de ransomware como objetivo final, pero fue detenida por el equipo de Respuesta Táctica de Huntress y el Centro de Operaciones de Seguridad (SOC). A continuación, un resumen de nuestras observaciones.

Puntos clave

• El acceso inicial probablemente fue a través de VPN. A pesar de la sofisticación del escape de VM, los atacantes entraron a través de una VPN de SonicWall comprometida. Lo básico sigue importando.
• El aislamiento de VM no es absoluto. Las vulnerabilidades del hipervisor pueden permitir que los atacantes escapen de las VM invitadas y comprometan todas las cargas de trabajo en un host.
• Parchea ESXi de forma agresiva. Este kit de herramientas de exploits es compatible con 155 compilaciones de ESXi que abarcan las versiones 5.1 a 8.0. Si estás ejecutando versiones fuera de soporte, estás expuesto sin solución disponible.
• El monitoreo de red tiene puntos ciegos. El tráfico VSOCK entre las VM y el hipervisor es invisible para los firewalls y los IDS. Monitorea procesos inusuales en los hosts ESXi directamente usando “lsof -a”.
• Presta atención a las técnicas BYOD. El uso de KDU para cargar controladores sin firmar evita la aplicación de firma de controladores. Monitorea la carga de controladores vulnerables conocidos.

¿Qué pasó?

Controlador de dominio de respaldo

El actor de amenazas (TA) se movió lateralmente aprovechando la cuenta comprometida de Administrador de Dominio (DA) hacia el controlador de dominio de respaldo mediante RDP. El TA intentó cambiar la contraseña del DA a Password01$ mediante Impacket, pero el intento fue evitado por Microsoft Defender for Endpoint (MDE) administrado por Huntress.

Se desplegaron las siguientes herramientas de reconocimiento:

• C:\Users\<username>\Downloads\Advanced_Port_Scanner_2.5.3869.exe
• C:\Program Files\SoftPerfect Network Scanner\netscan.exe

Luego, el TA ejecutó ShareFinder para enumerar los recursos compartidos de red, exportando los resultados a C:\ProgramData\shares.txt.

Controlador de dominio primario

Usando la misma cuenta DA comprometida, el TA se movió lateralmente hacia el controlador de dominio primario y desplegó el kit de herramientas de exploit de VMware ESXi. Aproximadamente 20 minutos después, modificaron el firewall de Windows para aislar el host de redes externas mientras preservaban la conectividad interna con los siguientes comandos:

• netsh advfirewall firewall add rule "name=Allow Local Network-2" dir=out action=allow remoteip=10.x.x.x/8 profile=any
• netsh advfirewall firewall add rule "name=Block External Outbound" dir=out action=block remoteip=0.0.0.0-255.255.255.255 profile=any
• netsh advfirewall firewall add rule "name=Allow Local Network-3" dir=out action=allow remoteip=172.x.x.x/12 profile=any

Estas modificaciones de firewall se observan comúnmente en intrusiones para evitar que la víctima acceda a recursos externos en busca de ayuda o que las herramientas de seguridad se comuniquen hacia afuera, mientras permiten que el atacante siga moviéndose lateralmente a través de redes internas para maximizar el radio de impacto del compromiso.

Tras los cambios de firewall, el TA comenzó a preparar los datos para exfiltración usando WinRAR:

• “C:\Program Files\WinRAR\WinRAR.exe” a -ep1 -scul -r0 -iext -imon1 -- . “Mapped Network Share”

Los comandos de explotación:

• devcon.exe disable “PCI\VEN_15AD&DEV_0740”- deshabilita el dispositivo PCI VMCI de VMware para obtener acceso directo al hardware
• devcon.exe disable “ROOT\VMWVMCIHOSTDEV” - deshabilita el controlador host de VMCI de VMware
• kdu.exe -prv 1 -map MyDriver.sys - aprovecha Kernel Driver Utility (KDU) para evitar la aplicación de firma de controladores y cargar el controlador de exploit sin firmar en la memoria del kernel
• exploit.exe (MAESTRO) orquesta el ataque de escape de VM e instala una puerta trasera en el hipervisor ESXi

Vulnerabilidades potencialmente explotadas

El 4 de marzo de 2025, VMware publicó el aviso de seguridad VMSA-2025-0004 que aborda tres vulnerabilidades reportadas por Microsoft Threat Intelligence Center. Las tres fueron confirmadas como explotadas en el entorno real:

• CVE-2025-22226 (CVSS 7.1): Una lectura fuera de límites en HGFS que permite filtrar memoria del proceso VMX
• CVE-2025-22224 (CVSS 9.3): Una vulnerabilidad TOCTOU en VMCI que lleva a una escritura fuera de límites, permitiendo la ejecución de código como el proceso VMX
• CVE-2025-22225 (CVSS 8.2): Una vulnerabilidad de escritura arbitraria en ESXi que permite escapar del sandbox de VMX hacia el kernel

Con base en nuestro análisis del comportamiento del exploit, su uso de HGFS para la filtración de información, VMCI para la corrupción de memoria y shellcode que escapa hacia el kernel, el equipo de Respuesta Táctica de Huntress evalúa con confianza moderada que este kit de herramientas aprovecha estos tres CVE.

¿Qué es VMX?

VMX (Virtual Machine Executable) es un proceso que se ejecuta en el host ESXi por cada máquina virtual. Según la documentación de VMware, VMX es “responsable de manejar E/S hacia dispositivos que no son críticos para el rendimiento” y de “comunicarse con interfaces de usuario, administradores de instantáneas y la consola remota”. Esto incluye funciones como el uso compartido del portapapeles, arrastrar y soltar, y la comunicación de VMware Tools, exactamente las funciones a las que apunta este exploit.

Cada VM en ejecución tiene su propio proceso VMX. Desde la perspectiva de un atacante, VMX es el primer objetivo para un escape de VM porque procesa entradas no confiables provenientes del invitado. Sin embargo, VMX se ejecuta dentro de un sandbox en ESXi, por lo que comprometerlo requiere un paso adicional para obtener acceso completo al host.

Herramientas de explotación de VMware

Figura 1: Flujo de explotación del escape de VM

Si este diagrama de flujo te está mareando, no te preocupes, sigue conmigo y, con suerte, al final todo tendrá sentido. Los colores no representan nada específico, solo están ahí para hacer el flujo más fácil de seguir.

Orquestación del exploit

exploit.exe (MAESTRO)

El binario exploit.exe, al que llamamos MAESTRO, actúa como el orquestador de todo el ataque de escape de VM. No contiene la lógica de explotación real; en cambio, prepara el entorno, despliega el controlador de exploit, monitorea el progreso y limpia después.

El ejecutable contiene 4 binarios incorporados en los recursos:

• MyDriver.sys - Controlador de kernel sin firmar que contiene el exploit de escape de VM
• kdu.exe - Kernel Driver Utility (herramienta de carga BYOD)
• devcon.exe - Microsoft Device Console, una utilidad de gestión de dispositivos
• drv64.dll - Biblioteca de soporte de KDU

Figura 2: Función principal de Maestro que muestra la secuencia completa del ataque

Fase 1: Deshabilitar los controladores VMCI de VMware

El exploit comienza deshabilitando los controladores VMCI del lado invitado de VMware usando la utilidad devcon.exe de Microsoft. Se deshabilitan dos instancias de dispositivo:

• PCI\VEN_15AD&DEV_0740 - El dispositivo PCI VMCI de VMware (Proveedor 0x15AD = VMware, Dispositivo 0x0740 = VMCI)
• ROOT\VMWVMCIHOSTDEV - El controlador del dispositivo host VMCI de VMware

¿Qué es VMCI?

La interfaz de comunicación de máquina virtual (VMCI) de VMware es un mecanismo de comunicación de alta velocidad que facilita la comunicación entre una máquina virtual y su host ESXi, y la comunicación directa entre máquinas virtuales en el mismo host.

¿Por qué deshabilitar el controlador VMCI? 

El controlador de exploit necesita comunicarse directamente con el hardware de VMCI usando instrucciones de puerto de E/S de bajo nivel. Si analizamos “MyDriver.sys” (el controlador malicioso), después de localizar el dispositivo VMCI en el bus PCI, lee el Registro de Dirección Base del dispositivo (BAR0) para obtener la dirección base del puerto de E/S.

Figura 3: Escaneo del bus PCI en busca del dispositivo VMCI

Una vez que el exploit obtiene la dirección BAR0, usa instrucciones x86 “IN/OUT” para comunicarse directamente con los registros de hardware de VMCI:

Cuando vmci.sys está cargado, posee el adaptador VMCI y usa activamente estos mismos puertos de E/S. Dos controladores no pueden compartir de forma segura el mismo hardware; si ambos intentan enviar comandos simultáneamente, corromperían el estado del dispositivo y bloquearían el sistema. Al deshabilitar vmci.sys primero, el exploit obtiene acceso exclusivo al hardware de VMCI.

Carga del controlador sin firmar mediante BYOD

Dado que “MyDriver.sys” no está firmado, no puede cargarse por medios normales en sistemas con la aplicación de firma de controladores (DSE) habilitada. El exploit usa KDU (Kernel Driver Utility), una herramienta de código abierto para cargar controladores sin firmar en la memoria del kernel.

• kdu.exe -prv 1 -map MyDriver.sys, donde:
• prv 1 - Usa el proveedor #1, un controlador legítimamente firmado pero vulnerable
• map - Mapea manualmente el controlador sin firmar en la memoria del kernel

KDU explota una vulnerabilidad en el controlador firmado para obtener ejecución de código a nivel de kernel, y luego usa ese acceso para cargar MyDriver.sys. La espera de 6 segundos después de la ejecución le da tiempo al controlador para inicializarse y comenzar el proceso de explotación.

Monitoreo del progreso del exploit

Una vez cargado, MyDriver.sys crea un objeto de dispositivo accesible a través del enlace simbólico \\.\TDLD (Figura 2). El orquestador (exploit.exe) abre este dispositivo y lo consulta cada 4 segundos; cuando el controlador devuelve el valor de estado 2, la explotación se completa y el bucle termina.

Restauración de los controladores de VMware

Tras una explotación exitosa (estado == 2), el orquestador vuelve a habilitar los controladores VMCI de VMware. Esta restauración probablemente sirve como seguridad operacional: la VM sigue funcionando normalmente con VMware Tools operativo, reduciendo las sospechas de que haya ocurrido algo malicioso.

El controlador de exploit

MyDriver.sys

Con la capa de orquestación ya entendida, profundicemos en MyDriver.sys, el controlador de kernel que realiza el escape de VM real. Este controlador contiene la siguiente lógica de explotación principal:

• Comunicación por puerta trasera de VMware para recopilación de información
• Manipulación del hardware VMCI para desencadenar vulnerabilidades
• Lectura y escritura de la memoria del proceso VMX
• Despliegue de shellcode en ESXi

Antes de que pueda comenzar la explotación, el controlador necesita identificar la versión exacta de ESXi que se ejecuta en el host. Diferentes compilaciones de ESXi tienen diferentes diseños de memoria, por lo que el exploit requiere desplazamientos específicos de la versión. El controlador consulta la versión del host ESXi usando el comando documentado del SDK de invitados de VMware “guestlib.stat.get text session”. Este comando, normalmente usado por VMware Tools y agentes de terceros con fines de monitoreo, devuelve información del host, incluida la cadena exacta de la versión de ESXi (por ejemplo, “VMware ESX 8.0.0 build-24022510”). El exploit analiza esta respuesta para extraer la versión y el número de compilación.

Figura 4: Consulta al host usando el comando del SDK de invitados de VMware

Una vez identificados la versión y el número de compilación de ESXi, el controlador busca en una tabla de desplazamientos precalculados específicos de esa compilación. El exploit incorpora una tabla fija que contiene 155 compilaciones de ESXi compatibles, abarcando las versiones 5.1 a 8.0.

Figura 5: Búsqueda de los desplazamientos

Cada entrada almacena el número de compilación y 17 desplazamientos específicos de versión necesarios para localizar las estructuras del proceso VMX. Estos desplazamientos cambian entre compilaciones de ESXi debido a modificaciones de código y variaciones del compilador. Si la compilación detectada no está en la tabla, la explotación falla, una limitación común de los exploits basados en desplazamientos.

Filtración de la dirección base de VMX

Con los desplazamientos específicos de versión cargados, el siguiente paso es filtrar la dirección base del proceso VMX para evitar el ASLR. Dado que la tabla de desplazamientos contiene desplazamientos relativos en lugar de direcciones absolutas, el exploit debe determinar dónde se carga VMX en la memoria antes de poder calcular las ubicaciones exactas para escribir shellcode y corromper estructuras. La siguiente función realiza una secuencia de operaciones de puerta trasera relacionadas con HGFS para desencadenar una divulgación de información.

Figura 6: Preparando la filtración de información: configurando la información del invitado, habilitando arrastrar y soltar, y abriendo canales de puerta trasera

La función realiza una secuencia de operaciones de puerta trasera relacionadas con HGFS para desencadenar una divulgación de información. La función comienza asignando un búfer de 64 KB y seleccionando un tamaño de mensaje según la versión de ESXi. Para ESXi 5.x y 6.x, el tamaño del mensaje es de 50616 bytes. Para ESXi 7.0 y 8.0, es de 50624 bytes. Luego, una serie de comandos RPC configuran el estado de VMware Tools dentro del proceso VMX:

El comando crítico es tools.capability.hgfs_server toolbox-dnd 1, que habilita la función de transferencia de archivos mediante arrastrar y soltar entre el host y el invitado. Esta funcionalidad es parte del Sistema de Archivos Host-Invitado (HGFS) de VMware y es lo que permite a los usuarios arrastrar archivos desde su escritorio a una ventana de VM. Según el aviso de seguridad VMSA-2025-0004 de VMware, CVE-2025-22226 es una vulnerabilidad de divulgación de información causada por una lectura fuera de límites en HGFS. El aviso indica que “un actor malicioso con privilegios administrativos en una máquina virtual podría explotar este problema para filtrar memoria del proceso vmx”. Si bien no podemos confirmar la causa raíz exacta, el uso de HGFS por parte del exploit y la consecuente fuga de memoria coinciden con esta descripción.

El exploit luego abre seis canales de comunicación de puerta trasera y cierra dos de ellos (canales 2 y 4). El término “puerta trasera” es aparentemente la propia terminología de VMware para su mecanismo de comunicación invitado-host. Funciona accediendo al puerto de E/S 0x5658; en una máquina física, este puerto no está conectado a nada, pero dentro de una VM de VMware, el hipervisor intercepta el acceso a él y lo usa como canal de comandos. Así es como VMware Tools implementa funciones como el uso compartido del portapapeles, arrastrar y soltar, y el redimensionamiento de pantalla.

Se envía a través del canal un gran búfer de ceros (~50 KB), seguido de la cadena “OK ATR toolbox-dnd” para inicializar la operación de arrastrar y soltar de HGFS.

Finalmente, el exploit construye y envía la carga útil que desencadena la lectura fuera de límites:

• 4F 4B 20 00 00 00 00 FF 00 00 00 A5 C5 00 00 A4 C5 00 00 00 00 00 80 29 00 00 00 + [50573 ceros]

Antes de usar el puntero filtrado, el exploit lo valida comparando los bits 8-11 con un valor esperado de la tabla de desplazamientos. Para la compilación 24022510, aplicar la máscara 0xF00 a ambos debería producir resultados coincidentes. Una vez validado, la dirección base de VMX se calcula restando el desplazamiento conocido (0x01590300) del puntero filtrado:

• vmxBase = leakedPtr - 0x01590300

La tabla de desplazamientos almacena una dirección conocida dentro de VMX para cada compilación compatible. El puntero filtrado apunta a una ubicación predecible dentro de VMX. Al restar este desplazamiento conocido, el exploit determina dónde se carga VMX en la memoria, derrotando el ASLR.

Escritura de shellcode en la memoria de VMX

Con la dirección base de VMX conocida, el exploit ahora puede leer y escribir datos directamente en la memoria de VMX.

Ambas operaciones funcionan construyendo un encabezado de 95 bytes y enviándolo a través de los canales de puerta trasera de VMware. Para las escrituras, el encabezado contiene el tipo de comando 2, el tamaño de los datos a escribir y la dirección objetivo en la memoria de VMX. El encabezado se envía primero, seguido de los datos reales en un segundo canal. Para las lecturas, el encabezado contiene el tipo de comando 3 y la dirección objetivo, y el exploit recibe 8 bytes de vuelta que contienen los datos en esa ubicación.

Evaluamos que esta capacidad de lectura/escritura es habilitada por CVE-2025-22224, que VMware describe como una vulnerabilidad que “lleva a una escritura fuera de límites”.

Figura 7: Escritura de datos en la memoria de VMX mediante canales de puerta trasera

Entonces, el exploit escribe tres cargas útiles en la memoria de VMX:

• Shellcode de etapa 1
• Shellcode de etapa 2
• Puerta trasera ELF

La puerta trasera ELF que llamamos “VSOCKpuppet” es un ejecutable de Linux; ESXi se ejecuta sobre un kernel basado en Linux, por lo que los binarios nativos de Linux pueden ejecutarse directamente en el hipervisor.

Después de escribir las cargas útiles, el exploit sobrescribe un puntero de función dentro de VMX. Primero guarda el valor original del puntero, y luego lo sobrescribe con la dirección del shellcode. El exploit entonces envía un mensaje VMCI al host para desencadenar VMX. Cuando VMX procesa el mensaje, sigue el puntero corrompido y salta al shellcode del atacante en lugar de 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 sandbox”.

Shellcode 1

El shellcode de la etapa 1 se ejecuta dentro del proceso VMX y usa llamadas al sistema de VMkernel para consultar los componentes internos del kernel. El shellcode repite hasta 4,902 veces buscando un objeto llamado “general”. Luego consulta información sobre “vmkernel” y “vmci”. Cuando se encuentran, extrae sus direcciones base.

• vmkernel base: %p, qpBrokerList: %p

Estas direcciones son críticas para la siguiente fase, ya que permiten al exploit calcular dónde escribir en la memoria del kernel para escapar del sandbox de VMX.

Figura 8: Fragmento del shellcode 1

Shellcode 2

El shellcode de la etapa 2 establece un punto de apoyo en el host ESXi usando llamadas al sistema estándar de Linux. Crea el archivo de puerta trasera en /var/run/a con permisos completos (0777), y luego le escribe la carga útil de VSOCKpuppet. Después, modifica /var/run/inetd.conf, el archivo de configuración del daemon de servicio de red inetd de ESXi, añadiendo la siguiente línea:

• ftp stream tcp nowait root /var/run/a a ++group=host/vim/vimuser/terminal/ssh

Esto secuestra el puerto 21 (FTP); cualquier conexión TCP a este puerto ejecuta /var/run/a como root. El parámetro ++group=host/vim/vimuser/terminal/ssh otorga a la puerta trasera acceso elevado en el host.

Para activar la configuración, el shellcode lee /var/run/inetd.pid, analiza el ID del proceso y envía SIGHUP (señal 1) a inetd, la señal estándar de Unix para recargar la configuración. Tras una breve espera, se conecta localmente a 127.0.0.1:21 para activar la puerta trasera.

Finalmente, el shellcode restaura el contenido original de /var/run/inetd.conf, eliminando la entrada maliciosa. Este paso de limpieza dificulta el análisis forense, ya que el archivo de configuración parece intacto después de la explotación.

Figura 9: Fragmento del shellcode 2

VSOCKpuppet: acceso remoto basado en VSOCK

VSOCKpuppet es un ejecutable ELF de 64 bits que proporciona acceso remoto persistente al host ESXi. En lugar de usar sockets de red tradicionales, la puerta trasera se comunica a través de VSOCK (Virtual Sockets), la interfaz de alta velocidad de VMware para la comunicación entre VM invitadas y el hipervisor. Esto hace que el tráfico de la puerta trasera sea invisible para las herramientas de monitoreo de red.

Al iniciar, la puerta trasera obtiene la familia de direcciones VSOCK abriendo /dev/vsock o /vmfs/devices/char/vsock/vsock y emitiendo el ioctl VMCI_SOCKETS_GET_AF_VALUE (0x7B8). Este ioctl consulta al controlador de vsock para obtener el número de protocolo correcto que se pasará a socket(); es necesario porque el número de protocolo de VSOCK se asigna dinámicamente cuando se carga el módulo del kernel y difiere entre Linux (normalmente 40) y ESXi.

Figura 10: Inicialización de VSOCK

La puerta trasera se vincula al puerto VSOCK 10000 con contexto ID -1 (VMADDR_CID_ANY), permitiendo que cualquier máquina virtual en el host se comunique con ella.

La puerta trasera espera un activador de dos bytes “ok”, y luego bifurca un proceso hijo para manejar comandos. Admite tres operaciones: GET lee un archivo del host ESXi y devuelve su contenido al atacante, permitiendo la transferencia de datos. POST recibe datos y los escribe en una ruta de archivo especificada en el host. Cualquier otra entrada se trata como un comando de shell: la puerta trasera lo escribe en /tmp/input, lo ejecuta mediante /bin/sh, y devuelve la salida.

¿Por qué VSOCK?

VSOCK permite la comunicación directa entre VM invitadas y el hipervisor sin atravesar la pila de red. A diferencia del tráfico TCP/IP, la comunicación VSOCK no genera paquetes de red visibles para las herramientas tradicionales de monitoreo de red, firewalls o sistemas de detección de intrusiones basados en red.

Los defensores pueden detectar procesos con sockets VMCI abiertos usando lsof -a en el host ESXi, lo que muestra entradas con el tipo SOCKET_VMCI. Sin embargo, la salida solo muestra IDs de procesos y descripciones genéricas como {no file name}; para identificar el binario malicioso real, los defensores necesitan volcar la memoria del proceso para un análisis más profundo. Mandiant ha publicado guías detalladas sobre la detección de puertas traseras VMCI y el compromiso de ESXi en sus publicaciones de blog sobre detección y fortalecimiento del hipervisor ESXi y detección, contención y fortalecimiento de VMware.

Genial, tenemos una puerta trasera... ahora, ¿cómo la usamos?

Con el hipervisor ESXi comprometido y VSOCKpuppet escuchando en el puerto VSOCK 10000, el actor de amenazas todavía necesita una forma de interactuar con ella. Dado que VSOCK proporciona un canal de comunicación directo entre las VM invitadas y el hipervisor, pueden ejecutar un cliente desde cualquier VM de Windows en ese host para enviar comandos de vuelta al ESXi comprometido. Ahí es donde entra en juego client.exe o el GetShell Plugin (encontrado en el archivo binario dejado por el actor de amenazas), un simple cliente VSOCK basado en Windows que proporciona acceso interactivo a shell a la puerta trasera.

El binario contiene una ruta PDB reveladora que ofrece una idea del entorno de desarrollo del actor de amenazas:

• C:\Users\test\Desktop\2023_11_02\vmci_vm_escape\getshell\source\client\x64\Release\client.pdb

La ruta nos indica que esto se construyó el 2 de noviembre de 2023, como parte de un kit de herramientas más amplio llamado vmci_vm_escape con un componente getshell. client.exe en sí no contiene código de exploit; es solo una herramienta genérica de comunicación VSOCK que funciona con cualquier versión de ESXi. Esto podría apuntar a un enfoque modular: el actor de amenazas mantiene herramientas reutilizables de post-explotación separadas de los exploits en sí, lo que le permite incorporar nuevas vulnerabilidades manteniendo la misma infraestructura.

Instalación del controlador

Antes de que pueda ocurrir la comunicación VSOCK, deben estar presentes los controladores apropiados de VMware. El cliente verifica la disponibilidad de VMCI e instala los controladores si es necesario.

Figura 11: Verificación de la disponibilidad de VMCI

Si el controlador VMCI no está disponible, el cliente ejecuta la instalación del controlador mediante “InfDefaultInstall.exe”.

• C:\Windows\System32\InfDefaultInstall.exe C:\Windows\vmci.inf
• C:\Windows\System32\InfDefaultInstall.exe C:\Windows\vsock.inf

La carpeta Binary también incluye paquetes de controladores de VMware modificados. Al examinar ambos archivos INF se revela una manipulación idéntica, como se muestra a continuación.

Figura 12: Fragmento de los archivos vmci.inf y vsock.inf

El mismo patrón aparece en ambos archivos: el encabezado de derechos de autor se cambió a “XLab”, mientras que las cadenas de Proveedor, las versiones de controladores, las claves de registro y las definiciones de servicio permanecen sin cambios respecto a los paquetes legítimos de VMware. El actor de amenazas simplemente editó los comentarios de derechos de autor y empaquetó los controladores originales firmados.

Después de la instalación del controlador, el cliente registra la biblioteca VSOCK de VMware como proveedor de Winsock usando la API WSCInstallProvider64_32 , lo que permite la comunicación por sockets a través de VMCI.

Uso y protocolo

El cliente espera un argumento simple de línea de comandos que especifica el CID y el puerto objetivo:

• client SERVER_CID:PORT 

En la arquitectura VSOCK de VMware, el CID 2 siempre está reservado para el host hipervisor, por lo que conectarse a la puerta trasera es simplemente:

• client.exe 2:10000

El protocolo comienza con un saludo: el cliente envía “test” seguido de “ok”, y luego espera una confirmación “ok” del servidor antes de continuar. Después del saludo, la comunicación usa mensajes con prefijo de longitud. Para transferencias más grandes, los datos se dividen en fragmentos de 32 KB, cada uno confirmado con “ok” antes de enviar el siguiente.

Figura 13: Lógica de transferencia de datos por fragmentos con segmentos de 32 KB y verificaciones de confirmación “ok”


Figura 14: Protocolo de comunicación VSOCK entre client.exe (GetShell Plugin) y VSOCKpuppet

El cliente refleja el conjunto de comandos de la puerta trasera: get descarga archivos de ESXi a la VM, post sube archivos de la VM a ESXi, y cualquier otra cosa se pasa como un comando de shell para su ejecución en el hipervisor.

Curiosamente, la carpeta Binary incluye un README con instrucciones de uso, lo que nos da una mirada directa al flujo de trabajo previsto.

Figura 15: Contenido del README

¿Quién hizo esto? Buena pregunta.

Los binarios del exploit contienen rutas PDB que ofrecen una idea del entorno de desarrollo.

MyDriver.sys:

• C:\Users\test\Desktop\2024_02_19\全版本逃逸--交付\report\ESXI_8.0u3\

El nombre de la carpeta se traduce como “Escape de todas las versiones - entrega”, lo que sugiere que se trataba de un entregable empaquetado dirigido a ESXi 8.0 Update 3. La fecha en la ruta (19 de febrero de 2024) es anterior en más de un año a la divulgación pública de VMware, confirmando que se desarrolló como un potencial exploit zero-day.

Curiosamente, aunque las rutas de desarrollo contienen chino simplificado, el kit de herramientas incluye un README en inglés con instrucciones de uso. Esta combinación, artefactos de desarrollo en chino junto con documentación en inglés, podría sugerir que el kit de herramientas estaba destinado a la venta o distribución a una audiencia más amplia.

En cuanto a los paquetes de controladores, tanto vmci.inf como vsock.inf contienen un encabezado de derechos de autor modificado que hace referencia a “XLab”; el significado de esta cadena no está claro. Durante nuestra investigación, notamos que XLab también es el nombre de un equipo de investigación de ciberseguridad dentro de Qi An Xin, una importante empresa de seguridad china. Sin embargo, “XLab” es un término genérico, y no tenemos evidencia que vincule este kit de herramientas con esa organización o cualquier otra entidad específica.

El uso de chino simplificado en las rutas de desarrollo, combinado con el nivel de sofisticación y el posible acceso a vulnerabilidades zero-day meses antes de la divulgación pública, sugiere un desarrollador con buenos recursos que probablemente opera en una región de habla china.

Conclusión

Esta intrusión demuestra una cadena de ataque sofisticada y de múltiples etapas, diseñada para escapar del aislamiento de la máquina virtual y comprometer el hipervisor ESXi subyacente. Al encadenar una fuga de información, corrupción de memoria y escape de sandbox, el actor de amenazas logró lo que todo administrador de VM teme: control total del hipervisor desde dentro de una VM invitada.

El uso de VSOCK para la comunicación de la puerta trasera es particularmente preocupante, ya que evita por completo el monitoreo de red tradicional, dificultando significativamente la detección. El kit de herramientas también prioriza el sigilo sobre la persistencia: restaura inetd.conf después de que la puerta trasera se inicia y coloca el binario en /var/run/, que no sobrevive a un reinicio. Esto sugiere que el atacante tenía la intención de completar sus objetivos rápidamente en lugar de mantener acceso a largo plazo.

La línea de tiempo de desarrollo revelada en las rutas PDB nos indica que este exploit potencialmente existió como un zero-day durante más de un año antes de la divulgación pública de VMware, destacando la amenaza persistente que representan los actores con buenos recursos que tienen acceso a vulnerabilidades sin parchear.

Recomendación

Las organizaciones que ejecutan VMware ESXi 7.0 u 8.0 deben aplicar los parches más recientes de inmediato. ESXi 6.x y versiones anteriores están fuera de soporte y permanecen sin parchear. Para obtener orientación adicional sobre fortalecimiento, consulta nuestro artículo sobre defensas del hipervisor contra el ransomware dirigido a ESXi.

Detección

Yara

https://github.com/RussianPanda95/Yara-Rules/blob/main/ESXiExploitToolkit/win_mal_GetShellPlugin.yar

https://github.com/RussianPanda95/Yara-Rules/blob/main/ESXiExploitToolkit/win_mal_MAESTRO.yar

https://github.com/RussianPanda95/Yara-Rules/blob/main/ESXiExploitToolkit/linux_mal_VSOCKpuppet.yar

https://github.com/RussianPanda95/Yara-Rules/blob/main/ESXiExploitToolkit/win_mal_MyDriverSYS.yar

Sigma

Reglas para detectar algunos de los comportamientos clave de exploit.exe que permiten la explotación de ESXi y el escape de VM:

https://github.com/huntresslabs/threat-intel/blob/main/2026/2026-01/vm_escape/sigma/proc_creation_win_devcon_disable_vmci_driver.yml

https://github.com/huntresslabs/threat-intel/blob/main/2026/2026-01/vm_escape/sigma/proc_creation_win_kdu_driver_tool_execution.yml

Indicadores de compromiso (IOC)