Comandi Amministrativi Cloud: Cloud Administration Command (T1651)

In un red team engagement su ambiente cloud, T1651 diventa rilevante subito dopo aver ottenuto credenziali con privilegi amministrativi sul tenant, tipicamente attraverso phishing, consent grant abuse o compromissione di service principal. La fase preparatoria consiste nell'enumerare i workload target e i permessi effettivi dell'identità compromessa.

Su AWS, il tool Pacu (open source) automatizza l'intera catena. Il modulo systemsmanager__rce_ec2 enumera istanze EC2 con agente SSM attivo e privilegi appropriati, poi invoca SendCommand per eseguire payload. La sequenza tipica in Pacu è: run ec2__enum, run iam__enum_permissions, run systemsmanager__rce_ec2 --command "id; uname -a". Il comando AWS CLI equivalente è aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceids,Values=i-xxxxx" --parameters 'commands=["whoami"]'.

Su Azure, il tool di riferimento è AADInternals (open source, PowerShell). Dopo autenticazione con Get-AADIntAccessTokenForAzureCoreManagement, il cmdlet Invoke-AADIntAzureVMScript -SubscriptionId -ResourceGroup -VM -Script "whoami" esegue il payload tramite l'agente VM senza generare log di login sul guest. In alternativa, il cmdlet nativo Invoke-AzVMRunCommand del modulo Az PowerShell (open source) offre la stessa funzionalità: Invoke-AzVMRunCommand -ResourceGroupName -VMName -CommandId 'RunPowerShellScript' -ScriptPath payload.ps1.

La catena d'attacco tipica prevede alcuni passaggi ricorrenti:

• Recon del tenant: enumerazione ruoli con Get-AzRoleAssignment o aws iam list-attached-user-policies
• Selezione target: identificazione VM con agente attivo tramite Get-AzVM -Status o aws ssm describe-instance-information
• Esecuzione payload: RunCommand con script che stabilisce C2 outbound (Cobalt Strike beacon HTTP, Sliver implant)
• Persistence: schedulazione di Runbook Azure Automation ricorrenti come backdoor

Un dettaglio spesso trascurato: RunCommand ha un limite di 4096 byte per il payload inline, quindi conviene usare un downloader in due stadi che scarica il secondo stadio da uno storage account controllato. Per l'AOBO (Admin-on-Behalf-of) usato da APT29, il flusso sfrutta il modello di delegated administration dei Cloud Solution Provider: se il red team simula un CSP compromesso, è possibile pivotare sui tenant clienti senza credenziali dirette.

In laboratorio, consiglio di testare in tenant Azure gratuiti (freemium) o AWS Free Tier con VM isolate, verificando che i CloudTrail e Activity Log catturino effettivamente le invocazioni prima di dichiarare il test completato.

La detection di T1651 richiede uno shift mentale importante: gli indicatori primari non stanno negli EDR sugli endpoint, ma nei log del control plane cloud. La visibilità va costruita correlando eventi che tradizionalmente appartengono a team diversi.

Su AWS, il log source critico è CloudTrail con focus sugli eventi SendCommand, StartSession e CreateAssociation del servizio SSM. Un alert efficace scatta quando l'evento ssm.amazonaws.com/SendCommand è invocato da un principal che non appartiene al gruppo abituale di automazione o quando il parametro DocumentName è AWS-RunShellScript o AWS-RunPowerShellScript al di fuori delle finestre di manutenzione dichiarate. In Splunk (a pagamento) la query base è index=cloudtrail eventName=SendCommand | stats count by userIdentity.arn, requestParameters.documentName, requestParameters.parameters.

Su Azure, gli Activity Log registrano invocazioni di RunCommand sotto l'operazione Microsoft.Compute/virtualMachines/runCommand/action e Microsoft.Compute/virtualMachines/runCommands/write. Va monitorata anche l'operazione Microsoft.Automation/automationAccounts/jobs/write per intercettare Runbook malevoli. In Microsoft Sentinel (a pagamento) o tramite KQL su Log Analytics, la query AzureActivity | where OperationNameValue contains "runCommand" | project TimeGenerated, Caller, ResourceId, ActivityStatusValue fornisce la baseline.

