Comandi Cloud sulle VM: Cloud Administration Command (T1651)

Il cuore di questa tecnica sta nel dimostrare al cliente che le credenziali cloud amministrative sono equivalenti a un accesso root su ogni VM dell'ambiente. In un engagement red team, il punto di partenza è sempre la raccolta delle credenziali: un token di sessione rubato, una service principal con permessi eccessivi, o un classico accesso da phishing su un account con ruolo Virtual Machine Contributor in Azure.

Simulazione su AWS con Pacu. Pacu (open source) è il framework di exploitation AWS sviluppato da Rhino Security Labs. Una volta configurato con le credenziali compromesse, permette di enumerare le istanze EC2 e lanciare comandi tramite SSM Run Command. La sequenza operativa prevede prima l'importazione delle chiavi nel framework, poi l'esecuzione del modulo specifico:

pacu --session redteam

All'interno della sessione interattiva, il modulo ec2__start_ssm_session permette di interagire con le istanze che hanno SSM Agent attivo. Prima dell'esecuzione, verifica le istanze raggiungibili con il modulo di enumerazione ec2__enum. L'output rivela quali istanze sono gestite da Systems Manager e quindi vulnerabili a questa catena d'attacco.

Simulazione su Azure con AADInternals. AADInternals (open source), il modulo PowerShell creato da Nestori Syynimaa, consente di sfruttare Azure RunCommand e la funzionalità Admin-on-Behalf-of (AOBO). Dopo l'importazione del modulo in una sessione PowerShell:

Import-Module AADInternals

L'operatore può autenticarsi con un token di accesso Azure e invocare l'esecuzione di script sulle VM target tramite il cmdlet Invoke-AADIntVMAgent. Questo comando sfrutta il VM Agent installato sulla macchina per eseguire codice nel contesto SYSTEM.

Via CLI nativa. Anche senza tool di terze parti, la CLI Azure permette l'esecuzione diretta:

az vm run-command invoke --resource-group <NomeRG> --name <NomeVM> --command-id RunPowerShellScript --scripts "whoami"

Su AWS, l'equivalente con la CLI ufficiale:

aws ssm send-command --instance-ids <ID_Istanza> --document-name "AWS-RunShellScript" --parameters commands="id"

Nella relazione finale, evidenzia quante VM erano raggiungibili con un singolo set di credenziali e quanto tempo è trascorso tra l'esecuzione e un'eventuale notifica — quel delta temporale è il vero indicatore di rischio per il cliente.

La detection di questa tecnica si gioca interamente sulla correlazione tra il piano di controllo cloud e ciò che accade dentro la VM. L'esecuzione di un RunCommand genera eventi in due strati distinti: i log di management del cloud provider e i log di processo del sistema operativo guest. Solo incrociando entrambi si ottiene una detection affidabile.

