BIPI
BIPI

DCSync: The Replication Right That Becomes Domain Compromise

Cybersecurity

DCSync is not an exploit. It is the legitimate Active Directory replication protocol abused by anyone holding two specific rights. We cover the detection that makes DCSync impossible to use undetected.

By Arjun Raghavan, Security & Systems Lead, BIPI · December 9, 2024 · 7 min read

#dcsync#active-directory#detection

DCSync is not a vulnerability. It is the Microsoft Directory Replication Service Remote Protocol (MS-DRSR) used by domain controllers to replicate the directory among themselves. Anyone holding the Replicating Directory Changes and Replicating Directory Changes All extended rights on the domain object can request a replication, including all password hashes. There is no exploit, no patch, no workaround. The defense is making sure those rights belong only to domain controllers.

How attackers run it

DCSync is one command from any account holding the rights. The two most common ways to acquire them are exploiting a stale ACL granting them to a non-DC account, or relaying NTLM auth to LDAP and using --escalate-user to add them.

  • Mimikatz: lsadump::dcsync /domain:corp.local /user:krbtgt pulls the krbtgt hash. With that, the attacker forges Golden Tickets indefinitely.
  • secretsdump.py -just-dc-ntlm domain/user:pass@dc01 dumps every user hash in the domain via DCSync without dropping anything on the DC.
  • NetExec: nxc ldap dc01 -u user -p pass --bloodhound -c All has built-in DCSync via -M dcsync. Scriptable across multiple targets.
  • BloodHound's DCSync edge identifies any account with the rights. The query: MATCH (n)-[:DCSync|GetChanges|GetChangesAll]->(d:Domain) RETURN n.name, d.name. Anything other than DCs in the result is a finding.

The most common path to DCSync rights in a mature environment is the Azure AD Connect / Entra Connect service account, which is granted GetChanges and GetChangesAll for password hash sync. If that account or its credentials are compromised, DCSync follows immediately. The second most common path is a forgotten 2014 backup product that needed replication rights and was never decommissioned.

What defenders see

DCSync produces a specific 4662 event on the domain controller. The catch is that 4662 is high-volume and most teams do not log it because of the noise.

  • Event ID 4662 with Properties containing the GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes) or 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All) is a DCSync.
  • The high-fidelity filter: 4662 with those GUIDs where the SubjectUserName is not a domain controller computer account. Legitimate replication is DC to DC. Anything else is hostile or a configuration mistake.
  • Combine with Sysmon Event 3 (network connection) to a DC on TCP 135 / dynamic RPC ports from a non-DC source. DCSync requires RPC to the DC's NTDS interface. The combination of network plus 4662 is conclusive.
  • Microsoft Defender for Identity has a built-in Suspected DCSync attack detection that fires on this exact pattern. If you run MDI, this is one of the alerts to never tune down.

Remediation

DCSync defense is detection, because the rights themselves cannot be removed without breaking the directory. The objective is making every DCSync visible.

  1. Audit the domain object's DACL: dsacls 'DC=corp,DC=local'. List every ACE with DS-Replication-Get-Changes or All. The result should be the standard SYSTEM, Enterprise Admins, Domain Admins, and Enterprise Domain Controllers entries plus your documented sync account.
  2. Remove any non-default replication ACEs. For each, find the application owner and migrate to a least-privilege alternative or document an exception.
  3. Enable Audit Directory Service Access at Success and Failure, then collect 4662 events centrally. Filter to the two replication GUIDs to manage volume.
  4. Build a SIEM rule: 4662 with replication GUID and SubjectUserName not in {list of DC computer accounts and approved sync account}. This is one of the highest-fidelity AD detections you can deploy.
  5. Rotate krbtgt twice (with at least 24 hours between rotations) on any suspicion of DCSync exposure. The second rotation invalidates Golden Tickets forged with the krbtgt hash from the first rotation.
  6. Treat the Entra Connect server as tier-0. It holds DCSync rights. It is a domain controller in everything but name.

After this hardening, every DCSync produces a high-fidelity alert. The attack is not blocked, but it is no longer covert, and the detection-to-response time falls from months to minutes. That is the actual security outcome.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.