VMware vCenter sotto attacco: due campagne su CVE-2026-59310 e CVE-2026-59309

🛡️ Executive Summary

• CVE-2026-59310 viene sfruttata globalmente contro vCenter: QUIRSO osserva 361 IP vittima in 47 Paesi e valuta un attore Chinese-nexus.
• La compromissione passa da root su vCenter a persistenza, furto credenziali SSO, accesso ESXi e cifratura VMFS con ransomware derivato da Babuk.
• QUIRSO rileva anche attività compatibile con CVE-2026-59309, ma la mantiene separata perché indicatori, account e infrastruttura non coincidono con l’altra campagna.

L’attacco contro VMware vCenter CVE-2026-59310 è molto più profondo di quanto emerso nelle prime rilevazioni. QUIRSO ha ricostruito una compromissione che parte dall’esecuzione di codice come root sull’appliance, costruisce più livelli di persistenza, sottrae credenziali del VMware Directory Service, crea amministratori SSO, raggiunge gli host ESXi e termina con un ransomware derivato da Babuk. La società ha associato con confidenza moderata la campagna a un attore Chinese-nexus, senza attribuirla a un gruppo APT noto o allo Stato cinese. Sullo stesso sistema emerge inoltre una precedente attività compatibile con CVE-2026-59309, che QUIRSO mantiene prudentemente come una possibile operazione parallela condotta da un attore differente.

CVE-2026-59310 raggiunge 361 indirizzi IP in 47 Paesi

La dimensione globale era emersa nella prima fase dell’indagine, ma il nuovo rapporto consente di leggerla insieme alla catena completa di compromissione. QUIRSO ha identificato 361 indirizzi IP vittima distribuiti in 47 Paesi, precisando correttamente che il numero non equivale a 361 organizzazioni perché alcuni indirizzi appartengono a provider, ambienti cloud o infrastrutture condivise.

Germania, Stati Uniti, Turchia, Iran e Francia concentrano 185 degli IP osservati, con rispettivamente 55, 41, 38, 26 e 25 sistemi. La vittimologia comprende soprattutto aziende tecnologiche e software, realtà della cybersecurity, università e centri di ricerca, telecomunicazioni e servizi di rete; nessuna vittima individuata si trova nella Cina continentale. Broadcom aveva pubblicato il bollettino VMSA-2026-0006 il 29 luglio, assegnando sia a CVE-2026-59310 sia a CVE-2026-59309 un punteggio CVSS 9.8 e specificando che non esistono workaround. I primi sistemi della campagna CVE-2026-59310 hanno iniziato a contattare l’infrastruttura dell’attaccante il 3 agosto, soltanto cinque giorni dopo la disclosure; entro il 5 agosto erano già comparsi 343 dei 361 IP, circa il 95% del totale osservato.

Matrice Digitale aveva seguito il passaggio dalla semplice disponibilità della patch allo sfruttamento reale già nell’analisi del 12 agosto su vCenter e reverse SSH, mentre il successivo aggiornamento del 17 agosto sulla campagna VMware aveva evidenziato proprio la rapidità con cui l’exploit era entrato in uso operativo. Il nuovo dossier di QUIRSO dimostra però che quel reverse SSH rappresentava soltanto una parte della compromissione.

Il Syslog di vCenter diventa un meccanismo per eseguire cron come root

