El implante de ESXi trae panel de control; tu hipervisor no trae agente

El 10 de noviembre el Insikt Group de Recorded Future publicó el análisis de GhostFrame, un marco de post-explotación hecho a medida para hipervisores VMware ESXi. Lo llamativo no es que alguien ataque ESXi —eso lleva años ocurriendo—, sino la forma: GhostFrame trae un panel web de operador con dos secciones, Sessions y Builder. El Builder genera el implante. El panel lista las máquinas virtuales invitadas, les cambia el estado de encendido, gestiona sus instantáneas y permite activar VNC para mirar el escritorio del invitado. Es, función por función, tu consola de virtualización. La diferencia es que a la suya nadie le pide un segundo factor.

Conviene decir desde el principio lo que GhostFrame no es: no es una vía de entrada. Se despliega cuando el atacante ya tiene root en el host; el panel viene después, con las instrucciones. Y ese es el fondo del asunto: no hay agente que instalar en la capa donde corre eso. El EDR de tu parque vive dentro de los Windows y de los Linux invitados. GhostFrame no vive ahí. Vive un piso más abajo, donde tus máquinas no son máquinas: son ficheros.

Qué es GhostFrame y de dónde sale

Insikt lo encontró siguiendo a un grupo al que llama TAG-218, cuya actividad se solapa con el ransomware Settra. La ventana observada va de finales de agosto a octubre de 2026, y cuatro de las organizaciones atacadas aparecieron después en el portal de extorsión de Settra. Los propios investigadores ponen un matiz que conviene respetar: «available evidence does not establish that the framework is exclusive to Settra or identify its distribution model». Solapamiento operativo, no propiedad exclusiva. Traducido: no es «el ransomware X ya tiene herramienta propia», es que la herramienta circula entre quienes comparten operación.

Lo nuevo, y lo que hay que retener, es el empaquetado: un marco que nadie había documentado —Insikt lo llama «previously undocumented»— y que mete el flujo entero en un único panel pensado para ESXi: persistencia, robo de credenciales y control de las máquinas.

El panel: lo que ve el que está al otro lado

El implante que genera el Builder se llama vmhostd-core y se copia a /opt/vmhostd-core. En ejecución se enmascara cambiando el nombre del proceso y su línea de comandos para parecerse a vmhostd. El nombre dice contra quién está diseñado: en ESXi el demonio de gestión se llama hostd. vmhostd no existe. Es un nombre pensado para sobrevivir a una mirada rápida a una lista de procesos a las tres de la madrugada, no a una búsqueda.

Si alguien enciende la consola gráfica del invitado desde el hipervisor, dentro de ese Windows no hay ninguna sesión que iniciar: no hay un proceso de escritorio remoto, y mirar no genera ningún evento de inicio de sesión. Solo lo generaría lo que alguien teclee después en esa consola. El framebuffer se sirve desde fuera del sistema operativo: el invitado no participa en que lo estén mirando y, por tanto, no se entera.

Diecisiete mil veces al día

Para persistir, el implante modifica /etc/rc.local.d/local.sh, el guion de arranque del host. Y una vez arriba, según describe el informe, ejecuta un bucle que aproximadamente cada cinco segundos desactiva el cortafuegos de ESXi y pone execInstalledOnly a cero. La aritmética es nuestra, no del informe, y por eso va redondeada: a cinco segundos salen del orden de 17.000 pasadas al día.

El informe ya explica para qué sirve el bucle: para volver a apagar los controles si un administrador intenta restaurarlos. Dicho de otro modo, el atacante no confía en que su cambio se quede y ha escrito el implante contra un administrador atento. Y gana, porque él corrige cada cinco segundos y tú miras una vez al trimestre.

Lo que no dice el informe, y es donde queremos llegar, es que ese mismo bucle es la señal más ruidosa de todo el conjunto y casi nadie la recoge. La configuración de un hipervisor se audita como una foto. Se mira el día de la auditoría, sale «conforme», se firma y se guarda el informe. Un host que reescribe su propia configuración diecisiete mil veces al día no es un hallazgo de auditoría: es una serie temporal. Y casi nadie la está graficando. El estado del cortafuegos de tu host debería ser una métrica con alerta, no una captura de pantalla en un PDF.

Cuando tu copia de configuración guarda la del atacante

Hay un detalle del informe que las crónicas citan de pasada y nadie lleva hasta el final: para que su debilitamiento sobreviva al reinicio, el implante ejecuta /sbin/auto-backup.sh. Ese guion no es suyo. Es el mecanismo legítimo con el que ESXi persiste los cambios de configuración que vive en memoria.

Las credenciales no salen del invitado, salen del disco

