L'implant d'ESXi porta panell de control; el teu hipervisor no porta agent

El 10 de novembre l'Insikt Group de Recorded Future va publicar l'anàlisi de GhostFrame, un marc de post-explotació fet a mida per a hipervisors VMware ESXi. El que crida l'atenció no és que algú ataqui ESXi —això fa anys que passa—, sinó la forma: GhostFrame porta un panell web d'operador amb dues seccions, Sessions i Builder. El Builder genera l'implant. El panell llista les màquines virtuals convidades, els canvia l'estat d'encesa, gestiona les seves instantànies i permet activar VNC per mirar l'escriptori del convidat. És, funció per funció, la teva consola de virtualització. La diferència és que a la seva ningú li demana un segon factor.

Convé dir des del principi què no és GhostFrame: no és una via d'entrada. Es desplega quan l'atacant ja té root al host; el panell ve després, amb les instruccions. I aquest és el fons de la qüestió: no hi ha cap agent per instal·lar a la capa on corre això. L'EDR del teu parc viu dins dels Windows i dels Linux convidats. GhostFrame no hi viu. Viu un pis més avall, on les teves màquines no són màquines: són fitxers.

Què és GhostFrame i d'on surt

Insikt el va trobar seguint un grup que anomena TAG-218, l'activitat del qual se solapa amb el ransomware Settra. La finestra observada va de finals d'agost a octubre de 2026, i quatre de les organitzacions atacades van aparèixer després al portal d'extorsió de Settra. Els mateixos investigadors hi posen un matís que convé respectar: «available evidence does not establish that the framework is exclusive to Settra or identify its distribution model». Solapament operatiu, no propietat exclusiva. Traduït: no és «el ransomware X ja té eina pròpia», és que l'eina circula entre els qui comparteixen operació.

El que és nou, i el que cal retenir, és l'empaquetament: un marc que ningú havia documentat —Insikt l'anomena «previously undocumented»— i que fica el flux sencer en un únic panell pensat per a ESXi: persistència, robatori de credencials i control de les màquines.

El panell: el que veu qui hi ha a l'altra banda

L'implant que genera el Builder es diu vmhostd-core i es copia a /opt/vmhostd-core. En execució s'emmascara canviant el nom del procés i la seva línia d'ordres per assemblar-se a vmhostd. El nom diu contra qui està dissenyat: a ESXi el dimoni de gestió es diu hostd. vmhostd no existeix. És un nom pensat per sobreviure a una mirada ràpida a una llista de processos a les tres de la matinada, no a una cerca.

Si algú encén la consola gràfica del convidat des de l'hipervisor, dins d'aquell Windows no hi ha cap sessió per iniciar: no hi ha un procés d'escriptori remot, i mirar no genera cap esdeveniment d'inici de sessió. Només el generaria el que algú teclegi després en aquella consola. El framebuffer se serveix des de fora del sistema operatiu: el convidat no participa en el fet que l'estiguin mirant i, per tant, no se n'assabenta.

Disset mil vegades al dia

Per persistir, l'implant modifica /etc/rc.local.d/local.sh, el guió d'arrencada del host. I un cop amunt, segons descriu l'informe, executa un bucle que aproximadament cada cinc segons desactiva el tallafoc d'ESXi i posa execInstalledOnly a zero. L'aritmètica és nostra, no de l'informe, i per això va arrodonida: a cinc segons en surten de l'ordre de 17.000 passades al dia.

L'informe ja explica per a què serveix el bucle: per tornar a apagar els controls si un administrador intenta restaurar-los. Dit d'una altra manera, l'atacant no confia que el seu canvi es quedi i ha escrit l'implant contra un administrador atent. I guanya, perquè ell corregeix cada cinc segons i tu mires un cop al trimestre.

El que no diu l'informe, i és on volem arribar, és que aquest mateix bucle és el senyal més sorollós de tot el conjunt i gairebé ningú el recull. La configuració d'un hipervisor s'audita com una foto. Es mira el dia de l'auditoria, surt «conforme», se signa i es desa l'informe. Un host que reescriu la seva pròpia configuració disset mil vegades al dia no és una troballa d'auditoria: és una sèrie temporal. I gairebé ningú la grafica. L'estat del tallafoc del teu host hauria de ser una mètrica amb alerta, no una captura de pantalla dins d'un PDF.

Quan la teva còpia de configuració desa la de l'atacant

Hi ha un detall de l'informe que les cròniques citen de passada i ningú porta fins al final: perquè el seu afebliment sobrevisqui al reinici, l'implant executa /sbin/auto-backup.sh. Aquest guió no és seu. És el mecanisme legítim amb què ESXi persisteix els canvis de configuració que viuen en memòria.

Les credencials no surten del convidat, surten del disc

