DCSync: How Attackers Steal Every Domain Password by Impersonating a Domain Controller

Most credential-theft techniques on Windows are noisy: you have to touch lsass.exe, drop a tool on a domain controller, or copy the NTDS.dit database off disk — all of which leave loud, detectable artifacts. DCSync sidesteps every one of them. Instead of stealing secrets from a domain controller, the attacker convinces a real DC to hand the secrets over using the same replication protocol that domain controllers use to sync with each other. No malware on the DC, no file access, no memory dump. Just a legitimate-looking network request that returns the NTLM hash — and often the Kerberos keys and password history — of any account you name, up to and including krbtgt.

How the attack actually works

Active Directory replicates directory data between domain controllers using the Directory Replication Service Remote Protocol (MS-DRSR). When one DC needs updated data — including secret attributes like password hashes — it calls DRSGetNCChanges against a peer. That RPC returns the requested objects, hashes included.

DCSync simply makes that same call from an attacker-controlled machine, pretending to be a domain controller. Windows doesn't check whether the caller is really a DC; it checks whether the caller has the right extended rights on the domain naming context:

• DS-Replication-Get-Changes (GUID 1131f6aa-...)
• DS-Replication-Get-Changes-All (GUID 1131f6ad-...) — this one unlocks the secret attributes
• DS-Replication-Get-Changes-In-Filtered-Set (situational)

The classic one-liner with Mimikatz looks like this:

lsadump::dcsync /domain:corp.local /user:krbtgt

Impacket's secretsdump.py does the same thing remotely, and it is the reason DCSync is a favorite prelude to a Golden Ticket: dump krbtgt, forge tickets, own the domain indefinitely.

Why it is so hard to catch

The request is valid AD traffic. On a busy domain, DCs replicate constantly, so a single extra DRSGetNCChanges blends into normal noise. The killers for defenders are:

• No DC-side tooling. The attacker runs from a workstation, so DC endpoint telemetry sees nothing unusual.
• Legitimate rights. If a compromised account already holds replication rights — or the attacker granted them via a stealthy ACL edit — the request is authorized.
• Over-permissive delegation. Years of "just make it work" changes leave service accounts, backup software, and even Exchange groups holding replication rights nobody remembers granting.

Detecting DCSync

The signal to hunt is a replication request coming from a security principal that is not a domain controller. On the DC's Security log, enable auditing of Directory Service Access and watch for Event ID 4662 where the Properties field references the replication GUIDs above and the Subject is not a machine account ending in $ that belongs to the Domain Controllers OU.

Rule of thumb: any account that is not a domain controller invoking DS-Replication-Get-Changes-All is either your backup product or an intrusion. You should be able to name every one of them.

Just as important as runtime detection is closing the exposure before it's used. Audit who actually holds replication rights on the domain root:

(Get-Acl "AD:\$((Get-ADDomain).DistinguishedName)").Access |
  Where-Object { $_.ObjectType -in @(
    '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2',   # Get-Changes
    '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'    # Get-Changes-All
  )} | Select-Object IdentityReference, ActiveDirectoryRights

Anything in that list that isn't Domain Controllers, Enterprise Domain Controllers, or Administrators deserves a hard question.

Hardening steps that hold up

1. Prune replication ACLs. Remove the extended rights from any account that doesn't strictly need them. Legacy Exchange installs and old sync tools are the usual offenders.
2. Protect privileged accounts. Put Domain Admins in the Protected Users group and enforce tiered administration so a workstation compromise never yields replication rights.
3. Rotate krbtgt — twice. If you suspect DCSync ever ran, reset the krbtgt password twice (24+ hours apart) to invalidate forged Golden Tickets.
4. Alert on 4662 for replication GUIDs from non-DC principals, and treat it as high severity.

Where WinSentinel fits

DCSync exploits configuration drift — rights that accumulated over years — far more than any zero-day. That's exactly the kind of quiet, easy-to-miss posture problem WinSentinel is built to surface. On a single machine, the free agent gives you the full audit power of all 33 modules with no limits: it inventories dangerous privilege and delegation exposures, flags cleartext credential and hash-theft risk (WDigest, LSASS protection, cached credentials), and maps findings to MITRE ATT&CK so the DCSync-adjacent weaknesses show up in plain language.

For organizations running many domain-joined machines, WinSentinel Pro adds fleet orchestration on top: a central node that manages agents, rolls compliance and posture up across every endpoint, and fires drift alerts the moment a node regresses — so the day someone quietly grants replication rights or disables an audit policy, you find out from a dashboard instead of from an incident. Catching the misconfiguration before it becomes a Golden Ticket is the whole game, and it starts with knowing exactly who can impersonate a domain controller.