Dalla prospettiva D3FEND, gli artefatti digitali rilevanti sono User Account, Cloud Service e Process generato sulla VM. Le contromisure detect si articolano su tre livelli:

• Cloud Service Login Analysis: correlazione tra chi ha invocato l'API e da quale IP/geolocation
• Process Spawn Analysis: sull'endpoint, i processi SSM Agent (amazon-ssm-agent) e WindowsAzureGuestAgent.exe che generano child process anomali (powershell.exe, cmd.exe, bash) sono segnali forti
• Job Function Access Pattern Analysis: modellazione del pattern d'uso per identità di servizio

Un tuning fondamentale riguarda tre dimensioni: user context (differenziare account di automazione noti da utenti umani), time window (correlare l'evento cloud con l'esecuzione sul guest entro 5 minuti) e allowlist di script approvati (hash o path noti riducono drasticamente i falsi positivi).

I falsi positivi tipici arrivano da: patch management automatizzato via SSM, tool di configuration management (Ansible con connection plugin AWS SSM), script di health check schedulati. La mitigazione consiste nell'etichettare le service identity legittime con tag dedicati e costruire allowlist basate su userIdentity.sessionContext.sessionIssuer in CloudTrail.

Un segnale particolarmente pesante è l'esecuzione di RunCommand da parte di un principal che non ha mai effettuato quell'operazione nei 90 giorni precedenti — un classico use case per rilevamento basato su baseline UEBA.

L'analisi forense di T1651 opera su due piani paralleli che vanno ricostruiti in modo sincronizzato: il piano di controllo cloud e il piano guest della VM. Il rischio di perdere evidenza è alto perché gli agenti cloud gestiscono il payload in maniera che spesso non lascia file persistenti sul disco.

Su AWS, l'artefatto primario è il log CloudTrail archiviato tipicamente su S3. Gli eventi rilevanti da estrarre sono SendCommand, GetCommandInvocation e ListCommandInvocations, che contengono commandId, instanceIds, documentName e — cruciale — i parametri passati, inclusi gli script inline. Sul guest Linux, l'agente scrive log in /var/log/amazon/ssm/amazon-ssm-agent.log e i dettagli delle esecuzioni in /var/lib/amazon/ssm/i-xxxxx/document/orchestration//, dove si trovano i file runShellScript con il payload effettivo. Su Windows, i log stanno in *C:\ProgramData\Amazon\SSM\Logs* e gli script temporanei in *C:\ProgramData\Amazon\SSM\InstanceData*.

Su Azure, gli Activity Log contengono la registrazione dell'invocazione RunCommand ma non il contenuto dello script — quello va recuperato dalle proprietà della risorsa runCommands via Get-AzVMRunCommand se ancora presente. Sul guest Windows, l'agente esegue lo script tramite *C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows<version>\Downloads* e lascia log in *C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.RunCommandWindows*. Sul guest Linux la path è /var/lib/waagent/Microsoft.CPlat.Core.RunCommandLinux-/download// con lo script salvato come script.sh.

Dalla prospettiva D3FEND, gli artefatti chiave per la timeline sono User Account, Authentication Log, Process e Command History. La ricostruzione temporale ideale segue questa sequenza:

