Comandi via ESXi Guest Ops: ESXi Administration Command (T1675)

In un esercizio red team autorizzato, la simulazione di T1675 presuppone accesso amministrativo a un host ESXi di laboratorio (root o account con ruolo Administrator su vCenter). L'obiettivo è dimostrare come, partendo dall'hypervisor, si possano pivotare comandi arbitrari all'interno dei guest senza toccare la rete di produzione.

Il punto di ingresso naturale è il vSphere Web Services SDK, disponibile in versione Python come pyVmomi (open source, repository GitHub ufficiale di VMware) e in versione PowerShell come VMware PowerCLI (gratuito, fornito da Broadcom/VMware). Entrambi espongono il namespace GuestOperationsManager, che è esattamente ciò che l'attaccante userebbe.

Con PowerCLI, dopo la connessione al vCenter tramite Connect-VIServer, il comando chiave per esecuzione in-guest è Invoke-VMScript, che internamente chiama StartProgramInGuest. Un esempio didattico su un guest Windows di lab:

Invoke-VMScript -VM "lab-win-01" -ScriptText "whoami; hostname" -GuestUser "Administrator" -GuestPassword "" -ScriptType Powershell

Per trasferire file dal guest verso l'host di controllo, il cmdlet equivalente è Copy-VMGuestFile con flag -GuestToLocal, che mappa su InitiateFileTransferFromGuest. In pyVmomi lo stesso flusso richiede di istanziare GuestAuthManager con NamePasswordAuthentication, quindi chiamare processManager.StartProgramInGuest() passando un oggetto GuestProgramSpec con path del binario e argomenti.

Una catena d'attacco realistica in lab prevede tre fasi. Prima, ricognizione dei processi guest con ListProcessesInGuest per identificare EDR attivi e sessioni utente. Seconda, staging di un binario tramite InitiateFileTransferToGuest verso una directory scrivibile come C:\Windows\Temp. Terza, esecuzione via StartProgramInGuest per ottenere un beacon; framework post-exploitation come Sliver (open source) o Mythic (open source) sono adatti a questa fase perché non richiedono infrastruttura di rete verso il guest.

Per simulare adversary emulation di UNC3886 e VIRTUALPITA il pattern documentato consiste nell'invocare direttamente vmtoolsd.exe con parametri di script embedded, oppure nel deployare backdoor lato hypervisor che parlano al daemon via socket locale VMCI. Strumenti come Chimera (open source, framework di adversary emulation) permettono di scriptare l'intera catena. È fondamentale operare solo su cluster ESXi di laboratorio isolati, perché l'abuso di Guest Ops su ambienti di produzione bypassa qualsiasi controllo di rete e può causare esecuzione simultanea su decine di VM.

La detection di T1675 richiede visibilità sui log dell'hypervisor, non solo sugli endpoint guest. La fonte primaria è esxi:hostd (il log del servizio hostd su ciascun host ESXi, tipicamente in /var/log/hostd.log), affiancato dai log di vCenter (vpxd.log) e dagli eventi di audit del vSphere API endpoint.

La strategia di detection DET0232 si concentra su chiamate anomale alle Guest Operations API: StartProgramInGuest, ListProcessesInGuest, ListFileInGuest e InitiateFileTransferFromGuest. Le dimensioni comportamentali rilevanti sono quattro: identità dell'account chiamante, finestra temporale, frequenza delle chiamate e set di VM target.

Un primo alert ad alto valore è l'invocazione di StartProgramInGuest da parte di account non presenti nella whitelist ExpectedAdminUsers. In un ambiente maturo, solo pochi service account (backup, patch management, orchestrazione) usano legittimamente Guest Ops; qualsiasi account umano interattivo o account di servizio nuovo va investigato. Un secondo alert riguarda l'attività fuori dalla TimeWindow operativa: chiamate Guest Ops alle 3 di notte in un dominio dove le manutenzioni sono pianificate tra le 22 e le 24 sono un segnale forte.

