Manipolazione Infrastruttura Cloud: Modify Cloud Compute Infrastructure (T1578)

In un ingaggio red team autorizzato su ambiente cloud, la simulazione di T1578 parte dall'ottenimento di credenziali IAM con permessi su servizi compute. Framework come Pacu (open source) di Rhino Security Labs sono progettati specificamente per esercitare TTP AWS post-exploitation e includono moduli dedicati alla manipolazione di EC2 e EBS. Per Azure, MicroBurst (open source) di NetSPI e ROADtools (open source) coprono scenari analoghi, mentre su GCP si utilizza GCPBucketBrute e script custom basati su gcloud SDK.

Uno scenario tipico su AWS prevede la clonazione di un volume EBS di una VM target per estrarne il contenuto senza toccare l'host monitorato. La sequenza operativa con AWS CLI (open source) inizia identificando il volume:

aws ec2 describe-instances --instance-ids i-xxxx

si crea uno snapshot del volume di interesse con aws ec2 create-snapshot --volume-id vol-xxxx, poi si genera un nuovo volume dallo snapshot in una AZ controllata dal team via aws ec2 create-volume --snapshot-id snap-xxxx --availability-zone eu-west-1a, e infine lo si attacca a un'istanza attacker-controlled con aws ec2 attach-volume. Il filesystem risultante può essere montato in read-only e analizzato con strumenti forensi standard senza generare alert sull'host originale.

Un secondo scenario riguarda l'evasione tramite creazione di istanze parallele. L'attaccante lancia una nuova EC2 in una VPC diversa, con AMI custom priva di agent EDR, e la utilizza come pivot verso risorse interne. Il comando base è aws ec2 run-instances --image-id ami-xxxx --instance-type t3.micro --subnet-id subnet-xxxx. Se il tenant applica Service Control Policy permissive, l'istanza può essere avviata in una region raramente usata, riducendo la visibilità dei team SOC che monitorano solo le region primarie.

Per misurare la resilienza difensiva, il team offensive dovrebbe testare anche la cancellazione controllata di snapshot forensi preesistenti (aws ec2 delete-snapshot) e la modifica dei security group per aprire temporaneamente porte di management. ScoutSuite (open source) di NCC Group è utile in fase di reconnaissance per mappare permessi eccessivi che abilitano queste azioni. Su Azure, l'equivalente è la creazione di disk snapshot via az snapshot create seguita da export su storage account esterno tramite SAS token, tecnica documentata in numerosi report di incident response cloud.

Ogni azione va coordinata con il blue team, registrata in un runbook e limitata a risorse dedicate al test per evitare impatti su workload di produzione.

La detection di T1578 si fonda quasi esclusivamente sui log del piano di controllo cloud: AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs. Il modello analitico AN0861 raccomanda di monitorare eventi di creazione, modifica ed eliminazione di istanze, volumi e snapshot al di fuori di finestre di change management approvate.

Su AWS, gli eventi CloudTrail rilevanti includono RunInstances, TerminateInstances, CreateSnapshot, CopySnapshot, DeleteSnapshot, CreateVolume, AttachVolume, ModifyInstanceAttribute e AuthorizeSecurityGroupIngress. Su Azure la controparte sono le operazioni Microsoft.Compute/virtualMachines/write, Microsoft.Compute/snapshots/write e le relative delete, visibili in Activity Log e inoltrabili a Microsoft Sentinel (a pagamento) o a SIEM di terze parti.

La correlazione più efficace non è sul singolo evento ma sul pattern comportamentale. Sequenze sospette includono: snapshot creato e immediatamente copiato in un account esterno tramite ModifySnapshotAttribute con createVolumePermission concesso a un account ID sconosciuto; nuova istanza avviata in una region storicamente inutilizzata dal tenant; delete massivi di snapshot da parte di un principal che non ha mai eseguito quell'operazione. Un alert efficace correla eventi CreateSnapshot seguiti entro pochi minuti da CreateVolume e AttachVolume su un'istanza differente da quella d'origine.

