Bundle Malevoli su Hypervisor: vSphere Installation Bundles (T1505.006)

La simulazione di questa tecnica in laboratorio richiede un ambiente ESXi 6.7 o 7.x isolato — mai su produzione. Il workflow classico prevede la costruzione di un VIB custom, la manipolazione dell'acceptance level e la verifica della persistenza post-reboot.

Per creare un VIB da zero il tool di riferimento è vibauthor (a pagamento, distribuito storicamente come Fling VMware) oppure il progetto community vibauthor-docker disponibile su GitHub (open source), che impacchetta l'utility in un container per evitare dipendenze legacy. La struttura base parte da una directory con lo script di persistenza — tipicamente in /etc/rc.local.d/local.sh o come init script — un file XML descriptor e un manifest. Il comando di build è nella forma vibauthor -C -t stage_dir -v output.vib -O descriptor.xml.

Sul target ESXi, la catena operativa prevede prima l'abbassamento dell'acceptance level:

esxcli software acceptance set --level=CommunitySupported

seguito dall'installazione forzata:

esxcli software vib install -v /tmp/malicious.vib --no-sig-check --force

Un approccio più stealth consiste nel modificare il tag <acceptance-level> del descriptor XML e ricalcolare gli hash SHA-256 dichiarati nel manifest, in modo che il bundle appaia come PartnerSupported senza necessità di flag sospetti nei log.

Per il payload persistente, l'attaccante inserisce nello script di boot regole firewall aggiuntive tramite esxcli network firewall ruleset per aprire porte C2, oppure copia un binario ELF statico nella partizione bootbank che viene rimontata a ogni avvio. La partizione /bootbank e /altbootbank sono i target chiave perché sopravvivono al reboot, a differenza della maggior parte del filesystem.

Per red team che operano contro ambienti VMware maturi, strumenti come Chainsaw (open source) e PowerCLI (gratuito, VMware) permettono di enumerare VIBs installati e acceptance level via Get-EsxCli -V2. La verifica post-exploitation avviene con esxcli software vib list per confermare la presenza del bundle e esxcli software vib get -n nome_vib per esaminarne i metadati.

Documentare in report la catena completa — dall'ottenimento delle credenziali root o dell'accesso SSH all'ESXi, fino alla persistenza — è cruciale per dimostrare l'impatto sistemico oltre la singola compromissione.

La detection di VIBs malevoli si fonda sul monitoraggio combinato di log ESXi, integrità del filesystem e telemetria di rete verso vCenter. Il rilevamento primario, come indicato dall'analitica AN1475, ruota intorno alla catena comportamentale: installazione di VIB non firmato o con flag di bypass, seguita dalla comparsa di script o binari nei percorsi di boot persistenti, seguita da attività anomala post-reboot.

Le log source critiche sono tre. Primo, esxupdate.log (/var/log/esxupdate.log) traccia ogni operazione di installazione VIB con timestamp, utente, nome del bundle e acceptance level accettato — un alert deve scattare su qualsiasi occorrenza di --force o --no-sig-check, oppure su installazioni di VIB con acceptance level CommunitySupported se la policy aziendale ammette solo PartnerSupported o superiore. Secondo, shell.log (/var/log/shell.log) registra i comandi eseguiti in ESXi Shell: qui si osservano invocazioni sospette di esxcli software acceptance set verso livelli permissivi. Terzo, un agente di File Integrity Monitoring compatibile con ESXi — configurabile via vRealize Log Insight (a pagamento) o esportando i log verso un SIEM centrale — monitora modifiche in /etc/rc.local.d/, /bootbank/ e /altbootbank/.

Le regole di correlazione più efficaci combinano eventi in finestre di 30 minuti: un comando di abbassamento acceptance level seguito da un'installazione VIB e da modifiche a percorsi di boot costituisce un pattern ad alta confidenza. Un secondo pattern è l'installazione di un VIB il cui nome non compare in nessuna baseline aziendale di bundle approvati.

Il tuning richiede attenzione perché ambienti di sviluppo o laboratori interni possono legittimamente installare VIBs CommunitySupported: la mitigazione è filtrare per publisher noti tramite whitelist. Anche la frequenza di installazione va calibrata — durante finestre di patching massivo si generano decine di eventi legittimi, quindi le soglie devono essere host-specifiche.

Sul fronte preventivo, le mitigazioni M1045 (Code Signing) e M1046 (Boot Integrity) vanno applicate abilitando execInstalledOnly per impedire l'esecuzione di binari non firmati e attivando UEFI Secure Boot su tutti gli host ESXi, che valida la firma di kernel e moduli durante il bootstrap. La mitigazione M1047 (Audit) si concretizza in scansioni periodiche con esxcli software vib list e esxcli software vib signature verify, i cui output vanno confrontati contro una baseline mantenuta in configuration management.

Infine, restringere l'accesso SSH e ESXi Shell tramite lockdown mode normale o strict riduce drasticamente la superficie disponibile per l'installazione manuale di VIBs.

L'analisi forense di un ESXi compromesso tramite VIB malevolo richiede un approccio metodico perché l'hypervisor non ospita EDR tradizionali e molte modifiche vivono in RAM. Il primo passo è acquisire i log persistenti tramite vm-support, l'utility ufficiale VMware (gratuita) che produce un bundle diagnostico completo: vm-support -w /vmfs/volumes/datastore_name genera un archivio .tgz con log, configurazioni e output diagnostici.