Log source critici. Su AWS, il log primario è CloudTrail: le API call SendCommand e StartSession del servizio SSM vengono registrate con il dettaglio dell'utente chiamante, l'istanza target e il documento eseguito. Su Azure, Azure Activity Log cattura le invocazioni di RunCommand sotto il resource provider Microsoft.Compute, mentre Azure VM Guest Logs (se configurati tramite l'estensione diagnostica o Azure Monitor Agent) mostrano l'esecuzione lato OS.

La strategia di tuning ruota su tre assi. Il primo è il contesto utente: occorre distinguere tra account amministrativi e di automazione legittimi — quelli legati a pipeline CI/CD o patch management — e account che non hanno ragione operativa per invocare comandi sulle VM. Il secondo asse è la finestra temporale: correlare la API call del control-plane con la creazione di processo lato guest entro un intervallo ristretto, orientativamente 5 minuti, riduce i falsi positivi da operazioni schedulate. Il terzo è la whitelist degli script approvati: i comandi di manutenzione ricorrenti (aggiornamenti agent, health check) possono essere censiti e filtrati per hash o nome documento.

Un alert efficace in ambiente AWS potrebbe monitorare in Splunk gli eventi CloudTrail con eventName=SendCommand dove il campo requestParameters.documentName non corrisponde a documenti approvati, oppure dove l'userIdentity.arn non appartiene al gruppo di amministratori autorizzati.

Su Azure, una regola analitica in Microsoft Sentinel (freemium) può intercettare le operazioni Microsoft.Compute/virtualMachines/runCommand/action nell'Activity Log e correlare con i processi spawn dal servizio WaAppAgent o WindowsAzureGuestAgent visibili nei log Sysmon della VM. La comparsa di powershell.exe o cmd.exe come processo figlio dell'agent, fuori dalle finestre di manutenzione programmate, merita un'escalation immediata.

Per i falsi positivi, il volume dipende dall'intensità dell'automazione nel tenant. Ambienti con forte uso di Infrastructure-as-Code genereranno rumore significativo: la baseline iniziale è fondamentale. Registra per almeno due settimane chi esegue cosa e su quali VM prima di attivare alert bloccanti.

L'indagine forense su un abuso di Cloud Administration Command si articola su due domini distinti: il cloud control-plane e il filesystem della VM compromessa. La sfida è costruire una timeline unica che colleghi l'identità dell'attaccante nel cloud alla catena di esecuzione dentro il sistema operativo.

Artefatti cloud-side. Il punto di partenza è il log di audit del provider. Su AWS, CloudTrail conserva ogni invocazione SendCommand con il timestamp, l'ARN dell'utente, l'IP sorgente, l'ID dell'istanza target e il contenuto del parametro commands. Questi log, se centralizzati in un bucket S3 dedicato, rappresentano un artefatto immutabile. Su Azure, l'Activity Log riporta la stessa classe di metadati per le operazioni RunCommand, incluso il correlation ID che permette di tracciare una singola azione attraverso più servizi.

Artefatti host-side su Windows. Quando Azure RunCommand esegue uno script PowerShell, il VM Agent scrive i file temporanei nella directory C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows. All'interno di questa struttura si trovano lo script eseguito, l'output standard e l'errore standard, con timestamp che devono allinearsi con il log del control-plane. Se Sysmon è installato sulla VM, gli eventi EventCode 1 (Process Create) mostreranno la catena di esecuzione con il parent process riconducibile al servizio WindowsAzureGuestAgent. I log PowerShell con Script Block Logging attivo (EventCode 4104) catturano il contenuto integrale degli script eseguiti.

Artefatti host-side su Linux. Su istanze Linux gestite da SSM Agent, i log di esecuzione risiedono tipicamente in /var/log/amazon/ssm/. Il file amazon-ssm-agent.log registra ogni comando ricevuto dal servizio, con ID documento e timestamp. I comandi effettivamente eseguiti compaiono anche nei log di sistema (syslog o journalctl) come processi figli dell'agent SSM.

Per ricostruire la timeline, allinea i clock: il timestamp UTC del CloudTrail o Activity Log deve corrispondere (con lo scarto della latenza di propagazione) al timestamp di creazione del processo sulla VM. Discrepanze superiori a pochi minuti suggeriscono manipolazione dei log o problemi di sincronizzazione NTP — entrambi degni di approfondimento.

Un aspetto critico è la persistenza: l'attaccante potrebbe usare il primo RunCommand per installare una backdoor o creare un account locale, separando così l'accesso iniziale (via cloud management) dal mantenimento della presenza (via canale tradizionale). Cerca artefatti di persistenza — chiavi di registro Run/RunOnce, scheduled task, crontab modificati — il cui timestamp di creazione cada nell'intorno dell'esecuzione RunCommand documentata nei log cloud.

Il panorama degli attori che sfruttano i comandi amministrativi cloud si concentra, nei dati osservati, su un singolo gruppo di alto profilo, ma il pattern operativo suggerisce una tendenza in crescita nell'ecosistema delle minacce rivolte agli ambienti cloud enterprise.

APT29 (noto anche come Cozy Bear, The Dukes) è il gruppo attribuito alla Russia che ha dimostrato l'uso operativo di questa tecnica. Il gruppo ha sfruttato Azure RunCommand per eseguire codice su macchine virtuali all'interno di tenant compromessi, e ha inoltre abusato della funzionalità Azure Admin-on-Behalf-of (AOBO) — un meccanismo di delega che consente ai partner Microsoft di amministrare i tenant dei propri clienti. Questa combinazione rivela una sofisticata comprensione dell'architettura di trust del cloud Microsoft: APT29 non si limita a compromettere un singolo ambiente, ma sfrutta le relazioni di fiducia tra provider e cliente per muoversi lateralmente attraverso i confini organizzativi.

L'arsenale tecnico collegato a questa tecnica include due strumenti pubblicamente documentati. AADInternals è un modulo PowerShell specializzato nell'interazione con Azure AD e i servizi Azure, capace di invocare il VM Agent per eseguire comandi sulle macchine virtuali. Pacu, il framework di exploitation AWS di Rhino Security Labs, copre l'equivalente lato Amazon attraverso i moduli SSM. La coesistenza di tool per entrambi i cloud provider principali segnala che la tecnica è multipiattaforma e la superficie d'attacco si estende a qualsiasi organizzazione con workload IaaS.

Dal punto di vista del profilo geografico, l'interesse di APT29 per gli ambienti cloud è coerente con la strategia di raccolta intelligence su larga scala che caratterizza il gruppo: colpire l'infrastruttura del service provider equivale a ottenere accesso a centinaia di organizzazioni downstream con un singolo punto di compromissione.

Il trend da monitorare è l'estensione di questa tecnica a GCP (tramite OS Config e OS Login) e l'adozione da parte di gruppi con motivazioni finanziarie. Le organizzazioni che delegano la gestione cloud a MSP (Managed Service Provider) sono particolarmente esposte: ogni relazione di trust AOBO o equivalente rappresenta un moltiplicatore di impatto. La mitigazione cardine resta la gestione degli account privilegiati (M1026): ridurre drasticamente il numero di account con permesso di esecuzione remota sulle VM, implementare accesso Just-in-Time tramite Azure PIM o ruoli temporanei AWS, e monitorare ogni utilizzo di queste capacità come evento ad alta priorità.

Framework MITRE ATT&CK: tecnica T1651 (Cloud Administration Command), tattica TA0002 (Execution), mitigazione M1026, detection DET0545/AN1502. Gruppi: G0016 (APT29). Software: S0677 (AADInternals), S1091 (Pacu). Integrato con conoscenza professionale per tool e procedure operative.