Account Cloud Malevoli: Cloud Accounts (T1585.003)
La tecnica T1585.003 descrive la creazione di account presso provider cloud da parte di un attaccante per sostenere le proprie operazioni. Non si tratta di compromettere credenziali legittime, ma di registrare ex novo identità su servizi come Dropbox, MEGA, Microsoft OneDrive o bucket AWS S3, sfruttandone poi lo storage per esfiltrare dati o distribuire tool.
Sul piano tattico la tecnica appartiene a TA0042 (Resource Development), la fase in cui l'avversario crea, acquista o compromette le risorse che alimenteranno l'intera catena d'attacco. Nella kill chain si colloca prima del contatto con la vittima: gli account cloud diventano poi infrastruttura per Command and Control, hosting di payload nella fase di Initial Access, oppure Exfiltration to Cloud Storage nelle fasi finali.
Il vantaggio per l'attaccante è duplice. Da un lato può sviluppare capacità sofisticate senza gestire server propri, appoggiandosi a infrastruttura a pagamento come Virtual Private Server o funzioni serverless. Dall'altro il traffico verso provider cloud legittimi si mimetizza nel rumore di rete aziendale, complicando il rilevamento.
La creazione di questi account spesso richiede a monte la registrazione di Email Accounts presso il provider stesso, creando una catena di risorse difficile da attribuire. Nei dati disponibili la tecnica è associata a 1 gruppo, 2 campagne e 1 mitigazione, un segnale della sua natura essenzialmente esterna al perimetro difendibile: la maggior parte dell'attività avviene fuori dalla visibilità dell'organizzazione bersaglio.
Trattandosi di una tecnica pre-compromise (TA0042), l'obiettivo in un ingaggio red team non è "bucare" nulla ma ricostruire in laboratorio l'infrastruttura di supporto che un avversario predisporrebbe, mantenendo l'esercizio lab-safe e concordato con il cliente.
Il primo passo è la creazione controllata di identità cloud usa-e-getta. In un tenant di test si registrano account Microsoft 365/OneDrive, Dropbox o MEGA partendo da caselle email dedicate all'esercizio, replicando la catena osservata nelle campagne reali dove gli account email precedono quelli cloud. Questa fase simula il pattern di Storm-1811, che ha creato account per abilitare attività via Microsoft Teams spacciandosi per IT support.
Per lo storage come canale di consegna e C2 si possono usare gli SDK ufficiali dei provider. Con la AWS CLI (open source) un bucket di test si crea con:
aws s3 mb s3://lab-redteam-payloads --region eu-south-1
e un artefatto benigno vi si carica con aws s3 cp beacon.txt s3://lab-redteam-payloads/. Per OneDrive e Dropbox si sfruttano le rispettive API tramite token OAuth generati nel proprio account di test.
Sul fronte del tooling di simulazione:
- rclone (open source) per orchestrare upload/download verso decine di provider cloud con un'unica sintassi, utile per emulare Exfiltration to Cloud Storage.
- Sliver (open source) e Mythic (open source) supportano profili C2 che si appoggiano a servizi cloud come dead-drop resolver.
- SpiderFoot (open source) e Recon-ng (open source) per mappare, dal lato OSINT, quali account e domini l'organizzazione bersaglio espone.
Una catena d'attacco realistica ricalca la campagna Operation AkaiRyū, dove account OneDrive ospitavano payload: si predispone il file malevolo simulato sullo storage, si genera un link condiviso e lo si veicola in una email di spear-phishing controllata. In alternativa, come in Outer Space, si configurano caselle M365 che fungono da canale C2 tramite lettura/scrittura di bozze o allegati.
L'obiettivo formativo è dimostrare quanto sia banale, per un avversario, ottenere infrastruttura affidabile e "reputata" senza mai toccare un server proprio, e quanto questo traffico si confonda con l'uso cloud legittimo dell'azienda.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.