DCSync Attacks Steal Active Directory Password Hashes Silently

Key Takeaways

• DCSync attacks exploit Active Directory’s legitimate replication protocol to steal sensitive password hashes, including the critical krbtgt account.
• This attack is notably stealthy, as it doesn’t involve deploying malware or directly accessing the NTDS.dit database on a domain controller, making traditional endpoint detection challenging.
• Attackers require specific replication rights (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All) to execute DCSync, often gained through misconfigurations or prior credential compromise.
• Successful DCSync grants attackers the ability to forge Golden Tickets, facilitating persistent, domain-wide compromise and lateral movement.
• Detection relies heavily on comprehensive directory service auditing (Event ID 4662), network telemetry for DRSUAPI traffic, and monitoring for unusual ACL modifications.

Active Directory (AD) serves as the central identity management system for most organizations, with its most critical assets being the password hashes for all user, service, and machine accounts. A sophisticated attack known as DCSync allows adversaries to extract these hashes without ever logging into a domain controller, installing tools, or directly accessing the NTDS.dit database.

Instead, a DCSync attack involves an attacker impersonating a legitimate domain controller and requesting sensitive account information from a target DC using the standard Microsoft Directory Replication Service Remote Protocol (MS-DRSR). This technique leverages the very mechanism DCs use to synchronize data among themselves.

Specifically, the attacker binds to the DRSUAPI RPC interface and invokes the IDL_DRSGetNCChanges function. This request prompts the domain controller to replicate credential attributes for a single account, a select few, or even every account within the domain. The unsuspecting DC, believing it is communicating with a peer, then transmits NTLM hashes, Kerberos keys, and password history to the attacker.

Originally weaponized in the Mimikatz tool by Benjamin Delpy and Vincent Le Toux, DCSync has since become a staple in the arsenals of ransomware groups and nation-state actors. MITRE ATT&CK categorizes this technique as T1003.006 (OS Credential Dumping: DCSync). Its position within a broader intrusion can be understood through the Active Directory Attack Kill Chain Checklist.

Why DCSync Is So Silent and So Dangerous

Unlike many credential theft methods that leave obvious traces, DCSync operates with remarkable stealth. Techniques like dumping LSASS typically generate suspicious process access alerts, while stealing the NTDS.dit file from a domain controller often involves creating a Volume Shadow Copy, copying a locked database, and extracting the SYSTEM hive – all actions that interact with the disk and trigger endpoint security alarms. DCSync bypasses these traditional indicators entirely.

The attack’s silence stems from its use of the legitimate replication channel. To the target domain controller, the DCSync request appears as routine directory synchronization. There are no malicious binaries to quarantine, no shadow copies to flag, and no unauthorized file access alerts. The entire operation is executed from the attacker’s workstation, meaning no attacker code runs on the domain controller itself. Consequently, detection relies almost exclusively on robust directory service auditing and network telemetry, rather than conventional antivirus solutions.

The ramifications of a successful DCSync attack are severe, primarily because it can yield the krbtgt account hash. Possession of this hash enables an attacker to forge Golden Tickets – self-minted Kerberos tickets that grant access as any user to any service, maintaining persistence until the krbtgt key is rotated twice. This effectively constitutes a persistent, domain-wide compromise from a single replication request. The stolen hashes also facilitate Pass-the-Hash lateral movement and offline password cracking. The outcome is as catastrophic as an NTDS.dit database theft, but achieved with significantly less noise.

How DCSync Works Under the Hood

A DCSync operation is a precisely defined, short exchange. Understanding each step is crucial for defenders to pinpoint detectable artifacts.

