What Is a DCSync Attack? How It Works and How to Detect It

A DCSync attack is typically the final step before ransomware deployment. By the time an attacker runs it, they control your domain. Understanding what DCSync is, how attackers reach it, and how to detect it gives your team a real chance to catch a breach before it becomes a regulatory notification.

Microsoft's December 2025 Active Directory threat guidance identifies DCSync as one of the most observed post-exploitation techniques in domain compromise scenarios. MITRE ATT&CK tracks it as T1003.006, OS Credential Dumping: DCSync.

What DCSync Actually Does

Domain controllers in Active Directory replicate data between each other continuously: user accounts, password hashes, and policy objects. This replication uses the Directory Replication Service (DRS) protocol, and any entity with the correct permissions can initiate it.

DCSync abuses those replication permissions. Instead of logging into a DC and running a tool locally, an attacker sends a legitimate replication request from a remote machine. The domain controller, treating it as normal inter-DC replication, responds with the requested data, including:

The outcome: every credential in your Active Directory, extracted remotely, without ever logging into a domain controller directly.

With those hashes, an attacker can authenticate to any system in the domain using pass-the-hash, crack passwords offline for weaker accounts, or forge Kerberos Golden Tickets using the KRBTGT hash to gain persistent domain access.

What Permissions DCSync Requires

DCSync requires one of these Active Directory rights on the domain root:

By default, these are held by Domain Admins, Enterprise Admins, and DC machine accounts. Regular user and service accounts should never have them.

Audit who has DCSync rights right now:

Import-Module ActiveDirectory
$domain = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domain"
$acl.Access | Where-Object {
  $_.ActiveDirectoryRights -match "ExtendedRight" -and
  ($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or
   $_.ObjectType -eq "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2")
} | Select-Object IdentityReference, ActiveDirectoryRights

Any identity in those results that isn't a DC machine account, Domain Admins, or Enterprise Admins warrants immediate investigation.

How Attackers Get There

DCSync requires domain admin or equivalent, which is why it's the endpoint of the attack chain rather than the starting point. The paths to getting there are what a penetration test actually maps.

Via ADCS abuse (ESC8): An attacker relays a domain controller's outbound authentication to the ADCS web enrollment endpoint, receives a certificate for the DC machine account, uses that certificate to get a Kerberos TGT for the DC, then runs DCSync as the DC. This chain requires zero domain privileges to initiate and completes in approximately 12 to 15 minutes in default configurations.

Via NTLM relay to LDAP: An attacker relays a privileged user's authentication to the LDAP interface and writes a new ACE granting their account DCSync rights on the domain root. This requires unsigned LDAP on DCs, which is the default on Server 2022 and below. See our NTLM relay prevention guide for the specific controls that close this path.

Via compromised domain admin account: Any domain admin credential compromise, through phishing, credential stuffing, or Kerberoasting a service account with DA privileges, grants direct DCSync capability.

Via ACL misconfiguration: Legacy accounts, backup operators, or application service accounts sometimes hold replication rights granted historically and never reviewed. BloodHound surfaces these automatically.

The KRBTGT Hash Problem

Of all the data DCSync retrieves, the KRBTGT hash is the most dangerous. KRBTGT encrypts and signs all Kerberos tickets in the domain. With it, an attacker forges Golden Tickets: valid Kerberos tickets for any user, to any service, with any group membership, that remain valid indefinitely.

A Golden Ticket persists across password resets. The only fix is resetting the KRBTGT account password twice in succession, a disruptive operation that invalidates all active Kerberos sessions in the domain.

If incident response confirms DCSync ran in your environment, assume the KRBTGT hash was extracted even without direct evidence. Reset it twice as part of recovery.

How to Detect DCSync

DCSync leaves a specific Windows Event Log signature when auditing is enabled and someone is watching.

Event ID 4662 on domain controllers, with: - Object Type: 19195a5b-6da0-11d0-afd3-00c04fd930c9 (domain object) - Access mask containing: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} or {1131f6ab-9c07-11d1-f79f-00c04fc2dcd2} - Subject Account Name: not a DC machine account (DC accounts end in $)

The alert rule: Event ID 4662 with replication access rights where the Subject is a user account rather than a computer account is highly anomalous and warrants immediate investigation.

Enable the audit policy on DCs:

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

Microsoft Defender for Identity has built-in DCSync detection and alerts when replication rights are exercised by non-DC accounts. It's the most reliable detection option for environments without a full SIEM.

Prevention: Closing the Paths to DCSync

Prevention focuses on blocking the prerequisite paths. DCSync itself is a legitimate protocol feature, so hardening the routes that lead to it is the right approach.

Frequently Asked Questions

Is DCSync detectable without a SIEM? With advanced auditing enabled and Windows Event Forwarding configured, DCSync detection is possible using native tools. Without active monitoring, logs may be overwritten before anyone reviews them. At minimum, configure WEF to forward Event ID 4662 from all DCs to a central location.

Does patching prevent DCSync? DCSync abuses legitimate AD replication permissions rather than exploiting a software vulnerability. Patches alone will not prevent it. Prevention requires hardening the prerequisite attack paths: ADCS, LDAP relay, and ACL misconfigurations.

How common is DCSync in real attacks? Very common. Microsoft's December 2025 guidance lists it as one of the most observed post-exploitation techniques. In most internal penetration tests of SMB environments with default configurations, DCSync is reachable within one to two hours of initial access.

Sources

Stay sharp. Stay prepared. — ThreatForged AI

Written by Ryan Kucher, founder of ThreatForged AI. Every ThreatForged AI assessment includes DCSync testing and documents the exact path that makes it reachable. Book a scoping call.