Le dimensioni di tuning suggerite dal modello sono quattro. ChangeWindow: mappare le finestre di manutenzione approvate tramite integrazione con la CMDB o il sistema di ticketing, sopprimendo alert per attività pianificata. UserContext: costruire allowlist di service account e ruoli di automazione (Terraform, CloudFormation stack roles, pipeline CI/CD) noti; l'esecuzione della stessa azione da un utente interattivo diventa immediatamente più sospetta. RateThreshold: definire soglie contestuali al workload — un ambiente con auto-scaling aggressivo genera decine di RunInstances al minuto, mentre un tenant statico non dovrebbe superare poche unità/ora. GeoLocation: correlare sourceIPAddress e region di destinazione con la baseline geografica del team operativo.

Strumenti utili includono Prowler (open source) e CloudSploit (freemium) per configurazione e detection continua, Falco (open source) con plugin cloud per streaming di eventi, e Grafana (open source) con dashboard CloudTrail per visualizzazione delle anomalie. Un principio D3FEND applicabile è Resource Access Pattern Analysis: modellare il pattern d'uso di ciascun principal IAM e alertare sulle deviazioni.

I falsi positivi principali derivano da deployment blue/green, disaster recovery drill e attività di backup automatizzata. Una tassonomia rigorosa dei service account che eseguono operazioni infrastrutturali è il prerequisito per ridurre il rumore senza cecare le detection.

L'analisi forense di T1578 si sviluppa quasi interamente nel piano di controllo del cloud provider, con integrazioni verso gli artefatti endpoint delle istanze coinvolte. La prima fonte da acquisire è il log completo di CloudTrail (AWS), Activity Log (Azure) o Cloud Audit Log (GCP) per l'intervallo temporale di interesse, includendo sia management events che data events. Su AWS, la retention di default in CloudWatch è di 90 giorni salvo configurazione di trail persistente su S3; questo vincolo condiziona la finestra di analisi possibile.

Gli eventi chiave da estrarre nella timeline sono le API call di modifica compute correlate all'identità sospetta. Per ciascun evento vanno registrati: eventTime, eventName, userIdentity (arn, accountId, sessionContext), sourceIPAddress, userAgent, requestParameters, responseElements. Il campo userAgent rivela spesso l'origine: valori come aws-cli/2.x Python/3.x Linux/x con IP residenziale su ruolo normalmente usato da servizi automatizzati sono un forte indicatore. Il sessionContext.sessionIssuer consente di ricostruire la catena di assunzione ruoli quando l'attaccante ha effettuato AssumeRole multipli.

La ricostruzione dell'attività snapshot-based richiede correlazione tra eventi CreateSnapshot, ModifySnapshotAttribute (per verificare condivisioni cross-account), CopySnapshot (per movimenti tra region), e DeleteSnapshot. Se lo snapshot è stato copiato verso un account esterno, il responseElements.snapshotId consente di tracciare l'artefatto attraverso i log di destinazione, quando disponibili tramite cooperazione con il provider o accordi legali.

Sul lato istanza, se una VM è stata creata dall'attaccante e successivamente terminata, gli artefatti diretti sono perduti a meno che non fosse abilitato VPC Flow Logs (utile per ricostruire connessioni di rete della VM effimera), AWS Config (per snapshot delle configurazioni), o soluzioni di backup automatico. I VPC Flow Logs mostrano srcaddr, dstaddr, srcport, dstport e action, permettendo di identificare beaconing o esfiltrazione originata dall'istanza scomparsa.

Per le istanze ancora vive, l'acquisizione forense segue le procedure standard: creazione di uno snapshot del volume EBS a scopo di preservazione, attach su istanza forense isolata, imaging con dc3dd (open source) o FTK Imager (gratuito), analisi con Autopsy (open source) o Volatility 3 (open source) per la memoria se catturata via AWS Systems Manager prima della terminazione.