El marco integra VMkatz, una herramienta abierta que extrae credenciales de instantáneas de memoria, de imágenes de disco virtual y del cruce de ambas, escaneando los almacenes de datos de forma recursiva. El botín que describe el informe: hashes NTLM, credenciales WDigest, tiques Kerberos, secretos SAM y LSA y NTDS.dit, la base de datos del Directorio Activo.

Nada de eso ocurre dentro del invitado. No hay un proceso leyendo lsass, no hay un volcado que un agente pueda bloquear ni una alerta de acceso sospechoso a memoria. Hay un fichero y alguien con permiso de lectura sobre el almacén donde está. Lo contamos hace una semana a propósito de otro caso: cuando el disco de un controlador de dominio se lee desde fuera, Windows no registra absolutamente nada, porque Windows no ha llegado a arrancar.

Y hay una pieza más, sdkmon, que altera la configuración de servicios para interceptar los usuarios y contraseñas de los inicios de sesión futuros contra el propio ESXi. Esto tiene una consecuencia operativa muy concreta para el día después: no basta con rotar lo que sospechas que se llevaron. Hay que rotar todo lo que se usó para entrar al host durante la ventana del incidente, porque se fue registrando según se tecleaba.

El interruptor que apaga el bucle, y por qué apagarlo sale gratis

El control que el bucle apaga es el que Broadcom define sin rodeos: con execInstalledOnly activado se garantiza «that the VMkernel executes only those binaries that have been packaged and signed as part of a VIB». Es decir, el control que a vmhostd-core le habría costado un paso más.

Los dos execInstalledOnly ya los desmontamos la semana pasada: hay una opción interna de ejecución, añadida en ESXi 8.0 y activada por defecto, que se apaga en caliente con esxcli system settings advanced set -o /User/execInstalledOnly -i 0; y una opción de arranque del VMkernel, que sigue desactivada por defecto. Lo que importa hoy es cuál de las dos ataca el bucle. Ataca la floja: la de ejecución, la que casi todo el mundo tiene, la que se quita con una línea sin reiniciar nada.

Desde vSphere 7.0 Update 2 la opción de arranque se puede imponer en cada arranque usando el TPM, y en ESXi 8.0 con UEFI Secure Boot y TPM 2.0 el host comprueba al arrancar que execInstalledOnly sigue activado y, si no lo está, se cae con una pantalla morada a propósito. Se activa con esxcli system settings encryption set --require-exec-installed-only=T, y el orden importa: la propia documentación avisa de que «the execInstalledOnly enforcement is built on top of the UEFI secure boot enforcement», así que primero va el arranque seguro.

Y no es lo que se espera de un control de seguridad: eso no impide el ataque. Cambia el desenlace. Pasas de un compromiso silencioso que puede durar meses a una caída ruidosa en el siguiente reinicio. Es un intercambio, y hay que decidirlo con los ojos abiertos, porque una pantalla morada es una avería con nombre y apellidos y alguien va a preguntar por qué se ha caído el host.

Nosotros lo decimos a menudo con otras palabras: el fallo es inevitable, la avería es una decisión de diseño. Este control es uno de los pocos casos en los que además puedes elegir qué fallo prefieres tener.

Y el contrapeso honesto, que es de quien documentó este control cuando casi no había documentación. Anders Olsson escribió en 2022, explicándolo con detalle, que «if the attacker has root access to your ESXi hosts, there is not much we can do to stop them. All the protections that we put in place using root privileges can in some way be removed by anyone with root privileges». Añadía un detalle que sigue siendo cierto: el intérprete de Python que VMware empaqueta dentro de ESXi sí llegó en un VIB, así que un atacante con root puede quedarse dentro de lo permitido y seguir operando. execInstalledOnly no es una barrera. Es un peaje: encarece el ataque y lo hace ruidoso. Que es bastante, pero no es lo mismo.

Esto empieza antes del hipervisor

Entre agosto y octubre de 2026, TAG-218 entró por aparatos VPN del perímetro —el informe nombra SonicWall, Fortinet y Palo Alto Networks—, y entre las vías está CVE-2026-0257, un salto de autenticación en el portal y la pasarela GlobalProtect de PAN-OS publicado por el fabricante el 13 de mayo de 2026, que permite a un atacante no autenticado establecer una sesión VPN forjando una cookie de anulación de autenticación —explotable cuando esa función está activa y el certificado que firma esas cookies se reutiliza o está expuesto—. Está en el catálogo KEV de CISA. Solo después, con root ya en la mano, aparece el hipervisor.

