DCSync: who really holds replication rights on your domain?
A DCSync attack needs no code on a domain controller and no access to NTDS.dit: two permissions on the domain root are enough. With them, the credentials of every account, including krbtgt, can be pulled remotely. Checking who holds those rights is one of the most valuable controls in an AD audit.
How it works
Domain controllers replicate with each other over the MS-DRSR protocol. An account with the right permissions can impersonate a domain controller and request replication of the secrets of one account, or all of them. No local elevation is needed: the operation looks like legitimate replication.
The permissions involved are extended rights set on the domain root object:
| Right | GUID |
|---|---|
| DS-Replication-Get-Changes | 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 |
| DS-Replication-Get-Changes-All | 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 |
| DS-Replication-Get-Changes-In-Filtered-Set | 89e95b76-444d-4c62-991a-0facbeda640c |
The first two combined give access to secret data, meaning password hashes.
Legitimate holders
By default, the domain root grants these rights to:
- the Domain Controllers and Enterprise Domain Controllers groups;
- Administrators, Domain Admins and Enterprise Admins, directly or through inheritance;
- Enterprise Read-only Domain Controllers, with the "Get-Changes" right only.
The Microsoft Entra Connect sync account (an MSOL_ account in an express installation) is usually added, because password hash synchronisation needs these rights. That is legitimate, but the account and the server hosting it become tier 0 assets and must be protected accordingly.
Finding unexpected holders
The review means reading the domain root ACL and isolating any entry that grants these GUIDs to a principal outside the list above.
$dn = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:$dn"
$acl.Access | Where-Object {
$_.ObjectType -in '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2',
'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
} | Select-Object IdentityReference, ObjectType, AccessControlType
Typical findings: an old sync account from a third-party directory tool, a service account of an identity management product, a group granted rights "temporarily" during a migration. Indirect rights matter too: a principal that can modify the root ACL (WriteDacl) can grant itself DCSync. Some older Exchange installations historically set this kind of permission; later cumulative updates addressed it, but the ACL should still be checked.
Key point. Any account capable of DCSync is equivalent to a domain administrator. Its password, its admin workstation and its monitoring must follow the same rules.
Detecting an attempt
With the Directory Service Access audit subcategory enabled and a suitable SACL on the domain root, domain controllers log event 4662 when these rights are exercised. The Properties field contains the GUID of the right used. The detection rule is then: 4662 with one of the replication GUIDs, from an account that is neither a domain controller computer account nor the known sync account. Identity threat detection tools can also flag replication requests coming from a machine that is not a domain controller.
What an audit checks
- The complete list of principals holding replication rights.
- Principals able to modify the domain root ACL.
- Protection of the Entra Connect sync account and server.
- Whether 4662 auditing and a matching alert rule are in place.