Cos'è un attacco DCSync: rilevamento e prevenzione

DCSync è un attacco che consente a un avversario di simulare il comportamento di un domain controller (DC) e recuperare i dati della password tramite la replica di dominio. L'uso classico di DCSync è come precursore di un attacco Golden Ticket in quanto può essere utilizzato per recuperare l'hash KRBTGT.

Nello specifico, DCSync è un comando nel tool open-source Mimikatz. Utilizza comandi nel Directory Replication Service Remote Protocol (MS-DRSR) per simulare il comportamento di un domain controller e chiedere ad altri domain controller di replicare informazioni — sfruttando funzioni valide e necessarie di Active Directory che non possono essere disattivate o disabilitate.

Il processo di attacco

L'attacco DCSYNC funziona nel seguente modo:

1. L'attaccante scopre un domain controller per richiedere la replica.
2. L'attaccante richiede la replica dell'utente utilizzando il GetNCChanges
3. Il DC restituisce i dati di replica al richiedente, inclusi gli hash delle password.

Diritti Richiesti

Per eseguire un attacco DCSync sono necessari alcuni diritti molto privilegiati. Poiché di solito ci vuole del tempo affinché un attaccante ottenga questi permessi, questo attacco è classificato come un attacco a catena di eliminazione in fase avanzata.

In generale, gli Amministratori, gli Admin di Dominio e gli Admin Aziendali hanno i diritti necessari per eseguire un attacco DCSync. In particolare, sono richiesti i seguenti diritti:

• Replicazione delle modifiche alla Directory
• Replicazione di tutte le modifiche alla Directory

Replicazione delle modifiche alla Directory in un insieme filtrato

Come le soluzioni Netwrix possono aiutarti a rilevare e sventare gli attacchi DCSync

Detection

Netwrix Threat Manager monitora tutto il traffico di replica di dominio alla ricerca di segni di DCSync. Non si basa su registri eventi o cattura pacchetti di rete. Il suo metodo principale di rilevamento è trovare schemi di comportamento che corrispondono a DCSync, inclusa l'attività di replica tra un controller di dominio e una macchina che non è un controller di dominio.

La soluzione fornisce un chiaro riassunto dell'attività sospetta, così come una visualizzazione che illustra quale utente ha perpetrato l'attacco, il dominio e l'utente presi di mira, e le prove a sostegno dell'attacco. Se lo stesso utente esegue più attacchi DCSync, queste informazioni critiche saranno incluse anch'esse.

Risposta

Per eseguire DCSync, un attaccante necessita di privilegi elevati, quindi il punto chiave per sventare un attacco è bloccare immediatamente l'escalation dei privilegi. La risposta standard del playbook che consiste nel disabilitare l'account utente potrebbe non essere sufficiente, poiché nel momento in cui si rileva l'attacco in corso, è probabile che l'attaccante abbia a disposizione una serie di altre risorse e opzioni.

Netwrix Threat Prevention fornisce politiche di blocco che possono impedire a un account o a una postazione di lavoro di eseguire ulteriori repliche, il che può rallentare un attacco e dare agli interventisti più tempo per eliminare completamente la minaccia.

Netwrix Threat Manager supporta questi passaggi di risposta fornendo dettagli sul responsabile dell'attacco DCSync, sulle fonti, sui bersagli e sugli oggetti interrogati.

Cos'è un attacco DCSync?

Gli aggressori vi accedono più spesso tramite quel tipo di delega residua che tramite un account amministratore compromesso, poiché i diritti di replica vengono assegnati agli account di servizio durante migrazioni e integrazioni e poi mai revocati.

Tuttavia, DCSync non ha una patch, poiché utilizza la stessa interfaccia di replica che i controller di dominio usano per rimanere sincronizzati, e bloccarlo romperebbe Active Directory. Il traffico risultante appare identico alla replica ordinaria a chiunque esamini i log rapidamente.

Come funziona un attacco DCSync

Solo il 26% delle organizzazioni è completamente sicuro che il proprio Active Directory sia privo di configurazioni errate che consentono l'escalation dei privilegi, secondo il Netwrix 2026 Data and Identity Security Report. Questa incertezza è ben fondata, poiché DCSync necessita di un solo permesso delegato su un account di servizio dimenticato per fornire ogni hash di password nel dominio.

La sequenza si completa in pochi secondi e non richiede l'esecuzione di codice sul controller di dominio.

1. L'attaccante prende di mira qualsiasi domain controller nel dominio

Un attacco DCSync è una tecnica di intrusione in cui un avversario simula un domain controller (DC) e recupera dati delle password tramite la replica del dominio. Di solito precede un attacco Golden Ticket.

3. Il controller di dominio mirato restituisce gli hash delle password

