Cancellare per Nascondersi: Delete Cloud Instance (T1578.003)

Simulare questa tecnica in un laboratorio cloud richiede un ambiente IaaS dedicato — mai eseguire test su subscription di produzione. L'obiettivo è validare se i controlli di detection del blue team rilevano la cancellazione anomala di istanze e quanto rapidamente scatta l'alert.

Scenario 1 — AWS con CLI. Dopo aver ottenuto credenziali IAM con permessi EC2 sufficienti (simulando un account compromesso), la catena d'attacco riproduce il ciclo create-use-destroy. Con AWS CLI (open source) si lancia un'istanza, si esegue un'azione simulata e si termina tutto:

aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t2.micro --key-name test-key

Dopo l'attività simulata, la distruzione:

aws ec2 terminate-instances --instance-ids i-0abcdef1234567890

Il punto critico per il red team è verificare che CloudTrail registri entrambi gli eventi — RunInstances e TerminateInstances — e che la correlazione temporale ravvicinata generi un alert.

Scenario 2 — Azure con az CLI. In ambiente Azure, la simulazione è analoga. Si crea un resource group di test, si deploya una VM e si procede alla cancellazione massiva come documentato per Storm-0501:

az vm delete --resource-group rg-redteam-test --name vm-target --yes --no-wait

Per replicare la distruzione su scala più ampia, si può eliminare l'intero resource group:

az group delete --name rg-redteam-test --yes --no-wait

Il flag --no-wait è significativo: l'attaccante reale non aspetta la conferma di completamento, vuole lanciare il comando e scomparire.

Scenario 3 — Strumenti di automazione red team. Strumenti come Pacu (open source), il framework di exploitation AWS, offrono moduli dedicati all'enumerazione e manipolazione di istanze EC2. Il modulo ec2__enum permette di mappare le istanze disponibili, mentre operazioni successive possono terminare le risorse identificate. Per Azure, MicroBurst (open source) di NetSPI fornisce funzionalità analoghe di enumerazione e manipolazione delle risorse.

Durante l'esercizio, documentate la finestra temporale tra creazione e distruzione e verificate con il blue team quali log hanno catturato l'evento. Se l'alert non scatta entro pochi minuti dalla cancellazione, il controllo è inadeguato.

La sfida principale nel monitorare la cancellazione di istanze cloud è il rapporto segnale-rumore. Ambienti con auto-scaling, pipeline CI/CD e infrastruttura effimera generano migliaia di eventi di creazione e distruzione al giorno. L'alert efficace non si limita a "qualcuno ha cancellato una VM", ma correla contesto, identità e tempistica.

Log source primari. Su AWS, CloudTrail è la fonte imprescindibile: gli eventi TerminateInstances, StopInstances e DeleteInstances devono confluire nel SIEM. Su Azure, l'Activity Log registra le operazioni Microsoft.Compute/virtualMachines/delete e Microsoft.Resources/subscriptions/resourceGroups/delete. Entrambi vanno configurati per inviare eventi in tempo reale al sistema di analisi — CloudTrail verso S3 + EventBridge, Azure Activity Log verso Event Hub o Log Analytics Workspace.

Logica di correlazione comportamentale. Gli indicatori con maggiore valore investigativo sono:

• Ciclo di vita anomalo: istanza creata e distrutta entro una finestra temporale ristretta (ad esempio meno di 30 minuti). Correlate gli eventi RunInstances/TerminateInstances per lo stesso instance ID e calcolate il delta temporale.
• Identità sospette: cancellazioni eseguite da account che non hanno mai eliminato istanze in precedenza, o da service account non associati a pipeline di automazione note.
• Geolocalizzazione incoerente: richieste di delete provenienti da IP o regioni cloud non allineate alla geografia operativa dell'organizzazione.
• Rate anomalo: più cancellazioni in rapida successione dallo stesso account, pattern coerente con la distruzione massiva documentata per Storm-0501 sulle subscription Azure.

Tuning dei falsi positivi. Il tuning richiede una whitelist granulare. Create una baseline degli account e dei ruoli autorizzati a operazioni di lifecycle (team DevOps, pipeline Terraform, auto-scaling group). Ogni cancellazione da un'identità fuori whitelist deve generare alert ad alta priorità. Per gli account in whitelist, alzate la soglia: alert solo se il rate supera il percentile storico del 95° per quell'identità.

Una regola efficace in pseudo-logica SIEM combina UserContext (identità non in whitelist O account dormiente riattivato), TimeWindow (creazione + cancellazione entro N minuti) e RateThreshold (più di X cancellazioni in Y minuti). La combinazione di almeno due di questi fattori alza significativamente la confidenza dell'alert e riduce il rumore.

Quando un'istanza cloud viene cancellata, gli artefatti interni — filesystem, memoria, log applicativi — spariscono con essa, a meno che non siano stati esternalizzati. La forensics su questa tecnica si gioca quasi interamente su fonti esterne all'istanza distrutta.

