Account Cloud Malevoli: Cloud Account Creation (T1136.003)
La creazione di account cloud da parte di un attaccante rappresenta una delle forme più insidiose di persistenza moderna. Catalogata come T1136.003 nel framework MITRE ATT&CK, questa sottotecnica appartiene alla tattica Persistence (TA0003) e sfrutta la logica stessa delle piattaforme IaaS, IdP e SaaS per garantire all'avversario un canale di rientro che non richiede impianti sul filesystem né beacon C2 tradizionali.
Una volta ottenuto un livello di privilegio sufficiente in un tenant Azure AD, in un'organizzazione Google Workspace o in un account AWS, l'attaccante crea utenze aggiuntive — user reali, guest, service principal o managed identity — che diventano credenziali secondarie perfettamente legittime agli occhi del provider. In Azure il concetto si estende ai service principal e alle managed identity associate a Function App o VM; in GCP ai service account impersonabili tramite Temporary Elevated Access; in AWS all'assunzione diretta di ruoli da parte di risorse.
I dati MITRE mappano 2 gruppi APT (APT29 e LAPSUS$), 1 tool (AADInternals) e 3 mitigazioni su questa tecnica, ma l'impatto reale è amplificato dalla difficoltà di distinguere una creazione legittima da una malevola in ambienti con provisioning continuo. La persistenza cloud è la nuova backdoor: non tocca gli endpoint, sopravvive ai reimaging e resta invisibile agli EDR.
In un ingaggio red team autorizzato, la simulazione di T1136.003 parte dal presupposto di aver già ottenuto credenziali privilegiate — tipicamente tramite phishing OAuth, token stealing da workstation di un Global Admin o abuso di service principal esistenti. L'obiettivo è dimostrare come stabilire persistenza silenziosa senza toccare gli endpoint.
Su Azure AD / Entra ID, il tool di riferimento è AADInternals (open source), il framework PowerShell di Nestori Syynimaa. Dopo l'autenticazione con Get-AADIntAccessTokenForAADGraph, la creazione di un utente avviene con New-AADIntUser -UserPrincipalName "svc-backup@tenant.onmicrosoft.com" -DisplayName "Backup Service". Per un approccio più stealthy, la creazione di un service principal con New-AzADServicePrincipal del modulo Az PowerShell (open source) di Microsoft passa spesso inosservata perché rientra nel rumore di fondo delle integrazioni DevOps.
Su AWS, la catena classica sfrutta la AWS CLI (open source) con credenziali IAM compromesse:
aws iam create-user --user-name svc-monitoring
aws iam attach-user-policy --user-name svc-monitoring --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam create-access-key --user-name svc-monitoring
Questa sequenza — nota come pattern LAPSUS$-style — genera in pochi secondi un utente amministrativo con Access Key utilizzabile da qualsiasi IP. Per emulazione più raffinata, framework come Pacu (open source) di Rhino Security Labs automatizzano moduli di persistenza IAM come iam__backdoor_users_keys e iam__create_admin.
Su GCP, la creazione di un service account con la gcloud CLI (open source) segue gcloud iam service-accounts create backup-svc --display-name="Backup" seguita da gcloud projects add-iam-policy-binding
Per ambienti Google Workspace e M365, tool come GoodHound (open source) e ROADtools (open source) permettono di mappare i privilegi post-creazione e verificare quali percorsi di escalation restano disponibili. In un red team maturo, la creazione dell'account è solo l'inizio: va sempre accompagnata dall'aggiunta di Additional Cloud Credentials (T1098.001) per ridondanza e da role assignment temporizzati per superare le review periodiche. La regola operativa è mimetizzarsi nel naming pattern dei service account legittimi già presenti nel tenant.
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.