What is a DCSync attack: Detection and prevention

Only 26% of organizations are fully confident their Active Directory is free of misconfigurations that enable privilege escalation, according to the Netwrix 2026 Data and Identity Security Report. That uncertainty is well-founded, since DCSync needs just one delegated permission on a forgotten service account to hand over every password hash in the domain.

Attackers reach it more often through that kind of leftover delegation than through a compromised administrator account, since replication rights get handed to service accounts during migrations and integrations and then never get revoked.

However, DCSync itself has no patch, since it uses the same replication interface domain controllers use to stay synchronized, and blocking it would break Active Directory. The resulting traffic looks identical to ordinary replication to anyone scanning logs at a glance.

What is a DCSync attack?

A DCSync attack is an intrusion technique in which an adversary simulates a domain controller (DC) and retrieves password data through domain replication. It usually precedes a Golden Ticket attack.

DCSync is also the name of a command in the open-source Mimikatz tool. The command uses the Directory Replication Service Remote Protocol (MS-DRSR) to impersonate a domain controller and ask real domain controllers to replicate directory information, abusing AD replication working exactly as designed. MITRE tracks it as T1003.006 under OS Credential Dumping, and there's no underlying vulnerability to fix.

How a DCSync attack works

The sequence completes in seconds and requires no code execution on the domain controller.

1. The attacker targets any domain controller in the domain

No prior foothold on that specific machine is needed, since the request travels over the network like any other replication traffic. Any domain controller will answer it.

2. The attacker impersonates a domain controller to request replication

The attacker calls IDL_DRSGetNCChanges in the MS-DRSR replication interface, also known as DRSUAPI, and requests user replication data while impersonating a domain controller. The call is legitimate replication API usage, not a malformed or unusual request, so it doesn't trigger protocol-level defenses.

3. The targeted domain controller returns password hashes

The domain controller responds with replication data, including password hashes, because the interface can't distinguish a legitimate domain controller from an account with the right permissions.

4. Existing tools carry out the request

Mimikatz's lsadump::dcsync module remains the best-known implementation, and other tooling performs the same replication request. Impacket's secretsdump.py runs it over the network, and the DSInternals PowerShell module exposes it through Get-ADReplAccount.Expand

The DSInternals PowerShell module exposes it through Get-ADReplAccount.Expand Extracting user password data with Mimikatz DCSync covers the full command sequence.

Which rights a DCSync attack requires

Administrators, Domain Admins, and Enterprise Admins hold the necessary rights by default. Because these privileges take time to obtain, DCSync tends to appear late in the kill chain. The specific permissions are:

• Replicating Directory Changes (DS-Replication-Get-Changes)Expand
• Replicating Directory Changes All (DS-Replication-Get-Changes-All)Expand
• Replicating Directory Changes In Filtered Set (required only in some environments)

Two more permissions open the same door and rarely surface in a review of privileged group membership. An account holding GenericAll (full control) or AllExtendedRights at the domain level can run DCSync while belonging to no privileged group.

Any account with these rights delegated at the domain naming context can replicate. Entra Connect service accounts, typically named with an MSOL_ prefix, legitimately hold these rights, as do accounts that inherited them from a migration or a long-forgotten integration.

Attackers reach these rights through privilege escalation, so any account that holds them needs the same privileged account management discipline as a Domain Admin, not standing access nobody revisits.

Enumerating who holds the rights today is the cheapest exposure check available, since the delegation lives in access control lists (ACLs) that a directory assessment tool reads directly, and attack path analysis shows how those rights chain together.

What attackers do with the hashes

The replication rights that make DCSync possible are permissions; the hashes it returns are not. A hash is credential material, the cryptographic representation of a password, and holding one lets an attacker impersonate whoever it belongs to without ever knowing that person's actual password. What an attacker does next depends on which account's hash they pulled.

KRBTGT hash: Forge tickets for any account in the domain

A DCSync run that reaches the KRBTGT account turns credential theft into domain compromise. The KRBTGT hash signs every Kerberos ticket in the domain. An attacker holding it can forge Ticket Granting Tickets (TGTs) for any account without touching that account's own credentials, and that forged access survives a normal password reset on the impersonated account. Only a KRBTGT reset invalidates the forged tickets.

Regular account hashes: Move laterally without cracking anything

NT LAN Manager (NTLM) hashes for regular and privileged accounts feed Pass-the-Hash movement directly. An attacker authenticates as that account by replaying the hash itself, so nothing needs to be cracked before the credential becomes usable elsewhere in the domain.

Weaker credential material: crack offline for a plaintext password

Kerberos keys and stored password history recovered in the same replication response get cracked offline when the hash type is weak enough to make that practical. Plaintext passwords surface directly only for accounts configured with reversible encryption, a setting worth auditing for exactly this reason.

How to detect a DCSync attack

Three places can catch a DCSync request, and each catches something different: the domain controller's event log, the network itself, and the behavior of the identity making the request.

Enable Directory Service auditing and alert on the replication GUIDs

Turn on Advanced Audit Policy for Directory Service Access first, since Windows leaves this off by default and Event ID 4662 won't fire without it. Once it's on, watch for these replication property GUIDs specifically, identified by globally unique identifier (GUID) rather than by friendly name:

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-ChangesExpand
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-Changes-AllExpand

Alert when those GUIDs appear against an account that isn't a domain controller or a known replication service account, and filter before you alert, since an unfiltered 4662 volume on a busy domain controller produces noise nobody reads. Treat this signal as a backstop rather than the primary control, since an attacker who reaches a domain controller can also clear or stall the logs a 4662-only strategy depends on.

