Crea Istanza Cloud: Modify Cloud Compute Infrastructure - Create Cloud Instance (T1578.002)

Per comprendere come LAPSUS$ e Scattered Spider sfruttano questa tecnica, iniziamo con la creazione di un'istanza AWS EC2 dopo aver compromesso le credenziali:

aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t2.micro --key-name compromised-key --security-group-ids sg-backdoor

Il vantaggio tattico emerge quando combiniamo questa capacità con la creazione di snapshot. Prima catturiamo i volumi esistenti:

aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "backup"

Poi montiamo lo snapshot sulla nuova istanza con policy meno restrittive. In Azure, l'approccio seguito durante la campagna C0027 prevedeva:

az vm create --resource-group rogue-rg --name stealth-vm --image UbuntuLTS --admin-username azureuser --generate-ssh-keys

La chiave sta nel creare l'istanza in una subnet diversa o con security group permissivi. Questo bypassa completamente i controlli network-level applicati alle istanze legittime. Per replicare l'attacco in laboratorio, configura prima un ambiente multi-subnet con policy differenziate.

Gli attaccanti più sofisticati automatizzano il processo. Uno script Python può orchestrare la sequenza: enumerate snapshots disponibili, creare l'istanza, montare gli snapshot, esfiltrare dati, terminare l'istanza. Il tutto in meno di 10 minuti, rendendo la detection window estremamente ridotta.

Per simulare scenari realistici, utilizza Terraform o CloudFormation per deployare rapidamente infrastrutture temporanee. Questo replica il comportamento di gruppi come Scattered Spider che creano e distruggono risorse velocemente per minimizzare l'esposizione.

La detection efficace richiede correlazione tra molteplici data source. CloudTrail in AWS e Activity Logs in Azure sono fondamentali, ma la configurazione degli alert deve essere chirurgica per evitare l'alert fatigue.

Primo indicatore critico: creazione di istanze da account raramente utilizzati. Se un service account dormiente improvvisamente crea VM, è un red flag immediato. Configura la baseline sui pattern storici degli ultimi 90 giorni.

Il secondo layer di detection sfrutta il context geografico. Se la tua organizzazione opera solo in US-East, una richiesta di creazione istanza da ap-southeast è anomala. Ma attenzione: molti servizi automatizzati operano cross-region legittimamente.

EventName: RunInstances AND sourceIPAddress NOT IN (trusted_ranges) AND userIdentity.type: IAMUser

La correlazione temporale è cruciale. Cerca pattern come: login anomalo → assunzione ruolo → creazione snapshot → creazione istanza → mounting volumi. Questa sequenza in meno di 30 minuti indica probabilmente attività malevola.

Per ridurre i falsi positivi, implementa allowlist dinamiche basate su tag. Le istanze legittime dovrebbero sempre avere tag come Owner, Purpose, CostCenter. L'assenza di questi tag standard è un indicatore affidabile di creazione non autorizzata.

Non dimenticare il rate limiting detection. Se un account crea più di 3 istanze in un'ora, merita investigazione immediata. Scattered Spider è noto per creare multiple istanze EC2 simultaneamente per parallelizzare le operazioni.

Durante la campagna C0027, Scattered Spider ha lasciato tracce forensi distintive nel tenant Azure delle vittime. La ricostruzione inizia sempre dai log di autenticazione per identificare il punto di ingresso iniziale.

Gli artefatti chiave in AWS includono CloudTrail events per RunInstances, CreateSnapshot, e ModifyInstanceAttribute. Ogni evento contiene timestamp UTC, sourceIPAddress, e userAgent che aiutano a profilare l'attaccante.

In Azure, cerca nei log delle attività gli eventi Microsoft.Compute/virtualMachines/write. La presenza di parametri non standard nella creazione VM, come dimensioni inusuali o immagini custom, può rivelare intenti malevoli.

La timeline tipica osservata con LAPSUS$ mostrava: compromissione credenziali via social engineering → escalation a ruoli amministrativi → enumerazione risorse → creazione VM in region alternative → mounting di managed disk contenenti dati sensibili.

Per correlare efficacemente, esporta i log in formato JSON e usa jq o Python per l'analisi. Cerca anomalie nei parametri di creazione: subnet non standard, security group aperti (0.0.0.0/0), o chiavi SSH non riconosciute. Questi dettagli costruiscono il profilo comportamentale dell'attaccante.

La persistenza attraverso startup script nelle VM create è comune. Esamina sempre userData o customData fields che potrebbero contenere backdoor o script di esfiltrazione. Durante C0027, gli attaccanti inserivano script di reverse shell direttamente nella configurazione iniziale delle VM.

LAPSUS$ ha dimostrato predilezione per ambienti cloud multi-tenant, sfruttando la creazione di VM come ponte verso asset più critici. Il gruppo opera con velocità estrema, spesso completando l'intera catena d'attacco in meno di 48 ore dalla compromissione iniziale.

Scattered Spider mostra pattern operativi diversi. Durante C0027, il gruppo ha specificamente targetizzato provider di telecomunicazioni e BPO, creando istanze EC2 per stabilire persistenza a lungo termine. La loro specialità include SIM swapping combinato con abuso di infrastrutture cloud.

L'overlap nei TTP è significativo: entrambi i gruppi privilegiano l'ingegneria sociale per l'accesso iniziale, seguito da rapida escalation verso ruoli cloud amministrativi. La creazione di istanze serve sia per evasion che per staging di ulteriori attività.

Geograficamente, Scattered Spider opera prevalentemente contro target nordamericani, mentre LAPSUS$ ha dimostrato portata globale. La scelta delle region cloud per le nuove istanze spesso riflette considerazioni di latenza e giurisdizione legale.

I trend emergenti mostrano evoluzione verso l'uso di container invece di VM tradizionali. Gruppi sofisticati iniziano a sfruttare Kubernetes per creare pod effimeri ancora più difficili da tracciare. L'integrazione con servizi serverless per l'esfiltrazione rappresenta la prossima frontiera evolutiva di questa tecnica.

Framework MITRE ATT&CK documenta questa tecnica come T1578.002 sotto Defense Evasion. La campagna C0027 (2022) fornisce case study dettagliati dell'uso operativo. AWS CloudTrail e Azure Activity Logs rimangono le fonti primarie per detection e forensics di questa tecnica.