DCSync is the technique that turns "I have the right privileges" into "I have every
password hash in the domain." It does not exploit a bug — it uses the legitimate
protocol that domain controllers use to replicate the directory between themselves.
If you can convince a DC that you are another DC asking to replicate, it will hand you
any account's secrets, including the one that matters most: krbtgt.
The replication protocol it abuses
Domain controllers keep their copies of the directory in sync using the
Directory Replication Service Remote Protocol (MS-DRSR), specifically
the DRSGetNCChanges call. When one DC needs updates from another, it asks
for the changed objects — and account objects include their secret attributes (password
hashes, Kerberos keys). This is normal, necessary behaviour: DCs must replicate password
data so any of them can authenticate any user.
DCSync simply makes that request from a machine that is not a domain controller. The target DC does not verify that the requester is really a DC — it checks only that the requester has the necessary replication rights. If you hold those rights, the DC replies with the secrets, exactly as it would to a peer.
The rights that permit it
DCSync requires specific extended rights on the domain object:
| Right | Purpose |
|---|---|
| DS-Replication-Get-Changes | Replicate standard directory data |
| DS-Replication-Get-Changes-All | Replicate secret attributes — the one that yields hashes |
| DS-Replication-Get-Changes-In-Filtered-Set | Sometimes needed depending on configuration |
By default these belong to Domain Admins, Enterprise Admins, and domain controllers. But they are just ACEs on the domain object, so anyone who can write that DACL — or who has been granted these rights directly — can DCSync without being a full admin. That is a common BloodHound finding: a non-admin principal that happens to hold replication rights is a straight line to the whole domain.
This is why granting DCSync rights is so sensitive. It looks like a narrow, technical
permission, but it is functionally equivalent to Domain Admin, because it lets you pull
the krbtgt hash and forge Golden
Tickets at will.
What you extract
| Target | Why it matters |
|---|---|
| krbtgt hash | The key that signs every TGT — enables Golden Tickets and permanent domain persistence |
| Domain Admin hashes | Direct pass-the-hash / overpass-the-hash to full control |
| All user hashes | The complete credential set for offline cracking and lateral movement |
| Machine account hashes | Enable Silver Tickets and further attacks |
| Trust keys | The inter-domain keys used to cross trusts |
Why it is quiet
Note what DCSync does not do: it never logs in to the DC interactively, never
runs code on it, and never touches NTDS.dit on disk. The whole operation is a
legitimate-looking replication request over the network, which is what makes DCSync both
powerful and relatively quiet compared to dumping the database file directly. The tooling
that issues that request — Impacket's secretsdump, NetExec, and Mimikatz — and the exact
commands are in the Vulns & Misconfigs section under
DCSync.
DCShadow — the write-side cousin
Worth a mention. Where DCSync reads via replication, DCShadow writes via replication: it registers a rogue domain controller long enough to push malicious changes (like adding a SID to a group, or setting an attribute) that then replicate to the real DCs as if legitimate. It is a stealthy persistence and manipulation technique built on the same protocol trust.
Detection and defence
| Control | Effect |
|---|---|
| Audit replication rights on the domain object | Only DCs and top-tier admins should hold Get-Changes-All; anything else is a finding |
| Monitor DRSGetNCChanges from non-DCs | A replication request from an IP that is not a domain controller is the primary signal |
| Rotate krbtgt twice after any DA compromise | Invalidates Golden Tickets that a DCSync of krbtgt would enable |
| Tier-0 protection | Keep the accounts that legitimately hold replication rights off lower-tier systems |
| Alert on new/unknown DC objects | Catches DCShadow's rogue-DC registration |
The takeaway
DCSync is the payoff step of most domain compromises: once you hold replication rights —
whether by becoming Domain Admin, or by finding a non-admin principal that was granted
them via an ACL — you ask a domain controller to replicate secrets to you and it
complies, because that is its job. The prize is the krbtgt key, which
converts a one-time compromise into durable, forgeable control of the domain. Treat
replication rights as equivalent to Domain Admin, monitor for replication from
non-DCs, and rotate krbtgt properly after any incident. The tools are in
theToolkit
Vulns & Misconfigs (Impacket secretsdump, NetExec, Mimikatz), and
what you do with the krbtgt hash afterward is on the
Ticket Attacks page.