Esecuzione via Cloud API: Command and Scripting Interpreter – Cloud API (T1059.009)

La simulazione di questa tecnica in laboratorio richiede un ambiente cloud di test con credenziali a permessi controllati. L'obiettivo è dimostrare come, partendo da un set di credenziali rubate, un attaccante possa operare interamente tramite API senza mai installare agenti sull'infrastruttura target.

Enumerazione con AWS CLI. Il punto di partenza naturale replica ciò che fa TeamTNT: configurare la CLI con credenziali compromesse e procedere a riconoscimento. Dopo aver configurato un profilo con aws configure --profile compromised, si può iniziare con un comando di verifica identità:

aws sts get-caller-identity --profile compromised

Questo restituisce Account ID, ARN e User ID — informazioni essenziali per capire che privilegi ha il token. Da lì si procede con enumerazione delle risorse:

aws s3 ls --profile compromised aws ec2 describe-instances --profile compromised --region us-east-1 aws iam list-users --profile compromised

Pacu per l'automazione. Il framework Pacu (open source) di Rhino Security Labs automatizza queste operazioni concatenando moduli di enumerazione e privilege escalation. Si installa tramite pip e opera come wrapper intelligente attorno alla CLI AWS. Dopo l'avvio con python3 pacu.py e l'importazione delle chiavi, moduli come iam__enum_permissions e ec2__enum producono un quadro completo dell'ambiente in pochi minuti.

Simulazione Azure con Az PowerShell e AADInternals. Per replicare le tecniche di APT29, si opera in un tenant Azure di laboratorio. Dopo l'autenticazione con Connect-AzAccount, il modulo Az consente operazioni come:

Get-AzResource Get-AzRoleAssignment

Per un approccio più aggressivo, il modulo AADInternals (open source) espone funzionalità che interagiscono direttamente con le API Microsoft Graph e Azure AD, replicando le procedure documentate per APT29. L'installazione avviene con Install-Module AADInternals e l'accesso con Get-AADIntAccessTokenForMSGraph.

GCP con gcloud CLI. Completando il trittico, l'autenticazione con gcloud auth activate-service-account --key-file=<file-chiave.json> permette enumerazione analoga: gcloud projects list, gcloud compute instances list, gcloud iam service-accounts list.

In ogni caso, documentate con timestamp ogni azione e limitate il perimetro al tenant di test. L'uso di credenziali cloud reali non autorizzate è reato anche in contesto di pentest.

Il rilevamento di abusi Cloud API si gioca su un terreno insidioso: ogni azione malevola è tecnicamente una chiamata API legittima. La differenza tra un amministratore che gestisce risorse e un attaccante con credenziali rubate sta nel contesto, non nel comando in sé.

Log source primari. La detection si basa su tre fonti fondamentali: AWS CloudTrail, Azure Activity Log e Okta SystemLog (o equivalente IdP). CloudTrail registra ogni chiamata API AWS con timestamp, IP sorgente, user agent e parametri. Azure Activity Log fa lo stesso per il piano di gestione Azure. Okta cattura il contesto di autenticazione a monte.

Il cuore della strategia di detection è l'analisi dei cinque indicatori di tuning definiti nella regola comportamentale associata a questa tecnica.

Lo User-Agent è il primo filtro ad alto valore. Quando vedete boto3/1.x o python-requests nel campo userAgent di CloudTrail, qualcuno sta usando SDK Python — e se quel profilo utente normalmente opera dalla console web, è un'anomalia significativa. Lo stesso vale per stringhe user-agent di azcopy, Pacu o agent non riconosciuti in Azure. Create una baseline degli user-agent legittimi per ogni service account e ogni utente admin, poi alertate sulle deviazioni.

La finestra temporale offre un secondo layer: chiamate API in orari non lavorativi o durante weekend, specialmente su servizi IAM e compute, meritano investigazione. Incrociate questo dato con la geolocalizzazione IP — un token normalmente usato da Milano che improvvisamente effettua chiamate da un ASN in un paese inatteso è un forte indicatore di compromissione.

Il pattern più sofisticato riguarda il chaining di API: sequenze rapide che toccano IAM (creazione ruoli, policy attachment), poi compute (lancio istanze), poi storage (listing o download da bucket). Questa concatenazione cross-service in finestre temporali ridotte è tipica di operazioni automatizzate tramite framework come Pacu.

Per ridurre i falsi positivi, distinguete tra Cloud Shell browser-based e CLI locale: il campo sessionContext in CloudTrail e il tipo di autenticazione in Azure aiutano a separare accessi interattivi da automazioni. Le pipeline CI/CD generano molto rumore — whitelist per service account dedicati e IP range noti dei runner.

Su Splunk (freemium) o Elastic Security (open source), una regola efficace correla eventSource=iam.amazonaws.com con user-agent non in whitelist e orario fuori baseline in una finestra di 15 minuti.

L'analisi forense di un incidente Cloud API presenta una peculiarità rispetto alle indagini endpoint tradizionali: il filesystem del cloud non esiste in senso classico, e gli artefatti principali sono log di piattaforma e metadati di autenticazione.

