Persistenza su ESXi via VIB Malevoli: vSphere Installation Bundles (T1505.006)

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

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://:514

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.

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.

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.