Abuso CLI Hypervisor: Hypervisor CLI (T1059.012)

In un esercizio red team contro ambienti virtualizzati VMware ESXi, l'accesso alla shell dell'hypervisor (tipicamente via SSH sulla porta 22 quando abilitato, o tramite ESXi Shell locale) apre l'accesso a una serie di CLI native estremamente potenti. Il presupposto è aver già ottenuto credenziali root o di un account con privilegi equivalenti, spesso tramite phishing verso amministratori di virtualizzazione, sfruttamento di vulnerabilità come CVE-2021-21985, o compromissione del vCenter.

Una volta sull'host, l'enumerazione delle VM avviene con vim-cmd vmsvc/getallvms, che restituisce VMID e path dei file .vmx. Per ottenere lo stato di alimentazione: vim-cmd vmsvc/power.getstate . L'operazione di terminazione forzata, replicata da Royal e Cheerscrypt, si esegue con esxcli vm process list per identificare i World ID e successivamente esxcli vm process kill --type=force --world-id=. Questo pattern è il preludio classico alle operazioni di cifratura sul datastore.

Per manipolare il firewall ESXi, riproducendo TTP di UNC3886, si usa esxcli network firewall ruleset set --enabled=true --ruleset-id=sshServer per abilitare SSH, oppure esxcli network firewall set --enabled false per disattivare completamente il filtraggio. La configurazione del forwarding dei log verso un syslog controllato dall'attaccante (o la sua disattivazione) avviene tramite esxcli system syslog config set --loghost='' seguito da esxcli system syslog reload.

Per la discovery del filesystem VMFS: esxcli storage filesystem list enumera i datastore montati, mentre la navigazione avviene sotto /vmfs/volumes/. Il deployment di payload persistenti sfrutta spesso i VIB (vSphere Installation Bundle) tramite esxcli software vib install, tecnica documentata per VIRTUALPIE e componenti correlati.

Strumenti utili in laboratorio includono PowerCLI (gratuito, VMware) per orchestrare test da workstation Windows, Metasploit Framework (open source) con moduli auxiliary per vCenter, e CrackMapExec/NetExec (open source) per credential spraying su interfacce di gestione. Per lo studio del comportamento di ransomware ESXi, il progetto Elastic Security Labs ha pubblicato analisi tecniche pubbliche di Cheerscrypt e famiglie affini.

Regola d'ingaggio: ogni test su hypervisor va condotto in ambienti isolati o con snapshot pre-esercizio, poiché la terminazione errata di VM di produzione ha impatto immediato e irreversibile sui workload dipendenti.

Il monitoraggio di T1059.012 su ESXi richiede l'ingestion centralizzata dei log dell'hypervisor, che di default non finiscono in un SIEM. La configurazione base prevede il forwarding via syslog verso un collector, monitorando specificamente hostd.log, vmkernel.log, shell.log, auth.log e vpxa.log. La detection DET0558 raccomanda di concentrarsi su due canali principali: esxi:vmkernel per l'esecuzione dei comandi e esxi:auth per l'autenticazione degli utenti che li invocano.

Gli indicatori comportamentali di alto valore includono l'esecuzione di esxcli o vim-cmd da parte di utenti non appartenenti al team di virtualizzazione, l'invocazione di questi tool al di fuori delle finestre di manutenzione pianificate, e specifici pattern di comando associati a intent malevolo. Tra i pattern da correlare in priorità: vm process kill con flag --type=force, modifiche al firewall come network firewall set --enabled false o abilitazione ruleset sshServer, alterazioni al syslog (system syslog config set), installazione VIB con community o partner acceptance level abbassato.

Una query di detection efficace correla eventi di login su auth.log con esecuzioni successive su shell.log nella stessa sessione, evidenziando sequenze come login SSH root seguito da enumerazione VM e terminazione massiva in una finestra temporale breve (tipicamente sotto i 5 minuti nei casi ransomware documentati).

Il tuning suggerito dalla detection strategy considera tre dimensioni. La TimeWindow permette di ridurre il rumore restringendo gli alert a orari fuori dai change window autorizzati; questo richiede l'integrazione con la CMDB o il sistema di ticketing. Lo UserContext distingue account amministrativi legittimi da account di servizio compromessi o utenze anomale — utile mantenere una allowlist degli operatori autorizzati. Il CommandPattern filtra sui verbi realmente sensibili (stop, reboot, firewall set, vib install) invece che su tutte le invocazioni CLI, che sarebbero ingestibili.

Sul fronte preventivo, il lockdown mode di ESXi (Normal o Strict) limita l'accesso alle sole operazioni via vCenter, riducendo la superficie CLI diretta. La disabilitazione di SSH e ESXi Shell quando non in uso, gestita centralmente, è un controllo hardening di base.

Falsi positivi tipici derivano da script di backup che invocano vim-cmd per snapshot orchestration, tool di monitoring che leggono configurazioni via esxcli, e attività di patch management durante finestre autorizzate. La baseline comportamentale per host va costruita su almeno 30 giorni per rendere significative le anomalie.

L'analisi forense di un incidente T1059.012 su ESXi presenta sfide specifiche: l'hypervisor non ha un EDR nativo, il filesystem è in gran parte in RAM, e molti log ruotano rapidamente se non forwardati esternamente. La priorità è quindi la preservazione immediata di shell.log, auth.log, hostd.log, vmkernel.log e vpxa.log, tutti localizzati sotto /var/log/ e simlinkati a /scratch/log/.