Il terzo asse è la soglia OperationThreshold: un attaccante che esegue lateral movement su un cluster tende a chiamare StartProgramInGuest su decine di VM in pochi minuti, un pattern raramente osservato in operazioni legittime che di solito sono seriali e distanziate. Correlare il conteggio di chiamate per sessione API in finestre di 5-10 minuti espone bene questo comportamento. Il quarto asse è la lista AuthorizedVMs: Guest Ops verso VM appartenenti a segmenti sensibili (domain controller, database production) senza change record aperto deve generare priorità critica.

Un indicatore complementare, lato guest, è l'esecuzione di processi con parent vmtoolsd.exe su Windows o vmtoolsd su Linux. Sysmon con EventCode 1 (Process Create) che mostri vmtoolsd.exe come parent di cmd.exe, powershell.exe, wscript.exe o binari da percorsi temporanei è altamente sospetto: le operazioni legittime di VMware Tools raramente lanciano interpreti shell. Su Linux la correlazione equivalente arriva da auditd con regole execve filtrate per ppid corrispondente a vmtoolsd.

I falsi positivi principali derivano da soluzioni di backup application-consistent (Veeam, Commvault) che usano legittimamente Guest Ops per quiescing, e da tool di patch management come vRealize Automation. Vanno identificati per service account e inseriti in whitelist con eccezioni granulari per orario e VM. Assenza di logging Guest Ops su hostd (spesso disabilitato di default a verbosity utile) è essa stessa un gap di visibilità da colmare aumentando il livello di log del vpxa/hostd a verbose per le operazioni Guest.

L'analisi forense di T1675 deve integrare tre superfici: hypervisor ESXi, guest VM e infrastruttura vCenter. La particolarità della tecnica è che gli artefatti più pesanti risiedono sull'host, non sul guest, e vengono spesso trascurati in indagini che partono dall'endpoint compromesso.

Sull'host ESXi il file cardine è /var/log/hostd.log, che registra le chiamate API ricevute dal servizio hostd inclusi i metodi StartProgramInGuest, InitiateFileTransferFromGuest e correlati. Ogni entry contiene timestamp, utente autenticato, VM target (moref, tipo vm-1234) e nome del programma invocato. Complementare è /var/log/vpxa.log, che traccia le comunicazioni con vCenter, utile per ricostruire se il comando è arrivato via UI vSphere, via API diretta o via console SSH sull'host. Il file /var/log/auth.log documenta le autenticazioni all'hostd, essenziali per attribuire azioni a specifici account.

Sul lato vCenter, /var/log/vmware/vpxd/vpxd.log fornisce la traccia centralizzata delle sessioni API con IP sorgente del client, timestamp di login e user agent — spesso rivelatorio, perché pyVmomi e PowerCLI hanno stringhe distintive diverse dai client GUI.

Dentro il guest, gli artefatti dipendono dall'OS. Su Windows, il servizio VMware Tools logga in C:\ProgramData\VMware\VMware Tools\vmware-vmsvc-.log* le operazioni ricevute dall'host, inclusi start di processi e trasferimenti file. In parallelo, gli eventi di Sysmon (se installato) mostrano processi figli di vmtoolsd.exe, e il Security log con EventCode 4688 cattura le esecuzioni con parent process ID risolvibile a vmtoolsd. Su Linux gli artefatti equivalenti sono in /var/log/vmware-vmsvc-root.log e negli eventi auditd con ppid del daemon.

La timeline forense tipica in un incidente ricollegabile a UNC3886 o VIRTUALPITA procede così: compromissione iniziale dell'host ESXi (spesso via credenziali vCenter rubate o vulnerabilità dell'hypervisor), installazione di componenti malevoli lato hypervisor, invocazione di Guest Ops verso VM ad alto valore, staging di tool nella C:\Windows\Temp o /tmp, esecuzione di credential dumping o data collection, esfiltrazione tramite InitiateFileTransferFromGuest verso l'host e da lì verso l'esterno. Quest'ultimo passaggio è particolarmente importante: i file estratti dal guest transitano temporaneamente su datastore ESXi, e ispezionare /vmfs/volumes/ per file recenti non associati a VM può rivelare staging area.