La timeline finale deve integrare tre livelli: eventi API cloud, telemetria di rete VPC, e artefatti host quando recuperabili. La correlazione temporale precisa (i timestamp CloudTrail sono in UTC con precisione al secondo) è essenziale per distinguere azioni dell'attaccante da attività amministrativa concomitante e per costruire una narrativa difendibile in sede di reporting.

I dati MITRE ATT&CK forniti per T1578 non associano gruppi APT, software o campagne specifiche a questa tecnica. Questo elemento è di per sé significativo dal punto di vista della threat intelligence: indica che la manipolazione dell'infrastruttura compute cloud è un comportamento trasversale e opportunistico, esercitato da un ampio spettro di attori una volta ottenuti privilegi sufficienti, piuttosto che una signature distintiva di specifici gruppi.

L'assenza di attribuzione consolidata riflette anche una difficoltà metodologica: le azioni compiute tramite API cloud legittime lasciano tracce che raramente permettono attribution tecnica affidabile. L'attaccante appare come un principal IAM valido, e la distinzione tra abuso interno, credential theft e attore statale sofisticato richiede analisi contestuali (geolocation, orari, TTP concomitanti) più che indicatori atomici.

Dal punto di vista degli strumenti, la telemetria disponibile dai major provider evidenzia due categorie ricorrenti di utilizzatori. La prima è composta da gruppi financially-motivated interessati al cryptomining: dopo aver compromesso credenziali, lanciano istanze GPU o compute-intensive in region multiple per massimizzare l'estrazione prima del rilevamento e della fatturazione anomala. La seconda categoria include operatori orientati all'esfiltrazione dati che utilizzano snapshot cloning per accedere a volumi contenenti database o file store senza toccare gli endpoint monitorati.

Il pattern geografico osservato nella pratica di incident response mostra concentrazione di attività in region cloud a bassa latenza rispetto all'origine dell'attaccante e in region che il tenant vittima non utilizza normalmente. La scelta di region asiatiche o sudamericane per tenant nordamericani è un pattern ricorrente perché sfrutta la minore attenzione dei team SOC che monitorano principalmente le region primarie di business.

Sul piano del tool overlap, la comunità difensiva osserva l'uso ricorrente di framework offensive cloud disponibili pubblicamente — Pacu, ROADtools, MicroBurst — sia in ingaggi red team legittimi sia in operazioni malevole, rendendo la sola presenza di user-agent o pattern API insufficiente per attribution.

Il trend più rilevante è la crescita di attacchi che sfruttano credenziali IAM esposte accidentalmente (repository Git pubblici, dump di stringhe di connessione, secrets in immagini container). Servizi come GitGuardian (freemium) e TruffleHog (open source) tracciano volumi crescenti di leak, e le chiavi esposte vengono spesso utilizzate entro minuti per lanciare compute anomalo. Le mitigazioni M1018 (User Account Management) e M1047 (Audit) diventano quindi il pilastro difensivo, con enfasi su rotazione automatica delle credenziali, MFA obbligatoria per operazioni sensibili, entitlement review periodici e alert su first-seen behavior di ciascun principal IAM.

Fonti principali: MITRE ATT&CK per la tecnica T1578 (Modify Cloud Compute Infrastructure), tattica TA0005, mitigazioni M1018 e M1047, detection strategy DET0308 con analytic AN0861. Per le tecniche difensive complementari è stato consultato il framework MITRE D3FEND. Le sezioni operative integrano conoscenza professionale verificata su tool open source (Pacu, ScoutSuite, Prowler, MicroBurst, Falco, Volatility, Autopsy) e documentazione ufficiale di AWS CloudTrail, Azure Activity Log e GCP Cloud Audit Logs per sintassi API ed eventi di riferimento.