Regioni Cloud Inutilizzate: Unused/Unsupported Cloud Regions (T1535)

In un ingaggio red team autorizzato l'obiettivo è dimostrare che le risorse possono nascere in regioni non presidiate. Il presupposto è il possesso di credenziali di gestione cloud, ottenute in fasi precedenti (phishing, chiavi esposte in repository, ruoli IAM permissivi).

Su AWS, dopo aver caricato credenziali temporanee, il primo passo è enumerare quali regioni sono abilitate sull'account:

aws account list-regions --region-opt-status-contains ENABLED

Si identifica poi una regione geograficamente distante e raramente usata dal cliente. Il provisioning di un'istanza compute in quella regione replica il comportamento di cryptomining:

aws ec2 run-instances --region ap-south-1 --image-id --instance-type c5.4xlarge --count 1

Per misurare la "cecità" difensiva, verifica se GuardDuty è attivo nella regione bersaglio:

aws guardduty list-detectors --region ap-south-1

Un output vuoto conferma l'assenza di detection managed. Analogamente su Azure si valuta la distribuzione con az account list-locations -o table e si crea un resource group in una location periferica con az group create --name rg-test --location southindia. Su GCP l'equivalente è gcloud compute regions list seguito da gcloud compute instances create con flag --zone su una zona non monitorata.

Per orchestrare l'intero scenario in laboratorio, alcuni tool reali aiutano a mappare la superficie e simulare l'abuso:

• Pacu (open source), framework di exploitation AWS con moduli di enumerazione IAM e regioni;
• ScoutSuite (open source), audit multi-cloud che evidenzia servizi di logging non abilitati per regione;
• Prowler (open source), che con controlli CIS segnala regioni prive di CloudTrail o GuardDuty;
• Stratus Red Team (open source) di DataDog, che include tecniche cloud emulate mappate ad ATT&CK.

La catena d'attacco tipica si articola così: acquisizione credenziali → enumerazione regioni abilitate e stato del logging → selezione della regione con detection assente → avvio di istanze compute ad alto consumo → occultamento del traffico C2 tramite endpoint regionali legittimi.

Regola d'oro del laboratorio: lavora su un account cloud dedicato e con budget cap, imposta aws budgets o quote esplicite per evitare costi reali, e distruggi le risorse (terraform destroy se usi IaC, open source) a fine test. Documenta ogni regione toccata per il report di remediation, così il blue team può derivare la lista delle regioni da disattivare.

Il rilevamento di T1535 è essenzialmente un problema di anomalia geografica e di correlazione temporale. Il segnale forte è la comparsa di attività di provisioning in una regione che storicamente l'organizzazione non ha mai usato, spesso pochi minuti dopo un accesso o l'uso di credenziali provenienti da regioni note.

La detection DET0247 / AN0690 indica come sorgenti primarie i log AWS CloudTrail (inclusa la chiamata GetCallerIdentity) e i VPC Flow Logs. Il perno operativo è mantenere una UnusedRegionList, l'elenco delle regioni storicamente inutilizzate per tenant o progetto, e generare alert quando eventi come RunInstances, CreateFunction o CreateCluster compaiono lì. Un dettaglio cruciale: CloudTrail deve essere configurato come trail multi-regione, altrimenti gli eventi nelle regioni "cieche" non arrivano nemmeno al SIEM.

Le regole efficaci combinano più condizioni. In pratica conviene correlare tre elementi: l'evento di creazione risorsa nella regione anomala, l'assenza di rilevatori GuardDuty in quella regione (guardduty:ListDetectors che ritorna vuoto), e un volume di traffico in uscita che supera l'OutboundTrafficThreshold definito — indizio tipico del cryptomining. La finestra temporale (TimeWindow) lega il provisioning all'accesso credenziali che lo precede.

Un esempio di logica in Splunk (a pagamento) parte da CloudTrail:

index=cloudtrail eventName=RunInstances NOT awsRegion IN (us-east-1, eu-west-1) | stats count by awsRegion, userIdentity.arn

Sul fronte preventivo (Harden), la mitigazione M1054 (Software Configuration) è dirimente: molti provider consentono di disattivare le regioni inutilizzate, riducendo drasticamente la superficie. Su AWS ciò si fa con Service Control Policy nelle Organizations che negano azioni fuori dalle regioni approvate, condizionando su aws:RequestedRegion. Vanno inoltre abilitati GuardDuty e Config in tutte le regioni attive e centralizzati i log in un SIEM.

Attenzione ai falsi positivi. Eventi legittimi che assomigliano all'attacco includono: nuovi progetti di espansione geografica, test di disaster recovery in regioni secondarie, servizi globali che registrano eventi in us-east-1 per natura, e attività di CDN o edge. Per questo la AllowedServiceList — whitelist dei servizi ammessi nelle regioni DR/secondarie — è indispensabile per non sommergere gli analisti. Un buon programma di detection classifica ogni regione come approvata, DR o vietata, e applica soglie diverse a ciascuna categoria.

L'analisi forense di un abuso di regioni cloud inutilizzate ruota attorno ai log del control plane, perché l'endpoint tradizionale spesso non esiste: le risorse sono effimere e vengono distrutte dopo l'uso. La fonte cardine è AWS CloudTrail, dove ogni azione API lascia una traccia con timestamp UTC, ARN del principal, IP sorgente, userAgent e regione. Ricostruire la timeline significa ordinare cronologicamente questi eventi.

