Enumerazione Account Cloud: Cloud Account (T1087.004)

L'enumerazione degli account cloud è una tecnica di Discovery (TA0007) attraverso cui un avversario, dopo aver ottenuto un accesso autenticato a un ambiente cloud, raccoglie l'elenco degli utenti, dei ruoli e dei service account configurati nel tenant o nel progetto. In pratica, l'attaccante sfrutta le stesse interfacce che gli amministratori usano quotidianamente — CLI native, cmdlet PowerShell, API REST — per costruire una mappa delle identità dell'organizzazione.

L'obiettivo è duplice: da un lato individuare account con privilegi elevati (Global Admin, Owner, root) da colpire con tecniche di privilege escalation o credential theft; dall'altro identificare service account, identità di automazione e utenti dormienti che offrono superfici d'attacco meno sorvegliate. Questa ricognizione è tipicamente silenziosa, perché le chiamate API utilizzate sono operazioni di lettura legittime, difficili da distinguere dal traffico amministrativo ordinario.

La tecnica è documentata con 2 gruppi APT, 3 tool offensivi, 1 campagna e 2 mitigazioni nel framework di riferimento, a conferma della sua rilevanza trasversale sia in operazioni di spionaggio sia in campagne a scopo finanziario. Il panorama multi-cloud rende il problema pervasivo: Azure AD, AWS IAM, GCP IAM e piattaforme SaaS espongono tutti endpoint di directory enumeration che, senza controlli granulari, possono essere interrogati da qualsiasi identità autenticata.

La simulazione di questa tecnica in laboratorio richiede un ambiente cloud di test con almeno un tenant Azure AD, un account AWS e un progetto GCP. Il prerequisito è sempre lo stesso: credenziali valide, anche a basso privilegio. Molti ambienti concedono di default permessi di lettura sulla directory a tutti gli utenti autenticati, ed è proprio questa configurazione che va verificata.

Azure AD — tre vie d'attacco

Il percorso più diretto passa dal modulo AzureAD PowerShell. Con una sessione autenticata tramite Connect-AzureAD, il cmdlet Get-AzureADUser -All $true restituisce l'intera lista degli utenti del tenant. Per ottenere i membri di un ruolo specifico — ad esempio Global Administrator — si può usare il vecchio modulo MSOnline con Get-MsolRoleMember -RoleObjectId <GUID_ruolo>.

ROADTools (open source) offre un approccio più strutturato: il sotto-comando roadrecon gather scarica l'intero database di Azure AD tramite le API Graph, salvandolo in un database SQLite locale. Da lì, roadrecon gui avvia un'interfaccia web che permette di esplorare utenti, gruppi, applicazioni e service principal in modo interattivo. È uno strumento eccezionale per un red team perché cattura una snapshot completa con una singola autenticazione.

AADInternals (open source) aggiunge capacità specifiche per l'enumerazione di tenant: il cmdlet Get-AADIntUsers restituisce la lista utenti completa, mentre Get-AADIntGlobalAdmins identifica gli account con ruolo amministrativo globale. L'installazione avviene tramite Install-Module AADInternals dalla PowerShell Gallery.

AWS — enumeration IAM

Dopo aver configurato le credenziali con aws configure, i comandi chiave sono:

aws iam list-users — lista di tutti gli utenti IAM dell'account
aws iam list-roles — elenco dei ruoli IAM con i relativi trust policy
aws iam list-groups-for-user --user-name — gruppi di appartenenza

Pacu (open source), il framework di exploitation AWS sviluppato da Rhino Security Labs, automatizza questa fase con il modulo iam__enum_users_roles_policies_groups. Lanciando Pacu e selezionando run iam__enum_users_roles_policies_groups, lo strumento enumera sistematicamente tutte le identità IAM e le loro policy associate.

GCP — service account e policy

In un progetto Google Cloud, gcloud iam service-accounts list elenca i service account, mentre gcloud projects get-iam-policy <PROJECT_ID> mostra i binding tra identità e ruoli IAM. Per enumerare gli utenti del dominio Workspace collegato serve accesso all'Admin SDK o al Directory API.

In tutti i casi, la raccomandazione è documentare quali permessi minimi consentono l'enumerazione: questo dato è il vero deliverable per il cliente, perché evidenzia la superficie di lettura concessa a identità a basso privilegio.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo

