← All field notes
active directorydcsynckerberosincident response

DCSync explained: how attackers replicate every password hash

DCSync abuses Active Directory replication rights to pull password hashes, including krbtgt. Here is how it works, how to detect it, and why recovery needs a double krbtgt reset.

Attack flow
1Get an account with replication rights
2Request directory replication (DCSync)
3DC returns password hashes
4Forge tickets or crack hashes
5Full domain compromise
Seen in the wildConti (Wizard Spider)Broad APT and ransomware use

DCSync is how an attacker who has gained the right Active Directory permissions copies password hashes straight out of a domain controller, including the krbtgt hash that underpins all Kerberos trust.

What DCSync is

An account with the directory replication extended rights, DS-Replication-Get-Changes and DS-Replication-Get-Changes-All, can ask a domain controller to replicate account secrets over the directory replication protocol (drsuapi). The DC complies, because that is how DCs normally sync with each other. The attacker is just pretending to be a DC. Mimikatz and Impacket secretsdump automate it. In ATT&CK terms this is T1003.006, OS Credential Dumping: DCSync.

Why the krbtgt hash matters

With the krbtgt account hash an attacker forges Golden Tickets: valid Kerberos ticket-granting tickets for any user, including Domain Admins, that the domain will honor until krbtgt is rotated. That is the moment a credential theft becomes durable domain dominance.

How to detect it

The signal is a replication request from a principal that is not a domain controller. Watch for Event 4662 referencing the replication GUIDs, or use Microsoft Defender for Identity, which flags DCSync in near real time. A non-DC source asking for replication is the tell.

Contain, eradicate, and recover

Remove the excessive replication rights and the ACL or account that granted them. Then reset the krbtgt password twice, with the second reset after the first has replicated, because a single reset leaves existing Golden Tickets valid through the rotation window. Audit AdminSDHolder for planted ACEs, move Tier 0 admins into the Protected Users group, and review exactly who holds replication rights. Until krbtgt is rotated and persistence is removed, you cannot trust Kerberos. Recovery is verified, not assumed.

Practice it

We built a DCSync scenario in GraphLattice Range so teams work this end to end, including the krbtgt double-reset decision under pressure.