Account di Dominio Malevoli: Create Domain Account (T1136.002)

Simulare la creazione di account di dominio in un laboratorio red team è un esercizio fondamentale per validare i controlli di detection. Il prerequisito è disporre di credenziali con privilegi sufficienti — almeno Account Operator o Domain Admin — e di un ambiente Active Directory dedicato ai test.

Il vettore classico resta il binario nativo di Windows. Da una shell con privilegi adeguati su una macchina domain-joined:

net user redteamuser P@ssw0rd2025! /add /domain

Per elevare immediatamente i privilegi dell'account appena creato, aggiungendolo al gruppo Domain Admins:

net group "Domain Admins" redteamuser /add /domain

Questi due comandi rappresentano la catena minima che molti gruppi APT eseguono in sequenza. Un red teamer dovrebbe verificare che entrambi generino alert distinti nel SIEM.

L'approccio PowerShell offre maggiore flessibilità e si presta a scenari di simulazione più sofisticati. Il modulo ActiveDirectory, disponibile nativamente sui domain controller e installabile su workstation tramite RSAT, espone cmdlet dedicati:

New-ADUser -Name "svc_backup" -SamAccountName "svc_backup" -UserPrincipalName "svc_backup@lab.local" -AccountPassword (ConvertTo-SecureString "C0mpl3x!Pass" -AsPlainText -Force) -Enabled $true -Path "OU=ServiceAccounts,DC=lab,DC=local"

Questo comando crea un account di servizio posizionandolo in una OU specifica — tattica usata per mimetizzare l'utenza tra gli account legittimi. Il flag -Path è particolarmente rilevante: un attaccante esperto non deposita mai un account nel container Users predefinito.

Per simulare lo scenario Linux, su una macchina con Samba installato e configurata per interagire con AD, il comando equivalente è:

samba-tool user create redteamuser P@ssw0rd2025!

Empire (open source) offre un modulo dedicato alla creazione di account di dominio, utile per testare la detection in scenari di post-exploitation con C2 attivo. Analogamente, Pupy (open source) sfrutta PowerView per eseguire comandi net user attraverso il suo framework di RAT. Per scenari che richiedono esecuzione remota, PsExec (gratuito, parte di Sysinternals) permette di lanciare comandi su domain controller remoti con le credenziali appropriate.

Un consiglio operativo: durante l'esercizio, create account con naming convention deliberatamente simili a quelle dell'organizzazione target (es. "svc_" per account di servizio, nomi plausibili per utenti). Questo testa la capacità del blue team di identificare anomalie non solo tecniche ma anche semantiche.

La detection della creazione di account di dominio ruota attorno a un evento cardine su Windows: Event ID 4720 (A user account was created), registrato nel Security log del domain controller. Questo evento è il punto di ancoraggio, ma da solo genera rumore significativo in ambienti enterprise dove il provisioning utenti è attività quotidiana.

La strategia di detection documentata prevede una correlazione comportamentale a due stadi: primo, l'esecuzione di un processo sospetto sul domain controller (tipicamente net.exe, net1.exe o powershell.exe); secondo, la comparsa dell'evento 4720 entro una finestra temporale di 2 minuti. Questa correlazione separa il provisioning legittimo — che avviene tramite console amministrative, portali self-service o script schedulati — dall'attività hands-on-keyboard di un avversario.

I log source critici sono WinEventLog:Security e WinEventLog:Sysmon. Sysmon, in particolare, fornisce il contesto del processo padre attraverso l'Event ID 1 (Process Creation), permettendo di distinguere un net.exe lanciato da cmd.exe in una sessione interattiva — altamente sospetto su un DC — da uno invocato da un sistema di orchestrazione IT noto.

Il tuning è essenziale per ridurre i falsi positivi e si articola su quattro assi:

• ParentProcessName: whitelist dei tool amministrativi legittimi (console MMC, script di provisioning approvati) vs. processi anomali come powershell.exe o cmd.exe invocati da sessioni RDP
• UserContext: distinguere operazioni eseguite da account del team IT/helpdesk (attività ordinaria) da quelle di account Domain Admin (potenziale abuso di privilegi)
• HostRole: restringere la regola ai soli domain controller, escludendo workstation e member server dove l'evento è irrilevante o fuorviante
• TimeWindow: la finestra di 2 minuti tra processo sospetto e creazione account è calibrata per catturare l'esecuzione interattiva senza generare correlazioni spurie

Su sistemi Linux, la detection si sposta sulle chiamate a tool come samba-tool, ldapmodify o realmd, monitorate tramite auditd con regole SYSCALL. Il traffico LDAP/Kerberos generato dalla creazione dell'account rappresenta un indicatore di rete complementare, osservabile tramite NSM. Per ambienti macOS domain-joined, il Unified Log cattura l'esecuzione di dsconfigad e dscl; la comparsa di autenticazioni da parte di un account mai visto prima su sistemi AD-bound è l'indicatore chiave.

Un alert ad alto valore è la creazione di account seguita dall'aggiunta immediata a gruppi privilegiati (Event ID 4728, 4732, 4756): questa sequenza riduce drasticamente i falsi positivi e identifica con precisione il pattern di escalation tipico degli attaccanti.

L'indagine forense su un account di dominio malevolo parte dal domain controller e si espande a ritroso lungo la catena di compromissione. L'artefatto primario è il Security Event Log, dove l'Event ID 4720 documenta la creazione dell'account con timestamp, SID del creatore e attributi iniziali dell'utenza. Questo evento è il punto zero della timeline.

