·7 min read·Yeray Martín

DCSync Attack: How It Works, How to Execute, and How to Detect It

DCSync mimics DC replication to dump all AD password hashes without touching LSASS. How to find DCSync rights, execute the attack, and detect it in your environment.

DCSync is one of the cleanest credential dumping techniques in Active Directory assessments. No process injection. No code running on the domain controller. No LSASS handle. The attack mimics the DC replication protocol — DRSUAPI — to request password hashes directly from a domain controller, the same way a legitimate DC would replicate data from its peers. If you find an account with the right permissions, you can pull every NTLM hash in the domain from your own machine. Stealthy, reliable, and far more common than most defenders realize.

MITRE ATT&CK: T1003.006 — OS Credential Dumping: DCSync

How DCSync Works

Domain controllers replicate directory changes between each other using the Directory Replication Service (DRS) Remote Protocol — a Microsoft RPC interface built on top of DRSUAPI. When a DC needs to sync a password change from another DC, it calls DsGetNCChanges and requests all attribute changes for a given object, including the unicodePwd attribute containing the NT hash.

DCSync abuses this mechanism. An attacker with the right permissions issues the same DsGetNCChanges RPC call — authenticated over Kerberos — to a live domain controller and requests the password attributes for any account in the domain. The DC responds as if it were talking to a replication partner. No code runs on the DC. No memory is read. The DC willingly hands over the hash.

Two permissions control access to this functionality, both granted on the domain root object:

  • DS-Replication-Get-Changes — GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
  • DS-Replication-Get-Changes-All — GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2

Both are required. DS-Replication-Get-Changes-All is the critical one — it grants access to sensitive attributes including password hashes. Normally, only domain controllers, Domain Admins, and Enterprise Admins hold these rights. The problem is ACL misconfiguration: in mature Active Directory environments, these permissions accumulate on service accounts, delegation accounts, and legacy admin accounts through GPO changes, custom delegation, or administrative shortcuts applied years ago and never audited.

Finding DCSync Rights

The operative question is not whether DCSync exists — it is which non-DC accounts have replication rights on your target domain.

BloodHound: The built-in query "Find Principals with DCSync Rights" returns all accounts with both replication GUIDs on the domain root. Run it immediately after collection. Non-DC accounts in this list are a critical finding.

PowerView: Enumerate ACEs on the domain root object and filter for the replication GUIDs:

Get-ObjectAcl -DistinguishedName "DC=domain,DC=local" -ResolveGUIDs |
  Where-Object {
    $_.ObjectAceType -match "DS-Replication-Get-Changes"
  } |
  Select-Object IdentityReference, ObjectAceType, ActiveDirectoryRights

This returns every principal with either replication right. Cross-reference against the list of domain controllers — any principal not a DC and not explicitly in your whitelist is a finding.

LDAP direct query: Query the nTSecurityDescriptor of the domain root object using any LDAP client and parse the DACL for ACEs matching either GUID. This works without PowerShell or BloodHound in constrained environments.

ADscan runs this check automatically as part of attack graph analysis. After start_auth and enumeration, any account holding DCSync rights that is not a domain controller is flagged as a high-severity finding and surfaced in the attack graph with full path context — showing how reachable that account is from currently owned credentials. You see not just the misconfiguration but the distance from your current position to exploiting it.

Executing DCSync

Once you have credentials for an account with DCSync rights, execution is straightforward.

secretsdump (impacket): The standard remote approach. Authenticates to the DC and calls DsGetNCChanges over the network:

secretsdump.py domain/user:password@<DC-IP> -just-dc

The -just-dc flag restricts output to domain credentials only, skipping local SAM and LSA secrets. To target a specific account rather than dumping everything:

secretsdump.py domain/user:password@<DC-IP> -just-dc-user krbtgt

mimikatz: Run from a domain-joined machine or in memory on a compromised host:

lsadump::dcsync /domain:domain.local /all /csv
lsadump::dcsync /domain:domain.local /user:krbtgt

The /csv flag outputs in a parseable format. Target krbtgt first — that hash is the only prerequisite for a golden ticket.