La ricostruzione forense fornisce elementi particolarmente forti sul probabile sfruttamento di CVE-2026-59310 come vettore iniziale. Alle 05:47 UTC del 3 agosto, crond registra un file anomalo denominato zz-poc59310-syslog.log all’interno di /etc/cron.d, immediatamente seguito da un comando eseguito come root che scarica il payload linuxFile, lo rende eseguibile e lo avvia. QUIRSO non ha recuperato i file iniziali e quindi mantiene la formulazione prudente di “likely exploitation”, ma diversi elementi convergono: il nome poc59310 richiama direttamente il numero della CVE, il suffisso syslog.log imita il naming utilizzato dall’appliance vCenter Server per i log remoti, non compaiono autenticazioni coerenti con l’accesso e registrazioni successive mostrano in modo più leggibile una directory traversal ../../../../etc/cron.d/ inserita all’interno di messaggi syslog controllati dall’attaccante. Il risultato è particolarmente grave perché non richiede una successiva privilege escalation: l’abuso del Syslog Server permette di depositare contenuto in una posizione processata da cron e i comandi vengono eseguiti direttamente nel contesto root dell’appliance. Il nuovo rapporto tecnico di QUIRSO mostra comandi che scaricano script attraverso curl o wget, utilizzano /tmp e /tmp/.x come aree di staging e recuperano payload da più server controllati dagli operatori, Netlify e servizi pubblici di file hosting. La centralità di vCenter rende questa fase molto più pericolosa di una normale RCE Linux: come già spiegato nell’analisi delle falle VMware pubblicate il 29 luglio, il management plane controlla host, macchine virtuali, datastore, ruoli e credenziali dell’intera infrastruttura virtualizzata.

Reverse SSH, webshell e account SSO creano una persistenza multilivello

Una volta ottenuto root, l’attore non si affida a una singola backdoor. linuxFile viene copiato sotto /root/.local/share/ e mantenuto attraverso un servizio systemd configurato per riavviarlo automaticamente. Altri cronjob con nomi costruiti per sembrare componenti VMware, come vmware-vpxd-stats-*, vmware-perf-collect-* e vmware-perf-sync-*, vengono eseguiti ogni minuto e svolgono funzioni differenti: riattivano SSH, aggiungono la chiave pubblica dell’attaccante alle authorized_keys di root, installano una JSP webshell nell’applicazione Perfcharts e assegnano al legittimo account perfcharts privilegi sudo root senza password. Parallelamente viene distribuito reverse_ssh, tool open source dual-use che inverte il normale modello SSH: è il sistema compromesso ad aprire la connessione verso il server dell’operatore, offrendo shell remota, trasferimento file e forwarding senza attendere una connessione amministrativa in ingresso. QUIRSO aveva già pubblicato una YARA generica per riconoscere le build dello strumento, raccomandando di correlare l’eventuale rilevazione con esecuzione non autorizzata sull’appliance e connessioni outbound inattese. L’attaccante aggiunge quindi altri percorsi attraverso gli account adminuser e vcadmin, oltre a un ulteriore account SSO creato da remoto usando un’identità amministrativa legittima successivamente compromessa. Questa ridondanza mostra un obiettivo preciso: sopravvivere alla rimozione di un singolo impianto e mantenere contemporaneamente accesso a Linux, vCenter SSO e interfaccia Web. L’utilità del reverse SSH contro appliance di gestione era già evidente nel primo pezzo di Matrice Digitale dedicato alla campagna, ma il nuovo quadro dimostra che il tunnel rappresentava soltanto uno dei numerosi meccanismi di re-accesso.

Le credenziali vmdir trasformano root Linux in controllo amministrativo vCenter

Uno dei passaggi tecnicamente più interessanti è il furto delle credenziali interne del VMware Directory Service, vmdir. Un cronjob root decodifica uno script Base64 in /tmp/.vmware-perf-upd.sh, lo esegue e lo cancella subito dopo per ridurre gli artefatti. Lo script utilizza principalmente lwregshell per leggere dcAccountDN e dcAccountPassword dal registro interno di VMware; se questa procedura fallisce, cerca il modulo Python vmafd e richiama GetMachineName(), GetMachinePassword() e GetDomainName(). La presenza di due sistemi indipendenti per ottenere le stesse credenziali suggerisce un toolkit preparato per operare su configurazioni o versioni vCenter differenti. Recuperata la password della machine identity, il payload si autentica direttamente al servizio LDAP locale di vmdir su LDAPS 636 oppure LDAP 389, crea l’account SSO adminuser con password hard-coded e lo inserisce nel gruppo built-in Administrators. In altri termini, la compromissione non rimane confinata al sistema operativo della VCSA: l’attore utilizza root per appropriarsi delle credenziali di fiducia interne e trasformarle in controllo legittimo del piano di identità vSphere. Questa capacità è particolarmente importante perché da quel momento API, SOAP, UI e datastore possono essere utilizzati attraverso identità amministrative create dall’attaccante anziché tramite semplici shell Linux. Gli exploit contro VMware ESXi analizzati da Matrice Digitale nel gennaio 2026 avevano già mostrato quanto sia fragile il confine tra workload e hypervisor quando viene conquistato un livello privilegiato: l’attacco reale con toolkit compatibile con 155 build ESXi rappresentava il percorso guest-to-host, mentre questa campagna compie il movimento inverso partendo dal control plane centrale per raggiungere l’intera flotta ESXi.