La detection dell'enumerazione account cloud è insidiosa perché le operazioni coinvolte sono identiche a quelle dell'amministrazione legittima. La chiave non è bloccare le singole API call, ma costruire un profilo comportamentale che distingua l'uso autorizzato dall'anomalia.

Sorgenti log indispensabili

La copertura minima richiede quattro flussi di log. I Microsoft Entra ID Audit Logs e gli Azure Sign-in Logs catturano ogni invocazione della Graph API e dei cmdlet AzureAD/MSOnline: i campi da monitorare sono operationName, initiatedBy e il campo targetResources che rivela il volume di oggetti acceduti. Su AWS, CloudTrail registra le chiamate IAM: gli eventi ListUsers, ListRoles e ListGroupsForUser vanno correlati con il campo sourceIPAddress e userAgent. Per GCP, il Cloud Audit Log — sezione Admin Activity — traccia le invocazioni IAM. Infine, per i SaaS, i log di Google Admin Audit, Okta System Log e le integrazioni SCIM vanno monitorati per accessi bulk alla directory.

Logica di detection

L'analisi AN1087 suggerisce di concentrarsi su tre dimensioni: TokenScope, ovvero il livello di permessi di lettura richiesti dal token OAuth — un'identità che richiede Directory.Read.All senza averne ragione merita un alert; AppContext, per distinguere le applicazioni di automazione autorizzate (Azure AD Connect, tool di provisioning) dai tool offensivi come ROADTools che si presentano con client ID non registrati; TimeWindow, per rilevare raffiche di query in intervalli brevi, tipiche dell'enumerazione automatizzata.

Per l'analisi AN1088 su IaaS, il tuning si basa su CallerType — sopprimere gli account admin noti e generare alert quando identità developer o di test invocano le API IAM — e su CLIUserAgent, correlando user-agent anomali (ad esempio il client Pacu) con la geolocalizzazione della sorgente.

Gestione dei falsi positivi

Il volume di falsi positivi è alto, specialmente nelle organizzazioni con automazione DevOps intensiva. Per ridurlo senza sacrificare visibilità si consiglia di creare una allowlist di service principal e automation account noti, associandoli ai rispettivi IP range. Le query di directory provenienti da endpoint non gestiti (unmanaged devices) o da regioni geografiche inconsuete vanno sempre escalate. Un buon indicatore composito è: identità non-admin + scope di lettura directory + volume di oggetti restituiti superiore a 50 in un singolo minuto + endpoint non in allowlist.

Infine, per l'ambiente SaaS (AN1090), monitorare il rate delle richieste API verso le directory Okta SCIM, Google Workspace Directory e Slack SCIM, triggerando alert su ricorsioni rapide di espansione dei gruppi da app integration non censite.

Vuoi diventare SOC Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e scopri come si monitorano e bloccano gli attacchi informatici

L'analisi forense dell'enumerazione account cloud si gioca quasi interamente sui log della piattaforma, poiché l'attaccante opera tramite API remote senza lasciare artefatti tradizionali su disco. Tuttavia, se l'operazione è stata condotta da un endpoint compromesso, i residui locali offrono contesto prezioso.

Artefatti cloud-side

In Azure AD, gli Audit Log conservano ogni operazione di lettura sulla directory con un retention di default di 30 giorni. Per la ricostruzione temporale, filtrare per activityDisplayName uguale a "List users" o "List role members" e ordinare per activityDateTime. Il campo initiatedBy.user.userPrincipalName identifica l'identità utilizzata, mentre additionalDetails può rivelare l'application ID del client — un dato fondamentale per distinguere il portale Azure dai tool come ROADTools, che usano client ID specifici.

Su AWS, CloudTrail registra gli eventi ListUsers e ListRoles con dettagli su eventSource (iam.amazonaws.com), sourceIPAddress e userAgent. Quest'ultimo campo è particolarmente rivelatore: Pacu si presenta con uno user-agent distintivo che include "Pacu" nel nome, mentre la CLI ufficiale riporta "aws-cli/2.x". Correlare il timestamp dell'enumerazione con eventuali eventi AssumeRole precedenti aiuta a ricostruire la catena di lateral movement.

Artefatti endpoint

Se l'attaccante ha eseguito i comandi da una workstation compromessa, sul sistema Windows si trovano tracce nei log PowerShell Script Block (EventCode 4104): i cmdlet Get-MsolRoleMember, Get-AzureADUser e i moduli AADInternals producono blocchi di script registrati integralmente. Le credenziali di autenticazione Azure possono persistere nel file TokenCache.dat all'interno del profilo utente, nella cartella .Azure — un artefatto che prova l'accesso autenticato al tenant.