All'interno del bundle, i file di interesse primario sono esxupdate.log, shell.log, auth.log, hostd.log e vmkernel.log. Da esxupdate.log si ricostruisce la timeline di installazione dei VIBs: ogni entry riporta timestamp ISO 8601, VIB ID, versione e acceptance level accettato. Un'anomalia tipica è un'installazione con acceptance level CommunitySupported in un ambiente che normalmente accetta solo PartnerSupported, oppure la presenza del flag --force.

Per estrarre i VIBs attualmente installati e correlarli con la baseline, il comando esxcli software vib list fornisce nome, vendor, versione e data di installazione. Il comando esxcli software vib get -n nome_vib espone i metadati completi inclusi i file installati, permettendo di identificare payload sospetti — binari in /opt/, script in /etc/rc.local.d/ o moduli kernel non standard. La verifica delle firme avviene con esxcli software vib signature verify e qualsiasi VIB che risulta invalid o unsigned richiede analisi immediata.

Gli artefatti chiave nella timeline includono il VIB stesso — recuperabile da /var/db/esximg/ dove ESXi mantiene i bundle installati — gli script in /etc/rc.local.d/local.sh e nelle directory init, le regole firewall custom visibili in /etc/vmware/firewall/, e i file nella partizione /bootbank/ che è il target primario per persistenza inter-reboot. Il file boot.cfg in bootbank dichiara quali moduli vengono caricati all'avvio e va confrontato con una versione golden.

Per l'analisi statica del VIB estratto, il bundle è un archivio ar standard: ar x malicious.vib separa il payload .vgz (ulteriormente decomprimibile con gzip e tar), il descriptor XML e il file di firma. Il descriptor rivela l'acceptance level dichiarato, l'elenco file, i checksum SHA-256 e le dipendenze — discrepanze tra hash dichiarati e file effettivi sono indicatori forti di manipolazione.

Nel caso UNC3886, il malware VIRTUALPIE è stato deployato come componente di VIBs malevoli su ESXi enterprise: l'analisi dei sample pubblicamente documentati mostra binari con capability di intercettare comunicazioni tra guest VM e hypervisor. Correlare l'installazione del VIB con connessioni C2 anomale dalla management interface dell'ESXi rafforza l'attribuzione.

L'abuso di vSphere Installation Bundles è una tecnica di nicchia con bassa prevalenza numerica ma altissimo impatto strategico, adottata quasi esclusivamente da attori con obiettivi di lungo periodo su infrastrutture enterprise virtualizzate. La ragione è duplice: richiede competenze specifiche su ecosistema VMware e produce persistenza sotto il livello di visibilità della maggior parte degli stack difensivi, rendendola l'ideale per operazioni di spionaggio prolungato.

UNC3886 è l'attore di riferimento tracciato per questa tecnica. Il gruppo ha operativizzato l'installazione di VIBs malevoli come vettore per deployare famiglie di malware custom su hypervisor ESXi, tra cui VIRTUALPIE, un backdoor progettato specificamente per l'ambiente ESXi e capace di comunicare via socket con componenti sull'hypervisor e potenzialmente con guest VM tramite VMCI (Virtual Machine Communication Interface). Il modus operandi documentato prevede l'accesso iniziale tramite compromissione delle credenziali di amministrazione vCenter o exploit di vulnerabilità note di vSphere, seguito dalla distribuzione dei VIBs tramite esxcli con acceptance level bypassato o con descriptor manipolato per apparire PartnerSupported.

Il pattern di targeting osservato in questa categoria di attori si concentra su settori dove la virtualizzazione ospita workload sensibili: contractor della difesa, telco, provider di servizi finanziari e organizzazioni governative. L'obiettivo tipico non è la disruption immediata ma l'accesso persistente e stealth ai dati processati dalle VM guest, sfruttando la posizione privilegiata dell'hypervisor per intercettare traffico, memoria e storage senza toccare gli endpoint monitorati.

A livello di trend, l'aumento dell'adozione di ambienti VMware in cloud privati enterprise ha ampliato la superficie di attacco per questa tecnica. Parallelamente, la disclosure pubblica delle capability di UNC3886 ha probabilmente stimolato altri attori sofisticati a esplorare il vettore, sebbene le attribuzioni pubbliche restino concentrate su un numero ridotto di cluster.

Dal punto di vista di intelligence produttiva, gli indicatori più affidabili per il threat hunting includono VIBs con vendor string atipici, acceptance level CommunitySupported in ambienti aziendali, e correlazione temporale tra installazione di bundle e comparsa di connessioni anomale dalla management network. Il monitoraggio delle vulnerabilità di vCenter e vSphere pubblicate da VMware è essenziale perché l'accesso iniziale a livello di management console è il prerequisito quasi universale per l'installazione di VIBs malevoli.

Infine, la tecnica si sposa naturalmente con altre di post-exploitation ipervisor-level: modifica dei log ESXi per anti-forensics, disabilitazione di feature di security come Secure Boot, e utilizzo dell'hypervisor come pivot verso VM isolate in segmenti di rete altrimenti irraggiungibili.

MITRE ATT&CK T1505.006 (vSphere Installation Bundles), tattica TA0003. Gruppo G1048 (UNC3886), software S1218 (VIRTUALPIE). Mitigazioni M1045 (Code Signing), M1046 (Boot Integrity), M1047 (Audit). Detection DET0535 con analitica AN1475. Documentazione ufficiale VMware su esxcli e VIB structure. Per comandi operativi e artefatti forensi è stata integrata conoscenza professionale verificata su tool VMware ufficiali (vm-support, esxcli, PowerCLI) e progetti open source (vibauthor-docker).