Enumerazione Oggetti Cloud Storage: Cloud Storage Object Discovery (T1619)

In un ingaggio di red team cloud, l'enumerazione dello storage arriva dopo aver ottenuto un set di credenziali — tipicamente access key AWS, service principal Azure o service account key GCP — tramite phishing, secret leak in repository pubblici o compromissione di un'istanza con ruoli IAM attaccati.

Su AWS il comando base è aws s3api list-buckets per elencare i bucket accessibili, seguito da aws s3api list-objects-v2 --bucket per enumerare gli oggetti. La versione CLI ad alto livello aws s3 ls s3:// --recursive fornisce output più leggibile. Per verificare rapidamente cosa può fare un set di chiavi rubate si usa aws sts get-caller-identity per confermarne la validità, poi si prova aws iam simulate-principal-policy se le policy IAM lo permettono.

Su Azure il comando equivalente è az storage blob list --container-name --account-name , mentre su GCP si usa gsutil ls -r gs:// oppure gcloud storage ls.

Gli strumenti dedicati che compaiono nei dataset MITRE sono due. Pacu (open source), sviluppato da Rhino Security Labs, è il framework di exploitation AWS più completo: il modulo s3__bucket_finder enumera bucket noti, mentre enum_ebs_volumes_snapshots mappa i volumi EBS. Peirates (open source) è invece orientato a Kubernetes ma include funzioni per enumerare bucket S3 dal contesto di un pod compromesso su EKS.

Altri tool utili in laboratorio: ScoutSuite (open source) di NCC Group per audit multi-cloud, CloudFox (open source) di Bishop Fox che automatizza la discovery post-compromise mostrando in output tabellare bucket, secret e ruoli assumibili, e Prowler (open source) per assessment di configurazione. Per la ricerca di bucket pubblici esposti si usa s3scanner (open source) o CloudBrute (open source), che tentano brute-force di nomi comuni.