El marc integra VMkatz, una eina oberta que extreu credencials d'instantànies de memòria, d'imatges de disc virtual i de l'encreuament de totes dues, escanejant els magatzems de dades de manera recursiva. El botí que descriu l'informe: hashos NTLM, credencials WDigest, tiquets Kerberos, secrets SAM i LSA i NTDS.dit, la base de dades del Directori Actiu.

Res d'això passa dins del convidat. No hi ha un procés llegint lsass, no hi ha un bolcat que un agent pugui bloquejar ni una alerta d'accés sospitós a memòria. Hi ha un fitxer i algú amb permís de lectura sobre el magatzem on és. Ho vam explicar fa una setmana a propòsit d'un altre cas: quan el disc d'un controlador de domini es llegeix des de fora, Windows no registra absolutament res, perquè Windows no ha arribat a arrencar.

I hi ha una peça més, sdkmon, que altera la configuració de serveis per interceptar els usuaris i contrasenyes dels inicis de sessió futurs contra el mateix ESXi. Això té una conseqüència operativa molt concreta per a l'endemà: no n'hi ha prou de rotar el que sospites que s'han endut. Cal rotar tot el que es va fer servir per entrar al host durant la finestra de l'incident, perquè es va anar registrant a mesura que es teclejava.

L'interruptor que apaga el bucle, i per què apagar-lo surt de franc

El control que el bucle apaga és el que Broadcom defineix sense embuts: amb execInstalledOnly activat es garanteix «that the VMkernel executes only those binaries that have been packaged and signed as part of a VIB». És a dir, el control que a vmhostd-core li hauria costat un pas més.

Els dos execInstalledOnly ja els vam desmuntar la setmana passada: hi ha una opció interna d'execució, afegida a ESXi 8.0 i activada per defecte, que s'apaga en calent amb esxcli system settings advanced set -o /User/execInstalledOnly -i 0; i una opció d'arrencada del VMkernel, que continua desactivada per defecte. El que importa avui és quina de les dues ataca el bucle. Ataca la fluixa: la d'execució, la que gairebé tothom té, la que es treu amb una línia sense reiniciar res.

Des de vSphere 7.0 Update 2 l'opció d'arrencada es pot imposar a cada arrencada fent servir el TPM, i a ESXi 8.0 amb UEFI Secure Boot i TPM 2.0 el host comprova en arrencar que execInstalledOnly continua activat i, si no ho està, cau amb una pantalla morada expressament. S'activa amb esxcli system settings encryption set --require-exec-installed-only=T, i l'ordre importa: la mateixa documentació avisa que «the execInstalledOnly enforcement is built on top of the UEFI secure boot enforcement», de manera que primer va l'arrencada segura.

I no és el que s'espera d'un control de seguretat: això no impedeix l'atac. Canvia el desenllaç. Passes d'un compromís silenciós que pot durar mesos a una caiguda sorollosa al següent reinici. És un intercanvi, i cal decidir-lo amb els ulls oberts, perquè una pantalla morada és una avaria amb nom i cognoms i algú preguntarà per què ha caigut el host.

Nosaltres ho diem sovint amb altres paraules: la fallada és inevitable, l'avaria és una decisió de disseny. Aquest control és un dels pocs casos en què a més pots triar quina fallada prefereixes tenir.

I el contrapès honest, que és de qui va documentar aquest control quan gairebé no hi havia documentació. L'Anders Olsson va escriure el 2022, explicant-lo amb detall, 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». Hi afegia un detall que continua sent cert: l'intèrpret de Python que VMware empaqueta dins d'ESXi sí que va arribar en un VIB, de manera que un atacant amb root pot quedar-se dins del que està permès i continuar operant. execInstalledOnly no és una barrera. És un peatge: encareix l'atac i el fa sorollós. Que és força, però no és el mateix.

Això comença abans de l'hipervisor

Entre agost i octubre de 2026, TAG-218 va entrar per aparells VPN del perímetre —l'informe anomena SonicWall, Fortinet i Palo Alto Networks—, i entre les vies hi ha CVE-2026-0257, un salt d'autenticació al portal i la passarel·la GlobalProtect de PAN-OS publicat pel fabricant el 13 de maig de 2026, que permet a un atacant no autenticat establir una sessió VPN forjant una galeta d'anul·lació d'autenticació —explotable quan aquesta funció és activa i el certificat que signa aquestes galetes es reutilitza o està exposat—. És al catàleg KEV de CISA. Només després, amb root ja a la mà, apareix l'hipervisor.