Per la CLI AWS, le credenziali risiedono nel file ~/.aws/credentials e la cronologia dei comandi in ~/.aws/cli/cache/. Su Linux, il file ~/.bash_history o il journal di systemd possono conservare le invocazioni aws iam list-users.

Ricostruzione della timeline

La sequenza tipica da cercare è: autenticazione iniziale (sign-in log o AssumeRole) → enumerazione utenti e ruoli → eventuale enumerazione dei permessi (ListAttachedUserPolicies su AWS, List role assignments su Azure) → azioni successive come privilege escalation o lateral movement. Nella campagna C0027, il gruppo Scattered Spider ha seguito esattamente questo schema, accedendo ad Azure AD per scaricare liste massive di membri dei gruppi e identificare utenti privilegiati insieme ai relativi attributi AD e indirizzi email. La correlazione tra il volume di oggetti directory acceduti e il successivo tentativo di accesso a risorse sensibili è il legame causale più forte per la narrativa forense.

Vuoi diventare Forensic Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto per analizzare incidenti e prove digitali

L'enumerazione degli account cloud è una tecnica condivisa tra attori con motivazioni molto diverse, dal cyberspionaggio statale al crimine finanziario. I due gruppi documentati e la campagna associata rivelano pattern operativi distinti ma complementari nell'analisi del rischio.

APT29 — lo spionaggio che punta al cloud

APT29, noto anche come Cozy Bear, è uno degli attori statali più sofisticati nel panorama delle minacce cloud. Il gruppo ha condotto enumerazione di account Azure AD come parte di campagne più ampie di compromissione di ambienti Microsoft 365. Per APT29, la discovery degli account non è fine a sé stessa: è il primo passo per identificare account con accesso a caselle email di alto valore, documenti SharePoint sensibili e configurazioni di tenant che possono essere manipolate per persistenza. L'attenzione di APT29 agli ambienti Azure AD suggerisce che le organizzazioni con tenant Microsoft ibridi (on-premises + cloud) siano bersagli privilegiati, poiché la complessità della sincronizzazione crea superfici d'attacco aggiuntive.

Storm-0501 — dal ransomware al cloud

Storm-0501 ha utilizzato specificamente Azurehound — il componente Azure del noto BloodHound — per enumerare utenti, ruoli e risorse all'interno dei tenant Azure delle vittime. Questo approccio rivela una maturità operativa significativa: Azurehound non si limita a listare gli account, ma mappa le relazioni tra identità, permessi e risorse, generando grafi di attacco che identificano automaticamente i percorsi di privilege escalation. Storm-0501 rappresenta la convergenza tra tattiche ransomware e compromissione cloud, un trend in crescita.

Campagna C0027 — Scattered Spider e il social engineering cloud

La campagna C0027, attiva tra giugno e dicembre 2022, ha visto Scattered Spider colpire aziende di telecomunicazioni e BPO con un mix di social engineering, SIM swapping e sfruttamento dell'accesso cloud. L'enumerazione di Azure AD è stata utilizzata per scaricare in bulk le liste dei membri dei gruppi e individuare utenti privilegiati con relativi indirizzi email e attributi AD. Il pattern di Scattered Spider è distintivo: l'accesso iniziale avviene tramite ingegneria sociale (vishing, phishing MFA), dopodiché l'attaccante opera direttamente nel cloud senza necessità di malware tradizionale.

Tool overlap e indicatori di priorità

La sovrapposizione di tool è rivelatrice. ROADTools e AADInternals sono specifici per Azure AD, suggerendo che Microsoft Entra ID è il bersaglio primario per l'enumerazione. Pacu copre il versante AWS. L'assenza di tool specifici GCP nei dati suggerisce che gli attacchi a Google Cloud passino più frequentemente per le CLI native. Le organizzazioni multi-cloud dovrebbero prioritizzare la detection su Azure AD, dove l'ecosistema di tool offensivi è più maturo, e implementare controlli granulari sui permessi di lettura directory in tutti i cloud provider, seguendo le mitigazioni di audit periodico dei permessi (M1047) e gestione restrittiva degli account (M1018) con revisioni periodiche delle entitlement e riduzione dei ruoli privilegiati permanenti.