Il file shell.log contiene la trascrizione dei comandi eseguiti in ESXi Shell, con timestamp e utente, ed è la fonte primaria per ricostruire la sequenza di azioni dell'attaccante. Ogni invocazione di esxcli o vim-cmd viene registrata con la riga di comando completa. In auth.log si trovano i tentativi di login SSH, sia riusciti sia falliti, essenziali per identificare vettore d'accesso e credenziali compromesse. hostd.log documenta operazioni sulle VM (power on/off, snapshot, riconfigurazioni) mentre vpxa.log registra le comunicazioni con vCenter.

Per la timeline di un incidente ransomware attribuibile a famiglie come Royal o Cheerscrypt, la sequenza tipica ricostruibile è: accesso SSH iniziale, esecuzione di esxcli vm process list per enumerazione, serie di esxcli vm process kill con world-id incrementali, quindi comparsa di file cifrati sui datastore. I file di cifratura vengono tipicamente droppati sotto /vmfs/volumes// accanto ai .vmdk originali, con estensioni distintive per famiglia.

Artefatti aggiuntivi da acquisire includono il contenuto di /etc/vmware/firewall/ per identificare ruleset custom introdotti dall'attaccante, l'output di esxcli software vib list per rilevare VIB non autorizzati (indicatore forte di persistenza tipo VIRTUALPIE), e la configurazione syslog corrente per verificare se il forwarding sia stato manomesso. Il comando esxcli system account list mostra eventuali account locali aggiunti.

La memoria dei processi ESXi può essere acquisita con tecniche di live forensic tramite ESXi Shell, ma la finestra è breve: se l'hypervisor viene riavviato, gran parte dello stato volatile è perso. Per questo l'acquisizione della configurazione runtime va fatta prima di qualsiasi remediation.

Cross-reference importanti: correlare i timestamp di shell.log con i log del jump host o della bastion da cui è partita la sessione SSH, e con i log di autenticazione di vCenter se l'accesso è avvenuto tramite quella catena. I casi documentati di UNC3886 hanno mostrato l'uso di tecniche di log tampering che richiedono di verificare la coerenza temporale (gap sospetti) e l'integrità del forwarding sul collector esterno, unica copia affidabile se l'host è stato manipolato.

L'abuso della CLI degli hypervisor si è consolidato come tecnica strategica in due cluster distinti di threat actor: gli operatori ransomware orientati al massimo impatto economico, e i gruppi state-sponsored focalizzati su espansione furtiva in infrastrutture enterprise.

Nel primo cluster si colloca Royal, la cui operatività ransomware sfrutta esxcli come componente chiave della fase di impact. Il pattern operativo prevede l'enumerazione delle VM in esecuzione seguita dalla loro terminazione forzata, in modo da rilasciare i lock sui file .vmdk e consentire alla routine di cifratura di operare sull'intero datastore invece che sui singoli file guest. Questa scelta massimizza il danno (un solo host ESXi compromesso può paralizzare centinaia di workload) e minimizza il tempo di cifratura, riducendo la finestra di detection. Cheerscrypt adotta un modello TTP quasi identico, confermando che questo pattern è ormai standardizzato nell'ecosistema ransomware ESXi-oriented, che include anche famiglie come Babuk, Hive ed ESXiArgs con varianti dello stesso approccio.

Nel secondo cluster spicca UNC3886, threat actor tracciato con attribuzione china-nexus e focalizzato su targeting di lungo periodo in ambienti di virtualizzazione. Il suo uso di esxcli è qualitativamente diverso: non serve a distruggere ma a persistere, con modifica delle regole firewall per aprire canali C2 discreti, installazione di malware direttamente sull'hypervisor, e artifact removal per eludere indagini successive. Correlato a UNC3886 è VIRTUALPIE, backdoor scritta in Python capace di eseguire comandi arbitrari su ESXi compromessi, che rappresenta un salto qualitativo nella maturità offensiva contro il layer di virtualizzazione — la persistenza non è più sul guest ma sotto di esso, invisibile agli EDR tradizionali.

Il trend emergente è la specializzazione degli attaccanti sul target ESXi come moltiplicatore di impatto. Le motivazioni convergono: gli hypervisor concentrano un rapporto uno-a-molti tra host compromesso e workload colpiti, hanno superficie di detection ridotta rispetto ai sistemi operativi tradizionali, e sono spesso gestiti da team distinti da quelli SOC, con visibilità limitata.

Gli overlap tra i tool utilizzati sono significativi: sia il cluster ransomware sia quello state-sponsored convergono sull'uso delle stesse CLI native (esxcli, vim-cmd), rendendo la detection basata sul solo tool inefficace. La discriminante intelligence-driven diventa il pattern di comandi, la finestra temporale e la sequenza operativa. Le priorità di threat hunting dovrebbero includere il monitoraggio di modifiche non pianificate al firewall ESXi, l'installazione di VIB da fonti non ufficiali, e picchi di vm process kill correlati temporalmente su più host dello stesso cluster.

MITRE ATT&CK T1059.012 (Hypervisor CLI), tattica TA0002. Gruppi: G1048 (UNC3886). Software: S1073 (Royal), S1096 (Cheerscrypt), S1218 (VIRTUALPIE). Detection strategy DET0558 con analytic AN1537. Consultato MITRE D3FEND per mapping tecniche difensive. Integrata conoscenza professionale su amministrazione VMware ESXi, sintassi esxcli e vim-cmd, filesystem VMFS e artefatti forensi degli hypervisor per contestualizzare comandi e procedure operative.