Replica Malevola di Active Directory: DCSync (T1003.006)

La simulazione di un DCSync in laboratorio è uno degli esercizi fondamentali per validare il livello di detection di un'infrastruttura Active Directory. Il prerequisito è disporre di un account con i privilegi di replica — in un test reale lo si ottiene tipicamente dopo una privilege escalation, ma in lab si può assegnare direttamente tramite la console Active Directory Users and Computers.

Mimikatz (open source) resta il riferimento principale. Il modulo lsadump include il comando DCSync nativo. Per estrarre l'hash NTLM dell'account KRBTGT:

mimikatz # lsadump::dcsync /domain:lab.local /user:krbtgt

Per esfiltrare tutti gli hash del dominio in un'unica operazione si aggiunge il flag /all:

mimikatz # lsadump::dcsync /domain:lab.local /all /csv

Il parametro /csv produce un output tabulare facilmente importabile in altri tool di post-exploitation. Vale la pena ricordare che Mimikatz supporta anche NetSync, una variante che utilizza il protocollo di replica legacy MS-NRPC, utile per testare ambienti con domain controller datati.

Su Linux, Impacket (open source) offre lo script secretsdump.py, che implementa DCSync senza necessità di eseguire codice sul domain controller:

secretsdump.py lab.local/admin:Password1@dc01.lab.local -just-dc-ntlm

Il flag -just-dc-ntlm limita l'estrazione ai soli hash NTLM, velocizzando l'operazione. Per ottenere anche le chiavi Kerberos AES si usa -just-dc senza il suffisso. Se si dispone di un hash NTLM invece della password in chiaro, Impacket supporta il pass-the-hash con il parametro -hashes.

Per una catena d'attacco completa in ambiente lab, il flusso tipico è: enumerare gli account con privilegi di replica tramite BloodHound (open source) e il suo collector SharpHound, identificare il path di escalation più breve verso un account con Replicating Directory Changes All, compromettere quell'account, e infine lanciare il DCSync.

Un test utile è verificare la detection eseguendo il DCSync da una workstation qualsiasi (non un DC): se il SOC non genera alert, la rete ha un gap di visibilità critico. In BloodHound si può interrogare il grafo con la query Cypher dedicata per trovare tutti i principal con diritti DCSync:

MATCH p=(n)-[:MemberOf|GetChanges|GetChangesAll1..]->(d:Domain) RETURN p*

Questa query restituisce ogni nodo che possiede, direttamente o per appartenenza a gruppi, i permessi necessari alla replica — un punto di partenza essenziale per la fase di ricognizione interna.

La detection di DCSync ruota attorno a un principio semplice: le richieste di replica che partono da un IP che non è un domain controller sono quasi certamente malevole. Tradurre questo principio in alert affidabili richiede però una configurazione accurata delle sorgenti di log e un tuning costante.

La sorgente primaria è il log Windows Security sul domain controller. L'evento chiave è EventCode 4662, che registra l'accesso a oggetti di directory. Un DCSync genera accessi con i GUID delle proprietà di replica: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes) e {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All). Filtrare il 4662 su questi due GUID, escludendo gli account macchina dei DC legittimi, produce un alert ad alta fedeltà.

Un secondo indicatore è EventCode 4624 (logon di tipo 3, network logon) originato da un IP non presente nella lista dei domain controller, immediatamente seguito da traffico DRS sulla porta TCP 135 e poi sulle porte dinamiche RPC. Correlare questi due eventi entro una finestra temporale di pochi secondi aumenta la precisione.

Sul versante rete, il monitoraggio del traffico DRSUAPI tramite un sensore NSM (Network Security Monitoring) è estremamente efficace. Le richieste DRSGetNCChanges possono essere identificate tramite deep packet inspection o analisi dei metadati RPC. Se la sorgente della richiesta non corrisponde a un DC noto, l'alert deve avere severità critica.

Per il tuning è essenziale mantenere una whitelist aggiornata degli IP dei domain controller e degli account di servizio autorizzati alla replica — ad esempio gli account utilizzati da Azure AD Connect per la sincronizzazione ibrida. I parametri di tuning suggeriti dalla detection DET0594 sono tre:

• TimeWindow: la finestra di correlazione tra logon anomalo e traffico DRSUAPI (consigliati 5-10 secondi)
• UserContext: account che legittimamente eseguono replica (account macchina dei DC, Azure AD Connect)
• SourceIP: indirizzi dei DC noti, da escludere per ridurre i falsi positivi

Microsoft Defender for Identity (a pagamento, incluso in Microsoft 365 E5) fornisce un alert nativo per DCSync e rappresenta una soluzione chiavi in mano per chi opera in ambienti Microsoft. Per chi utilizza SIEM open source, Sigma (open source) include regole pronte per il 4662 con i GUID di replica, convertibili nei formati Splunk, Elastic e QRadar tramite il compilatore sigma-cli.

Infine, un controllo preventivo: auditare periodicamente chi possiede i permessi Replicating Directory Changes All tramite PowerShell con il cmdlet Get-ACL sull'oggetto dominio, e generare un alert ogni volta che questa ACL viene modificata (EventCode 5136, directory service change).

L'analisi forense di un DCSync richiede la convergenza di artefatti endpoint e network, perché l'operazione non tocca il filesystem del domain controller — non ci sono file scritti, né processi creati sul DC. Tutta l'azione avviene dal lato dell'attaccante.

Sul domain controller vittima, il punto di partenza sono i log Security. L'analista deve cercare il EventCode 4662 con le proprietà di replica già descritte, prestando attenzione al campo SubjectUserName (l'account usato per la replica) e SubjectLogonId (per correlare con il logon iniziale). Il EventCode 4624 corrispondente fornisce l'IP sorgente della richiesta: se non è un DC, è la workstation compromessa da cui è partito l'attacco.

