DCSync attack — how it works, why it’s dangerous, and how to stop it

Imagine an attacker who never needs to touch a Domain Controller’s disk, never needs to “dump” NTDS.dit, and yet walks away with password hashes for any account in your domain — including the krbtgt account used to forge Kerberos tickets. That’s exactly what a DCSync attack lets them do.

What is DCSync?

DCSync is a post‑exploitation technique that abuses Active Directory’s legitimate replication APIs (the Directory Replication Service / DRS Remote Protocol) to request credential material (password hashes, Kerberos keys, and other sensitive attributes) from a Domain Controller as if the attacker were another DC. It was popularized in tools like Mimikatz and is tracked by MITRE as sub‑technique T1003.006 (DCSync). attack.mitre.org+1

How it works — the technical nutshell

1. Active Directory DCs use DRS to replicate account attributes between controllers. The protocol expects requests from trusted replication partners.
2. An attacker who controls an account with replication rights (for example: Replicating Directory Changes, Replicating Directory Changes All, or a high‑privilege account such as a Domain Admin) can call DRS APIs remotely and demand attribute values for users — including unicodePwd, ntHash, and Kerberos key material.
3. Tools (Mimikatz, Impacket scripts, custom code) can simulate a DC and perform these calls remotely; the target DC responds and hands over the secrets without needing local file access.

Why it’s so dangerous

• Complete credential exposure: Attackers can extract NTLM hashes and Kerberos keys for any account, including service accounts and high‑privilege users.
• Golden Ticket enablement: Stealing the krbtgt account keys lets attackers create forged Kerberos Ticket Granting Tickets (Golden Tickets), granting virtually persistent, undetectable domain access.
• No on‑disk artifacts required: Since the attack uses legitimate replication APIs, it can evade some controls that look for file‑based credential dumps. Detection must therefore focus on anomalous replication behaviour.

Typical attack chain (example)

1. Initial foothold on a workstation or server.
2. Credential or privilege escalation to an account that has replication rights or Domain Admin.
3. Run DCSync (via Mimikatz/Impacket or custom code) targeting a DC and request sensitive attributes.
4. Use stolen hashes/keys for lateral movement, persistence (Pass‑the‑Hash, Golden Ticket), or domain takeover.

Detection — what defenders should look for

Because DCSync leverages normal replication APIs, detection relies on logging, correlation, and baselining:

• Windows event correlation: On the targeted DC, correlate Security Event 4624 (Logon) with 4662 (Directory Service Access) or 5136/5137 (object modifications) using the LogonId — DCSync often appears as a network logon (Logon Type 3) followed by directory object access events. Finding a non‑DC host performing replication‑style access is highly suspicious.
• Monitor replication rights & unusual principals: Alerts when non‑DC machines or low‑privilege accounts suddenly perform replication actions or when an account that never acted as a replication source begins doing so. Elastic/other SIEMs provide prebuilt rules for this.
• Audit DACL changes and privileged group changes: Attackers sometimes add privileges or modify ACLs to grant replication rights — monitor for these changes.

(Important note: Events like 4662 may be noisy or disabled by default — you must enable advanced AD auditing to capture meaningful data.)

Prevention & hardening — practical steps

1. Least privilege for replication: Only domain controllers and very few dedicated service accounts should have Replicating Directory Changes / Replicating Directory Changes All rights. Remove replication privileges from user/service accounts wherever possible.
2. Tiered admin model: Separate accounts and workstations for high‑privilege administration (PAM/Red/Blue tiers) so compromises of user workstations don’t lead to domain‑privilege escalation.
3. Strong monitoring & alerting: Implement SIEM rules that flag first‑time replication activity, correlation of 4624+4662 with non‑DC source IPs, and unexpected access to krbtgt or other sensitive objects. Use vendor/OSS detection content (Elastic, SentinelOne, vendor playbooks).
4. Protect and rotate krbtgt when necessary: If compromise is suspected (or as part of recovery), reset the krbtgt account password twice (waiting the recommended interval between resets) so old Kerberos keys are removed from history — this invalidates forged TGTs. Microsoft documents and community guidance explain doing two resets with the appropriate wait (default >10 hours) to ensure replication/KS lifetimes are handled. Plan this carefully — it impacts authentication infrastructure.
5. Limit admin tools & monitor for Mimikatz/Impacket usage: Block or alert on known offensive tool behaviour and suspicious use of RPC/DRS APIs from endpoints.
6. Harden service accounts and rotate secrets: Use Managed Service Accounts, reduce reuse of credentials, and rotate high‑value secrets frequently. Consider LAPS for admin workstations and strong PAM tooling.

Incident response checklist (if you detect DCSync)

1. Isolate the source (host/account) of the replication request — use correlated 4624/4662 logs to find source IP / LogonId.
2. Contain compromised accounts/hosts: Disable or reset credentials of the suspected account(s); isolate affected workstations/servers from the network.
3. Assess scope: Determine which accounts were requested/replicated — did attacker target only a subset, service accounts, or krbtgt?
4. If krbtgt was exposed, plan a krbtgt rotation: Follow Microsoft guidance — reset krbtgt twice with the recommended wait period, and test authentication across AD‑integrated services (this can cause service disruptions if not planned).
5. Full investigation & remediation: Hunt for initial access vectors, lateral movement artifacts, and persistence; rebuild or thoroughly clean compromised systems as required.
6. Post‑incident hardening & lessons learned: Close permission gaps, improve logging and detection, and run red/blue exercises to validate improvements.

Final takeaways

• DCSync is especially insidious because it abuses legitimate AD functionality and can yield domain‑wide credential compromise without an on‑disk credential dump.
• Defend with a combination of least privilege, tiered admin models, strong auditing/alerting, and careful incident planning (including krbtgt rotations when necessary).