CVE-2026-59309 compare prima dell’attacco ma potrebbe appartenere a un altro attore

Lo stesso vCenter presentava però attività sospetta antecedente alla catena CVE-2026-59310. Il 1° agosto, un indirizzo IP remoto aveva interrogato l’endpoint SAML con uno user agent insolito, GoodMoodle-VCProbe/1.0, e pochi minuti dopo risultava creato un nuovo account amministrativo vcenter_admin all’interno di VMware Directory Service. Nei log non compare una sessione del legittimo amministratore indicato come creatore dell’account. Il 3 agosto lo stesso IP utilizza quindi l’API REST vSphere con un secondo user agent, GoodMoodle-VCFleet/1.0, per enumerare versione, datacenter, cluster, host, VM, datastore e reti. CVE-2026-59309 è precisamente un authentication bypass nel VMware Directory Service e Broadcom afferma che un attaccante con accesso di rete può sfruttarla per superare l’autenticazione e ottenere accesso non autorizzato a vCenter. La successione è quindi compatibile con la vulnerabilità, ma QUIRSO evita correttamente di presentarla come prova definitiva. Soprattutto, l’account vcenter_admin, gli IP e i due user agent non ricompaiono nella catena successiva di CVE-2026-59310 e non esiste al momento un collegamento infrastrutturale sufficientemente forte. I ricercatori mantengono perciò l’attività come track separato e possibile operazione di un secondo attore. Questa distinzione è essenziale: Broadcom ha corretto entrambe le falle nello stesso advisory e lo stesso sistema può essere stato raggiunto attraverso entrambe, ma la coesistenza temporale non dimostra automaticamente un’unica campagna. È anche il motivo per cui la nuova ricerca amplia il quadro rispetto alle prime notizie sulla doppia esposizione pre-auth di VMware vCenter: oggi esistono evidenze operative per entrambe le superfici, ma solo la catena CVE-2026-59310 viene collegata con sufficiente continuità all’intrusione culminata nel ransomware.

Dagli account SSO agli host ESXi fino al ransomware Babuk-derived

Il punto finale mostra perché la compromissione di vCenter rappresenti un rischio sistemico. Dopo avere creato amministratori SSO e utilizzato API e UI per enumerare l’ambiente, l’attore crea un account locale adminuser su ciascun host ESXi. Attraverso la datastore browser API carica quindi due file denominati backup e run.sh, nomi costruiti per apparire innocui. Lo script disabilita execInstalledOnly, concede permessi di esecuzione al payload, termina forzatamente le macchine virtuali evitando alcune istanze di servizio e avvia il ransomware contro i volumi VMFS. Come passaggio ulteriore rimuove vmware-fdm, agente utilizzato da vSphere High Availability, probabilmente con l’obiettivo di ostacolare failover e recupero. Il binario backup cifra i file e applica l’estensione .babyk; sui grandi dischi VMDK limita la cifratura ai primi 512 MB, strategia che accelera enormemente l’impatto perché non è necessario processare interamente file virtual disk da centinaia di gigabyte. Il codice appartiene alla famiglia derivata da Babuk, ma QUIRSO sottolinea un limite attributivo importante: dopo il leak del builder Babuk nel 2021, gli encryptor ESXi basati su quel codice sono stati riutilizzati da numerosi gruppi e non costituiscono una firma affidabile dell’operatore. L’obiettivo tattico è invece chiaro. Colpire ESXi consente di spegnere e cifrare molte macchine virtuali dal livello sottostante, moltiplicando l’impatto rispetto all’attacco contro singoli server. Matrice Digitale ha documentato questa strategia sia con TR-Kyber contro sistemi Windows ed ESXi sia nell’approfondimento dedicato ai gruppi ransomware che scelgono VMware ESXi come moltiplicatore operativo.

