Persistenza su ESXi via VIB Malevoli: vSphere Installation Bundles (T1505.006)
Gli hypervisor VMware ESXi rappresentano il cuore pulsante di migliaia di data center e, proprio per questo, sono diventati un bersaglio di altissimo valore per gli attaccanti più sofisticati. La tecnica T1505.006 – vSphere Installation Bundles sfrutta il meccanismo nativo di distribuzione software di ESXi — i cosiddetti VIB — per impiantare codice malevolo che sopravvive ai riavvii dell'host, un risultato tutt'altro che scontato su un sistema operativo che vive quasi interamente in RAM.
La tecnica si colloca nella fase di Persistence (TA0003), quella in cui l'avversario ha già ottenuto accesso privilegiato all'hypervisor e cerca un modo per mantenerlo nel tempo. Il filesystem in-memory di ESXi cancella quasi tutto al reboot, ma i VIB rappresentano un'eccezione progettuale: sono pensati per applicare patch, driver e configurazioni che devono persistere. Un attaccante che confeziona un VIB malevolo può inserire script di avvio, regole firewall personalizzate e backdoor binarie che vengono reinstallate a ogni boot, rendendo l'impianto estremamente resiliente.
I numeri di questa tecnica parlano chiaro: 1 gruppo APT documentato, 1 software specifico e 3 mitigazioni applicabili. Pochi attori, ma con un impatto potenzialmente devastante sull'intera infrastruttura virtuale di un'organizzazione.
La simulazione di questa tecnica richiede un laboratorio ESXi dedicato — mai su ambienti di produzione — con accesso SSH abilitato e credenziali privilegiate. L'obiettivo è dimostrare come un attaccante con accesso root possa confezionare un VIB malevolo e installarlo in modo persistente.
Un VIB è composto da tre elementi: il payload (un archivio .vgz con i file da distribuire), un file di firma che ne certifica l'acceptance level e un descrittore XML con i metadati. In un esercizio red team, il primo passo è costruire questa struttura partendo da un VIB legittimo come template.
Per abbassare le difese dell'host e permettere l'installazione di VIB non firmati, si modifica l'acceptance level:
esxcli software acceptance set --level CommunitySupported
Questo comando porta l'host ad accettare pacchetti senza firma di partner VMware certificati. In alternativa, l'installazione forzata bypassa completamente il controllo:
esxcli software vib install --force -v /tmp/malicious.vib
Il flag --force ignora sia la verifica della firma sia eventuali conflitti con VIB già presenti. Un attaccante reale potrebbe anche usare --no-sig-check per saltare esplicitamente la validazione crittografica.
Per la costruzione del payload, il red teamer prepara uno script di avvio da posizionare nel percorso persistente /etc/rc.local.d/. Questo è uno dei pochi punti del filesystem ESXi che sopravvive al reboot quando distribuito via VIB. Lo script potrebbe aprire un listener su una porta specifica o modificare le regole del firewall integrato:
esxcli network firewall ruleset set --enabled true --ruleset-id=customBackdoor
Per verificare la corretta installazione e persistenza, dopo il reboot si controlla la lista dei VIB installati:
esxcli software vib list | grep -i "nome_vib_test"
Il tool VIB Author (gratuito, distribuito da VMware/Broadcom) è lo strumento ufficiale per creare pacchetti VIB personalizzati e rappresenta il punto di partenza per costruire il payload di test. Per la parte di post-exploitation e lateral movement verso altre VM, il framework Metasploit (open source) offre moduli specifici per ambienti VMware, sebbene non includa un modulo dedicato alla creazione di VIB malevoli — che va quindi gestita manualmente.
È fondamentale documentare ogni passaggio e ripristinare l'acceptance level originale al termine del test:
esxcli software acceptance set --level PartnerSupported
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo
Il monitoraggio di questa tecnica richiede visibilità diretta sugli host ESXi, un punto spesso debole nelle architetture SOC tradizionali che si concentrano su endpoint Windows e Linux. Le log source critiche sono tre: esxi:esxupdate per tracciare le installazioni di VIB, esxi:shell per catturare i comandi eseguiti via SSH o dalla console, e un sistema di file integrity monitoring per rilevare modifiche ai percorsi persistenti.
La detection principale ruota attorno a una catena comportamentale in tre fasi. Primo: l'installazione di un VIB non firmato o forzato, identificabile dal comando esxcli software vib install accompagnato dai flag --force o --no-sig-check. Secondo: la comparsa di script o binari nei percorsi di avvio persistenti, in particolare sotto /etc/rc.local.d/. Terzo: la sopravvivenza di queste modifiche dopo un reboot, segno inequivocabile di persistenza riuscita.
Per il forwarding dei log ESXi verso il SIEM, la configurazione del syslog remoto è essenziale. Sul host ESXi:
esxcli system syslog config set --loghost=udp://
Una regola di correlazione efficace deve intercettare le modifiche all'acceptance level dell'host. Ogni esecuzione di esxcli software acceptance set con valore diverso da PartnerSupported o VMwareCertified merita un alert ad alta severità, perché in ambienti di produzione non c'è quasi mai una ragione operativa per abbassare questo livello.
Il tuning dei falsi positivi richiede attenzione a tre scenari. Alcuni ambienti utilizzano legittimamente VIB di tipo CommunitySupported per driver di terze parti o tool di monitoraggio: è necessario mantenere una whitelist aggiornata dei publisher autorizzati. Le finestre di patching pianificate generano installazioni VIB massive che vanno filtrate per contesto temporale. Infine, la soglia di alert sulla frequenza di installazione va calibrata — più di 2-3 installazioni VIB per host in 24 ore fuori da una finestra di manutenzione è anomalo.
Un controllo preventivo potente è l'abilitazione della funzionalità execInstalledOnly, che impedisce l'esecuzione di qualsiasi binario non distribuito tramite un VIB firmato. Questo riduce drasticamente la superficie d'attacco, ma richiede validazione accurata prima dell'attivazione per non bloccare tool di gestione legittimi.
Per la verifica periodica proattiva, uno script schedulato che esegua esxcli software vib signature verify e confronti l'output con una baseline nota rappresenta un controllo detective a basso costo e alta efficacia.
Vuoi diventare SOC Analyst ma non sai da dove iniziare?
Scarica la guida gratuita e scopri come si monitorano e bloccano gli attacchi informatici
L'analisi forense su ESXi presenta sfide uniche legate al filesystem in-memory: gran parte degli artefatti volatili scompare al reboot, rendendo il triage a caldo prioritario rispetto a qualsiasi altra operazione. Se l'host è ancora acceso, il primo passo è acquisire lo stato corrente prima di qualunque intervento.
L'elenco dei VIB installati rappresenta il punto di partenza dell'indagine:
esxcli software vib list
Ogni VIB riporta nome, versione, vendor, data di installazione e acceptance level. I VIB con acceptance level CommunitySupported o con vendor sconosciuti meritano attenzione immediata. La verifica delle firme aggiunge un secondo livello di analisi:
esxcli software vib signature verify
Un VIB con firma non valida o assente è un indicatore forte di compromissione. L'analista deve estrarre il pacchetto VIB sospetto per analisi offline — i payload .vgz si trovano tipicamente sotto /var/log/vmware/ o nella directory temporanea usata per l'installazione.
La ricostruzione della timeline si concentra su diversi artefatti. I log di esxupdate registrano ogni operazione di installazione e rimozione VIB con timestamp precisi. I file sotto /etc/rc.local.d/ devono essere esaminati riga per riga: qualsiasi script che apre porte di rete, modifica regole firewall o lancia processi in background è sospetto. La directory /bootbank/ contiene i VIB che vengono caricati al boot e rappresenta lo storage persistente da cui l'impianto si rigenera.
Per correlare l'attività dell'attore UNC3886, l'analista cerca la presenza del malware VIRTUALPIE, un impianto specificamente distribuito tramite VIB malevoli su server ESXi. Gli artefatti correlati includono listener su porte hardcoded, regole firewall personalizzate non riconducibili a configurazioni note e script di avvio che eseguono binari con nomi generici progettati per mimetizzarsi tra i componenti legittimi di VMware.
Il descrittore XML del VIB sospetto va esaminato con attenzione: un attaccante sofisticato modifica i campi del descrittore per far apparire il pacchetto come PartnerSupported, mascherando il livello di accettazione reale. Il confronto dell'hash del descrittore con repository ufficiali VMware permette di smascherare questa manipolazione.
Se l'host è stato riavviato prima dell'acquisizione, l'analisi è più limitata ma non impossibile: i VIB persistono per definizione in /bootbank/, e i log syslog inoltrati a un server remoto conservano la storia delle operazioni eseguite sull'host.
Vuoi diventare Forensic Analyst ma non sai da dove iniziare?
Scarica la guida gratuita e segui il percorso corretto per analizzare incidenti e prove digitali
Il panorama degli attori che sfruttano VIB malevoli è attualmente ristretto ma di altissimo profilo. L'unico gruppo documentato nell'utilizzo di questa tecnica è UNC3886, un threat actor con capacità avanzate focalizzato sull'infiltrazione di infrastrutture di virtualizzazione.
UNC3886 dimostra una comprensione profonda dell'ecosistema VMware che va ben oltre la semplice compromissione di credenziali. L'utilizzo di VIB come vettore di persistenza rivela una conoscenza dettagliata dell'architettura interna di ESXi — dal meccanismo di boot alla struttura del filesystem, dalle modalità di firma dei pacchetti alle directory persistenti. Questo livello di specializzazione suggerisce un investimento significativo in ricerca e sviluppo, tipico di attori state-sponsored con risorse dedicate.
Il software VIRTUALPIE è lo strumento specifico associato a questa tecnica. Si tratta di un impianto progettato per operare nativamente su ESXi, distribuito attraverso VIB malevoli. La scelta di sviluppare malware nativo per l'hypervisor piuttosto che compromettere le macchine virtuali ospitate indica una strategia deliberata: controllare l'hypervisor significa avere accesso potenziale a tutte le VM in esecuzione, con la possibilità di intercettare memoria, disco e traffico di rete a un livello che le difese endpoint tradizionali non possono rilevare.
Dal punto di vista del targeting, questa tecnica si presta a operazioni di spionaggio a lungo termine piuttosto che a campagne distruttive. La persistenza tramite VIB è silenziosa, resiliente ai riavvii e difficile da individuare senza controlli specifici sull'hypervisor — caratteristiche ideali per attori interessati alla raccolta continuativa di informazioni.
Il trend di fondo è preoccupante: man mano che le organizzazioni rafforzano la sicurezza degli endpoint tradizionali, gli attaccanti si spostano verso i livelli infrastrutturali meno presidiati. Gli hypervisor, i dispositivi di rete e i sistemi di storage sono i nuovi "punti ciechi" della difesa. L'intelligence analyst dovrebbe monitorare l'eventuale comparsa di nuovi tool o attori che adottano tecniche simili di persistenza a livello hypervisor, e verificare se l'organizzazione dispone di visibilità adeguata su questi asset.
Framework MITRE ATT&CK: tecnica T1505.006 (vSphere Installation Bundles), tattica TA0003 (Persistence). Gruppo: G1048 (UNC3886). Software: S1218 (VIRTUALPIE). Mitigazioni: M1046, M1045, M1047. Detection: DET0535/AN1475. Integrato con conoscenza professionale per tool e procedure operative.