Non è necessario un accesso precedente a quella macchina specifica, poiché la richiesta viaggia sulla rete come qualsiasi altro traffico di replica. Qualsiasi controller di dominio risponderà.

2. L’attaccante si spaccia per un controller di dominio per richiedere la replica

DCSync è anche il nome di un comando nello strumento open-source Mimikatz. Il comando utilizza il Directory Replication Service Remote Protocol (MS-DRSR) per impersonare un controller di dominio e chiedere ai controller reali di replicare le informazioni della directory, abusando della replicazione AD che funziona esattamente come progettato. MITRE la traccia come T1003.006 sotto OS Credential Dumping, e non c'è nessuna vulnerabilità sottostante da correggere.

L'attaccante chiama IDL_DRSGetNCChanges nell'interfaccia di replica MS-DRSR, nota anche come DRSUAPI, e richiede dati di replica utente fingendo di essere un controller di dominio. La chiamata è un uso legittimo dell'API di replica, non una richiesta malformata o insolita, quindi non attiva le difese a livello di protocollo.

Il controller di dominio risponde con dati di replica, inclusi gli hash delle password, perché l'interfaccia non può distinguere un controller di dominio legittimo da un account con i permessi corretti.

4. Gli strumenti esistenti eseguono la richiesta

Quali diritti richiede un attacco DCSync

Gli Administrators, Domain Admins e Enterprise Admins possiedono i diritti necessari di default. Poiché questi privilegi richiedono tempo per essere ottenuti, DCSync tende a comparire tardi nella kill chain. I permessi specifici sono:

• Replica delle modifiche di Directory (DS-Replication-Get-ChangesExpand)

Il modulo PowerShell DSInternals lo espone tramite Get-ADReplAccountExpand. L'estrazione dei dati delle password utente con Mimikatz DCSync copre l'intera sequenza di comandi.

Il modulo lsadump::dcsync di Mimikatz rimane l'implementazione più nota, e altri strumenti eseguono la stessa richiesta di replica. secretsdump.py di Impacket lo esegue tramite rete, e il modulo DSInternals di PowerShell lo espone tramite Get-ADReplAccountExpand.

• Replicazione Directory Changes All (DS-Replication-Get-Changes-AllExpand)
• Replica delle modifiche di Directory in set filtrato (richiesto solo in alcuni ambienti)

Altri due permessi aprono la stessa porta e raramente emergono in una revisione dell'appartenenza a gruppi privilegiati. Un account con GenericAll (controllo completo) o AllExtendedRights a livello di dominio può eseguire DCSync senza appartenere a nessun gruppo privilegiato.

Cosa fanno gli aggressori con gli hash

Qualsiasi account con questi diritti delegati nel contesto di denominazione del dominio può replicare. Gli account di servizio Entra Connect, solitamente nominati con il prefisso MSOL_, detengono legittimamente questi diritti, così come gli account che li hanno ereditati da una migrazione o da un'integrazione dimenticata da tempo.

I diritti di replica che rendono possibile DCSync sono permessi; gli hash che restituisce non lo sono. Un hash è materiale di credenziali, la rappresentazione crittografica di una password, e possederne uno permette a un attaccante di impersonare chiunque appartenga senza mai conoscere la password reale di quella persona. Ciò che l'attaccante fa dopo dipende dall'account di cui ha ottenuto l'hash.

Hash KRBTGT: Forgiare ticket per qualsiasi account nel dominio

Enumerare chi detiene oggi i diritti è il controllo di esposizione più economico disponibile, poiché la delega risiede nelle liste di controllo accessi (ACL) che uno strumento di valutazione della directory legge direttamente, e analisi del percorso di attacco mostra come tali diritti si concatenano.

Gli aggressori ottengono questi diritti tramite privilege escalation, quindi qualsiasi account che li possiede necessita della stessa privileged account management disciplina di un Domain Admin, non un accesso permanente mai rivisto.

Hash di account regolari: Muoviti lateralmente senza decifrare nulla

Un'esecuzione di DCSync che raggiunge l'account KRBTGT trasforma il furto di credenziali in una compromissione del dominio. L'hash KRBTGT firma ogni ticket Kerberos nel dominio. Un attaccante che lo possiede può falsificare Ticket Granting Tickets (TGT) per qualsiasi account senza toccare le credenziali di quell'account, e quell'accesso falsificato sopravvive a un normale reset della password sull'account impersonato. Solo un reset di KRBTGT invalida i ticket falsificati.

Materiale di credenziali più debole: decifrare offline una password in chiaro

Come rilevare un attacco DCSync

Gli hash NT LAN Manager (NTLM) per account normali e privilegiati alimentano Pass-the-Hash direttamente. Un attaccante si autentica come quell’account riproducendo l’hash stesso, quindi non è necessario decifrare nulla prima che la credenziale possa essere utilizzata altrove nel dominio.

