Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità

VMware ESXi violato dall’interno: quando l’isolamento delle VM smette di esistere

8 Gennaio 2026 08:12

Un nuovo report pubblicato dall’Huntress Tactical Response Team documenta un’intrusione estremamente sofisticata individuata nel dicembre 2025, nella quale un attore avanzato è riuscito a compromettere un’infrastruttura VMware ESXi sfruttando una VM escape, ovvero l’evasione da una macchina virtuale guest verso l’hypervisor sottostante.

Secondo gli analisti, l’attacco si basa su un toolkit sviluppato e operativo molto prima della divulgazione pubblica delle vulnerabilità sfruttate, evidenziando come alcune falle critiche dell’ecosistema di virtualizzazione siano state probabilmente utilizzate come zero-day per oltre un anno.

L’accesso iniziale: un errore banale, non un exploit

Contrariamente a quanto ci si potrebbe aspettare da un’operazione di questo livello, l’accesso iniziale non è avvenuto tramite una vulnerabilità dell’hypervisor, ma attraverso la compromissione di un account VPN SonicWall.

Da qui, gli aggressori hanno ottenuto accesso a un ambiente Windows interno e hanno iniziato una fase di movimento laterale che li ha portati da un Domain Controller di backup al Domain Controller primario.

Solo dopo aver consolidato il controllo sull’infrastruttura Windows, gli attaccanti hanno distribuito un toolkit avanzato orchestrato da un binario denominato “MAESTRO” (exploit.exe), utilizzato come componente di coordinamento dell’intera catena di attacco.

Escalation su Windows e preparazione dell’ambiente

All’interno dei sistemi Windows compromessi, riportano i ricercatori di Huntress, il toolkit ha sfruttato la tecnica Bring Your Own Vulnerable Driver (BYOVD) per ottenere privilegi a livello kernel. In questa fase viene caricato un driver malevolo non firmato, MyDriver.sys, il cui scopo non è colpire l’hypervisor ESXi, bensì:

  • disattivare o aggirare le protezioni di sicurezza (EDR, HVCI, DSE);
  • ottenere controllo completo del sistema Windows;
  • preparare l’ambiente per le fasi successive dell’attacco.

È importante sottolineare che ESXi non esegue codice Windows e che il BYOVD rappresenta esclusivamente una fase di escalation e consolidamento all’interno dell’infrastruttura Microsoft, fungendo da trampolino di lancio verso l’ambiente di virtualizzazione.

La VM Escape: colpire il confine tra guest e host

La fase più critica dell’operazione è rappresentata dalla VM escape, ottenuta sfruttando una o più vulnerabilità nell’interfaccia tra guest e hypervisor. Questo tipo di attacco non “disabilita i driver VMware dall’interno della VM”, ma colpisce bug nell’emulazione hardware o nei meccanismi di comunicazione guest-host, come i processi vmx e i device virtuali.

Il report collega l’attacco allo sfruttamento delle vulnerabilità successivamente identificate come:

Al momento dell’intrusione, tali vulnerabilità non erano ancora di dominio pubblico, suggerendo un utilizzo attivo come zero-day prima della disclosure ufficiale da parte di VMware.

Come sottolinea Huntress: “L’isolamento delle macchine virtuali non è assoluto. Vulnerabilità dell’hypervisor possono consentire agli attaccanti di evadere dalla VM guest e compromettere tutti i workload presenti sull’host.”

VSOCKpuppet: controllo stealth fuori dalla rete

Una volta ottenuto l’accesso all’host ESXi, gli aggressori hanno evitato deliberatamente l’uso delle tradizionali comunicazioni di rete, che sarebbero state intercettabili da firewall, IDS o sistemi NDR. Al loro posto, hanno implementato una backdoor denominata VSOCKpuppet.

Questo malware sfrutta VSOCK (Virtual Sockets), un canale di comunicazione ad alta velocità progettato per il traffico host-guest all’interno degli ambienti VMware. L’abuso di VSOCK consente agli attaccanti di:

  • comunicare al di fuori dello stack di rete tradizionale;
  • eludere completamente il monitoraggio perimetrale e di livello L3/L4;
  • mantenere una shell di controllo difficilmente rilevabile dai sistemi di sicurezza basati sulla rete.

L’attività rimane visibile a livello di host ESXi, ma risulta opaca ai controlli di sicurezza di tipo network-centric.

