DCSync (T1003.006) is a credential access sub-technique for Windows. Adversaries abuse a domain controller's application programming interface to simulate the replication process from a remote domain controller. Done with the right permissions, it returns password data from Active Directory without logging on to a domain controller or touching its files.
How attackers use it
MITRE says members of the Administrators, Domain Admins and Enterprise Admins groups, and computer accounts on the domain controller, can run DCSync to pull password data. That may include current and historical hashes of valuable accounts such as KRBTGT and Administrators. Those hashes can then support a Golden Ticket for Pass the Ticket, or a password change as covered under Account Manipulation. DCSync is included in the lsadump module of Mimikatz, which also has NetSync for a legacy replication protocol.
The key point for defenders is that replication is a legitimate feature. Real domain controllers do it all the time. The question is who is asking.
How to detect it
MITRE's analytic is about unauthorized use of the Directory Replication Service from endpoints that are not domain controllers.
Concrete ways to do that:
- Log directory service access on domain controllers (Security Event ID 4662) and look for the replication rights, Replicating Directory Changes and Replicating Directory Changes All, requested by an account that is not a domain controller computer account.
- Watch network traffic. DRS calls from a workstation or member server to a domain controller are unusual. Replication should be between domain controllers.
- Review who holds the replication rights. A change to those permissions is itself a detection point.
Keep an allowlist of the accounts that are expected to replicate. Directory synchronization products you run on purpose belong on that list, so find them before you alert.
How to reduce the risk
MITRE lists:
- Active Directory Configuration: manage the access control list for Replicating Directory Changes and other permissions tied to domain controller replication.
- Privileged Account Management: do not put domain accounts into local administrator groups across systems unless tightly controlled, and limit privileged account use across administrative tiers.
- Password Policies: complex, unique local administrator passwords across systems.
In practice, review the replication permissions at the domain root. Regular user accounts should never hold them. Service accounts for sync tools should hold them only where needed, with strong passwords and no interactive logon.
Who should be allowed to replicate
In a healthy domain, the accounts that need replication rights are few: the domain controllers themselves and perhaps a directory synchronization service. Everything else is a mistake or an exposure.
Review the permissions at the domain root and list every account and group holding the replication rights. Anything you cannot explain is a finding. Look especially for service accounts that were granted the rights for a project that has since ended, and for broad groups with accidental nesting.
Treat the group memberships MITRE names, Administrators, Domain Admins and Enterprise Admins, as the high-risk tier. Keep those groups small. Use separate accounts for administration, and do not use them for email or browsing.
Building the alert
The directory service access event on a domain controller records the replication rights that were requested, along with the account name. A rule that fires when the requesting account is not on your approved list is simple and high in value. Because real replication between domain controllers is constant, filter on account type, so computer accounts of domain controllers are excluded and everything else triggers.
Support it with a network rule. Directory replication calls from a host that is not a domain controller are the other half of the same event.
What a hit means
A hit means the requesting account holds, or has obtained, rights that allow it to read password data for the domain. The response has two parts. Contain the account and the host the request came from, and then assume the secrets it could read are exposed. MITRE names the KRBTGT account among the hashes available, which is why recovery plans include resetting that account in the proper sequence, and why teams should rehearse it ahead of time.
Linking it to the wider picture
DCSync often follows other credential access. An adversary who already holds a privileged account uses it to get everything else. So when you see a DCSync alert, look back for the access that gave the account its rights. That earlier event is the one that tells you how they got in.
Check your own environment
- Who holds replication rights on the domain object? Export the ACL with your directory tooling and compare it to your approved list.
- Are directory service access events enabled on domain controllers?
- Can workstations reach domain controllers on directory replication ports? Segmentation should restrict that to what you need.
- After a suspected exposure, do you know how you would reset KRBTGT twice? Practice the procedure before you need it.
Quick check
Why is DCSync hard to spot at the file level?
It uses a legitimate replication API, so nothing is copied from the domain controller's disk. Detection has to focus on who requested replication and from where.
Which accounts can run DCSync according to MITRE?
Members of the Administrators, Domain Admins and Enterprise Admins groups, and computer accounts on the domain controller.