Ricostruzione della catena di autenticazione. Il primo passo è stabilire come l'attaccante ha ottenuto le credenziali. In CloudTrail, cercate eventi AssumeRole, GetSessionToken e AssumeRoleWithWebIdentity — ognuno rivela un passaggio nella catena di delega. Per Azure, gli eventi di sign-in nel log di Azure AD mostrano il metodo di autenticazione, l'IP sorgente e se è stato soddisfatto il requisito MFA. Se l'accesso è avvenuto tramite token rubato, spesso vedrete autenticazione senza challenge MFA interattivo da IP non consueti.

Timeline delle operazioni API. Scaricate l'intero trail CloudTrail per il periodo sospetto con aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<AKIA...> --start-time --end-time . Questo comando filtra per la chiave di accesso compromessa, producendo la sequenza cronologica completa delle azioni. In Azure, l'equivalente si ottiene dal portale Log Analytics con query KQL su AzureActivity filtrando per Caller e intervallo temporale.

Per arricchire la timeline, correlate gli artefatti cloud con quelli endpoint: se l'attaccante ha usato Storm-0501's approach con Cloud CLI da un host compromesso on-premises, l'host stesso conterrà tracce. Su Windows, la cronologia PowerShell in %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt può contenere comandi az o Connect-AzAccount. Su Linux, ~/.bash_history e ~/.aws/credentials rivelano configurazioni di profili CLI.

Artefatti specifici per framework offensivi. Se sospettate l'uso di Pacu, cercate la directory ~/.pacu/ sull'host compromesso — contiene database SQLite con la cronologia completa di sessioni, moduli eseguiti e credenziali utilizzate. È un artefatto forense di valore eccezionale, quando disponibile.

I metadati delle risorse create raccontano il resto della storia. Ogni istanza EC2, funzione Lambda o ruolo IAM creato dall'attaccante porta un timestamp di creazione e l'ARN del creatore nei metadati. In Azure, ogni risorsa nel Resource Graph include createdBy e createdTime. Questi metadati permettono di ricostruire cosa l'avversario ha costruito nell'ambiente e con quale sequenza logica — dall'escalation dei privilegi all'esfiltrazione dei dati.

Tre gruppi distinti utilizzano questa tecnica, ciascuno con finalità e sofisticazione differenti, delineando uno spettro che va dal cybercrime opportunistico allo spionaggio statale avanzato.

APT29 rappresenta l'estremo più sofisticato. Questo gruppo, attribuito alla Russia, sfrutta specificamente la Microsoft Graph API per muoversi attraverso ambienti Azure e Microsoft 365. L'uso di AADInternals — moduli PowerShell che espongono funzionalità non sempre documentate delle API Microsoft — suggerisce una conoscenza profonda dell'ecosistema cloud Microsoft. Il pattern operativo di APT29 in cloud è caratterizzato da movimenti lenti e deliberati: l'accesso API viene usato per raccolta intelligence e persistenza, non per azioni distruttive. Chi difende ambienti M365 e Azure AD deve considerare APT29 come la minaccia di riferimento per questa tecnica.

Storm-0501 opera con un approccio più diretto, sfruttando la Cloud CLI per eseguire comandi ed esfiltrare dati da ambienti compromessi. Il profilo suggerisce un attore orientato al ransomware e all'estorsione, che utilizza l'accesso cloud come estensione naturale della compromissione on-premises. Il passaggio da Active Directory locale ad Azure AD — il cosiddetto lateral movement cloud — è un pattern in crescita che Storm-0501 esemplifica bene.

TeamTNT si posiziona sull'altro estremo: un gruppo cybercriminale focalizzato su AWS, che usa credenziali compromesse per enumerare ambienti cloud tramite CLI. Il loro obiettivo storico è il cryptomining, ma l'enumerazione via API indica capacità di ricognizione che possono precedere azioni più impattanti. TeamTNT cerca tipicamente credenziali AWS in file di configurazione su host compromessi, poi le usa per esplorare l'intera infrastruttura cloud dell'organizzazione.

Il tool Pacu (open source) funge da denominatore comune per il lato offensivo AWS: è il Metasploit dell'exploitation cloud, e la sua presenza — anche solo come indicatore di formazione — segnala un attore con competenze specifiche AWS.

Il trend emergente è chiaro: la superficie d'attacco si sta spostando dall'endpoint all'API cloud. La convergenza di tutti e tre i gruppi su questa tecnica — pur con motivazioni diverse — indica che le API cloud sono diventate un vettore mainstream, non più appannaggio di soli attori nation-state. Per la prioritizzazione difensiva, monitorate con attenzione speciale gli ambienti Microsoft (per APT29 e Storm-0501) e AWS (per TeamTNT e Pacu-based attacks).

Framework MITRE ATT&CK: tecnica T1059.009, tattica TA0002, mitigazioni M1038 e M1026, detection DET0078/AN0215. Gruppi: G0016 (APT29), G1053 (Storm-0501), G0139 (TeamTNT). Software: S1091 (Pacu). Integrato con conoscenza professionale per tool e procedure operative.