• Step 1 — RPC Bind: The attacker initiates an RPC bind to the DRSUAPI interface (UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2) on the chosen target domain controller.
• Step 2 — Replication Request: The attacker calls IDL_DRSGetNCChanges, instructing the DC to replicate the secret attributes of a specified object. Common targets include the krbtgt account, a Domain Admin account, or all accounts in the domain.
• Step 3 — Access Check: The domain controller validates whether the requesting entity possesses the necessary DS-Replication-Get-Changes(-All) extended rights. If these rights are present, the request is processed as a legitimate peer replication.
• Step 4 — Secrets Returned: The DC then transmits the NTLM hash, AES/Kerberos keys, LM hash (if configured), and password history for the requested account(s) back to the attacker.

The Replication Rights That Make It Possible

DCSync fundamentally relies on two extended rights granted on the domain naming context: Get-Changes and Get-Changes-All. The former authorizes the replication of directory changes, while the latter specifically unlocks confidential attributes, including password hashes. A third right, DS-Replication-Get-Changes-In-Filtered-Set, which allows replication of the RODC filtered attribute set, is often abused in conjunction with the primary two.

By default, these critical rights are exclusively assigned to members of the Domain Admins, Enterprise Admins, Administrators, and Domain Controllers groups. However, a common vulnerability arises from “ACL drift,” where these rights are mistakenly or unnecessarily granted to other accounts, such as mail connectors, Entra Connect / Azure AD Sync, backup software, or legacy migration accounts. Such misconfigurations can transform an ordinary service account into a launchpad for DCSync, representing one of the most common Active Directory misconfigurations leading to full domain compromise.

What an Attacker Needs First (Prerequisites)

DCSync is not typically an initial access vector; rather, it is a post-exploitation technique employed once an attacker has secured an identity with sufficient privileges. Realistic pathways to obtaining a DCSync-capable account include:

• Privileged Group Membership: Compromising a Domain Admin, Enterprise Admin, or Administrator account through methods like phishing, credential reuse, or LSASS dumping.
• Abused ACL on the Domain Head: Discovering a lower-privileged account that has been erroneously granted Get-Changes-All rights (often identified using tools like BloodHound) and taking control of it.
• AD CS Abuse (ESC1–ESC8): Exploiting vulnerabilities in certificate templates to obtain a certificate for a privileged account, then authenticating as that account.
• Coercion + NTLM Relay: Coercing a domain controller or other privileged host to authenticate, then relaying that authentication to escalate privileges to replication rights. This includes authentication coercion attacks and MITM6 + NTLM relay.
• Delegation / dMSA Abuse: Leveraging weaknesses in constrained/unconstrained delegation or the newer dMSA in Windows Server 2025 to impersonate a high-privilege account.

DCSync Attack Techniques, Tools & Commands

Once an attacker gains control of a principal with the requisite replication rights, executing a DCSync attack is straightforward. The following tools are frequently cited in threat reports, along with representative commands.

1. Reconnaissance — find who can DCSync

Before, or as an alternative to, escalating to Domain Admin, attackers will enumerate which principals already possess replication rights. Defenders should proactively conduct the same queries.

# PowerView — list principals with replication rights on the domain head
Get-ObjectAcl -DistinguishedName “DC=corp,DC=local” -ResolveGUIDs | 
  ? { ($_.ObjectAceType -match “Replication-Get-Changes”) } | 
  select SecurityIdentifier, ActiveDirectoryRights, ObjectAceType

# BloodHound: shortest path to “GetChangesAll” edges highlights DCSync paths

2. Mimikatz — the classic

Mimikatz’s lsadump::dcsync module is a Windows-based tool capable of targeting a single account or extracting all accounts from a domain.

mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt
[DC] ‘corp.local’ will be the domain
[DC] ‘DC01.corp.local’ will be the DC server
Object RDN           : krbtgt
Hash NTLM            : 5f4dcc3b5aa765d61d8327deb882cf99
Kerberos AES256      : e0c3a1b2… (truncated)

# Dump every account at once:
mimikatz # lsadump::dcsync /domain:corp.local /all /csv

3. Impacket secretsdump.py — remote and agentless

