Account Cloud Persistenti: Create Cloud Account (T1136.003)

La simulazione di questa tecnica in laboratorio richiede un tenant cloud di test — mai eseguire queste operazioni in ambienti di produzione senza autorizzazione scritta. L'obiettivo è verificare se i controlli difensivi rilevano la creazione di account anomali e le successive operazioni di privilege escalation.

Azure AD / Entra ID con AADInternals

Il tool AADInternals (open source) è un modulo PowerShell progettato per interagire con le API interne di Azure AD. Per simulare la tecnica, dopo aver ottenuto un token di accesso valido con privilegi amministrativi, il flusso operativo prevede l'importazione del modulo e la creazione di un nuovo utente:

Import-Module AADInternals New-AADIntUser -UserPrincipalName "svc-backup@target.onmicrosoft.com" -DisplayName "Backup Service" -Password "P@ssw0rdComplex!"

L'account appena creato va poi dotato di ruoli per verificare se la catena di escalation viene intercettata. Tramite il modulo AzureAD di Microsoft (gratuito):

Connect-AzureAD Add-AzureADDirectoryRoleMember -ObjectId <RoleObjectId> -RefObjectId <UserObjectId>

AWS con CLI nativa

Su AWS la simulazione passa dalla CLI ufficiale (gratuita). La catena operativa che replica il comportamento documentato nelle detection è la seguente:

aws iam create-user --user-name svc-persistence aws iam attach-user-policy --user-name svc-persistence --policy-arn arn:aws:iam::aws:policy/AdministratorAccess aws iam create-access-key --user-name svc-persistence

Questa sequenza — creazione utente, assegnazione policy, generazione access key — è esattamente la catena temporale che i detection engineer cercano nei log CloudTrail. Eseguirla in un account sandbox permette di validare le regole di correlazione.

GCP con gcloud

Per Google Cloud Platform, la CLI gcloud (gratuita) consente di creare service account e assegnare ruoli IAM:

gcloud iam service-accounts create svc-persistence --display-name="Persistence Test" gcloud projects add-iam-policy-binding <PROJECT_ID> --member="serviceAccount:svc-persistence@<PROJECT_ID>.iam.gserviceaccount.com" --role="roles/editor"

Un aspetto critico del red team è testare la creazione di account con permessi limitati a singoli servizi. Gli attaccanti sofisticati evitano ruoli globali come AdministratorAccess o Global Admin, preferendo permessi chirurgici che riducono il rumore nei log. Provate a creare account con policy custom limitate a un singolo servizio (es. solo S3 o solo Storage) e verificate se il SOC riesce comunque a intercettarli.

Per la reportistica, documentate il timestamp di ogni operazione, l'IP sorgente e il user-agent utilizzato: questi sono esattamente i campi su cui si basano le regole di detection.

La detection della creazione di account cloud richiede visibilità su quattro superfici distinte, ciascuna con log source e logiche di tuning differenti. Il principio guida è lo stesso: non è la singola creazione a essere sospetta, ma il contesto operativo in cui avviene e le azioni che la seguono.

Identity Provider (Azure AD / Okta)

I log azure:audit e azure:signinlogs sono la fonte primaria. L'evento chiave è l'operazione "Add User", ma il valore reale emerge dalla correlazione con il contesto. Configurate gli alert per triggerare quando la creazione avviene da IP esterni alle reti amministrative note, e aggiungete un controllo sul tipo di identità creata — differenziando tra utente standard e service principal tramite il flag dedicato. Un secondo livello di alert dovrebbe scattare quando il numero totale di account con ruoli amministrativi supera la baseline storica del tenant.

Il falso positivo più frequente è l'onboarding massivo gestito da HR o da pipeline di provisioning automatizzato. Per gestirlo, mantenete una whitelist degli IP e degli account di servizio autorizzati al provisioning e applicate una finestra temporale di soppressione durante i cicli di onboarding pianificati.

IaaS (AWS CloudTrail)

Su AWS i log CloudTrail catturano l'intera catena. La regola più efficace correla tre eventi in finestra temporale ristretta: IAM:CreateUser, seguito da AttachUserPolicy, seguito da CreateAccessKey. Ogni evento va arricchito con tre campi:

• Region — alert immediato se la creazione avviene in regioni non utilizzate dall'organizzazione
• UserAgent — monitorare chiamate API da tool CLI o SDK non standard, che suggeriscono automazione
• TimeWindow — la catena completa in meno di 5 minuti è altamente sospetta

SaaS e Office Suite

Per le piattaforme SaaS (log saas:zoom e analoghi), monitorate gli eventi di tipo lifecycle.create filtrandoli per applicazioni ad alto privilegio e confrontando l'attore con la lista degli amministratori approvati. Per Microsoft 365 (log m365:unified), concentrate gli alert sull'aggiunta di utenti a gruppi sensibili — Domain Admins, Global Admins — e sulla distinzione tra account guest e account interni, che hanno profili di rischio molto diversi.

Un approccio trasversale efficace: create una dashboard che mostri il tasso giornaliero di creazione account per ogni piattaforma cloud. Qualsiasi deviazione significativa dalla media mobile a 30 giorni merita un'indagine.

L'analisi forense di un account cloud malevolo parte dalla ricostruzione della catena temporale: chi ha creato l'account, da dove, con quali credenziali, e cosa è successo dopo. Gli artefatti principali sono quasi interamente log-based, dato che l'infrastruttura cloud non lascia tracce tradizionali su disco.