Watch the wire for replication from a non-DC host

Monitor for a DRSUAPI bind carrying IDL_DRSGetNCChanges from any host that isn't a domain controller, since legitimate replication runs only between domain controllers and no benign version of that traffic exists to filter around. Prioritize this signal over event-log detection, since network monitoring catches the request whether or not the domain controller recorded it, which keeps the signal available even after an attacker tampers with endpoint logging.

Baseline identity behavior to catch what a single event can't

Feed replication events into an identity threat detection platform that builds a baseline for each account's normal behavior, since one 4662 event or one DRSUAPI bind can look legitimate in isolation but abnormal against that specific account's own history. An account that has never issued a replication request before doing so once is the pattern this layer exists to catch, which a static allowlist or a one-off rule can miss entirely.

How to prevent DCSync attacks

No protocol-level control blocks DCSync, so prevention comes down to controlling who can invoke replication and shortening the paths that lead to those rights.

Gate new replication rights at provisioning, not just at the next review

Require a documented justification and a named owner before any new integration or migration receives DS-Replication-Get-ChangesExpand, DS-Replication-Get-Changes-AllExpand, GenericAllExpand, or AllExtendedRightsExpand, rather than granting the right first and revisiting it at the next audit cycle.

Rights handed out during a migration or integration tend to stay long after the project ends, since removing access nobody remembers granting is a harder call than granting it was in the first place.

Review and remove replication rights nobody can justify

Review every account holding the three replication permissions plus GenericAll and AllExtendedRights at the domain naming context, and remove what nobody can justify. Repeat the review on a schedule, since new integrations reintroduce the rights.

Enterprise Key Admins is the recurring example, since adprep /domainprep on Windows Server 2016 granted that group full control over the Domain Naming Context and its child objects. Microsoft called it a bug rather than a vulnerability and closed it for new domain preparations starting with the 1709 update, but domains prepped before that fix need a separate remediation script; domain-wide schema updates alone won't clear it.

Restrict replication RPC to known domain controller addresses

Where the topology allows it, permit remote procedure call (RPC) replication only between known domain controller addresses. This won't stop an attacker who already has valid replication rights, but it does block requests from any host with no legitimate reason to make one.

Close the paths attackers use to reach replication rights

Verify that Zerologon (CVE-2020-1472) is remediated, since vulnerabilities that grant domain privileges directly shortcut the whole kill chain. Treat credential-harvesting routes such as Kerberoasting as how attackers reach replication rights in the first place, not as a separate problem to solve later. Both fixes are part of the wider Active Directory security best practices that keep the domain's other privileged paths in check.

How to respond to a suspected DCSync attack

Assume the hashes are already gone, because the data left the domain before the alert fired. What you do next decides how long that access keeps paying off for the attacker.

Scope what the attacker actually queried

Review Event ID 4662, Directory Service, and Sysmon logs to establish which objects the attacker queried before deciding how far containment and remediation need to reach. What comes back here determines whether the response stops at one account or extends to a domain-wide credential reset.

Contain the source, not just the implicated account

Disabling the implicated account is the reflex, and on its own it accomplishes little, because the attacker now holds credentials that work independently of that account. Revoke the replication rights and privileged group memberships instead, and isolate the source host.

Reset KRBTGT twice if it was among the hashes

If KRBTGT was among them, reset the KRBTGT password twice, leaving a gap between the two resets longer than both the maximum ticket lifetime (10 hours by default) and one full replication cycle. A single reset leaves the previous key valid, so forged tickets keep working. Where the logs can't establish the scope, default to a domain-wide credential reset instead of guessing.

How Netwrix helps you detect and block DCSync attacks

Assessment, detection, and prevention run through different products here, and they work together.

Find every account holding replication rights

Netwrix PingCastle scores Active Directory against its MITRE ATT&CK-mapped checks, including accounts holding replication rights outside the default groups, turning the delegation review above into a repeatable check.

Detect a replication request from a non-DC host

Netwrix Threat Manager detects credential theft techniques against Active Directory, including a replication request issued by a machine that isn't a domain controller, and alerts on it.

Its alerts surface the account behind the request, the domain and account targeted, and the objects queried, which is the detail an analyst needs to scope the run rather than just confirm it happened.

Its DCSync detection is sourced from a Netwrix Threat Prevention AD Replication Monitoring policy, so the two products run as a pair.

Block the replication request before it completes

Netwrix Threat Prevention applies blocking policies that stop a specific account or workstation from executing further replication. Both fit into identity threat detection and response, with Threat Manager extending detection to Entra ID and Threat Prevention enforcing at the on-premises Active Directory layer.

[IMAGE PLACEHOLDER: Product, request to PMM. Need a product screenshot of Netwrix Threat Manager (any current view showing a detected DCSync event with source host, targeted account, and queried objects)]

Where to start on DCSync exposure

Replication rights carry most of the defensive weight here, and a delegation list nobody has reviewed since the last migration is the realistic attack path. Enumerating it costs an afternoon.

Alerting on replication from hosts that aren't domain controllers catches the attempt itself, and that signal holds up whether or not Directory Service auditing was ever switched on. A documented KRBTGT reset procedure then decides how long a successful run keeps paying the attacker.

Request a demo to see how Netwrix finds replication rights, detects a live DCSync attempt, and blocks the next one against your own Active Directory environment.