DCSync: How Attackers Steal Every Password in Your Domain — and How to Stop Them

The domain controller received a replication request at 11:23 PM on a Tuesday. It authenticated the requestor, confirmed the replication rights, and handed over the NTLM hashes for every account in the domain — including krbtgt. The requestor wasn’t another domain controller. It was a compromised workstation running Mimikatz.

That’s DCSync. No code execution on the DC. No LSASS access. No alerts fired. Just a legitimate-looking replication request that walked out with every credential in your environment.

TL;DR

• DCSync impersonates a domain controller to request password hashes via Active Directory replication
• Only requires an account with “Replicating Directory Changes” rights — not Domain Admin
• Tools: mimikatz lsadump::dcsync, impacket-secretsdump
• Detection relies on Event ID 4662 with specific replication GUIDs — but only if Directory Service auditing is enabled (it’s off by default)
• Network-level detection is possible: DRSUAPI traffic from non-DC hosts is always suspicious
• Mitigations: audit and remove unnecessary replication rights, enable Protected Users for krbtgt equivalent accounts

Why DCSync Is Different from Other Credential Attacks

Most credential dumping techniques require code execution on the target system. LSASS dumping means touching the domain controller’s memory directly — risky, noisy, and increasingly caught by EDR. DCSync sidesteps all of that.

Active Directory uses a protocol called MS-DRSR (Directory Replication Service Remote Protocol) to synchronize data between domain controllers. When a new DC joins the domain, it uses this protocol to pull the entire directory — including password hashes. The protocol is fundamental to how AD works and cannot be disabled.

DCSync abuses this. An attacker with the right permissions sends a replication request as if they were a new domain controller. The real DC validates the permissions, sees nothing unusual, and hands over the requested data. The attacker never needs to log into the DC, never touches LSASS, and leaves no traces on the DC itself — only in its audit logs.

The attack was popularized by Mimikatz in 2015 but remains one of the highest-value techniques in AD environments today, frequently seen as the final step before a full domain takeover.

The Attacker’s Perspective

What Permissions Are Required

DCSync requires an account with at least one of these extended rights on the domain object:

Both the first two rights are needed to dump password hashes. An attacker who compromises a Domain Admin account has them automatically. But the dangerous scenario is when these rights have been delegated to non-admin accounts — a misconfiguration that’s more common than it should be, and hard to spot without explicit auditing.

# Find accounts with replication rights (run as domain user)
# Look for accounts outside of Domain Admins / Enterprise Admins
Get-ObjectAcl -DistinguishedName "DC=corp,DC=local" -ResolveGUIDs |
  Where-Object { $_.ActiveDirectoryRights -match "Replicat" } |
  Select-Object IdentityReference, ActiveDirectoryRights

BloodHound will also surface these as DCSync edges — any path from a compromised account to a node with these rights is a DCSync path. See BloodHound: Practical Guide to AD Attack Paths for how to hunt these edges.

Performing DCSync with Mimikatz

# Dump a single account's hashes (stealthy — fewer log entries)
lsadump::dcsync /domain:corp.local /user:Administrator

# Dump all accounts — generates significant log volume
lsadump::dcsync /domain:corp.local /all /csv

# Target krbtgt specifically — enables Golden Ticket creation
lsadump::dcsync /domain:corp.local /user:krbtgt

The krbtgt account is the most dangerous target. Its hash is used to sign all Kerberos tickets in the domain. With the krbtgt hash, an attacker can forge Golden Tickets — valid Kerberos TGTs for any user, with any group membership, valid for any length of time. This is the full domain compromise.

Mimikatz uses LDAP to identify the target, then DRSUAPI (the replication protocol) to pull the credentials. The traffic goes from the attacker’s machine to the DC — not from the DC outward.

Performing DCSync with Impacket

# Remote DCSync — runs entirely from the attacker's machine
impacket-secretsdump corp.local/Administrator:'Password123!'@dc01.corp.local

# Using hash instead of password (combined with Pass-the-Hash)
impacket-secretsdump -hashes :<ntlm_hash> corp.local/Administrator@dc01.corp.local

# Dump only the domain hashes, not local SAM
impacket-secretsdump -just-dc corp.local/Administrator:'Password123!'@dc01.corp.local

Impacket’s approach differs slightly from Mimikatz: it uses SMB first (authentication), then DRSUAPI for the actual replication. This means it requires an open SMB connection to the DC, which is worth noting for network-level detection.

The -just-dc flag limits output to domain hashes, reducing noise and making it faster in large environments. Attackers targeting specific accounts often combine this with Mimikatz’s single-user approach to minimize log volume.

What DCSync Leaves Behind

Detection depends entirely on having the right audit policy enabled. Without it, DCSync leaves nothing in Windows event logs.