Azure AD Audit Log

Il punto di partenza è l'Azure AD Audit Log, accessibile tramite il portale Entra ID o esportabile via API. Ogni operazione di creazione utente genera un record con ActivityDisplayName "Add User" che contiene l'identità dell'attore (InitiatedBy), l'IP sorgente, il target creato e il timestamp UTC. Corredate questo evento con i SignInLogs dello stesso periodo per identificare la sessione dell'attaccante — cercando in particolare login da IP anomali, user-agent insoliti o assenza di MFA.

Per ricostruire la catena di escalation post-creazione, filtrate gli audit log per l'ObjectId del nuovo account e cercate eventi di tipo "Add member to role" o "Add app role assignment". Ogni assegnazione di ruolo o credenziale aggiuntiva diventa un nodo della timeline.

AWS CloudTrail

Su AWS, l'evento CreateUser in CloudTrail include il campo sourceIPAddress, userAgent e userIdentity (che rivela quale account ha eseguito l'operazione). La sequenza forense critica è:

1. CreateUser — creazione dell'identità
2. AttachUserPolicy o PutUserPolicy — assegnazione permessi
3. CreateAccessKey — generazione di credenziali programmatiche
4. ConsoleLogin o chiamate API successive — primo utilizzo dell'account

Esportate gli eventi CloudTrail nel vostro SIEM o in un bucket S3 dedicato all'analisi e filtrate per il campo requestParameters.userName corrispondente all'account sospetto. Il tool aws-cli (open source) permette il filtraggio diretto con aws cloudtrail lookup-events.

GCP Cloud Audit Logs

In GCP, i log di tipo Admin Activity catturano la creazione di service account (google.iam.admin.v1.CreateServiceAccount) e l'assegnazione di ruoli (SetIamPolicy). Questi log sono abilitati di default e non possono essere disattivati, il che li rende una fonte forense affidabile.

Correlazione cross-cloud

Nei casi documentati di LAPSUS$, la creazione di account Global Admin nel tenant cloud è stata seguita da accesso immediato a risorse critiche. La timeline tipica mostra: compromissione credenziali iniziali → login al portale admin → creazione nuovo account con privilegi massimi → utilizzo del nuovo account per accedere a repository di codice o dati sensibili. L'intero arco temporale può comprimersi in poche ore, il che rende essenziale l'accesso rapido ai log di audit.

Due gruppi documentati utilizzano questa tecnica, con profili operativi e motivazioni profondamente diversi che richiedono modelli di anticipazione distinti.

APT29 è un gruppo con capacità sofisticate che sfrutta Azure AD per creare nuovi utenti nel tenant compromesso. Questa operazione si inserisce in un modello operativo più ampio orientato allo spionaggio di lungo periodo: la creazione di account cloud non è fine a sé stessa, ma serve a stabilire un canale di accesso resiliente che sopravviva alla revoca delle credenziali iniziali. Per APT29, l'account cloud è un punto di persistenza tra molti, coerente con la loro tendenza a mantenere accessi multipli e ridondanti negli ambienti vittima. Organizzazioni nel mirino di questo gruppo — tipicamente enti governativi, think tank e settore diplomatico — dovrebbero considerare la creazione anomala di utenti Azure AD come un indicatore ad alta priorità.

LAPSUS$ presenta un approccio diametralmente opposto: aggressivo, veloce, orientato all'impatto immediato. Il gruppo crea account con ruolo Global Admin direttamente nelle istanze cloud dell'organizzazione bersaglio. Non c'è sottigliezza nella scelta dei privilegi — l'obiettivo è massimizzare l'accesso nel minor tempo possibile. I target di LAPSUS$ spaziano tra grandi aziende tecnologiche e telco, con motivazioni che combinano estorsione e notorietà.

Il tool AADInternals rappresenta un punto di convergenza tecnico interessante: essendo uno strumento open source specifico per l'interazione con le API interne di Azure AD, la sua presenza o i suoi artefatti (moduli PowerShell importati, chiamate API specifiche) possono fungere da indicatore tecnico trasversale.

Dal punto di vista predittivo, il trend è chiaro: man mano che le organizzazioni migrano infrastruttura e identità verso il cloud, la creazione di account persistenti diventa un'alternativa sempre più attraente rispetto ai tradizionali impianti malware su endpoint. Il passaggio dalla persistenza basata su file system a quella basata su identità cloud rappresenta un'evoluzione strutturale del panorama delle minacce, particolarmente rilevante per ambienti multi-cloud dove la visibilità unificata sulle identità è spesso frammentaria.

Per il monitoraggio strategico, incrociate i feed di threat intelligence relativi ad APT29 e LAPSUS$ con i log di creazione account del vostro tenant. Un'allerta precoce da fonti di intelligence settoriale su campagne attive di questi gruppi dovrebbe automaticamente abbassare la soglia di alert per le regole di detection sulla creazione di account cloud.

Framework MITRE ATT&CK v16 — Tecnica T1136.003, Tattica TA0003. Gruppi: G0016 (APT29), G1004 (LAPSUS$). Software: S0677 (AADInternals). Mitigazioni: M1030, M1032, M1026. Detection: DET0319 con analisi AN0899, AN0900, AN0901, AN0902. Integrato con conoscenza professionale per tool e procedure operative.