Eliminazione Istanze Cloud: Delete Cloud Instance (T1578.003)

In un ingaggio red team autorizzato su ambiente cloud, la simulazione di T1578.003 richiede credenziali con privilegi di gestione compute e va sempre eseguita in subscription/account di laboratorio isolati, mai in produzione, previa autorizzazione scritta.

Su AWS, dopo aver ottenuto access key valide (via phishing simulato, secret leaked in repository, o assunzione di ruolo IAM), l'operazione base con AWS CLI (open source) è:

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

Per scenari più realistici, un attaccante enumererebbe prima le istanze con aws ec2 describe-instances filtrando per tag di produzione, quindi automatizzerebbe la terminazione in batch. La stessa CLI permette di disabilitare la termination protection con aws ec2 modify-instance-attribute --instance-id --no-disable-api-termination prima della delete, passaggio spesso necessario in ambienti maturi.

Su Azure, con Azure CLI (open source) il comando equivalente è:

az vm delete --resource-group --name --yes

Per emulare il pattern Storm-0501 di distruzione massiva, uno script PowerShell con modulo Az (open source) può iterare su Get-AzVM | Remove-AzVM -Force, estendendosi poi a storage account e key vault. Su GCP con gcloud (open source): gcloud compute instances delete --zone= --quiet.

Per red team più sofisticati, framework come Pacu (open source, Rhino Security Labs) offrono moduli specifici per AWS post-exploitation inclusa l'enumerazione e manipolazione di istanze EC2. ScoutSuite (open source) e PurplePanda (open source) aiutano nella fase di ricognizione dei privilegi disponibili prima dell'azione distruttiva. Su Azure, MicroBurst (open source) e ROADtools (open source) coprono enumeration e abuso di token.

La catena d'attacco realistica prevede: acquisizione credenziali cloud (spesso via T1552 - Unsecured Credentials in repository Git o pipeline CI/CD), enumerazione dei permessi tramite aws iam simulate-principal-policy o equivalenti, creazione opzionale di istanze staging con AMI/immagini custom, esecuzione delle azioni obiettivo, e infine cleanup con terminazione delle istanze e possibile eliminazione di CloudTrail trail o Azure Activity Log diagnostic settings per rendere più difficile la ricostruzione. È buona pratica di ingaggio documentare ogni comando eseguito con timestamp per la fase di reporting.

La detection di T1578.003 vive interamente sul control plane cloud: le API di terminazione istanze non lasciano tracce endpoint, quindi la telemetria di riferimento sono AWS CloudTrail, Azure Activity Log e GCP Cloud Audit Logs. Un SOC maturo deve garantire che questi log siano centralizzati in un SIEM (Splunk, Sentinel, Chronicle, Elastic) con retention adeguata alla finestra di indagine tipica.

Gli eventi chiave da monitorare sono TerminateInstances e StopInstances su CloudTrail, Microsoft.Compute/virtualMachines/delete su Azure Activity Log, e v1.compute.instances.delete su GCP. La detection efficace non si basa sul singolo evento — spesso legittimo — ma sulla correlazione comportamentale, come suggerito dalla strategia di detection DET0084/AN0234.

I pattern prioritari da implementare come regole SIEM includono la sequenza creazione + eliminazione entro pochi minuti dalla stessa identità, indicativa di istanze usate come pivot transitori; le eliminazioni originate da service account nuovi o raramente attivi, che deviano dal baseline di automazione noto; le cancellazioni precedute da snapshot creation o image copy, che suggeriscono esfiltrazione seguita da distruzione delle prove; e i burst di Delete multipli in finestre brevi, pattern osservato in Storm-0501 e LAPSUS$.

Il tuning richiede attenzione ai falsi positivi: pipeline CI/CD, auto-scaling group, servizi di build ephemeral (AWS CodeBuild, Azure DevOps agents) generano legittimamente migliaia di terminazioni. La strategia raccomandata prevede una allowlist di service principal e ruoli IAM noti per automazione, con soglie separate per identità umane vs. non-umane. Una regola robusta correla anche la geolocalizzazione dell'IP sorgente dell'API call (campo sourceIPAddress in CloudTrail, callerIpAddress in Azure) con la geografia attesa dell'organizzazione, alzando severity quando la richiesta arriva da ASN residenziali, VPN commerciali o paesi non allineati al footprint aziendale.

Indicatori aggiuntivi ad alto valore: modifiche a DisableApiTermination immediatamente precedenti la delete, disabilitazione di CloudTrail o diagnostic settings nella stessa sessione (concomitante T1562.008 - Disable or Modify Cloud Logs), e utilizzo di access key long-lived invece di ruoli assumed. Su Azure, la correlazione con Azure AD Sign-in Logs permette di legare l'evento di delete al login originante e valutare risk score, MFA status e conditional access match. È inoltre utile alimentare un dashboard con rate deletion per identity su finestre scorrevoli di 5, 15 e 60 minuti per triage rapido.

L'indagine forense su T1578.003 è resa complessa proprio dall'obiettivo della tecnica: distruggere le prove locali. L'analista deve quindi lavorare su fonti alternative, principalmente log del control plane cloud e artefatti residui nei servizi di storage e networking.

Il punto di partenza è il CloudTrail event history (AWS) o Azure Activity Log, dove ogni evento TerminateInstances/virtualMachines/delete contiene metadati critici: eventTime per la timeline, userIdentity con ARN e tipo (IAMUser, AssumedRole, Root), sourceIPAddress, userAgent, requestParameters con l'ID esatto dell'istanza. La ricostruzione della sequenza richiede di estrarre tutti gli eventi correlati alla stessa sessionId o accessKeyId nelle ore precedenti, per identificare enumerazione, creazione di snapshot, modifica di security group e infine la delete.