Prerequisite: Enable Directory Service Auditing

By default, Audit Directory Service Access is disabled on domain controllers. Enable it via Group Policy:

Computer Configuration → Windows Settings → Security Settings →
Advanced Audit Policy Configuration → DS Access →
Audit Directory Service Access → Success

Without this policy, Event ID 4662 is never generated and DCSync is effectively invisible to log-based detection.

Event ID 4662 — The Core DCSync Signature

When DCSync runs, the DC generates Event ID 4662 (An operation was performed on an Active Directory object) for each replication request. The key fields:

The replication GUIDs that indicate credential access:

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}

A single 4662 event with AccessMask: 0x100 and one of these GUIDs from a non-DC account is a high-confidence DCSync detection.

Correlating 4662 with 4624

One 4662 event doesn’t tell you where the request came from. To identify the source IP, correlate with Event ID 4624 (logon) on the same DC using the Logon ID:

1. Find the 4662 event → note the SubjectLogonId
2. Find the 4624 event with matching TargetLogonId → this contains the source IpAddress

This correlation tells you: the request came from this IP, authenticated as this account, at this time. That’s enough to scope the incident.

Building the Detections

Sigma Rule: DCSync via Non-DC Account

title: DCSync Attack - Replication Rights Abuse by Non-DC Account
id: a7c4e8f9-2b3d-4e5f-8a9b-1c2d3e4f5a6b
status: stable
description: >
  Detects DCSync attacks by monitoring for Active Directory replication
  requests using extended rights GUIDs from accounts that are not
  Domain Controllers.
references:
  - https://attack.mitre.org/techniques/T1003/006/
  - https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_dcsync.yml
author: HiveSecurity
date: 2026/04/18
tags:
  - attack.credential_access
  - attack.t1003.006
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    AccessMask: '0x100'
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes-All
      - '89e95b76-444d-4c62-991a-0facbeda640c'  # DS-Replication-Get-Changes-In-Filtered-Set
  filter_dc_accounts:
    # Exclude legitimate domain controller machine accounts
    SubjectUserName|endswith: '$'
  filter_msol:
    # Exclude Azure AD Connect sync accounts (common false positive)
    SubjectUserName|startswith: 'MSOL_'
  condition: selection and not 1 of filter_*
falsepositives:
  - Azure AD Connect accounts with sync permissions (add to filter_msol)
  - Third-party AD sync tools with replication rights
  - Legitimate backup/monitoring tools with replication rights
level: critical

This is a critical severity rule because in a properly configured environment, the only accounts that should trigger it are domain controllers (filtered out) and Azure AD Connect sync accounts (also filtered). Any remaining hit is almost certainly malicious or a significant misconfiguration.

Sigma Rule: Suspicious Replication Rights Assignment

Catch the setup phase — when an attacker grants replication rights to a compromised account:

title: Replication Rights Granted to Non-Default Account
id: b8d5f9a1-3c4e-5f6a-9b0c-2d3e4f5a6b7c
status: experimental
description: Detects when DS-Replication rights are added to an account that shouldn't have them
author: HiveSecurity
date: 2026/04/18
tags:
  - attack.persistence
  - attack.t1098
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136  # Directory Service Object Modified
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
    ObjectDN|contains: 'DC='
  condition: selection
falsepositives:
  - Legitimate AD administrative changes
  - Azure AD Connect installation
level: high

Event ID 5136 fires when an AD object’s security descriptor changes. Filtering for changes to the domain root object (DC=) catches replication rights modifications directly.

Wazuh Rules

<!-- DCSync: replication rights exercised by non-DC account -->
<rule id="100210" level="15">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4662$</field>
  <field name="win.eventdata.accessMask">^0x100$</field>
  <field name="win.eventdata.properties">1131f6aa|1131f6ad|89e95b76</field>
  <field name="win.eventdata.subjectUserName" negate="yes">.*\$$</field>
  <field name="win.eventdata.subjectUserName" negate="yes">^MSOL_</field>
  <description>DCSync attack detected: replication rights exercised by non-DC account $(win.eventdata.subjectUserName)</description>
  <mitre>
    <id>T1003.006</id>
  </mitre>
</rule>

<!-- Replication rights granted to a new account -->
<rule id="100211" level="12">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^5136$</field>
  <field name="win.eventdata.attributeLDAPDisplayName">nTSecurityDescriptor</field>
  <field name="win.eventdata.objectDN">DC=</field>
  <description>Active Directory domain object security descriptor modified - possible replication rights change</description>
  <mitre>
    <id>T1098</id>
  </mitre>
</rule>

Rule 100210 is level 15 — Wazuh’s maximum. In a production environment this should page immediately.

Microsoft Sentinel KQL

