DCSync Attack: Finding and Fixing Replication Rights in Active Directory
- Chris Keim
- 12 hours ago
- 4 min read
In This Article:
DCSync doesn't require a foothold on a domain controller. It doesn't require touching NTDS.dit or running code on any server. All it takes is one account with the right to replicate directory data. From there, an attacker can pull every password hash in your environment across the network, silently, using tooling that looks like normal AD replication traffic.
This isn't theoretical, it's been used in high-profile breaches including SolarWinds and campaigns attributed to LAPSUS$.
This article is for AD administrators who want to understand what DCSync is, find out who has those rights in their environment, and lock it down. You don't need a pen testing background, just PowerShell and access to Active Directory.
How DCSync Works
Active Directory replication is a legitimate, essential process. When a password changes or a new user gets created, all domain controllers need to sync that update. The Directory Replication Service Remote Protocol (MS-DRSR) handles this via a function called GetNCChanges.
DCSync abuses that protocol. An attacker with the right permissions uses a tool like Mimikatz, Impacket's secretsdump.py, or DSInternals to impersonate a replication request. The target DC responds with password hashes, Kerberos keys, and password history, because it has no way to distinguish the malicious request from a legitimate one.
No code runs on the DC. No files get touched. The attacker just needs the right ACL entry and a network path to a domain controller.
The most dangerous outcome is obtaining the KRBTGT hash, which enables Golden Ticket creation, a forged Kerberos ticket that grants unrestricted domain access indefinitely.
Who Has DCSync Rights?
Two extended rights on the domain naming context object enable DCSync:
Replicating Directory Changes (DS-Replication-Get-Changes)
Replicating Directory Changes All (DS-Replication-Get-Changes-All)
Default principals that legitimately hold these rights:
Domain Controllers
Domain Admins
Enterprise Admins
Administrators (built-in)
AZure AD Connect account (If AAD Connect is deployed)
The defaults aren't the problem. The problem is delegation drift, backup agents, identity sync products, and application service accounts accumulate these rights over time, often with no documentation and no review. One notable example: running adprep /domainprep on Server 2016 silently added an ACE for Enterprise Key Admins in some environments. That group membership can grow in ways no one intended.
Any non-DC, non-default principal with these rights is a DCSync vector if that account gets compromised.
Finding DCSync Rights with PowerShell
This script queries the ACL on the domain object, filters out known-default principals, and surfaces everything else:
No elevated rights required, standard domain user access is enough to read the domain object ACL.
Interpreting Results
Azure AD Connect accounts (MSOL_ or AAD_), expected if you're running hybrid identity. Verify it's the actual sync account, secured appropriately (dedicated account, no interactive logon, MFA).
Service or application accounts, investigate. Common culprits are backup software and identity governance tools. Confirm the delegation was intentional and that the account is adequately protected.
Regular user accounts, treat as a critical finding. No standard user should have DCSync rights. Remove immediately and investigate how it happened.
Enterprise Key Admins, check whether adprep /domainprep was run on Server 2016 in your environment. Verify group membership and remove the ACE if nobody legitimately needs it.
Remediation
Remove unnecessary ACEs. For any principal without a documented, legitimate need for replication rights, remove the ACE on the domain object. You can do this in ADUC (View → Advanced Features → right-click domain → Properties → Security) or via Set-Acl in PowerShell. Understand the delegation before removing anything.
Protect accounts that legitimately need these rights. AAD Connect sync accounts should be treated as Tier 0 assets, dedicated, long random passwords, no interactive logon, monitored.
Rotate KRBTGT if you've had a confirmed incident. If you have reason to believe DCSync was used in your environment, rotate the KRBTGT password twice and audit for Golden Ticket activity.
Detecting DCSync Attacks in Your Environment
DCSync generates a consistent event pattern on domain controllers.
Event ID 4662: Operation performed on an object
This is the primary signal. When DCSync runs, the DC logs 4662 events for replication access on the domain object. Filter for:
Object Type: domainDNS
Properties GUIDs: 1131f6aa... or 1131f6ab...
Subject Account: any non-DC principal is suspicious
Event ID 4624: Logon
DCSync generates a Type 3 (Network) logon on the DC. Correlate TargetLogonId from 4624 with SubjectLogonId from 4662 to identify the source IP. If it's not a known DC, investigate.
Script prerequisites: Enable Audit Directory Service Access in your Default Domain Controllers Policy under Computer Configuration → Advanced Audit Policy Configuration → DS Access. Without it, 4662 events won't be generated.
Conclusion
DCSync is dangerous because it abuses something AD is designed to do. There's no exploit, no vulnerability to patch, just an attacker with the right ACL entry and a tool that speaks the replication protocol. The environments that get hurt are the ones where nobody looked at who has those rights and nobody was watching for replication traffic from unexpected sources.
Run the audit script. If you find non-default principals with DCSync rights, understand why they have them and remove what doesn't belong. Get Event 4662 logging in place so you know if someone is already using this technique in your environment.
If you haven't worked through your Kerberoasting and AS-REP Roasting exposure yet, check those posts, both of those attack paths can feed the privilege escalation chain that leads to DCSync.
Comments