QUIRSO vede un attore Chinese-nexus ma non attribuisce l’operazione a Pechino

L’attribuzione è costruita su un insieme di indicatori e viene espressa con confidenza moderata. QUIRSO ha trovato commenti e artefatti in lingua cinese negli script creati dall’attaccante, strumenti e software di gestione frequentemente utilizzati in ambienti cinesi, possibili elementi di riuso derivati da una ricerca di sicurezza cinese, orari di attività compatibili con UTC+8 e una vittimologia globale dalla quale risulta assente la Cina continentale. Un errore di operational security ha inoltre esposto quello che potrebbe essere un sistema di test o staging: nei log del backend reverse_ssh compare una macchina kali.kali proveniente dall’indirizzo 146.56.116.119, usata per provare diverse build del client contro l’infrastruttura poi impiegata in produzione. La rapidità conta anch’essa nella valutazione. L’exploitation inizia circa cinque giorni dopo la pubblicazione della CVE e QUIRSO non era a conoscenza, in quel momento, di un proof-of-concept pubblico funzionante: sviluppare o acquisire un exploit affidabile, preparare l’infrastruttura e raggiungere centinaia di sistemi in un intervallo così ridotto è coerente con un operatore dotato di risorse e capacità superiori a quelle di una scansione opportunistica ordinaria. Questo non basta però ad attribuire la campagna a APT41, Volt Typhoon, Salt Typhoon o qualsiasi altro gruppo noto, né dimostra una direzione statale cinese. QUIRSO la mantiene quindi come uncategorized Chinese-nexus intrusion set. La prudenza è particolarmente necessaria nel panorama VMware, dove Matrice Digitale ha già seguito toolkit ESXi con stringhe in cinese osservati in attacchi reali senza che il semplice artefatto linguistico fosse sufficiente a risolvere l’attribuzione.

Patchare vCenter non basta quando l’appliance ha già eseguito codice root

Per i sistemi non ancora compromessi la risposta resta netta: installare le versioni corrette indicate da Broadcom per CVE-2026-59309 e CVE-2026-59310 e ridurre al minimo l’esposizione del management plane verso reti non fidate. Per gli ambienti nei quali compaiono indicatori della campagna, però, la semplice applicazione della patch non può essere considerata sufficiente. L’attore crea servizi systemd, cronjob persistenti, chiavi SSH root, webshell JSP, modifiche a sudoers, nuovi account SSO e locali ESXi e backdoor reverse SSH; recupera inoltre la machine password di vmdir e utilizza credenziali amministrative già presenti. Una risposta efficace deve quindi comprendere ricostruzione dell’appliance, rotazione delle credenziali, revisione completa degli account SSO, controllo degli host ESXi, verifica dei datastore e hunting sull’egress, oltre alla ricerca degli indicatori pubblicati da QUIRSO. La Shadowserver Foundation, che ha collaborato all’elaborazione dei dati, ha predisposto un report speciale per notificare gli operatori dei sistemi potenzialmente compromessi. L’incidente conferma così il rischio specifico delle piattaforme di virtualizzazione: un singolo difetto pre-auth non offre soltanto una shell su un server, ma può consegnare all’attaccante l’identità amministrativa, il piano di gestione e infine gli hypervisor che ospitano l’intera infrastruttura aziendale.