Hunt query — find DCSync in historical logs:

SecurityEvent
| where EventID == 4662
| where AccessMask == "0x100"
| where Properties has_any (
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
    "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
    "89e95b76-444d-4c62-991a-0facbeda640c"
)
| where SubjectUserName !endswith "$"
| where SubjectUserName !startswith "MSOL_"
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName,
          SubjectLogonId, AccessMask, Properties
| sort by TimeGenerated desc

Correlate with source IP (join with 4624):

let dcsync_events = SecurityEvent
| where EventID == 4662
| where AccessMask == "0x100"
| where Properties has_any (
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
    "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
)
| where SubjectUserName !endswith "$"
| project TimeGenerated, Computer, SubjectUserName, SubjectLogonId;
let logon_events = SecurityEvent
| where EventID == 4624
| project LogonId = TargetLogonId, IpAddress, WorkstationName, LogonTime = TimeGenerated;
dcsync_events
| join kind=leftouter logon_events on $left.SubjectLogonId == $right.LogonId
| project TimeGenerated, Computer, SubjectUserName, IpAddress, WorkstationName
| sort by TimeGenerated desc

This join gives you the source IP of the DCSync request — the attacker’s machine — which is the critical piece for scoping and containment.

Network-Level Detection

Log-based detection requires the right audit policy. Network detection doesn’t.

DRSUAPI traffic from a non-DC host is always anomalous. Domain controllers use this protocol to talk to each other — workstations and member servers never should. This can be detected at the network level:

• Source IP is not a known DC + destination port 135 (RPC endpoint mapper) to a DC = investigate
• Firewall/NDR alert: DRSUAPI calls (RPC interface UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2) from non-DC hosts
• Zeek/Suricata: alert on dce_rpc connections to domain controllers from unexpected sources

This provides detection even if audit logging is misconfigured or disabled — which is exactly when it matters most.

Reducing the Attack Surface

Audit replication rights now. Run the PowerShell query above and verify that only Domain Controllers, Enterprise Admins, and your Azure AD Connect account have replication rights. Anything else is a finding.

Remove unnecessary delegations. A frequent source of DCSync paths is helpdesk or backup accounts that were granted replication rights years ago and never reviewed. These persist silently until BloodHound or an attacker finds them.

Protect krbtgt. Enable the Protected Users security group for krbtgt-equivalent accounts where possible. While krbtgt itself has technical constraints that prevent it from being in Protected Users, understanding the blast radius of its compromise should drive your detection investment here.

Regularly reset krbtgt. Microsoft recommends resetting the krbtgt password twice (due to how its password history works) at least annually. After a DCSync incident, this is mandatory — it invalidates all Golden Tickets derived from the compromised hash.

Tier your administration. If Domain Admin credentials never touch workstations or member servers, a compromised workstation can’t harvest credentials with DCSync rights. Tiered administration (Tier 0 = DCs only, Tier 1 = servers, Tier 2 = workstations) limits the blast radius of any single compromise.

What You Can Do Today

1. Enable Directory Service auditing — without this, DCSync is invisible. Group Policy → Advanced Audit Policy → DS Access → Audit Directory Service Access → Success. Deploy to all domain controllers now.
2. Run the replication rights audit — execute the PowerShell query and review every result that isn’t a DC or known sync account.
3. Deploy the Sigma rules — the DCSync rule is critical severity and should have near-zero false positives in a properly configured environment.
4. Run the Sentinel KQL hunt — query your last 90 days of DC logs for DCSync patterns. If you find hits, treat it as an active incident.
5. Test your detection — if you have a lab environment, run lsadump::dcsync /domain:lab.local /user:krbtgt and verify your SIEM catches it. Detection you haven’t tested is detection you don’t have.

Related Posts

• Pass-the-Hash & Pass-the-Ticket: How Attackers Move Laterally — the lateral movement techniques that often precede DCSync in an attack chain
• LSASS Dumping Techniques — alternative credential access path that DCSync is designed to replace
• Kerberoasting: A Deep Dive — another credential attack that targets service accounts and shares the AD abuse pattern
• BloodHound: Practical Guide to AD Attack Paths — how to find DCSync paths in your environment before attackers do
• AD Attack Chains: Initial Access to Domain Admin — where DCSync fits in the full domain compromise chain
• Active Directory Attacks Guide — complete map of AD attack techniques

Sources

• MITRE ATT&CK T1003.006 — DCSync
• The Hacker Recipes — DCSync
• NCC Group — Defending Your Directory: Securing AD Against DCSync
• Elastic Detection Rules — DCSync Replication Rights
• Splunk Security Content — AD Replication Request by User Account
• Black Lantern Security — Detecting DCSync
• Netwrix — DCSync Attack Explained