Gli artefatti residui più preziosi sono gli snapshot EBS (AWS) o managed disk snapshot (Azure) eventualmente sopravvissuti — spesso l'attaccante dimentica di eliminarli, oppure sono creati automaticamente da policy di backup. Il servizio AWS Backup, Azure Backup e AWS Recycle Bin (introdotto per proteggere da eliminazioni accidentali e malevole) possono contenere copie recuperabili dell'istanza. Se disponibili, questi snapshot vanno acquisiti creando un volume forense read-only montato su una workstation di analisi isolata, con hash SHA-256 registrato prima dell'analisi.

Altre fonti da correlare: VPC Flow Logs (AWS) o NSG Flow Logs (Azure) mostrano le connessioni di rete dell'istanza fino al momento della terminazione, utili per identificare C2, esfiltrazione e movimento laterale; i DNS query logs (Route 53 Resolver Query Logs, Azure DNS Analytics) rivelano risoluzioni verso domini sospetti; i log applicativi centralizzati (CloudWatch Logs, Log Analytics Workspace) sopravvivono alla delete dell'istanza se erano configurati correttamente prima dell'incidente.

La timeline forense dovrebbe integrare eventi da tre livelli: identità (sign-in su Azure AD o AWS IAM, uso di access key, assunzione di ruoli), control plane (creazione istanza, modifica attributi, delete), e data plane residuo (flow log, DNS, log applicativi). Tool come Cado Response (a pagamento), Magnet AXIOM Cyber (a pagamento) e la suite open source AWS-IR o Cloud Custodian (open source) accelerano l'acquisizione. Per l'analisi degli snapshot recuperati, The Sleuth Kit e Autopsy (open source) restano riferimenti solidi. Nel caso LAPSUS$, la ricostruzione ha richiesto correlazione tra IdP logs, cloud audit e telemetria SaaS, pattern replicabile in casi analoghi.

Il panorama degli attori che abusano di T1578.003 è ancora limitato numericamente ma qualitativamente rilevante, perché la tecnica compare in attacchi ad alto impatto dove la distruzione di risorse cloud diventa parte integrante della strategia estorsiva o disruptive.

LAPSUS$ (G1004) rappresenta il caso più mediatizzato. Il gruppo, composto prevalentemente da attori giovani con base in Sud America ed Europa, ha adottato un modello operativo atipico rispetto al ransomware tradizionale: invece di cifrare i dati per estorsione, ha eliminato sistemi e risorse cloud del target per innescare la risposta di crisi organizzativa e amplificare la pressione. Le vittime documentate — che includono grandi aziende tecnologiche e di telecomunicazioni — mostrano un pattern in cui l'accesso iniziale avviene tramite social engineering, SIM swap e acquisto di credenziali da initial access broker, seguito da escalation su tenant cloud e infine distruzione mirata. La motivazione è mista: notorietà, estorsione economica e leak pubblici via Telegram.

Storm-0501 (G1053), tracciato principalmente da Microsoft Threat Intelligence, ha portato la tecnica su scala superiore con eliminazioni di massa di data store e risorse in sottoscrizioni Azure. Il gruppo opera come affiliate ransomware con affiliazioni note a famiglie multiple (Hive, BlackCat/ALPHV, LockBit, Embargo). L'evoluzione osservata è il passaggio da ransomware puramente on-premise a operazioni ibride cloud-native, dove la fase finale include cancellazione di risorse Azure e blob storage per massimizzare il danno e ridurre la capacità di ripristino della vittima. Il vettore tipico è il compromesso di identità sincronizzate tra Active Directory on-prem ed Entra ID, con abuso di service principal privilegiati.

Il pattern comune ai due gruppi è l'orientamento verso impatto e coercizione più che verso esfiltrazione silente prolungata. Entrambi operano in fasi rapide, con dwell time nell'ambiente cloud spesso misurato in ore o giorni piuttosto che mesi. La geografia dei target è ampia (Nord America, Europa, LATAM per LAPSUS$; principalmente Nord America per Storm-0501), mentre l'infrastruttura di attacco fa leva su servizi legittimi (Azure CLI da residenziali VPN, browser session hijacking) più che su malware custom.

Il trend previsionale indica che T1578.003 diventerà componente standard delle catene ransomware cloud-aware, sostituendo o affiancando la cifratura tradizionale nei casi dove la vittima ha alta dipendenza da IaaS. L'implicazione difensiva è che backup off-cloud immutabili, separazione dei ruoli tra piano di produzione e piano di backup e just-in-time access ai permessi di delete diventano contromisure di priorità assoluta, in linea con M1018 e M1047.

MITRE ATT&CK T1578.003 (Delete Cloud Instance), tattica TA0005. Gruppi: G1004 (LAPSUS$), G1053 (Storm-0501). Mitigazioni: M1018 (User Account Management), M1047 (Audit). Detection strategy DET0084/AN0234. Riferimento MITRE D3FEND per tecniche difensive di Cloud Service Usage Analysis. Integrata conoscenza professionale su tool cloud pentest (Pacu, ScoutSuite, MicroBurst, ROADtools), CLI dei provider AWS/Azure/GCP e piattaforme di cloud forensics, per comandi e procedure operative non presenti nei dati MITRE.