Ricognizione Infrastruttura Cloud: Cloud Infrastructure Discovery (T1580)

In un ingaggio red team autorizzato su ambiente AWS, l'operatività su T1580 inizia dopo aver ottenuto una coppia di access key valide, tipicamente da un token trafugato o da una repository esposta. La prima operazione è validare l'identità con AWS CLI (open source):

aws sts get-caller-identity

Questo comando restituisce ARN, UserId e Account senza consumare privilegi particolari. Da qui si passa all'enumerazione compute e storage:

aws ec2 describe-instances --region us-east-1 aws s3api list-buckets aws rds describe-db-instances

Per bucket individuati, la verifica della configurazione pubblica avviene con aws s3api get-public-access-block --bucket e aws s3api get-bucket-acl --bucket . La chiamata HeadBucket consente di determinare esistenza e permessi anche su bucket non propri, utile per side-channel discovery.

Su Azure, il flusso equivalente usa Azure CLI (open source): az account show, az vm list -o table, az storage account list, az sql server list. Su GCP, il Cloud SDK (open source) offre gcloud auth list, gcloud compute instances list, gcloud storage buckets list, gcloud sql instances list.

Per automatizzare in scenari post-exploitation, il framework di riferimento è Pacu (S1091, open source), sviluppato da Rhino Security Labs. Dopo import delle chiavi con set_keys, moduli come ec2__enum, s3__enum, iam__enum_permissions e rds__enum mappano l'intera superficie AWS accessibile all'identità compromessa, salvando l'output in un database SQLite locale per correlazioni successive.

Per la fase di Wordlist Scanning su bucket pubblici (senza credenziali), tool come CloudBrute (open source) e S3Scanner (open source) permutano nomi comuni combinati col brand target per identificare storage esposto. Un esempio: s3scanner scan --bucket-file candidates.txt elenca bucket esistenti e le loro ACL.

Durante il red team, è buona pratica limitare la frequenza delle chiamate API sotto le soglie di rilevamento tipiche di GuardDuty (chiamate Discovery:IAMUser/AnomalousBehavior) e distribuire l'attività su più IP tramite proxy residenziali autorizzati dal contratto. L'obiettivo finale non è raccogliere l'intero inventario, ma identificare in modo mirato i pochi asset che consentono escalation: ruoli IAM con AssumeRole verso account privilegiati, bucket con backup di database, snapshot EBS non cifrati contenenti credenziali applicative.

La detection di T1580 in ambiente AWS ruota attorno a CloudTrail, che registra ogni chiamata API management-plane. Gli eventi chiave da monitorare includono DescribeInstances, DescribeSnapshots, DescribeVolumes, ListBuckets, HeadBucket, GetPublicAccessBlock, GetBucketAcl, DescribeDBInstances e ListFunctions. In Azure, l'equivalente è Azure Activity Log con operazioni Microsoft.Compute/virtualMachines/read e Microsoft.Storage/storageAccounts/read; in GCP si consultano gli Admin Activity Logs con metodi compute.instances.list e storage.buckets.list.

La strategia di detection DET0169/AN0481 suggerisce un approccio comportamentale piuttosto che signature-based. Un singolo ListBuckets è rumore di fondo; il segnale emerge quando una stessa identità esegue in rapida sequenza chiamate di discovery su servizi eterogenei (EC2, S3, RDS, Lambda) entro pochi minuti, pattern tipico di tool automatizzati come Pacu. Una query KQL su Sentinel o un detector su GuardDuty (a pagamento) dovrebbe correlare:

• UserContext: identità coinvolta, filtrando account di inventory noti (es. AWS Config, Prisma Cloud, Wiz scanner)
• GeoLocation: IP sorgente confrontato con le regioni operative attese; chiamate da ASN residenziali o VPN commerciali sono sospette
• TimeWindow: finestra di correlazione di 10-30 minuti per collegare discovery a successive CreateSnapshot, ModifyImageAttribute o PutBucketPolicy
• APIThreshold: volume di chiamate Describe/List per identità/ora, con baseline per ruolo

