Detecting DCSync Attacks

DCSync is credential theft without touching the domain controller. Instead of dumping LSASS on a DC, the attacker asks a DC for password hashes using the same replication protocol domain controllers use to sync with each other — and if they hold the right replication permissions, the DC hands over the hashes of anyone, including krbtgt and domain admins. The detection is precise: a replication request from something that is not a domain controller. This guide ships that signal and the least-privilege fix.

DCSync maps to MITRE ATT&CK T1003.006 — OS Credential Dumping: DCSync, yielding T1078 — Valid Accounts at the highest level. It sits alongside Kerberoasting, NTLM relay, and AD CS abuse in the Active Directory attack surface — and it is often the final step after them.

What is a DCSync attack?

Domain controllers keep each other in sync by replicating directory data, including secrets, over the MS-DRSR protocol. DCSync abuses that: an attacker who holds the replication extended rights sends a replication request to a DC as if they were another DC, and the DC returns the requested account’s password hashes — NTLM hashes, Kerberos keys, everything. No malware runs on the DC; it is a legitimate protocol used illegitimately.

The prize is usually krbtgt (whose hash forges Golden Tickets) or domain admin accounts. DCSync is typically the payoff after an earlier escalation granted the replication rights, which is why detecting the replication request itself is such a valuable backstop.

What does DCSync look like, and how is it reached?

The unifying fact: replication is a DC-to-DC operation, so a replication request from a workstation or a user account is definitionally abnormal. That is the whole detection.

How to detect DCSync

Enable auditing of directory service access, then alert on the replication request from a non-DC account.

title: Directory Replication Requested by a Non-DC Account
id: 7a3d1f92-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes-All
  filter_dc:
    SubjectUserName|endswith: '$'                # exclude DC machine accounts
  filter_known_dcs:
    SubjectUserName|contains: 'DC0'              # tune to your DC naming/allowlist
  condition: selection and not (filter_dc and filter_known_dcs)
falsepositives:
  - Domain controllers (allowlist their machine accounts precisely)
  - Approved directory-sync services (e.g. Entra Connect) — allowlist explicitly
level: high

How to test your DCSync detection

In an isolated AD lab you own:

1. Grant a test account the replication rights and run a DCSync tool against a lab DC; confirm Event ID 4662 with the replication GUIDs fires and the rule alerts.
2. Confirm normal DC-to-DC replication (from allowlisted machine accounts) does not alert.
3. Confirm an approved sync service, once allowlisted, stays quiet.
4. Verify the alert escalates when the target is krbtgt.

How to prevent DCSync

• Audit domain-object ACLs regularly (BloodHound flags dangerous replication rights).
• Alert on ACL grants of replication rights as a leading indicator.
• Harden the escalation paths that lead here — AD CS and NTLM relay.

Common DCSync detection mistakes

• Not auditing directory service access. No 4662, no detection.
• Alerting on all 4662. Filter to the replication GUIDs; allowlist DCs.
• Forgetting sync services. Entra Connect replicates legitimately — allowlist it.
• Missing the ACL-grant precursor. The rights are granted before they’re used.

DCSync detection checklist

1. Enable auditing of directory service access (Event ID 4662).
2. Alert on 4662 with the replication GUIDs (1131f6aa / 1131f6ad).
3. Allowlist domain controller machine accounts and approved sync services precisely.
4. Escalate when the targeted account is krbtgt or a domain admin.
5. Audit and remove replication rights from non-DC principals.
6. Monitor ACL changes on the domain object for granted replication rights.
7. Protect Tier 0 accounts; plan a double krbtgt reset for suspected DCSync.
8. Test with a lab DCSync and confirm normal replication stays quiet.

The takeaway

Detecting DCSync is a single high-fidelity rule: Event ID 4662 carrying the replication GUIDs from a non-domain-controller account, with your DCs and sync services allowlisted. Remove the replication rights from everything that isn’t a DC, and watch the ACLs that grant them. Continue with NTLM relay detection and AD CS abuse detection, or browse the full Detection Engineering pillar.