Ricognizione dell'Infrastruttura Cloud: Cloud Infrastructure Discovery (T1580)

La simulazione di questa tecnica in laboratorio è un esercizio fondamentale per qualsiasi red team che operi su ambienti cloud. Il prerequisito è disporre di credenziali valide — tipicamente una coppia access key/secret key AWS, un service account GCP o un service principal Azure — ottenute in una fase precedente dell'engagement.

Su AWS, il punto di partenza è l'enumerazione delle istanze EC2. Con la CLI ufficiale, il comando è diretto:

aws ec2 describe-instances --region us-east-1 --output json

Questo restituisce l'intero inventario di istanze nella regione specificata, inclusi security group, subnet e ruoli IAM associati. Per ampliare la ricognizione allo storage, si passa ai bucket S3:

aws s3api list-buckets

Seguito da un controllo delle policy di accesso pubblico su ciascun bucket individuato:

aws s3api get-public-access-block --bucket

L'enumerazione dei database RDS completa il quadro:

aws rds describe-db-instances --output table

Su Azure, la CLI nativa offre comandi equivalenti. Per le macchine virtuali:

az vm list --output table

Per gli account di storage e i relativi container:

az storage account list --output table

Su GCP, il Cloud SDK espone comandi analoghi:

gcloud compute instances list

gcloud storage ls

Per un approccio più strutturato e automatizzato, Pacu (open source) è il framework di riferimento per il pentesting AWS. Dopo l'installazione via pip e la configurazione delle credenziali con il comando set_keys, il modulo di enumerazione EC2 si lancia così:

run ec2__enum

Pacu dispone di decine di moduli che enumerano progressivamente IAM, S3, Lambda, RDS e altri servizi, costruendo un inventario completo dell'ambiente target. L'equivalente multi-cloud è ScoutSuite (open source), che esegue audit automatizzati su AWS, Azure e GCP generando report HTML navigabili con evidenza di misconfiguration.

Un aspetto cruciale della simulazione: documentate ogni chiamata API effettuata, perché il blue team dovrà essere in grado di ricostruirle in CloudTrail o nei log equivalenti. Se la detection non scatta, avete trovato un gap da colmare.

La detection di questa tecnica ruota quasi interamente attorno ai log delle API cloud. Su AWS, CloudTrail è la sorgente primaria e imprescindibile: ogni chiamata API viene registrata con l'identità chiamante, l'IP sorgente, la regione e il timestamp. Su Azure l'equivalente è Activity Log e Azure Monitor, su GCP i Cloud Audit Logs.

Il primo livello di alert si costruisce sulle chiamate di enumerazione ad alto valore. Su AWS, le event name da monitorare includono DescribeInstances, ListBuckets, HeadBucket, GetPublicAccessBlock, DescribeDBInstances, DescribeSnapshots e ListVolumes. Un singolo evento non è significativo — un burst di chiamate diverse in una finestra temporale ristretta, invece, lo è.

La strategia di tuning suggerita dai dati detection prevede quattro dimensioni di filtraggio:

• UserContext: filtrate le identità note che eseguono operazioni di inventario legittime (tool di asset management, pipeline CI/CD, account di monitoraggio). Tutto ciò che resta merita attenzione.
• GeoLocation: confrontate l'IP sorgente con le regioni operative attese. Un'enumerazione da un IP in un paese dove l'organizzazione non opera è un segnale forte.
• TimeWindow: correlate le chiamate di discovery con azioni successive come la creazione di snapshot, la modifica di security group o l'avvio di nuove istanze. Una sequenza enumerate-then-act in pochi minuti è un pattern classico di compromissione.
• APIThreshold: definite una soglia di volume per le chiamate di discovery in una sessione. Strumenti come Pacu o ScoutSuite generano decine o centinaia di chiamate in sequenza rapida, un pattern molto diverso dall'uso umano.

Su piattaforme SIEM come Splunk (a pagamento) o Elastic Security (freemium), una regola efficace correla il numero di API di discovery distinte invocate dalla stessa identità in una finestra di 5-10 minuti. Se supera una soglia — ad esempio 5 API di enumerazione diverse su 3 o più servizi — l'alert scatta con priorità media, da elevare a alta se l'identità è nuova o il contesto geografico è anomalo.

Attenzione al falso positivo più comune: i tool di inventory e compliance come AWS Config, Prisma Cloud o CloudCustodian effettuano scansioni periodiche che generano esattamente le stesse chiamate API. La whitelist per service account è obbligatoria, ma va revisionata trimestralmente per evitare che diventi un punto cieco.

L'analisi forense di un'attività di cloud infrastructure discovery si svolge quasi interamente nel piano dei log cloud, con una logica diversa dalla forensics tradizionale su endpoint. Non ci sono artefatti su disco da acquisire: la prova è nei metadati delle chiamate API.