Il punto di partenza tipico è un evento GetCallerIdentity o AssumeRole, che segnala il momento in cui le credenziali compromesse sono state validate. Da lì si cerca la sequenza RunInstances, CreateVolume o CreateFunction nelle regioni anomale. Correlando i campi sourceIPAddress e userAgent si distingue l'attività amministrativa legittima da quella dell'avversario: SDK insoliti, IP di provider VPS o Tor, e orari fuori dal fuso operativo del team sono indicatori forti.

Gli artefatti chiave da raccogliere includono:

• Record CloudTrail dell'evento di provisioning con l'eventID e la regione;
• VPC Flow Logs della regione anomala, che rivelano volumi di traffico verso pool di mining o endpoint C2;
• Snapshot dei metadati dell'istanza (tipo, AMI, tag) recuperabili via aws ec2 describe-instances --region finché la risorsa esiste;
• Fatturazione dettagliata Cost and Usage Report, spesso l'unica prova residua dopo la distruzione delle istanze, utile a datare inizio e fine dell'attività.

Quando le istanze sono ancora vive, va acquisita l'immagine dei volumi EBS con aws ec2 create-snapshot prima di qualsiasi terminazione, preservando la catena di custodia. L'analisi del volume con strumenti classici come The Sleuth Kit (open source) o Velociraptor (open source) può recuperare binari di mining, script di persistenza e configurazioni del pool.

Per le fonti esterne e la contestualizzazione, i log di autenticazione dell'IdP e i CloudTrail di sts:AssumeRole aiutano a stabilire come le credenziali sono state ottenute a monte. In ambienti multi-cloud, l'equivalente da esaminare è l'Azure Activity Log o i GCP Cloud Audit Logs, filtrando per location non approvate.

Una lezione ricorrente nelle indagini di cryptomining è che l'assenza di GuardDuty nella regione compromessa lascia un vuoto proprio nel periodo critico: il forense deve quindi ricostruire l'accaduto dai log di billing e dai trail multi-regione, integrando ciò che il rilevamento managed non ha catturato.

Nei dati MITRE ATT&CK associati a T1535 non risultano gruppi APT, software o campagne formalmente attribuiti. Questa assenza è di per sé un segnale di intelligence: la tecnica non è appannaggio di un attore statale specifico, ma un comportamento trasversale e opportunistico, adottato soprattutto da operatori a movente finanziario che sfruttano credenziali cloud esposte.

Il pattern dominante osservabile nel panorama è quello del cryptojacking: attori che scandagliano continuamente repository pubblici, log applicativi e bucket mal configurati alla ricerca di chiavi di accesso, per poi avviare flotte di istanze compute in regioni remote. La scelta della regione inutilizzata è una decisione puramente tattica di Stealth (TA0005): massimizza il tempo prima della scoperta, che nel cryptomining coincide direttamente con il profitto. Più a lungo l'istanza mina indisturbata, maggiore è il ricavo e il danno economico per la vittima.

Sul piano dei pattern geografici, l'abuso tende a concentrarsi nelle regioni più distanti dal baricentro operativo della vittima — tipicamente Asia-Pacifico o Sud America per organizzazioni con footprint prevalentemente nordamericano o europeo — proprio perché lì la probabilità di monitoraggio attivo è minima. Questa asimmetria fra dove l'azienda lavora e dove l'avversario opera è il tratto distintivo di questa tecnica.

Sul fronte del tool overlap, gli avversari riutilizzano largamente strumenti open source pensati per legittime finalità offensive e di audit, come framework di exploitation cloud e miner standard (XMRig è ricorrente negli incidenti di resource hijacking cloud). La barriera d'ingresso bassa spiega perché la tecnica non si cristallizzi attorno a un singolo threat actor: chiunque disponga di credenziali valide e di uno script di automazione può eseguirla.

In termini di trend, l'adozione della tecnica cresce parallelamente all'aumento delle superfici multi-cloud e alla proliferazione di regioni disponibili presso i provider. Ogni nuova regione abilitata di default rappresenta un potenziale punto cieco. La contromisura strategica raccomandata dalla mitigazione M1054 — disattivare le regioni non necessarie — è anche la migliore forma di riduzione dell'intelligence surface, perché elimina alla radice il territorio in cui l'avversario preferisce operare.

Per un CISO, la lettura chiave è che il rischio non deriva da un nemico identificabile, ma da una configurazione permissiva: la governance delle regioni cloud è, in sé, una misura di threat prevention.

MITRE ATT&CK: tecnica T1535 (Unused/Unsupported Cloud Regions), tattica TA0005; mitigazione M1054 (Software Configuration); detection DET0247 e analitica AN0690 (fonti log AWS CloudTrail, GetCallerIdentity, VPC Flow Logs). Tool citati per implementazione e simulazione: Pacu, ScoutSuite, Prowler, Stratus Red Team, The Sleuth Kit, Velociraptor (open source), Splunk (a pagamento). Parte dei comandi operativi e delle procedure forensi deriva da conoscenza professionale di cybersecurity, verificata rispetto alla documentazione ufficiale dei tool e dei provider cloud.