Creazione Account Cloud: Cloud Account (T1136.003)

Per testare efficacemente questa tecnica nel vostro ambiente di laboratorio, iniziate con Azure AD. Il tool AADInternals fornisce capacità avanzate per la creazione di utenti:

Install-Module AADInternals $cred = Get-Credential Connect-AADIntAzureAD -Credential $cred New-AADIntUser -UserPrincipalName "persistence@victim.onmicrosoft.com" -DisplayName "Service Account"

In AWS, la creazione di un utente IAM con policy specifiche richiede una sequenza precisa. Prima create l'utente, poi associate una policy inline per accesso minimo:

aws iam create-user --user-name service-persistence aws iam attach-user-policy --user-name service-persistence --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess aws iam create-access-key --user-name service-persistence

Per GCP, la creazione di service account segue un pattern simile ma con nomenclatura diversa. L'aspetto critico è l'assegnazione di ruoli che permettano l'impersonificazione:

gcloud iam service-accounts create persistence-sa --display-name="Persistence Account" gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:persistence-sa@PROJECT_ID.iam.gserviceaccount.com" --role="roles/viewer"

L'approccio di APT29 documentato prevede la creazione di utenti attraverso Azure AD con privilegi elevati. Replicate questa catena d'attacco assegnando ruoli amministrativi gradualmente per evitare detection threshold.

Il gruppo LAPSUS$ ha dimostrato l'efficacia di creare account con privilegi global admin. Nel vostro lab, testate la creazione incrementale di privilegi partendo da account base fino a raggiungere livelli amministrativi completi.

La detection efficace richiede monitoraggio multi-layer attraverso diversi log source. Per Azure, configurate alert su azure:audit e azure:signinlogs focalizzandovi su pattern temporali sospetti.

Create una regola che triggera quando CreateUser è seguito da AttachPolicy entro 5 minuti. Questa sequenza temporale stretta indica automazione, caratteristica comune negli attacchi reali. Il tuning deve considerare gli IP di origine: filtrate quelli esterni alle vostre subnet amministrative conosciute.

Per AWS CloudTrail, monitorate gli eventi IAM:CreateUser provenienti da user agent non standard. Gli attaccanti spesso usano CLI o API dirette invece della console, generando pattern distintivi nel campo UserAgent.

L'analisi comportamentale deve includere il conteggio degli admin totali. Se il numero di account con privilegi elevati supera la vostra baseline storica del 20%, generate un alert ad alta priorità. Questo approccio cattura creazioni massive tipiche di campagne APT.

Per i service principal in Azure, implementate detection differenziata. La creazione di service principal richiede scrutinio maggiore rispetto agli account utente standard, specialmente quando associata a OAuth applications o serverless functions.

Il monitoraggio di Office 365 attraverso m365:unified logs deve focalizzarsi su aggiunte a gruppi sensibili. Non tutti i gruppi sono uguali: Domain Admins, Enterprise Admins e Global Administrators richiedono alert immediati.

La ricostruzione forense inizia identificando il momento esatto della creazione account. In Azure AD, gli audit log mantengono dettagli granulari inclusi timestamp UTC, IP sorgente e metodo di autenticazione utilizzato.

Per AWS, CloudTrail fornisce una timeline completa. Cercate pattern dove eventName contiene "CreateUser" seguito da "CreateAccessKey". Questa sequenza indica preparazione per accesso programmatico persistente.

Gli artefatti critici includono i metadata dell'account creato. In GCP, i service account mantengono un campo createdTime immutabile che fornisce l'ancoraggio temporale per la vostra timeline. Correlate questo timestamp con attività di rete anomale nello stesso periodo.

L'analisi deve estendersi oltre la creazione iniziale. Tracciate le successive modifiche di privilegi attraverso eventi come AddUserToGroup o AttachRolePolicy. Questi eventi secondari rivelano l'escalation progressiva tipica di attaccanti sofisticati.

Per identificare l'origine dell'attacco, esaminate i log di autenticazione precedenti la creazione. Gli attaccanti devono autenticarsi con credenziali compromesse prima di creare nuovi account. Questa fase pre-creazione spesso rivela il vettore iniziale di compromissione.

La correlazione temporale con altri IoC è fondamentale. Se trovate creazione di account cloud coincidente con lateral movement interno o data exfiltration, avete identificato una campagna coordinata che richiede response immediata.

Il gruppo APT29 utilizza questa tecnica come parte di campagne di spionaggio a lungo termine. La loro metodologia prevede creazione di account Azure AD con nomi che mimano convenzioni aziendali legittime. Aspettatevi naming pattern come "svc_backup" o "admin_temp" progettati per passare inosservati durante audit di routine.

LAPSUS$ adotta un approccio più aggressivo, creando direttamente global admin accounts. Questo gruppo opera con timeline accelerate, spesso completando l'intera catena di attacco in meno di 48 ore. La loro preferenza per privilegi massimi indica obiettivi di data theft su larga scala piuttosto che persistenza stealth.

L'overlapping di tool tra gruppi rivela pattern interessanti. AADInternals viene utilizzato sia da threat actor opportunistici che da APT strutturati, rendendo l'attribution basata solo su tool presence insufficiente. Concentrate l'analisi su TTP comportamentali post-creazione.

I pattern geografici mostrano concentrazione di questa tecnica in campagne originate da Eastern Europe e Southeast Asia. Tuttavia, l'uso di cloud infrastructure per staging rende l'attribution geografica sempre più complessa.

Le previsioni indicano evoluzione verso account creation in ambienti multi-cloud simultanei. Gli attaccanti creano account ridondanti across AWS, Azure e GCP per garantire persistenza anche in caso di detection parziale. Preparate playbook che coprano remediation cross-cloud coordinata.

Tecnica documentata nel framework MITRE ATT&CK con identificativo T1136.003. Analisi basata su intelligence di campagne APT29 e LAPSUS$, con detection strategy validate su ambienti Azure AD, AWS e GCP. Tool references includono AADInternals per testing e CyberArk/BeyondTrust per mitigation enterprise.