Tre luoghi possono rilevare una richiesta DCSync, e ciascuno rileva qualcosa di diverso: il registro eventi del controller di dominio, la rete stessa e il comportamento dell’identità che effettua la richiesta.

Le chiavi Kerberos e la cronologia delle password memorizzate recuperate nella stessa risposta di replica vengono decifrate offline quando il tipo di hash è abbastanza debole da renderlo praticabile. Le password in chiaro emergono direttamente solo per gli account configurati con crittografia reversibile, un'impostazione che vale la pena controllare proprio per questo motivo.

Abilita l’auditing di Directory Service e gli avvisi sui GUID di replica

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 per DS-Replication-Get-ChangesExpand
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 per DS-Replication-Get-Changes-AllExpand

Osserva il traffico per la replica da un host non DC

Comportamento di base dell'identità per catturare ciò che un singolo evento non può

Attiva prima la Advanced Audit Policy per Directory Service Access, poiché Windows la disattiva di default e l'Evento ID 4662 non si attiverà senza di essa. Una volta attivata, monitora specificamente questi GUID delle proprietà di replica, identificati tramite identificatore univoco globale (GUID) anziché con nome amichevole:

Avvisa quando quei GUID compaiono su un account che non è un domain controller o un noto account di servizio di replica, e filtra prima di avvisare, poiché un volume 4662 non filtrato su un domain controller occupato produce rumore che nessuno legge. Considera questo segnale come un supporto e non come il controllo principale, poiché un attaccante che raggiunge un domain controller può anche cancellare o bloccare i log su cui si basa una strategia solo 4662.

Come prevenire gli attacchi DCSync

Gestisci i nuovi diritti di replica al provisioning, non solo alla revisione successiva

Non esistono controlli a livello di protocollo che blocchino DCSync, quindi la prevenzione si basa sul controllo di chi può invocare la replica e sull'accorciamento dei percorsi che conducono a tali diritti.

Monitora un bind DRSUAPI che trasporta IDL_DRSGetNCChanges da qualsiasi host che non sia un domain controller, poiché la replica legittima avviene solo tra domain controller e non esiste una versione innocua di quel traffico da filtrare. Dai priorità a questo segnale rispetto al rilevamento nei log eventi, poiché il monitoraggio della rete cattura la richiesta indipendentemente dal fatto che il domain controller l’abbia registrata, mantenendo il segnale disponibile anche dopo che un attaccante ha manomesso il logging dell’endpoint.

Inserisci eventi di replica in una piattaforma di Identity Threat Detection che costruisce una baseline per il comportamento normale di ogni account, poiché un singolo evento 4662 o una bind DRSUAPI possono sembrare legittimi isolatamente ma anomali rispetto alla storia specifica di quell’account. Questo livello esiste per rilevare il modello di un account che non ha mai effettuato una richiesta di replica prima di farlo una volta, cosa che una allowlist statica o una regola singola possono completamente mancare.

I diritti concessi durante una migrazione o integrazione tendono a rimanere a lungo dopo la fine del progetto, poiché rimuovere accessi che nessuno ricorda di aver concesso è più difficile che concederli inizialmente.

Rivedi e rimuovi i diritti di replica che nessuno può giustificare

Limitare la RPC di replica agli indirizzi noti dei controller di dominio

Esamina ogni account che possiede le tre autorizzazioni di replica più GenericAll e AllExtendedRights nel contesto di denominazione del dominio e rimuovi ciò che nessuno può giustificare. Ripeti la revisione secondo un programma, poiché nuove integrazioni reintroducono i diritti.

Chiudi i percorsi che gli aggressori usano per raggiungere i diritti di replica

Quando la topologia lo consente, consenti la replicazione delle chiamate di procedura remota (RPC) solo tra indirizzi noti dei controller di dominio. Questo non impedirà a un attaccante che ha già diritti di replicazione validi, ma blocca le richieste da qualsiasi host senza una ragione legittima per farlo.

Come rispondere a un sospetto attacco DCSync

Definisci l'ambito di ciò che l'attaccante ha effettivamente interrogato

Enterprise Key Admins è l’esempio ricorrente, poiché adprep /domainprep su Windows Server 2016 ha concesso a quel gruppo il pieno controllo sul Domain Naming Context e sui suoi oggetti secondari. Microsoft lo ha definito un bug piuttosto che una vulnerabilità e lo ha chiuso per le nuove preparazioni del dominio a partire dall’aggiornamento 1709, ma i domini preparati prima di quella correzione necessitano di uno script di rimedio separato; gli aggiornamenti dello schema a livello di dominio da soli non lo risolveranno.