Su AWS CloudTrail, ogni evento contiene campi essenziali per la ricostruzione della timeline: eventTime, eventName, userIdentity (con ARN, account ID, tipo di identità), sourceIPAddress, userAgent e requestParameters. Il campo userAgent è particolarmente prezioso: Pacu si identifica con una stringa specifica diversa dalla AWS CLI standard, e tool come ScoutSuite lasciano firme analoghe. Anche quando l'attaccante non usa tool noti, l'user agent rivela spesso la libreria sottostante (ad esempio boto3 con una versione insolita).

La ricostruzione della timeline parte dall'identificazione della prima chiamata di discovery anomala e si espande in entrambe le direzioni temporali. All'indietro, si cerca il momento di compromissione delle credenziali — spesso una CreateAccessKey, un AssumeRole anomalo o un login da IP insolito. In avanti, si tracciano le azioni post-discovery: creazione di snapshot (CreateSnapshot), modifica delle policy dei bucket (PutBucketPolicy), avvio di istanze (RunInstances) o tentativi di esfiltrazione.

Per consolidare l'analisi, l'export dei log CloudTrail in formato JSON e l'ingestione in jq (open source) permette query rapide. Ad esempio, per estrarre tutte le chiamate di un'identità specifica in ordine cronologico:

cat cloudtrail-logs.json | jq '.Records[] | select(.userIdentity.arn == "") | {eventTime, eventName, sourceIPAddress, userAgent}' | sort

Su Azure, gli Activity Log offrono una struttura simile con il campo caller, operationName e claims. Su GCP, i Cloud Audit Logs registrano protoPayload.authenticationInfo e protoPayload.methodName.

Un artefatto spesso trascurato è il log di AWS S3 Server Access Logging, se abilitato sui bucket target. Questo log registra gli accessi HeadBucket e ListObjects anche quando CloudTrail non cattura data event S3 (funzionalità che richiede configurazione esplicita). La presenza di accessi HEAD sistematici su bucket diversi da un singolo IP è un indicatore di wordlist scanning.

Nella timeline finale, evidenziate la finestra temporale tra la prima discovery e la prima azione offensiva: se è brevissima (minuti), suggerisce automazione e quindi l'uso di un framework come Pacu. Se è più ampia (ore o giorni), indica un operatore umano che analizza i risultati prima di procedere.

Il panorama degli attori che impiegano T1580 è attualmente circoscritto ma rappresentativo di due modelli operativi distinti nel targeting cloud.

Scattered Spider (G1015) è il primo profilo da analizzare. Questo gruppo, noto per le operazioni di social engineering sofisticate, utilizza la cloud infrastructure discovery in modo mirato: enumera specificamente i bucket S3 di AWS per identificare infrastrutture di gestione server e backup, accessi alle risorse, database e container di storage. Il pattern è chiaro — Scattered Spider non esegue una ricognizione generica, ma cerca asset specifici che supportano la gestione dell'infrastruttura, perché il controllo di quei sistemi amplifica enormemente l'accesso. L'interesse per i backup è particolarmente rilevante: compromettere i backup significa sia poter esfiltrare dati storici sia, in scenari ransomware, eliminare le opzioni di recovery della vittima.

Storm-0501 (G1053) rappresenta il secondo modello. Questo attore enumera ambienti cloud compromessi con un focus su asset critici, data store e risorse di backup. La somiglianza con il targeting di Scattered Spider non è casuale: entrambi i gruppi convergono sui backup e sui data store come obiettivi primari della discovery, confermando un trend più ampio nell'ecosistema threat in cui la ricognizione cloud è orientata alla massimizzazione dell'impatto piuttosto che alla semplice mappatura.

Sul piano degli strumenti, Pacu (S1091) è l'unico tool formalmente associato a questa tecnica. Sviluppato originariamente come framework di pentesting AWS da Rhino Security Labs, Pacu automatizza l'enumerazione di EC2, S3, IAM, RDS e altri servizi con moduli dedicati. La sua presenza in un'indagine è un indicatore ambivalente: può segnalare sia un red team legittimo sia un attaccante che adotta tool offensivi pubblici.

Il trend emergente da monitorare è la convergenza tra cloud discovery e azioni distruttive. Entrambi i gruppi documentati cercano backup durante la fase di ricognizione, il che suggerisce che la discovery non è solo propedeutica all'esfiltrazione ma anche a operazioni di tipo estorsivo. Per il threat intelligence officer, il consiglio operativo è correlare qualsiasi alert T1580 con indicatori di compromissione legati a questi gruppi e verificare immediatamente lo stato delle policy di accesso ai backup e ai data store critici.

Framework MITRE ATT&CK v16 — Tecnica T1580 (Cloud Infrastructure Discovery), Tattica TA0007 (Discovery). Gruppi: G1015 (Scattered Spider), G1053 (Storm-0501). Software: S1091 (Pacu). Mitigazione: M1018 (User Account Management). Detection: DET0169, AN0481. Integrato con conoscenza professionale per tool e procedure operative.