Immediatamente dopo, cercate gli eventi di modifica gruppo: Event ID 4728 (membro aggiunto a un gruppo security-enabled globale), 4732 (gruppo locale) e 4756 (gruppo universale). Nella campagna 2016 Ukraine Electric Power Attack (C0025), Sandworm Team creò due account — "admin" e "система" (System) — assegnandoli a un dominio corrispondente alle operazioni locali e delegando loro nuovi privilegi. Questa sequenza creazione-assegnazione è un pattern forensicamente ricorrente.

Il database Active Directory stesso è una fonte preziosa. L'attributo whenCreated dell'oggetto utente nel directory fornisce il timestamp di creazione, mentre whenChanged traccia le modifiche successive. Con il modulo PowerShell ActiveDirectory:

Get-ADUser -Identity "accountsospetto" -Properties whenCreated, whenChanged, memberOf, lastLogon

Sysmon arricchisce la timeline con il contesto di esecuzione. L'Event ID 1 registra la command line completa del processo che ha creato l'account — fondamentale per ricostruire se l'avversario ha usato net.exe, PowerShell o un tool custom. Il campo ParentImage rivela la catena di processi padre, potenzialmente tracciabile fino al vettore di accesso iniziale.

Per ricostruire l'uso post-creazione dell'account malevolo, gli Event ID 4624 (logon riuscito) e 4625 (logon fallito) mostrano dove e quando l'account è stato impiegato. Il Logon Type è discriminante: Type 3 (network) indica lateral movement, Type 10 (RemoteInteractive) segnala accesso RDP. Nella campagna 2015 Ukraine Electric Power Attack (C0028), gli account privilegiati creati da Sandworm Team furono utilizzati esplicitamente per exploitation successiva e movimento laterale.

Su sistemi Linux coinvolti nella gestione AD, i log di auditd registrano le syscall associate all'esecuzione di samba-tool o ldapmodify, con PID, UID e argomenti del comando. Il file /var/log/samba/log.samba può contenere tracce aggiuntive delle operazioni LDAP.

Un passaggio spesso trascurato: verificate i Deleted Objects container di Active Directory. Se l'attaccante ha tentato di eliminare l'account dopo l'uso, il tombstone preserva i metadati per un periodo configurabile (di default 180 giorni), permettendo di recuperare evidenze anche dopo tentativi di pulizia.

La creazione di account di dominio è una tecnica trasversale che accomuna operatori state-sponsored e gruppi ransomware, ma con finalità e pattern operativi distinti che permettono un profiling efficace.

Sandworm Team rappresenta il caso studio più documentato, con due campagne storiche contro l'infrastruttura energetica ucraina. Nella 2015 Ukraine Electric Power Attack (C0028), il gruppo creò account di dominio privilegiati come trampolino per exploitation e lateral movement all'interno delle sottostazioni di trasmissione e distribuzione, utilizzando BlackEnergy3 e KillDisk. L'anno successivo, nella 2016 Ukraine Electric Power Attack (C0025), raffinò l'approccio: i due account "admin" e "система" furono assegnati a un dominio che rispecchiava le operazioni locali, dimostrando una crescente attenzione all'OPSEC e alla mimetizzazione. L'uso del cirillico nel nome "система" è un indicatore di familiarità con l'ambiente target — un dettaglio utile per l'attribuzione.

GALLIUM (G0093) opera nel settore telecomunicazioni e crea account di dominio ad alto privilegio come meccanismo di persistenza primario. Il pattern è orientato al mantenimento di accesso a lungo termine su reti complesse, coerente con operazioni di cyber espionage.

Wizard Spider (G0102), gruppo a matrice finanziaria noto per le operazioni ransomware, integra la creazione di account AD nel proprio playbook di persistenza. Il gruppo crea e utilizza nuove utenze all'interno dell'Active Directory della vittima — un approccio che garantisce sopravvivenza anche quando gli strumenti di accesso remoto vengono individuati e rimossi.

BlackByte (G1043) segue un pattern simile, creando account di dominio privilegiati durante le intrusioni. La predilezione per il privilegio elevato immediato suggerisce operazioni con finestre temporali brevi, tipiche del modello ransomware.

Medusa Group (G1051) completa il quadro con la creazione di account di dominio nell'ambiente vittima, confermando che questa tecnica è diventata procedura standard nel playbook ransomware contemporaneo.

L'analisi dei tool sovrapposti rivela un pattern interessante: Empire e Pupy (entrambi open source) sono framework di post-exploitation che democratizzano l'accesso a questa tecnica, mentre Net e PsExec sono strumenti legittimi abusati — il classico paradigma living-off-the-land. Per il TI officer, la presenza di questi tool nella telemetria di un incidente non è discriminante per l'attribuzione, ma il contesto d'uso (naming convention degli account, sequenza di operazioni, target verticale) lo è.

Il trend emergente è chiaro: la creazione di domain account si sta spostando da tecnica accessoria a componente strutturale della kill chain, utilizzata sia per persistenza sia come prerequisito per il lateral movement, indipendentemente dalla motivazione dell'attaccante.

Framework MITRE ATT&CK v16 — Tecnica T1136.002 (Create Account: Domain Account). Campagne: C0028 (2015 Ukraine Electric Power Attack), C0025 (2016 Ukraine Electric Power Attack). Detection basata su Event ID 4720, 4728, Sysmon Event ID 1, auditd SYSCALL, macOS Unified Log. Integrato con conoscenza professionale per tool e procedure operative.