Supponi che gli hash siano già spariti, perché i dati hanno lasciato il dominio prima che scattasse l’allarme. Ciò che farai dopo deciderà per quanto tempo quell’accesso continuerà a fruttare per l’attaccante.

Richiedere una giustificazione documentata e un responsabile nominato prima che qualsiasi nuova integrazione o migrazione riceva DS-Replication-Get-ChangesExpand, DS-Replication-Get-Changes-AllExpand, GenericAllExpand, o AllExtendedRightsExpand, invece di concedere prima il diritto e rivederlo al prossimo ciclo di audit.

Esamina l'ID evento 4662, Directory Service e i log di Sysmon per stabilire quali oggetti l'attaccante ha interrogato prima di decidere fino a che punto devono arrivare il contenimento e la rimedio. Ciò che emerge qui determina se la risposta si ferma a un account o si estende a un reset delle credenziali a livello di dominio.

Verifica che Zerologon (CVE-2020-1472) sia risolto, poiché le vulnerabilità che concedono privilegi di dominio saltano direttamente tutta la catena di attacco. Considera le vie di raccolta delle credenziali come Kerberoasting come il modo in cui gli attaccanti ottengono i diritti di replica fin dall'inizio, non come un problema separato da risolvere in seguito. Entrambe le correzioni fanno parte delle migliori pratiche di sicurezza di Active Directory che mantengono sotto controllo gli altri percorsi privilegiati del dominio.

Reimpostare KRBTGT due volte se era tra gli hash

Contieni la fonte, non solo l'account implicato

Disabilitare l'account implicato è il riflesso, ma da solo ottiene poco, perché l'attaccante ora possiede credenziali che funzionano indipendentemente da quell'account. Revoca invece i diritti di replica e le appartenenze ai gruppi privilegiati, e isola l'host di origine.

Come Netwrix ti aiuta a rilevare e bloccare gli attacchi DCSync

Trova tutti gli account con diritti di replica

Valutazione, rilevamento e prevenzione avvengono tramite diversi prodotti qui, e lavorano insieme.

Se KRBTGT era tra questi, reimpostare la password KRBTGT due volte, lasciando un intervallo tra i due reset più lungo sia della durata massima del ticket (10 ore per impostazione predefinita) sia di un ciclo completo di replica. Un singolo reset lascia valida la chiave precedente, quindi i ticket contraffatti continuano a funzionare. Quando i log non possono stabilire l'ambito, impostare di default un reset delle credenziali a livello di dominio invece di indovinare.

Rileva una richiesta di replica da un host non DC

Blocca la richiesta di replica prima che venga completata

Netwrix PingCastle valuta Active Directory rispetto ai controlli mappati MITRE ATT&CK, incluse le utenze con diritti di replica fuori dai gruppi predefiniti, trasformando la revisione della delega sopra in un controllo ripetibile.

I suoi avvisi mostrano l’account dietro la richiesta, il dominio e l’account mirati, e gli oggetti interrogati, che sono i dettagli di cui un analista ha bisogno per definire l’ambito dell’esecuzione anziché solo confermarne l’avvenimento.

Il rilevamento DCSync proviene da una policy di Netwrix Threat Prevention AD Replication Monitoring, quindi i due prodotti funzionano in coppia.

Netwrix Threat Manager rileva tecniche di furto di credenziali contro Active Directory, inclusa una richiesta di replica emessa da una macchina che non è un controller di dominio, e invia un avviso.

Netwrix Threat Prevention applica politiche di blocco che impediscono a un account o workstation specifico di eseguire ulteriori repliche. Entrambi rientrano in identity threat detection and response, con Threat Manager che estende il rilevamento a Entra ID e Threat Prevention che applica le regole a livello di Active Directory on-premises.

Da dove iniziare con l'esposizione DCSync

[SEGNAPOSTO IMMAGINE: Prodotto, richiesta a PMM. Necessaria una schermata del prodotto Netwrix Threat Manager (qualsiasi vista attuale che mostri un evento DCSync rilevato con host sorgente, account target e oggetti interrogati)]

I diritti di replica hanno la maggior parte del peso difensivo qui, e una lista di deleghe che nessuno ha rivisto dall'ultima migrazione è il percorso di attacco realistico. Enumerarla richiede un pomeriggio.

Richiedi una demo per vedere come Netwrix individua i diritti di replica, rileva un tentativo attivo di DCSync e blocca il successivo nel tuo ambiente Active Directory.

L’allerta sulla replica da host che non sono controller di dominio intercetta il tentativo stesso, e quel segnale rimane valido indipendentemente dal fatto che l’auditing di Directory Service sia mai stato attivato. Una procedura documentata di reset KRBTGT decide quindi per quanto tempo una corsa riuscita continua a favorire l’attaccante.