Y esto se cuenta mal a menudo: una sesión de VPN establecida sin autenticarse no «se salta el MFA». Es que no llega a pasar por él. El segundo factor está cuesta abajo del punto donde se rompió la cadena, y por eso no interviene. Después viene lo de siempre: herramientas de gestión remota de doble uso —Insikt sitúa un servidor MeshCentral en la cadena, usado para persistir—, movimiento lateral por RDP y SMB y recolección de credenciales por fases antes del cifrado, que es como lo describe Unit 42. Es la misma forma que contábamos a finales de octubre: se entra por el inicio de sesión de un portal y se sale con el hipervisor. Y ayer mismo, sobre los tres críticos de FortiOS: lo que entra, entra por donde el aparato ya confiaba.

Seis cosas que sí puedes mirar en un host sin agente

No hay agente, pero hay estado y hay tráfico. Esto es lo que nosotros pondríamos bajo vigilancia continua en un parque ESXi, en este orden:

El informe publica indicadores concretos para quien quiera buscarlos hacia atrás: 193.5.65.114 como servidor de mando del MeshCentral y 45.158.196.81 y 45.158.196.141 para GhostFrame, además del resumen SHA-256 del implante. Si tienes registros de salida guardados, esa búsqueda cuesta una tarde.

Cuándo no, y lo que no arregla cambiar de hipervisor

Si tus hosts no llevan TPM 2.0 ni arranque seguro, todo el párrafo del TPM no es tu jugada de este trimestre. Tu jugada es cerrar quién llega a la interfaz de gestión y poner esos cuatro ajustes bajo vigilancia continua. Eso no cuesta dinero y es la mayor parte del beneficio. Y si tu interfaz de gestión solo responde en una red de gestión a la que no se llega desde una sesión de VPN de usuario, buena parte de esta cadena no tiene con quién hablar. Decirlo nos quita trabajo, pero es la verdad.

Y lo que probablemente no te va a decir nadie que viva de esto: migrar de VMware a Proxmox no arregla este problema. Lo decimos nosotros, que hemos migrado empresas de VMware a Proxmox y también hemos recomendado quedarse cuando tenía sentido. Un nodo Proxmox es un Debian con root. El equivalente de todo lo anterior se escribe en una unidad de systemd en lugar de en /etc/rc.local.d/local.sh, y para leer el disco de un invitado no hace falta ninguna herramienta especial: bastan las del propio sistema. La diferencia real a favor de Proxmox es que es un Linux normal y sí admite auditoría, recolección de registros y las herramientas que tu equipo ya sabe usar. Pero eso es trabajo que hay que hacer, no un regalo que venga en la caja del cambio de hipervisor.

Lo que de verdad ha cambiado

Leer el disco de una máquina invitada desde el hipervisor no es una técnica nueva, y quien lleva tiempo en esto lo sabe. Lo nuevo es el empaquetado. Cuando una cadena de ataque entera cabe en un panel con pestañas, deja de hacer falta el especialista que sabía encadenarla a mano. Eso no sube el techo de lo que se puede hacer contra tu infraestructura: sube el suelo de quién puede hacerlo. Y el suelo es, justamente, lo que te acaba tocando a ti.

La capa de virtualización se ha quedado, durante años, en un hueco raro: demasiado crítica para no vigilarla y demasiado cerrada para meterle un agente. En nuestro servicio de EDR y MDR gestionado esa capa entra en el alcance como cualquier otra, con la diferencia de que lo que se vigila ahí no son procesos: son el estado de la configuración, los cambios en los guiones de arranque y lo que el host intenta hablar hacia fuera. Y el perímetro por el que empezó todo esto —los aparatos VPN— es el mismo trabajo de ciberseguridad de siempre: saber qué versión corre cada uno y cuándo se parcheó.

Fuentes (verificadas): análisis de GhostFrame, panel de operador, vmhostd-core, gfsox, sdkmon, VMkatz, persistencia, patrón de seis puertos e indicadores — Insikt Group, Recorded Future, 10-nov-2026, recordedfuture.com; detalles de VNC, instantáneas y enmascaramiento del proceso — securityonline.info; comportamiento y órdenes de execInstalledOnly, dependencia del arranque seguro UEFI — documentación de vSphere 8.0, techdocs.broadcom.com; distinción entre la opción de ejecución y la de arranque, comprobación por TPM y pantalla morada deliberada, y la cita sobre los límites del control — Anders Olsson, Truesec, 16-dic-2022, truesec.com; CVE-2026-0257 (salto de autenticación en GlobalProtect, publicado 13-may-2026, condición previa de las cookies de anulación, en el KEV de CISA) y la cadena de post-explotación posterior (herramientas de gestión remota de doble uso, RDP/SMB y recolección de credenciales antes del cifrado) — Unit 42. La cifra de diecisiete mil pasadas al día es aritmética propia, redondeada a propósito sobre el intervalo aproximado de cinco segundos que describe el informe; la consecuencia sobre la copia de configuración del host se señala en el texto como deducción, no como dato de la fuente.