La prima fonte è il control plane. CloudTrail su AWS e Activity Log su Azure conservano il record delle operazioni API indipendentemente dall'esistenza dell'istanza. Per ogni evento di cancellazione, estraete: identità chiamante (ARN o UPN), source IP, user agent, timestamp e request parameters. Il user agent è particolarmente rivelatore: una cancellazione via aws-cli/2.x da un IP residenziale ha un significato diverso da una chiamata con user agent Terraform da un IP della pipeline CI/CD.

Ricostruite la timeline all'indietro partendo dall'evento di delete. Cercate nello stesso intervallo temporale eventi di CreateSnapshot o CreateImage — l'attaccante potrebbe aver esportato un'immagine dell'istanza prima di distruggerla, preservando i dati per sé mentre li nega alla difesa. Su Azure, verificate operazioni su Blob Storage o trasferimenti verso subscription esterne che precedono la cancellazione.

Recupero dei log esternalizzati. Se l'organizzazione aveva configurato l'invio di log a servizi centralizzati — CloudWatch Logs su AWS, Log Analytics Workspace su Azure, o un SIEM on-premise — i log dell'istanza distrutta potrebbero essere ancora disponibili. Cercate log di sistema, log di autenticazione e output di agenti di sicurezza (EDR, agent di monitoring) che erano in esecuzione sull'istanza prima della sua distruzione. Il gap tra l'ultimo log ricevuto e l'evento di delete indica per quanto tempo l'attaccante ha operato senza generare telemetria.

Network flow e DNS. I VPC Flow Logs (AWS) e i NSG Flow Logs (Azure) sono conservati indipendentemente dall'istanza. Filtrate per l'IP privato dell'istanza cancellata e ricostruite le comunicazioni di rete: connessioni verso IP esterni, volumi di dati trasferiti, protocolli utilizzati. Questo può rivelare esfiltrazione avvenuta prima della distruzione.

Per la correlazione con l'attività di LAPSUS$, prestate attenzione a cancellazioni che coinvolgono non solo VM ma interi ecosistemi — resource group, storage account, database — come trigger deliberato della risposta di crisi dell'organizzazione. La distruzione non è solo evasione, ma anche distrazione.

I due gruppi associati a questa tecnica rappresentano profili di minaccia distinti ma accomunati da una forte componente distruttiva nelle operazioni cloud.

LAPSUS$ (G1004) è un gruppo noto per operazioni ad alto impatto mediatico e con una componente di estorsione e disruption. La cancellazione di sistemi e risorse cloud non è per loro un semplice atto di evasione: viene utilizzata deliberatamente per innescare i processi di incident response e crisis management dell'organizzazione target. Questo approccio serve un duplice scopo tattico — distrugge evidenze e simultaneamente crea caos operativo che distrae i difensori, potenzialmente coprendo altre attività in corso o aumentando la pressione per il pagamento di un riscatto. Il profilo di LAPSUS$ suggerisce operatori con accesso privilegiato ottenuto tramite social engineering o insider threat, capaci di agire con ampia libertà all'interno degli ambienti cloud.

Storm-0501 (G1053) presenta un pattern più sistematico. La cancellazione massiva di data store e risorse da subscription Azure indica un livello di accesso profondo — probabilmente ruoli di Owner o Contributor a livello di subscription — e un obiettivo di massimizzazione del danno. Il focus specifico su Azure posiziona questo gruppo come una minaccia prioritaria per organizzazioni con footprint significativo sulla piattaforma Microsoft.

Il pattern comune è chiaro: entrambi i gruppi operano con privilegi elevati nel cloud e utilizzano la distruzione come arma, non solo come tecnica di copertura. Questo suggerisce che la tecnica T1578.003 tende a comparire nelle fasi finali di un'intrusione, quando l'attaccante ha già raggiunto i propri obiettivi primari — esfiltrazione, deployment di ransomware o posizionamento di persistenze alternative.

Per il threat modeling, un'organizzazione che osserva segnali di compromissione cloud (credenziali IAM rubate, accessi anomali alla console) dovrebbe trattare la potenziale distruzione di risorse come scenario ad alta probabilità e attivare immediatamente misure preventive: snapshot protetti da policy di retention immutabili, revoca dei permessi di delete per gli account sospetti e isolamento delle subscription compromesse.

Il trend evolutivo punta verso un uso sempre più frequente di questa tecnica man mano che le organizzazioni migrano workload critici in cloud senza implementare controlli di governance adeguati sulle operazioni distruttive.

Framework MITRE ATT&CK v16 — T1578.003 (Delete Cloud Instance), TA0005 (Defense Evasion), G1004, G1053, M1018, M1047, DET0084/AN0234. Tool operativi: AWS CLI, Azure CLI, Pacu, MicroBurst. Integrato con conoscenza professionale per tool e procedure operative.