Creazione di Istanze Cloud: Create Cloud Instance (T1578.002)
La tecnica T1578.002 - Create Cloud Instance descrive l'abuso da parte di un attaccante delle funzionalità di provisioning offerte dai servizi di compute cloud (AWS EC2, Azure Compute, Google Compute Engine) per creare nuove macchine virtuali all'interno di un tenant compromesso. L'obiettivo non è compromettere sistemi esistenti, ma istanziare ambienti paralleli privi dei controlli di sicurezza applicati alle risorse legittime.
Dal punto di vista tattico, la tecnica appartiene a TA0005 (Defense Evasion): l'avversario aggira firewall, agent EDR, policy IAM restrittive e regole di logging che sono state configurate sulle istanze produttive, semplicemente lavorando su una VM di sua creazione. Un pattern ricorrente prevede la creazione di uno snapshot di un volume contenente dati sensibili (T1578.001), il mount di tale snapshot su una nuova istanza controllata dall'attaccante e la successiva esfiltrazione via canali che appaiono come traffico legittimo di un workload cloud.
L'impatto è significativo perché la tecnica sfrutta capacità native e legittime del cloud provider: nessun exploit, nessun malware, solo API autenticate. I dati MITRE censiscono 2 gruppi APT (LAPSUS$ e Scattered Spider), 1 campagna documentata (C0027) e 2 mitigazioni primarie basate su least privilege e audit. Il vettore d'ingresso tipico è credential access preventivo: l'attaccante ottiene credenziali cloud valide, tipicamente tramite social engineering o SIM swapping, e solo dopo procede al provisioning malevolo.
In un esercizio red team autorizzato su ambiente cloud, la simulazione di T1578.002 parte dal presupposto di aver già ottenuto credenziali con permessi di compute provisioning. La catena tipica in AWS prevede l'enumerazione dei permessi correnti, l'identificazione di volumi o snapshot di interesse, la creazione di una nuova istanza in una VPC controllata e il mount del volume target.
Con AWS CLI (open source) l'enumerazione parte da:
aws sts get-caller-identity
aws iam simulate-principal-policy --policy-source-arn
Per identificare snapshot esistenti utili al pivoting:
aws ec2 describe-snapshots --owner-ids self
La creazione dell'istanza malevola con un security group permissivo si esegue con aws ec2 run-instances, specificando AMI, tipo di istanza, subnet e un security group creato ad hoc con aws ec2 authorize-security-group-ingress. Il mount di uno snapshot su un nuovo volume avviene creando il volume da snapshot con aws ec2 create-volume --snapshot-id e allegandolo all'istanza tramite aws ec2 attach-volume.
Su Azure la sequenza equivalente usa Azure CLI (open source): az login, az vm create con parametri di image, size, resource group e admin credentials, seguito da az disk create --source
Per automatizzare l'intera fase di enumeration e attack path discovery, i tool di riferimento in laboratorio sono Pacu (open source), framework di exploitation AWS che include moduli come ec2__enum ed ec2__startup_shell_script; ScoutSuite (open source) per assessment multi-cloud della postura; CloudGoat (open source) di Rhino Security Labs per costruire scenari vulnerabili di training. Per Azure, MicroBurst (open source) offre funzioni PowerShell come Get-AzureVMs e Invoke-AzureVmBulkCMD utili nella fase post-exploitation.
Un dettaglio operativo importante: molti team red simulano anche la persistenza sull'istanza creata caricando uno script di user-data che riavvia un beacon C2 a ogni boot, replicando comportamenti osservati in C0027. Documenta sempre le istanze create con tag identificativi dell'esercizio e concorda con il blue team una finestra di dismissione controllata per evitare drift di costo e falsi allarmi persistenti dopo la fine dell'assessment.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.