Exploit ESXi con fuga da VM non è più un’ipotesi teorica ma una realtà osservata sul campo. Nel dicembre 2025, Huntress ha documentato un’intrusione reale culminata nello sfruttamento di vulnerabilità critiche di VMware ESXi, attraverso un toolkit exploit avanzato in grado di supportare 155 build differenti, dalle versioni 5.1 fino alla 8.0. L’episodio dimostra in modo definitivo che l’isolamento tra macchine virtuali e hypervisor non è assoluto e che, senza patch aggressive, l’intero stack di virtualizzazione può diventare un singolo punto di compromissione.
Cosa leggere
Accesso iniziale tramite VPN compromessa e controllo del dominio
L’intrusione ha avuto origine da una VPN SonicWall compromessa, elemento che Huntress valuta con alta confidenza come vettore iniziale sulla base di indicatori di workstation, naming convention e TTP coerenti con un accesso remoto persistente. Una volta all’interno della rete, gli attaccanti hanno operato con account Domain Admin già compromesso, muovendosi lateralmente via RDP verso un backup domain controller.
Qui è emerso uno dei primi segnali di contenimento efficace: il tentativo di cambiare la password del Domain Admin in una stringa banale come Password01$, effettuato tramite Impacket, è stato bloccato dal Microsoft Defender for Endpoint gestito dal SOC Huntress. Nonostante questo stop, gli attaccanti hanno proseguito con attività di ricognizione aggressiva, utilizzando strumenti come Advanced Port Scanner e SoftPerfect Network Scanner, e avviando ShareFinder per enumerare le condivisioni di rete, con output salvato in C:\ProgramData\shares.txt.
Questa fase ha permesso una mappatura completa della rete interna, prerequisito per l’escalation successiva verso l’infrastruttura di virtualizzazione.
Isolamento della rete e preparazione all’esfiltrazione
Raggiunto il primary domain controller, gli attaccanti hanno modificato in modo chirurgico il firewall di Windows per tagliare le comunicazioni esterne mantenendo però la connettività interna. Le regole netsh advfirewall introdotte consentivano traffico in uscita solo verso 10.0.0.0/8 e 172.16.0.0/12, bloccando tutto il resto.
🔴 OSSERVATORIO INTELLIGENCE: APT & GEOPOLITICA LIVE
Questa manovra aveva un duplice obiettivo: impedire richieste di aiuto esterne e limitare la visibilità degli strumenti di sicurezza, consentendo al tempo stesso movimenti laterali e staging dei dati. Subito dopo, i file sensibili sono stati compressi con WinRAR su share di rete mappate, in preparazione a una esfiltrazione successiva che, secondo Huntress, avrebbe potuto precedere un attacco ransomware su larga scala.
Il toolkit exploit VMware ESXi e gli indicatori di maturità
Il cuore dell’attacco è rappresentato da un toolkit exploit ESXi estremamente maturo, caratterizzato da stringhe in cinese semplificato e da una compatibilità sorprendentemente ampia: 155 build ESXi, incluse versioni end-of-life. Secondo Huntress, il toolkit potrebbe essere stato sviluppato come zero-day almeno un anno prima della divulgazione pubblica delle vulnerabilità.
Il coordinamento dell’attacco è affidato a un binario denominato exploit.exe, chiamato internamente Maestro, che orchestra tutte le fasi: disabilitazione dei driver VMware, caricamento di driver kernel malevoli, exploit della fuga da VM e ripristino dello stato per ridurre i sospetti.
Le vulnerabilità sfruttate: CVE confermate in natura
L’attacco sfrutta una catena di tre vulnerabilità critiche, tutte confermate come attivamente sfruttate in natura anche dal Microsoft Threat Intelligence Center e corrette da VMware con l’advisory VMSA-2025-0004, pubblicato il 4 marzo 2025.
La CVE-2025-22226 (CVSS 7.1) è un out-of-bounds read nel componente HGFS, che consente di leakare memoria dal processo VMX. Questa vulnerabilità viene usata per ottenere informazioni critiche come indirizzi base, fondamentali per aggirare l’ASLR.
La CVE-2025-22224 (CVSS 9.3) sfrutta una condizione TOCTOU nel componente VMCI, permettendo un out-of-bounds write e quindi esecuzione di codice nel contesto VMX.
La catena si completa con la CVE-2025-22225 (CVSS 8.2), che consente una scrittura arbitraria in ESXi, permettendo la fuga dalla sandbox VMX al kernel dell’hypervisor. È questo passaggio a trasformare un compromesso di una singola VM in un controllo completo dell’host ESXi.
VMX: il bersaglio ideale per la fuga da VM
Il processo VMX è centrale nell’architettura ESXi. Ogni VM in esecuzione possiede il proprio processo VMX, responsabile della gestione dell’I/O verso dispositivi non critici per le performance, della console remota, degli snapshot e delle funzionalità di VMware Tools come clipboard e drag-and-drop.
Proprio perché processa input non fidato proveniente dal guest, VMX rappresenta un bersaglio ideale. Sebbene operi in una sandbox, una volta compromesso diventa il trampolino perfetto per raggiungere il kernel dell’hypervisor.
Dettaglio tecnico dell’exploit: VMCI, driver unsigned e shellcode
L’exploit segue un flusso rigoroso. Maestro disabilita prima il dispositivo PCI VMware VMCI e il relativo driver host, usando devcon.exe, per evitare conflitti e crash. Successivamente carica un driver kernel unsigned, denominato MyDriver.sys, aggirando il Driver Signature Enforcement tramite KDU, una tecnica classica di Bring Your Own Vulnerable Driver.
Il comando kdu.exe -prv 1 -map MyDriver.sys mappa il driver in memoria kernel, consentendogli di scansionare il bus PCI, individuare il dispositivo VMCI e interagire direttamente con i registri I/O tramite offset specifici. Questo accesso a basso livello viene usato per manipolare lo stato VMCI, innescare la vulnerabilità TOCTOU e corrompere la memoria del processo VMX.
Una volta ottenuta l’esecuzione di codice come VMX, il driver sfrutta la CVE-2025-22225 per evadere la sandbox e installare shellcode persistente nel kernel ESXi, aprendo la strada a una backdoor sull’hypervisor.
Compatibilità estrema: 155 build ESXi supportate
Uno degli aspetti più allarmanti è la tabella hardcoded di 155 build ESXi, ciascuna con 17 offset specifici per le strutture interne VMX. Il driver identifica la versione host interrogando il VMware Guest SDK con guestlib.stat.get text session, estrae la stringa di build e seleziona gli offset corretti. Se la build non è presente, l’exploit si interrompe.
Questo livello di precisione indica testing esteso, accesso a molte versioni ESXi e un investimento di risorse significativo, incompatibile con campagne opportunistiche.
Blind spot difensivi: traffico VSOCK invisibile
Un ulteriore problema difensivo è il traffico VSOCK tra VM e hypervisor, invisibile a firewall e IDS di rete. Huntress sottolinea che il monitoraggio deve avvenire direttamente sull’host ESXi, ad esempio usando comandi come lsof -a, perché la rete tradizionale non vede queste comunicazioni.
Questo dettaglio ribadisce che la sicurezza ESXi non può essere demandata solo a strumenti perimetrali, ma richiede telemetria host-based e controlli specifici sull’hypervisor.
Impatto strategico e raccomandazioni
Secondo Huntress, l’attacco osservato aveva tutte le caratteristiche di una preparazione a ransomware, fermata solo dall’intervento tempestivo del Tactical Response Team e del SOC. La presenza di stringhe in cinese semplificato suggerisce attori well-resourced, potenzialmente legati a ecosistemi di sviluppo malware dell’area sinofona.
La lezione è chiara: le VM non sono muri invalicabili. Le organizzazioni devono patchare ESXi in modo aggressivo, soprattutto dove persistono versioni end-of-life senza fix, monitorare tecniche BYOD e proteggere con la massima priorità i gateway VPN, perché l’accesso iniziale resta il punto di partenza di compromissioni devastanti.
Domande frequenti sugli exploit ESXi con fuga da VM
Che cos’è una fuga da VM su ESXi?
È una tecnica che consente a un attaccante di uscire dall’ambiente isolato di una macchina virtuale e ottenere accesso al processo VMX o direttamente al kernel dell’hypervisor ESXi.
Le vulnerabilità sfruttate sono state corrette da VMware?
Sì, VMware ha rilasciato le patch con l’advisory VMSA-2025-0004 il 4 marzo 2025, ma i sistemi non aggiornati restano vulnerabili.
Perché questo exploit è considerato particolarmente grave?
Perché supporta 155 build ESXi, indica uno sviluppo maturo e permette il controllo completo dell’host, compromettendo tutte le VM residenti.
Come si può difendere un’infrastruttura ESXi?
Patch tempestive, protezione rigorosa delle VPN, monitoraggio host-based su ESXi e attenzione a tecniche BYOD sono misure essenziali per ridurre il rischio.