I això s'explica malament sovint: una sessió de VPN establerta sense autenticar-se no «se salta l'MFA». És que no hi arriba a passar. El segon factor és avall del punt on es va trencar la cadena, i per això no hi intervé. Després ve el de sempre: eines de gestió remota de doble ús —Insikt situa un servidor MeshCentral a la cadena, fet servir per persistir—, moviment lateral per RDP i SMB i recollida de credencials per fases abans del xifratge, que és com ho descriu Unit 42. És la mateixa forma que explicàvem a finals d'octubre: s'entra per l'inici de sessió d'un portal i se surt amb l'hipervisor. I ahir mateix, sobre els tres crítics de FortiOS: el que entra, entra per on l'aparell ja confiava.

Sis coses que sí que pots mirar en un host sense agent

No hi ha agent, però hi ha estat i hi ha trànsit. Això és el que nosaltres posaríem sota vigilància contínua en un parc ESXi, en aquest ordre:

L'informe publica indicadors concrets per a qui els vulgui buscar cap enrere: 193.5.65.114 com a servidor de comandament del MeshCentral i 45.158.196.81 i 45.158.196.141 per a GhostFrame, a més del resum SHA-256 de l'implant. Si tens registres de sortida desats, aquesta cerca costa una tarda.

Quan no, i el que no arregla canviar d'hipervisor

Si els teus hosts no porten TPM 2.0 ni arrencada segura, tot el paràgraf del TPM no és la teva jugada d'aquest trimestre. La teva jugada és tancar qui arriba a la interfície de gestió i posar aquests quatre ajustos sota vigilància contínua. Això no costa diners i és la major part del benefici. I si la teva interfície de gestió només respon en una xarxa de gestió a la qual no s'arriba des d'una sessió de VPN d'usuari, bona part d'aquesta cadena no té amb qui parlar. Dir-ho ens treu feina, però és la veritat.

I el que probablement no et dirà ningú que visqui d'això: migrar de VMware a Proxmox no arregla aquest problema. Ho diem nosaltres, que hem migrat empreses de VMware a Proxmox i també hem recomanat quedar-s'hi quan tenia sentit. Un node Proxmox és un Debian amb root. L'equivalent de tot l'anterior s'escriu en una unitat de systemd en lloc de a /etc/rc.local.d/local.sh, i per llegir el disc d'un convidat no cal cap eina especial: n'hi ha prou amb les del mateix sistema. La diferència real a favor de Proxmox és que és un Linux normal i sí que admet auditoria, recollida de registres i les eines que el teu equip ja sap fer servir. Però això és feina que s'ha de fer, no un regal que vingui a la caixa del canvi d'hipervisor.

El que de debò ha canviat

Llegir el disc d'una màquina convidada des de l'hipervisor no és una tècnica nova, i qui fa temps que hi és ho sap. El que és nou és l'empaquetament. Quan una cadena d'atac sencera cap en un panell amb pestanyes, deixa de caldre l'especialista que la sabia encadenar a mà. Això no apuja el sostre del que es pot fer contra la teva infraestructura: apuja el terra de qui ho pot fer. I el terra és, justament, el que t'acaba tocant a tu.

La capa de virtualització s'ha quedat, durant anys, en un buit estrany: massa crítica per no vigilar-la i massa tancada per posar-hi un agent. Al nostre servei d'EDR i MDR gestionat aquesta capa entra dins l'abast com qualsevol altra, amb la diferència que el que s'hi vigila no són processos: són l'estat de la configuració, els canvis als guions d'arrencada i el que el host intenta parlar cap a fora. I el perímetre pel qual va començar tot això —els aparells VPN— és la mateixa feina de ciberseguretat de sempre: saber quina versió corre cadascun i quan es va pedaçar.

Fonts (verificades): anàlisi de GhostFrame, panell d'operador, vmhostd-core, gfsox, sdkmon, VMkatz, persistència, patró de sis ports i indicadors — Insikt Group, Recorded Future, 10-nov-2026, recordedfuture.com; detalls de VNC, instantànies i emmascarament del procés — securityonline.info; comportament i ordres d'execInstalledOnly, dependència de l'arrencada segura UEFI — documentació de vSphere 8.0, techdocs.broadcom.com; distinció entre l'opció d'execució i la d'arrencada, comprovació per TPM i pantalla morada deliberada, i la citació sobre els límits del control — Anders Olsson, Truesec, 16-des-2022, truesec.com; CVE-2026-0257 (salt d\x27autenticació a GlobalProtect, publicat 13-maig-2026, condició prèvia de les galetes d\x27anul·lació, al KEV de CISA) i la cadena de post-explotació posterior (eines de gestió remota de doble ús, RDP/SMB i recollida de credencials abans del xifratge) — Unit 42. La xifra de disset mil passades al dia és aritmètica pròpia, arrodonida expressament sobre l'interval aproximat de cinc segons que descriu l'informe; la conseqüència sobre la còpia de configuració del host se senyala al text com a deducció, no com a dada de la font.