• T0: autenticazione dell'identità compromessa sul control plane (Azure AD Sign-in Logs o AWS CloudTrail ConsoleLogin/AssumeRole)
• T1: invocazione API RunCommand/SendCommand con estrazione del commandId
• T2: pickup del comando da parte dell'agente sulla VM (log agente)
• T3: esecuzione del processo figlio (Event ID 4688 su Windows con parent WindowsAzureGuestAgent.exe o amazon-ssm-agent.exe; auditd execve su Linux con parent PID dell'agente)
• T4: attività post-exploitation (connessioni C2, creazione file, modifiche registry)

Su Windows, il log Security con auditing di process creation abilitato è la fonte più affidabile per collegare il comando cloud all'esecuzione locale. Sysmon Event ID 1 con enrichment di ParentImage rende immediata la correlazione. Su Linux, auditd con regola -a always,exit -F arch=b64 -S execve -F ppid=<pid_agente> cattura la catena.

APT29 nelle sue operazioni ha usato specificamente Azure Run Command e il meccanismo Admin-on-Behalf-of (AOBO): nel secondo caso l'evidence si estende ai log del tenant CSP delegante, spesso non accessibili al forense della vittima senza escalation contrattuale.

Il panorama degli attori che hanno operativizzato T1651 è ristretto ma di altissimo profilo, riflettendo il fatto che questa tecnica richiede sia sofisticazione tecnica sia accesso privilegiato al piano di controllo cloud — un asset non banale da acquisire.

APT29 (noto anche come Cozy Bear, Midnight Blizzard, Nobelium) è il gruppo di riferimento documentato per l'uso di questa tecnica. Attribuito al servizio di intelligence esterno russo SVR, APT29 ha integrato Azure Run Command e il meccanismo Azure Admin-on-Behalf-of (AOBO) nel proprio arsenale per l'esecuzione di codice su VM in ambienti target. L'uso di AOBO è particolarmente indicativo del modus operandi del gruppo: sfrutta il modello di delegated administration dei Cloud Solution Provider Microsoft per pivotare dai tenant compromessi dei provider di servizi verso i clienti downstream, trasformando la fiducia contrattuale in un vettore di supply chain. Questo pattern si allinea con la strategia più ampia di APT29 di targeting di managed service provider come amplificatore d'accesso, già osservata in altre operazioni di lungo respiro contro settori diplomatico, difesa e think tank occidentali.

Sul fronte del tool overlap, l'ecosistema offensive per T1651 mostra due strumenti principali con orientamenti diversi:

• AADInternals (S1091 nel catalogo MITRE come tool): framework PowerShell sviluppato da Nestori Syynimaa, ampiamente adottato sia da red team legittimi sia da attori malevoli. La sua capacità di eseguire comandi su Azure VM tramite VM agent lo rende una scelta naturale per operatori che hanno già ottenuto token di accesso al tenant.
• Pacu: framework open source di Rhino Security Labs orientato specificamente ad AWS, con moduli dedicati all'abuso di Systems Manager Run Command su istanze EC2.

La disponibilità di entrambi come progetti pubblici abbassa significativamente la barriera d'ingresso, e ci si può ragionevolmente attendere che attori di livello inferiore ad APT29 — inclusi gruppi financially motivated e ransomware affiliate — adottino T1651 man mano che le loro operazioni si spostano su target cloud-native.

Il trend geografico e settoriale riflette la geometria dell'adozione cloud aziendale: APT29 concentra l'attività su target NATO, agenzie governative, aziende tecnologiche e organizzazioni sanitarie negli Stati Uniti e in Europa occidentale, con crescente enfasi su ambienti Microsoft 365 e Azure dopo che questi hanno sostituito l'on-premise come core del perimetro informativo.

Dal punto di vista prospettico, T1651 è una tecnica in crescita strutturale: la migrazione cloud continua, i team di sicurezza spesso hanno visibilità matura sull'endpoint ma limitata sul control plane, e i canali di management legittimi rimangono un blind spot difensivo. Il pattern APT29-AOBO in particolare merita attenzione perché indica che gli avversari state-sponsored hanno compreso il valore della trusted relationship cloud come moltiplicatore d'accesso, un modello che verrà replicato.

MITRE ATT&CK T1651 (Cloud Administration Command), tattica TA0002. Gruppi: G0016 APT29. Software: S0677 AADInternals, S1091 Pacu. Mitigazione: M1026 Privileged Account Management. Detection: DET0545, AN1502. Framework MITRE D3FEND per artefatti digitali e contromisure. Documentazione ufficiale AWS Systems Manager e Azure RunCommand per sintassi comandi. Conoscenza professionale integrata per dettagli operativi su tool open source (Pacu, AADInternals, Az PowerShell), path artefatti forensi degli agenti VM e query di detection su piattaforme SIEM.