Un indicatore ad alto valore è la chiamata GetCallerIdentity seguita entro secondi da enumerazioni multi-servizio: pattern classico di un attaccante che valida credenziali appena ottenute. Analogamente, iam:SimulatePrincipalPolicy o enumerazione massiva di ListAttachedUserPolicies indica mappatura dei privilegi, spesso preludio a escalation.

Dal lato D3FEND, le contromisure rilevanti sono Authentication Event Thresholding e Resource Access Pattern Analysis: costruire baseline per ogni ruolo IAM sulle API tipicamente invocate e alertare su deviazioni. GuardDuty dispone nativamente del finding Discovery:IAMUser/AnomalousBehavior che copre buona parte dello scenario.

I falsi positivi più frequenti provengono da: strumenti di CSPM (Wiz, Prisma, Orca), backup solution che enumerano volumi, script DevOps di inventory, migrazioni cloud. La whitelist deve basarsi su ARN dei ruoli service-linked, non su IP che possono cambiare. Un'ulteriore fonte di rumore sono i console utenti amministrativi che navigano manualmente: filtrare eventi con userAgent contenente console.amazonaws.com riduce il volume, mantenendo però visibilità sulle chiamate CLI e SDK che rappresentano il vero rischio.

L'analisi forense di un incidente T1580 è quasi interamente cloud-side, poiché la tecnica non lascia artefatti significativi sugli endpoint tradizionali. Il repository primario è AWS CloudTrail, idealmente configurato come organization trail con log archiviati in un bucket S3 dedicato e immutabile tramite Object Lock. In caso di compromissione sospetta, il primo step è esportare gli eventi delle ultime 90 giorni relativi all'identità compromessa e ricostruire la timeline con Athena (a pagamento) o jq (open source) su file JSON estratti.

Una query Athena tipica filtra su eventName IN ('DescribeInstances','ListBuckets','DescribeSnapshots','DescribeDBInstances') raggruppando per userIdentity.arn, sourceIPAddress e userAgent. Il campo userAgent è diagnostico: valori come aws-cli/2.x o Boto3/1.x Python/3.x indicano uso programmatico, mentre Pacu lascia stringhe caratteristiche se non modificato. La presenza di aws-sdk-go combinata con IP di hosting provider (DigitalOcean, Hetzner, OVH) è un forte indicatore di attività malevola.