Gli IOC persistenti da preservare includono hash dei binari droppati nei guest, hash di eventuali VIB non firmati installati sull'ESXi, snapshot dei log hostd/vpxd, dump della configurazione /etc/vmware/ dell'host e memoria del processo hostd se acquisibile. La chain of custody deve documentare che i log ESXi sono soggetti a rotazione aggressiva: preservazione immediata è critica.

Il panorama di attori che sfruttano T1675 è ristretto ma di altissimo profilo, riflettendo il fatto che l'abuso di Guest Ops presuppone competenze specifiche sull'ecosistema VMware e accesso privilegiato all'hypervisor — condizioni che tipicamente si trovano solo in operazioni state-sponsored o in ransomware crew molto maturi.

UNC3886 è il gruppo di riferimento per questa tecnica. Tracciato come attore di spionaggio con targeting su organizzazioni della difesa, telco e settore governativo, si è distinto per un uso metodico dell'infrastruttura di virtualizzazione come piano di persistenza e movimento laterale. La caratteristica operativa più rilevante è l'uso di vmtoolsd.exe per eseguire comandi sui guest Windows da un host ESXi già compromesso, evitando completamente qualsiasi telemetria di rete tra host e VM. Questo pattern implica che il gruppo mantenga toolkit progettati per parlare nativamente con il VMware Tools Daemon, non semplici script generici. UNC3886 è stato associato al deployment di rootkit hypervisor-side e alla catena con backdoor lato guest, delineando un profilo di attore paziente, orientato a persistenza multi-anno.

Dal punto di vista delle famiglie malware, VIRTUALPITA è il software esplicitamente mappato su T1675. Si tratta di una backdoor progettata per operare lato hypervisor ESXi e capace di eseguire comandi sui guest ospitati direttamente attraverso il canale Guest Operations. Il design è coerente con quello di malware sviluppato per operazioni di lungo periodo: bassa footprint di rete verso l'esterno del datacenter, riuso di canali legittimi VMware, evasione degli EDR tradizionali che vivono dentro il guest e non hanno visibilità sull'hypervisor.

Il tool overlap tra UNC3886 e VIRTUALPITA rafforza l'ipotesi che l'ecosistema di minacce contro l'hypervisor sia sviluppato da un numero ristretto di team con investimento sostenuto in R&D specifico su VMware. Non emergono dai dati campagne pubbliche formalmente codificate con codice C, ma il pattern operativo è consistente: compromissione iniziale di credenziali vCenter o exploit di vulnerabilità hypervisor, pivot verso ESXi, deployment di componenti persistenti sull'host, e uso di Guest Ops per raccolta intelligence sui guest ad alto valore.

Il trend emergente da monitorare è la trasferibilità di questo playbook al mondo ransomware. Gruppi che già colpiscono ESXi per cifratura di VMDK (BlackCat, Akira, LockBit in versioni ESXi-native) hanno l'accesso e le competenze per aggiungere Guest Ops al proprio arsenale, spostandosi dalla semplice cifratura a doppia estorsione con esfiltrazione condotta interamente via canale hypervisor. Le organizzazioni con datacenter VMware devono trattare la telemetria hostd come priorità di monitoraggio pari ai domain controller.

MITRE ATT&CK: tecnica T1675 (ESXi Administration Command), tattica TA0002, gruppo G1048 (UNC3886), software S1217 (VIRTUALPITA), mitigazione M1018 (User Account Management), detection DET0232 con analytic AN0646. Riferimenti D3FEND per artefatti Process e File e per tecniche di Process Analysis. Per comandi operativi, sintassi PowerCLI, pyVmomi e strategie di detection su log esxi:hostd è stata utilizzata conoscenza professionale verificata su documentazione ufficiale VMware/Broadcom e repository pubblici dei tool citati.