Output: NTLM hashes for every account in the domain. The hashes are in the format you need directly — no further extraction required. The NTLM hash can be used immediately for pass-the-hash (PTH) against any service that accepts NTLM authentication.

KRBTGT hash: Forge golden tickets with Mimikatz kerberos::golden or impacket ticketer.py. A golden ticket gives you a valid Kerberos TGT for any user, for any service, with no expiration limit (configurable up to 10 years). This is indefinite persistence — even if the account you originally compromised has its password changed, the golden ticket remains valid until krbtgt is rotated twice.

Domain Admin hash: Immediate lateral movement via PTH to any system in the domain that accepts NTLM. Combined with KRBTGT, DCSync is the technique that ends the engagement.

ADscan runs DCSync natively — no impacket subprocess, no separate Python environment. Once the attack graph identifies an account with DCSync rights and you obtain credentials for that account during the assessment, ADscan executes DsGetNCChanges directly from the native stack. All harvested hashes are saved to the workspace automatically, linked to the finding, and included in the audit trail.

ADscan Workflow

The typical flow in an ADscan assessment:

  1. start_auth — authenticate against the domain using any credential type (user/pass, NTLM hash, Kerberos ticket)
  2. Attack graph analysis runs automatically — LDAP enumeration, ACL collection, trust mapping
  3. ADscan identifies accounts with DS-Replication-Get-Changes-All on the domain root that are not DCs
  4. Finding is flagged as high severity with full attack path context: which owned accounts can reach the DCSync-capable account, through how many hops, via which relationships

If credentials for a DCSync-capable account were obtained earlier in the assessment (through Kerberoasting, AS-REP roasting, credential in a share, ACL abuse chain), ADscan can execute DCSync directly from the shell:

dcsync

Hashes are stored in the workspace. No external tool required.

With ADscan PRO, adscan deliver generates the client-ready PDF with the DCSync finding documented: CVSS score, affected accounts, attack chain evidence, and remediation guidance. Hashes are redacted in the PDF; full credential data stays in the encrypted workspace. The report goes out the same day as the assessment.

Running internal AD assessments regularly? Request PRO beta access — free for 90 days in exchange for feedback.

Detection

DCSync generates a specific, detectable event when you know what to look for.

Event ID 4662 — Directory Service Access: Generated on the DC when a replication request is received. Filter for:

  • Object Type: domainDNS
  • Access Mask or Properties: GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All)

Exclude events where the account is a known domain controller machine account (these are legitimate replication events). Any other account triggering this event is a DCSync attempt — alert immediately.

Copy this XPath query directly into Windows Event Viewer or your SIEM:

<QueryList>
  <Query Id="0">
    <Select Path="Security">
      *[System[EventID=4662] and 
        EventData[Data[@Name='Properties'] and 
          (Data='1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')]]
    </Select>
  </Query>
</QueryList>

Microsoft Defender for Identity (MDI): Built-in "DCSync attack (replication of directory services)" alert. MDI correlates DsGetNCChanges calls from non-DC IP addresses and fires the alert with the source account and IP. If you have MDI deployed, DCSync is not stealthy.

Network-level detection: DRSUAPI traffic (RPC over TCP, typically port 135 + dynamic ports) originating from a non-DC IP address is anomalous. A SIEM or NDR rule filtering for MS-DRSR traffic from hosts that are not in the domain controller OU catches secretsdump and similar tools regardless of the source account.

What DCSync does not generate: failed login events, LSASS access events, process injection alerts, or any event on the workstation running the attack. The only trace is on the DC and in network traffic.

Conclusion

DCSync is end-game. If you find an account with DS-Replication-Get-Changes-All that is not a domain controller, you have a direct path to every password hash in the domain. KRBTGT gives you golden tickets. DA hashes give you immediate lateral movement. The attack requires no code on the DC, no LSASS access, and no special tools beyond network connectivity to the domain controller.

The misconfiguration is more common than it should be — service accounts, legacy delegation entries, and leftover ACEs from custom administrative tooling all accumulate these permissions over time. A domain that has never had an explicit ACL audit is likely vulnerable.

ADscan flags DCSync-capable non-DC accounts automatically in every assessment.

DCSync Attack: How It Works, How to Execute, and How to Detect It — ADscan | ADscan