Gli artefatti chiave da collezionare includono: eventi CloudTrail completi con requestParameters e responseElements, snapshot delle policy IAM applicate all'identità al momento dell'incidente (spesso modificate durante l'attacco), log di VPC Flow per correlare traffico verso endpoint dei servizi API, e configurazione di AWS Config per ricostruire lo stato delle risorse prima e dopo la compromissione.

Per Azure, gli Activity Logs e i Microsoft Entra ID Sign-in Logs vanno correlati: il campo appDisplayName identifica se le chiamate provengono da Azure CLI, PowerShell o SDK custom, mentre conditionalAccessStatus indica se l'accesso ha bypassato policy MFA. In GCP, i Cloud Audit Logs con severità NOTICE e sopra devono essere esportati verso BigQuery per query storiche.

Dal punto di vista D3FEND, gli artefatti digitali rilevanti sono Authentication Log, Resource Access Log e User Account. Ricostruire la sequenza credential use → discovery → privilege enumeration → resource modification consente di stabilire l'esatto blast radius. È fondamentale verificare se durante la finestra di discovery siano state create nuove access key, ruoli con AssumeRolePolicy permissiva, o snapshot copiati verso account esterni tramite ModifySnapshotAttribute.

Gruppi come Scattered Spider (G1015) hanno storicamente enumerato bucket S3 per identificare backup, mentre Storm-0501 (G1053) ha mappato data store critici in ambienti ibridi prima di deployare ransomware. Nella timeline, la fase T1580 tipicamente si colloca tra 30 minuti e 6 ore dopo il primo accesso non autorizzato, e precede immediatamente esfiltrazione o distruzione. Conservare gli hash MD5 dei file di log e la chain of custody è essenziale se l'incidente sfocia in azione legale.

L'enumerazione dell'infrastruttura cloud è diventata una fase standardizzata negli attacchi contro ambienti IaaS, con due profili avversariali particolarmente attivi documentati in MITRE ATT&CK.

Scattered Spider (G1015), noto anche come UNC3944 e Octo Tempest, è un collettivo cybercriminale di lingua inglese specializzato in social engineering avanzato contro help desk aziendali. Il gruppo ha colpito ripetutamente settori telco, hospitality, retail e finance, con vittime di alto profilo negli Stati Uniti. Nel contesto T1580, Scattered Spider enumera sistematicamente bucket S3 dopo aver ottenuto credenziali AWS, con l'obiettivo esplicito di identificare infrastrutture di backup management, database e storage container. Questa focalizzazione sui backup è coerente con la loro strategia post-compromise: prima esfiltrare, poi disabilitare i backup, infine deployare ransomware (spesso ALPHV/BlackCat o RansomHub) massimizzando la leva estorsiva. L'uso di credenziali legittime rende la loro attività di discovery difficile da distinguere da amministratori reali senza analisi comportamentale.

Storm-0501 (G1053) è un attore tracciato da Microsoft, evoluto da affiliato ransomware tradizionale a specialista di ambienti ibridi on-prem/cloud. Il gruppo enumera ambienti cloud compromessi per identificare asset critici, data store e risorse di backup, con particolare attenzione a scenari di lateral movement da Active Directory on-prem verso Entra ID e Azure. La loro TTP di discovery precede tipicamente la creazione di backdoor federate e l'esfiltrazione selettiva prima del deploy ransomware.

Dal punto di vista del tool overlap, entrambi i gruppi si affidano prevalentemente a strumenti nativi (AWS CLI, Azure CLI, PowerShell) piuttosto che a malware custom, riducendo la superficie di detection endpoint. Pacu (S1091), sviluppato da Rhino Security Labs come framework offensivo AWS open source, è emerso come tool preferito da red team ma anche da attori malevoli per la sua modularità: i suoi moduli di enumerazione (ec2__enum, s3__enum, iam__enum_permissions) coprono l'intero spettro T1580 con un singolo comando.

Il trend osservabile è una progressiva industrializzazione della fase di discovery cloud: gli attaccanti dedicano tempo significativo (ore o giorni) a mappare l'ambiente prima di agire, sfruttando la difficoltà organizzativa nel distinguere enumerazione legittima (CSPM, audit) da malevola. La contromisura strategica è ridurre drasticamente i privilegi permanenti tramite M1018 (User Account Management): applicare least privilege, ridurre gli assegnamenti privilegiati permanenti, condurre entitlement review periodiche su utenti IAM, ruoli e policy. L'adozione di Just-in-Time access tramite soluzioni PAM come CyberArk o BeyondTrust (a pagamento) limita la finestra temporale in cui credenziali privilegiate sono utilizzabili per discovery malevola.

MITRE ATT&CK T1580 (Cloud Infrastructure Discovery), tattica TA0007. Gruppi G1015 (Scattered Spider), G1053 (Storm-0501). Software S1091 (Pacu). Mitigazione M1018 (User Account Management). Detection strategy DET0169/AN0481. MITRE D3FEND per Resource Access Pattern Analysis e Authentication Event Thresholding. Documentazione ufficiale AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs. Per comandi CLI e tool operativi è stata usata conoscenza professionale di cybersecurity basata su documentazione ufficiale dei vendor cloud e repository pubblici dei tool citati.