What is DCSync?

Definition

DCSync is an Active Directory attack that abuses directory replication rights to request password hashes — including the all-powerful KRBTGT hash — from a Domain Controller, without ever logging into the DC.

It is MITRE ATT&CK T1003.006 (OS Credential Dumping: DCSync).

In simple terms:

If you can replicate, you can dump every password hash in the domain — without touching a DC.

---

Why DCSync Matters

• Lets attackers extract every domain hash including KRBTGT (enables Golden Tickets).
• Requires only specific replication permissions, not local admin on a DC.
• Easy to misgrant — many environments unintentionally grant these rights.
• Typically the last step before total domain takeover.

---

How DCSync Works

DCSync abuses the MS-DRSR protocol — the same protocol DCs use to replicate with each other. The attacker calls IDL_DRSGetNCChanges and asks the DC to send replicated data including secrets (hasMasterNCs, objectName, etc.).

Tools: Mimikatz (lsadump::dcsync), Impacket's secretsdump.py.

Required Permissions

To DCSync, an account needs:

• Replicating Directory Changes (DS-Replication-Get-Changes)
• Replicating Directory Changes All (DS-Replication-Get-Changes-All)
• (Sometimes) Replicating Directory Changes In Filtered Set

These are granted at the domain root by default to:

• Domain Admins
• Enterprise Admins
• Administrators
• Domain Controllers
• Read-only Domain Controllers (limited)

But they can be delegated to other accounts — and often are by mistake.

---

How Attackers Get DCSync Rights

• Member of Domain Admins / Enterprise Admins / Administrators (the obvious case).
• Delegated rights at the domain root for an integration product (Entra Connect, identity sync tools, backup products) — sometimes left granted to expired accounts.
• ACL backdoor planted by an earlier attacker.
• Compromised computer object that holds the rights.
• Misconfigured group membership.
• Service accounts running connectors (e.g., Microsoft Entra ID (formerly Azure AD) Connect MSOL_) often have replication rights.

---

Real-World Examples

1. Compromised Entra Connect Service Account

The MSOL_ account used by Microsoft Entra Connect has replication rights by design. Compromise of the Entra Connect server exposes this account, enabling DCSync against the domain.

2. Forgotten Delegation

An old identity sync product was granted replication rights years ago. The product was decommissioned, but the rights remained on a service account. Attacker compromises the account → DCSync.

3. Golden Ticket via DCSync

Attacker reaches Domain Admin, performs DCSync to get the KRBTGT hash, and forges Golden Tickets for persistence.

4. ACL Backdoor

After initial compromise, attacker grants DS-Replication-Get-Changes-All to a low-profile account at the domain root. Even if their original access is revoked, they retain DCSync persistence.

---

Defense Against DCSync

Audit Replication Rights

1. Enumerate all accounts with replication rights at the domain root:

(Get-Acl "AD:DC=corp,DC=local").Access |
  Where-Object {$_.ObjectType -in @(
    'GUID-of-DS-Replication-Get-Changes',
    'GUID-of-DS-Replication-Get-Changes-All'
  )}

(Tools like Get-DCSyncRights and BloodHound visualize these.)

2. Remove unnecessary delegations.
3. Document every legitimate replication right with owner.

Protect Replication Service Accounts

4. Vault Entra Connect / sync product credentials.
5. Rotate sync account passwords after personnel changes.
6. Restrict logon for sync accounts (no interactive logon).
7. Treat sync servers as Tier 0.

Cryptography & KRBTGT

8. Rotate KRBTGT twice per year — and twice consecutively after any DCSync incident.
9. Monitor KRBTGT password age and alert on staleness.

Detection

10. Detect DCSync by monitoring for DSRGetNCChanges traffic from non-DC sources.
11. Event ID 4662 with replication GUIDs from non-DC accounts.
12. Alert on ACL changes at the domain root.
13. Honeypot account with subtle replication rights and monitor for any use.

Tier 0 Discipline

14. Apply tiered admin model — DCSync is a Tier 0 capability.
15. PAWs and JIT for any account that legitimately needs replication rights.

---

DCSync Defense Checklist

• All accounts with DCSync rights inventoried?
• Unnecessary replication delegations removed?
• Entra Connect / sync accounts vaulted and protected?
• Sync servers treated as Tier 0?
• KRBTGT rotation schedule (twice per year)?
• DCSync detection (4662 + replication GUIDs) live?
• ACL change alerts at domain root?
• Honeypot replication-rights account configured?
• Forest recovery plan tested?

---

How Forestall Helps

Forestall computes effective DCSync rights across your forest, including:

• Direct grants on the domain root.
• Indirect grants via group membership (including nested).
• Computer / service account holders of these rights.
• Sync product accounts and their security posture.
• Attack paths from low-privilege identity → DCSync.

It surfaces high-leverage remediations (a single ACL fix often closes many paths) and tracks DCSync surface area over time.

---

Frequently Asked Questions

Do I need local admin on a DC to DCSync?

No — that's the danger. You only need the replication rights, which can be delegated remotely.

What's the difference between DCSync and DCShadow?

• DCSync — reads replicated data (extracts hashes).
• DCShadow — writes replicated data (injects malicious changes by registering a fake DC).

Does Microsoft consider DCSync a vulnerability?

It's working as designed (replication is necessary). The vulnerability is misgranted permissions. The fix is permission hygiene.

Does the Protected Users group help?

Not directly — DCSync uses replication APIs, not user authentication. The fix is at the ACL level.

How often should I audit replication rights?

Continuously is best; quarterly at minimum. They drift quickly with product installs and personnel changes.

---

Conclusion

DCSync is one of the most consequential AD attacks because it provides every password hash in the domain — including KRBTGT — without any local DC access. Defense requires careful auditing of replication rights, hardening of sync service accounts and servers, regular KRBTGT rotation, and detection of replication anomalies. Treat DCSync rights like Tier 0 admin: minimal, monitored, and reviewed continuously.