La correlazione temporale è cruciale. In una timeline tipica si osserva questa sequenza:

1. 4624 (logon tipo 3) da IP non-DC con account privilegiato
2. 4662 con accesso ai GUID di replica, stesso LogonId
3. Ripetizione del 4662 per ogni account replicato (possono essere migliaia in pochi secondi)
4. Eventuale 4672 (special privileges assigned) per lo stesso logon

Sul sistema attaccante — se acquisito — gli artefatti dipendono dal tool utilizzato. Per Mimikatz, la memoria del processo contiene le strutture dati con gli hash estratti. Un dump della RAM analizzato con Volatility 3 (open source) permette di cercare le stringhe caratteristiche del modulo lsadump. Se l'attaccante ha usato il parametro /csv, il file di output potrebbe trovarsi su disco o nella cronologia dei comandi PowerShell, accessibile tramite il file ConsoleHost_history.txt nel profilo utente.

Per Impacket su Linux, il file .bash_history o il log di sessione tmux/screen possono contenere la riga di comando con secretsdump.py. Gli hash estratti vengono tipicamente scritti in un file con estensione .ntds nella directory corrente.

Sul versante network, un PCAP dell'intervallo temporale sospetto permette di isolare il traffico DRSUAPI. Il protocollo utilizza RPC over TCP, e con Wireshark (open source) è possibile filtrare per drsuapi e osservare le singole richieste DRSGetNCChanges. Il volume di dati trasferiti è un indicatore: una replica completa genera diversi megabyte di traffico in uscita dal DC verso l'IP attaccante, anomalo rispetto al traffico di replica inter-DC che segue pattern prevedibili.

Per contestualizzare i risultati, l'analista deve verificare se dopo il DCSync sono comparsi artefatti di Golden Ticket: eventi Kerberos EventCode 4769 con cifratura RC4 (tipo 0x17) per account che normalmente usano AES, oppure ticket con durata anomala. Questo collega la fase di credential access alla successiva lateral movement.

DCSync è una tecnica trasversale che unisce gruppi con motivazioni e sofisticazione molto diverse, a dimostrazione che l'accesso alle credenziali di dominio resta un obiettivo universale indipendentemente dall'intento finale dell'operazione.

Earth Lusca (G1006) è un gruppo con focus su cyber-espionage che ha utilizzato DCSync tramite Mimikatz dopo aver compromesso un domain controller. Il pattern operativo prevede lo sfruttamento di vulnerabilità su servizi esposti per ottenere un primo accesso, seguito da escalation fino ai privilegi di dominio. L'uso di DCSync come tecnica di raccolta credenziali suggerisce operazioni mirate a mantenere persistenza a lungo termine in ambienti enterprise.

Mustang Panda (G0129), noto per campagne di spionaggio con targeting geopolitico prevalentemente asiatico, ha integrato la funzionalità DCSync di Mimikatz nel proprio arsenale. Il ricorso a un tool pubblico come Mimikatz, anziché a strumenti custom, indica un approccio pragmatico: il gruppo privilegia l'efficacia operativa rispetto all'evasione forense.

LAPSUS$ (G1004) rappresenta un caso atipico: un collettivo orientato all'estorsione e alla notorietà che ha impiegato DCSync per alimentare routine di privilege escalation. L'uso di questa tecnica da parte di un gruppo con operatori relativamente giovani e tattiche basate su social engineering dimostra quanto DCSync sia accessibile una volta ottenuto un livello minimo di privilegio nel dominio.

Storm-0501 (G1053) ha utilizzato DCSync per l'estrazione di credenziali dalle vittime, inserendosi nel panorama dei gruppi con motivazione finanziaria che operano attacchi ransomware multi-fase.

Le 3 campagne documentate confermano la versatilità della tecnica. La campagna C0027, attribuita a Scattered Spider, ha colpito il settore telecomunicazioni e BPO con replica di dominio a supporto di operazioni di SIM swapping. Operation Wocao (C0014), condotta da attori probabilmente legati ad APT20, ha utilizzato DCSync con Mimikatz contro organizzazioni governative e aziende in oltre dieci paesi, confermando l'uso in operazioni di cyber-espionage su larga scala. La SolarWinds Compromise (C0024), condotta da APT29, ha visto l'uso di account privilegiati per replicare dati dei directory service — un impiego di DCSync all'interno di una delle operazioni di supply chain più sofisticate documentate.

Il pattern ricorrente è chiaro: Mimikatz (S0002) è il denominatore comune. Ogni gruppo e campagna lo utilizza come vettore primario per DCSync. Per il threat intelligence officer, questo significa che qualsiasi rilevamento di Mimikatz in memoria o su disco deve immediatamente far scattare l'ipotesi di DCSync avvenuto o tentato, con verifica immediata delle ACL di replica e degli eventi 4662 sui domain controller.

L'overlap di tool tra gruppi così diversi — da APT29 a LAPSUS$ — rende l'attribuzione basata sul solo uso di DCSync praticamente impossibile. L'analista deve concentrarsi sugli indicatori contestuali: vettore di accesso iniziale, infrastruttura C2, e target verticali per discriminare tra le diverse matrici di minaccia.

Framework MITRE ATT&CK: T1003.006 (DCSync), TA0006 (Credential Access). Campagne: C0027, C0014 (Operation Wocao), C0024 (SolarWinds Compromise). Detection: DET0594 — EventCode 4662, 4624, DRSUAPI network monitoring. Tool di detection citati: Volatility 3, Wireshark, Sigma, BloodHound, Microsoft Defender for Identity. Integrato con conoscenza professionale per tool e procedure operative.