Tracce di sviluppo e uso prolungato come zero-day

Durante l’analisi forense, i ricercatori hanno individuato stringhe in cinese semplificato all’interno dei percorsi di sviluppo, inclusa una directory denominata “全版本逃逸-交付”, traducibile come “Escape di tutte le versioni – consegna”.

I timestamp e i riferimenti presenti nei file PDB indicano che il toolkit era già pronto e operativo nel febbraio 2024, più di un anno prima della divulgazione pubblica delle CVE sfruttate.

Secondo Huntress: “La cronologia di sviluppo suggerisce che questo exploit sia esistito come zero-day per un periodo prolungato, evidenziando il rischio rappresentato da attori ben finanziati con accesso continuativo a vulnerabilità non corrette.”

Una compatibilità estesa e un rischio sistemico

Il toolkit risulta progettato come una vera e propria chiave universale, con supporto dichiarato per 155 build di VMware ESXi, dalla versione 5.1 fino alla 8.0, includendo numerose release end-of-life ancora ampiamente diffuse in ambienti enterprise.

Le raccomandazioni di Huntress

Huntress invita le organizzazioni a rivedere l’assunto secondo cui la virtualizzazione rappresenti una barriera di sicurezza intrinseca. Le raccomandazioni includono:

  • applicare patch a ESXi in modo aggressivo e tempestivo;
  • eliminare l’uso di versioni non più supportate;
  • implementare monitoraggio diretto sugli host ESXi, non limitandosi ai controlli perimetrali;
  • trattare l’hypervisor come un asset critico al pari dei Domain Controller.

Il messaggio finale è chiaro: affidarsi esclusivamente all’isolamento delle VM e alle difese di rete non è più sufficiente.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Silvia Felici 150x150
Red Hot Cyber Security Advisor, Open Source e Supply Chain Network. Attualmente presso FiberCop S.p.A. in qualità di Network Operations Specialist, coniuga la gestione operativa di infrastrutture di rete critiche con l'analisi strategica della sicurezza digitale e dei flussi informativi.
Aree di competenza: Network Operations, Open Source, Supply Chain Security, Innovazione Tecnologica, Sistemi Operativi.
Visita il sito web dell'autore

Articoli in evidenza

Immagine del sitoCybercrime
Campagna di phishing su Signal in Europa: sospetto coinvolgimento di attori statali
Bajram Zeqiri - 07/02/2026

Le autorità tedesche hanno recentemente lanciato un avviso riguardante una sofisticata campagna di phishing che prende di mira gli utenti di Signal in Germania e nel resto d’Europa. L’attacco si concentra su profili specifici, tra…

Immagine del sitoInnovazione
Robot in cerca di carne: Quando l’AI affitta periferiche. Il tuo corpo!
Silvia Felici - 06/02/2026

L’evoluzione dell’Intelligenza Artificiale ha superato una nuova, inquietante frontiera. Se fino a ieri parlavamo di algoritmi confinati dietro uno schermo, oggi ci troviamo di fronte al concetto di “Meatspace Layer”: un’infrastruttura dove le macchine non…

Immagine del sitoCybercrime
DKnife: il framework di spionaggio Cinese che manipola le reti
Pietro Melillo - 06/02/2026

Negli ultimi anni, la sicurezza delle reti ha affrontato minacce sempre più sofisticate, capaci di aggirare le difese tradizionali e di penetrare negli strati più profondi delle infrastrutture. Un’analisi recente ha portato alla luce uno…

Immagine del sitoVulnerabilità
Così tante vulnerabilità in n8n tutti in questo momento. Cosa sta succedendo?
Agostino Pellegrino - 06/02/2026

Negli ultimi tempi, la piattaforma di automazione n8n sta affrontando una serie crescente di bug di sicurezza. n8n è una piattaforma di automazione che trasforma task complessi in operazioni semplici e veloci. Con pochi click…

Immagine del sitoInnovazione
L’IA va in orbita: Qwen 3, Starcloud e l’ascesa del calcolo spaziale
Sergio Corpettini - 06/02/2026

Articolo scritto con la collaborazione di Giovanni Pollola. Per anni, “IA a bordo dei satelliti” serviva soprattutto a “ripulire” i dati: meno rumore nelle immagini e nei dati acquisiti attraverso i vari payload multisensoriali, meno…