Impacket’s secretsdump.py executes DCSync entirely over the network from a Linux system using the -just-dc flag, meaning no code needs to run on the domain controller. Impacket is included in Kali Linux and is regularly updated with new attack capabilities and relay tricks.

$ secretsdump.py -just-dc corp.local/backupadm:’P@ssw0rd’@10.0.0.10
[*] Dumping Domain Credentials (domainuid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404ee…:5f4dcc3b5aa765d6…:::
krbtgt:502:aad3b435b51404ee…:8f3d1e6b0c9a44f2…:::

# NTLM hashes only: 
secretsdump.py -just-dc-ntlm corp.local/[email protected]
# Pass-the-hash auth: 
secretsdump.py -just-dc -hashes :<nthash> corp.local/[email protected]

4. DSInternals — native replication API in PowerShell

DSInternals leverages the same replication protocol from PowerShell, allowing it to blend in with legitimate administrative activities.

Get-ADReplAccount -All -Server dc01 -NamingContext “DC=corp,DC=local”
Get-ADReplAccount -SamAccountName krbtgt -Server dc01 -NamingContext “DC=corp,DC=local”

From Hashes to Full Domain Takeover

DCSync represents the credential access phase of an attack. The true extent of the damage lies in what those stolen hashes enable. Defenders must treat a confirmed DCSync incident as a full-scale domain compromise, not merely an isolated account breach.

• Golden Ticket (T1558.001): The krbtgt hash allows attackers to forge Kerberos Ticket Granting Tickets (TGTs) for any identity, providing stealthy and long-lasting domain access until the krbtgt key is rotated twice.
• Pass-the-Hash & Overpass-the-Hash (T1550.002): NTLM hashes facilitate lateral authentication without requiring password cracking, while AES keys enable Kerberos-based movement across the network.
• Offline Cracking: Weaker NTLM hashes can be cracked using tools like hashcat, and legacy NTLMv1 is vulnerable to rainbow table attacks.
• Ransomware Staging: Threat actors frequently perform DCSync, then deploy encryptors across the entire domain from a compromised DC, often via Group Policy Objects (GPO) or Remote Desktop Protocol (RDP).

For more context on intrusion techniques, explore how attackers exfiltrate NTDS.dit for full AD access and how they exploit domain controllers to deploy ransomware over RDP.

Indicators of Compromise (IOCs)

Since DCSync leaves no files on the domain controller, its indicators are found within directory-service audit logs, network traffic, and Active Directory configuration. Defenders should actively hunt for the following:

Indicator	Type	Why it matters
Event ID 4662 with Access Mask 0x100 + a replication GUID, from a non-DC principal	Directory audit log	Single highest-confidence DCSync signal
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2	Property GUID	DS-Replication-Get-Changes seen in 4662 Properties
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2	Property GUID	DS-Replication-Get-Changes-All — returns password data
89e95b76-444d-4c62-991a-0facbeda640c	Property GUID	Get-Changes-In-Filtered-Set — often paired in attacks
DRSUAPI UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2 from a non-DC IP	Network / RPC	DRSGetNCChanges sourced from a workstation
Replication request whose source account is a user or workstation	Behavioural	Only DCs should perform replication
New/unexpected ACE granting Get-Changes-All on the domain head	AD configuration	Attacker persistence or DCSync setup (watch Event 5136)
Mimikatz / secretsdump artifacts on a non-DC host	Host artifact	Tooling runs on the attacker system, not the DC

How to Detect a DCSync Attack

Event ID 4662 — the primary signal

The primary detection mechanism for DCSync is Windows Security Event ID 4662, titled “An operation was performed on an Active Directory object.” A high-confidence DCSync alert is triggered by a single Event 4662 exhibiting an Access Mask of 0x100 (Control Access) in conjunction with one of the specific replication GUIDs, provided that the subject initiating the operation is NOT a domain controller. Crucially, this detection requires “Audit Directory Service Access” to be enabled with an appropriate System Access Control List (SACL), as it is disabled by default.

# Sigma / SIEM logic for DCSync
SELECT * FROM SecurityLog
WHERE EventID = 4662
  AND AccessMask = “0x100”
  AND Properties MATCHES (“1131f6aa-9c07-11d1-f79f-00c04fc2dcd2”
                        OR “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2”)
  AND SubjectUserName NOT IN (<list of domain controller computer accounts$>)
=> ALERT: Possible DCSync (credential replication by non-DC)

Pin down the source account and IP

While Event 4662 identifies that a DCSync operation occurred, it doesn’t specify the origin. To gain actionable intelligence, correlate Event 4662 with Event ID 4624 (successful account logon) on the same domain controller, using the shared Logon ID. This correlation reveals the attacker’s source IP address, the compromised identity used, and the precise time of the attack, transforming a detection into a concrete investigative lead. For a broader approach, see detecting unauthorized access attempts in Active Directory.

Network and platform detections

• Network/NDR: Configure alerts for DRSUAPI (DRSGetNCChanges) traffic originating from any host that is not a recognized domain controller. Community signatures for this activity are available in tools like Zeek and Suricata.
• Microsoft Defender for Identity: This solution provides a built-in alert for “Suspected DCSync attack (replication of directory services),” eliminating the need for manual SACL configuration.
• Open-source DCSYNCMonitor: This tool generates custom Windows events specifically for DCSync and DCShadow activities.
• Event ID 5136 Monitoring: Watch for Event ID 5136, which indicates ACL changes that grant replication rights. This is a common step for establishing persistence or setting up a DCSync attack, and also a key indicator for the related DCShadow technique.

What You Should Do

Harden — reduce who can DCSync

• Audit Replication ACLs: Regularly enumerate all principals holding Get-Changes / Get-Changes-All rights on the domain naming context using tools like BloodHound, PingCastle, or Purple Knight.
• Strip Rights from Non-DC Accounts: Ensure that no user or service account outside of Tier 0 (privileged accounts) possesses Get-Changes-All rights. This includes reviewing and removing legacy sync or backup grants.
• Lock Down Privileged Groups: Minimize membership in Domain Admins, Enterprise Admins, and Administrators groups, and continuously review these memberships for legitimacy.
• Enforce a Tier 0 Model: Administer domain controllers exclusively from Privileged Access Workstations (PAWs), and never expose Domain Admin credentials to user-tier hosts.
• Close Escalation Paths: Remediate Active Directory Certificate Services (AD CS) misconfigurations (ESC1–ESC8), unconstrained delegation, and weak object ACLs that could lead to privilege escalation.
• Modernize Credentials: Implement Group Managed Service Accounts (gMSA) and Local Administrator Password Solution (LAPS). Disable legacy NTLM where feasible to reduce the value of Pass-the-Hash attacks.

Detect & contain the blast radius

• Turn on Directory Auditing: Enable “Audit Directory Service Access” and configure alerts for Event ID 4662 combined with specific replication GUIDs when initiated by non-DC sources.
• Deploy Identity Threat Detection: Utilize solutions such as Microsoft Defender for Identity (which includes a “Suspected DCSync” alert) or open-source tools like DCSYNCMonitor.
• Watch the Wire: Implement network detection and response (NDR) or intrusion detection systems (IDS) to alert on DRSUAPI / DRSGetNCChanges traffic originating from any non-DC source IP address.
• Segment and Restrict RPC: Configure network segmentation to permit replication traffic only between legitimate domain controllers, effectively isolating DCs from other network segments.
• Rotate krbtgt Twice: Immediately after any confirmed Domain Admin compromise, rotate the krbtgt account password twice to invalidate any forged Golden Tickets.
• Hunt Assuming Breach: After an incident, reset all exposed privileged credentials and actively hunt for signs of Golden Ticket and Pass-the-Hash usage within the environment.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.

Tags:

AttackBreachExploitHackerMalwarephishingransomwareSecurityThreat