La catena tipica in un esercizio red team parte quindi dal recupero delle credenziali (spesso da file .aws/credentials su un host compromesso o da variabili d'ambiente in container), passa per la conferma dell'identità con get-caller-identity, prosegue con l'enumerazione dei servizi tramite CloudFox o ScoutSuite in modalità read-only, e culmina con la lettura selettiva degli oggetti più interessanti. È buona pratica in lab-safe operations limitare il rate delle chiamate API con --page-size e evitare download massivi che genererebbero costi anomali per il cliente.

La detection di T1619 poggia quasi interamente sulla telemetria del control plane cloud. Su AWS il log source primario è CloudTrail, dove gli eventi rilevanti sono ListObjects, ListObjectsV2, ListBuckets e GetBucketLocation. Su Azure si consultano gli Storage Analytics Logs e i Diagnostic Logs del servizio Blob, cercando operazioni ListBlobs e ListContainers. Su GCP i Cloud Audit Logs — specificamente i Data Access logs — registrano storage.objects.list e storage.buckets.list, ma richiedono attivazione esplicita perché non sono abilitati di default.

La detection strategy DET0578 proposta da MITRE (analitica AN1594) suggerisce di correlare le chiamate di enumerazione con il contesto dell'identità chiamante. Tre dimensioni di tuning sono particolarmente efficaci:

• TimeWindow: una finestra di correlazione di 5 minuti che conta più di N chiamate ListObjects distingue enumerazione automatizzata da uso applicativo regolare.
• UserContext: mantenere una baseline dei service account e dei ruoli IAM che legittimamente enumerano storage; qualsiasi principal fuori lista genera alert ad alta priorità.
• RegionScope: enumerazioni che spaziano su più regioni geografiche in rapida successione sono un forte segnale di ricognizione ostile, poiché applicazioni legittime tipicamente operano su regioni definite.

Un secondo layer di detection è l'anomalia di volume. Se un ruolo che normalmente esegue 10 chiamate ListObjectsV2 al giorno ne genera improvvisamente 500 in un'ora, l'evento merita triage. AWS GuardDuty (a pagamento) include il finding Discovery:S3/AnomalousBehavior che copre esattamente questo scenario. Azure Defender for Storage (a pagamento) offre alert equivalenti, mentre in GCP si può usare Security Command Center (freemium, tier Premium a pagamento).

Per chi costruisce detection custom, Panther (a pagamento), Sumo Logic Cloud SIEM (a pagamento) e Elastic Security (freemium) hanno regole predefinite per anomalie CloudTrail. In alternativa, query Athena su bucket CloudTrail o KQL su Sentinel permettono di implementare la logica di correlazione descritta.

I falsi positivi più comuni derivano da: strumenti di backup che scansionano periodicamente i bucket, pipeline CI/CD che verificano artefatti, agent di cost optimization e tool di compliance come Prowler o ScoutSuite eseguiti dal team interno. Per ridurre il rumore è essenziale mantenere un allow-list documentato di principal autorizzati alla discovery, e ogni nuovo strumento introdotto in ambiente deve essere registrato prima di essere attivato. Una regola pratica: alert solo quando l'enumerazione proviene da identità non presenti nell'allow-list, o quando proviene da IP esterni a range noti.

L'indagine forense su un incidente che coinvolge T1619 è quasi interamente cloud-native: gli artefatti risiedono nei log del provider, non su endpoint. Il primo passo è acquisire i log CloudTrail (AWS), Activity Log e Storage Analytics (Azure) o Cloud Audit Logs (GCP) coprendo una finestra temporale adeguata attorno all'evento sospetto — tipicamente 30 giorni prima e dopo, se la retention lo consente.

Su AWS i campi CloudTrail chiave da estrarre per ricostruire la timeline sono eventTime, eventName (ListObjectsV2, ListBuckets), userIdentity.arn, userIdentity.accessKeyId, sourceIPAddress, userAgent e requestParameters.bucketName. Lo userAgent è particolarmente prezioso: valori come aws-cli/2.x, Boto3/1.x, o stringhe custom di tool come Pacu (Pacu/1.x) o CloudFox rivelano lo strumento usato dall'attaccante. Su Azure il campo equivalente è callerIpAddress e userAgentHeader nei diagnostic logs dello Storage Account.

Per l'analisi si può usare jq (open source) su export JSON, Athena (a pagamento, pay-per-query) direttamente su bucket CloudTrail, o strumenti dedicati come Cloudtrail2Timesketch (open source) per costruire timeline importabili in Timesketch (open source). Grayhat Warfare (freemium) è utile per verificare se un bucket enumerato compare in indici pubblici di storage esposti.

La correlazione con altri artefatti è cruciale. Se le credenziali usate erano access key statiche, si cerca la loro origine: sono state generate legittimamente e poi rubate? CreateAccessKey in CloudTrail rivela quando e da chi. Se invece si tratta di credenziali temporanee (STS), gli eventi AssumeRole mostrano la catena di assunzione dei ruoli e permettono di risalire al principal originale — spesso un'istanza EC2 compromessa o un utente federato via SSO.

Su endpoint on-prem o cloud, quando disponibili, gli artefatti utili sono: file ~/.aws/credentials e ~/.aws/config con timestamp di modifica, history di shell (.bash_history, .zsh_history) contenenti comandi aws s3api o gsutil, e in ambiente Windows le voci PowerShell in Microsoft-Windows-PowerShell/Operational (EventCode 4104) che registrano l'esecuzione di moduli come AWSPowerShell.

Per ambienti Kubernetes compromessi tramite Peirates, i log del kubelet e gli audit log dell'API server mostrano l'exec nei pod da cui parte l'enumerazione. Il file /var/run/secrets/kubernetes.io/serviceaccount/token usato per ottenere credenziali va documentato come artefatto, insieme al mount dei metadata endpoint (169.254.169.254) tipicamente contattati per estrarre le credenziali IAM del nodo. La timeline finale deve intrecciare l'evento di initial access, il momento della credential theft, e le successive chiamate di enumerazione, mostrando la progressione tattica.

Il dataset MITRE non associa gruppi APT specifici a T1619, il che è di per sé un dato interessante: l'assenza di attribuzione riflette la natura opportunistica e cross-actor dell'attività di enumerazione cloud. Praticamente ogni attore che ottiene accesso a un ambiente AWS, Azure o GCP esegue questa tecnica, ma raramente viene documentata come signature distintiva perché è troppo comune e povera di indicatori attribuibili.

Gli unici due software mappati sono strumenti di offensive security legittimi, non malware. Pacu (S1091), sviluppato da Rhino Security Labs come framework open source per exploitation AWS, è diventato lo standard de facto sia per red team autorizzati sia per attori malevoli opportunistici. La sua modularità — decine di moduli tra cui s3__bucket_finder, enum_ebs_volumes_snapshots e iam__enum_permissions — lo rende comodo per la ricognizione automatizzata dopo la compromissione di credenziali. Peirates (S0683), sviluppato da InGuardians, è specializzato in attacchi Kubernetes e include capacità di enumerazione S3 dal contesto di pod eseguiti su cluster EKS. Entrambi sono pubblicamente disponibili su GitHub, il che abbatte la barriera d'ingresso per attori di ogni livello.

Dal punto di vista dei pattern osservati nel threat landscape più ampio (conoscenza professionale del settore), le campagne che sfruttano intensamente questa tecnica tendono a rientrare in tre categorie: attori financially-motivated che cercano dump di database e credenziali monetizzabili, gruppi ransomware che negli ultimi anni hanno esteso il playbook al cloud (esfiltrando da bucket S3 prima di cifrare on-prem come leva di doppia estorsione), e insider threat o ex-dipendenti con credenziali ancora valide.

Un trend rilevante è lo shift verso attacchi che iniziano con secret leak su GitHub, GitLab o Docker Hub: bot automatizzati scansionano continuamente i push pubblici per estrarre access key, e nel giro di minuti le usano per enumerare buckets. Servizi come GitGuardian (freemium) e TruffleHog (open source) documentano milioni di secret esposti ogni anno, e le telemetrie AWS mostrano che una chiave leaked viene tipicamente sfruttata entro pochi minuti dalla pubblicazione.

Un secondo trend è l'uso di living-off-the-cloud: gli attori evitano di installare malware e operano interamente tramite API cloud autenticate, rendendo la detection endpoint irrilevante e spostando l'onere sul monitoring del control plane. Questo modello, associato in letteratura pubblica a gruppi come Scattered Spider nelle intrusioni SaaS-heavy, si sta estendendo anche alle intrusioni IaaS. La difesa richiede investimento in CSPM (Cloud Security Posture Management) e in detection basate su CloudTrail/Activity Log piuttosto che in EDR tradizionale.

MITRE ATT&CK: T1619 (Cloud Storage Object Discovery), tattica TA0007. Software: S1091 (Pacu), S0683 (Peirates). Mitigazione: M1018 (User Account Management). Detection: DET0578, analitica AN1594. MITRE D3FEND per tecniche difensive correlate a cloud service enumeration. Parti dei contenuti relativi a tool operativi, comandi CLI dei provider cloud e trend di threat landscape derivano da conoscenza professionale di settore su piattaforme AWS, Azure e GCP e su strumenti di offensive security pubblicamente documentati.