DCSync Attack: Abusing Replication to Steal Hashes

Domain controllers keep each other in sync by copying directory changes back and forth, and that synchronization includes password hashes. DCSync is the attack that walks up to a domain controller, pretends to be another domain controller, and simply asks for those hashes. The protocol answers, because answering replication requests is its job. Nothing runs on the domain controller, nothing is dropped to disk there, and the request looks like the routine chatter domain controllers exchange all day.

How replication normally works

Active Directory is a multi-master directory. A change written on one domain controller has to propagate to all the others. The mechanism is the Directory Replication Service (DRS) Remote Protocol, and one of its operations lets a domain controller request the changes it is missing from a peer.

Because password hashes are part of the directory, replication necessarily moves them between domain controllers. That is by design; a DC has to hold every account's Kerberos keys to authenticate users. So the replication protocol is fully capable of returning secret attributes, including the NTLM hashes and Kerberos keys of every account in the domain, up to and including krbtgt.

The protocol trusts the caller based on Active Directory permissions. If the requesting principal holds the right extended rights, the domain controller replies with the requested data. It does not care whether the caller is actually a domain controller or a workstation impersonating one.

What DCSync does

DCSync issues a replication request for the secret attributes of one or more accounts, then reads back the returned hashes. It is a client speaking the replication protocol on the network, so it never needs to log on to the domain controller interactively or run a process there. On MITRE ATT&CK this is DCSync (T1003.006), a sub-technique of OS Credential Dumping.

The permissions that make it possible are two extended rights on the domain object:

• Replicating Directory Changes
• Replicating Directory Changes All

Any account granted both can perform a full DCSync. By default these rights belong to Domain Admins, Enterprise Admins, and domain controllers themselves. The risk appears when they are granted more widely, sometimes accidentally, sometimes through delegation or a misconfigured application, leaving a lower-privileged account able to extract the entire domain's credentials.

Why DCSync matters so much

A successful DCSync of a privileged account hash is bad. A DCSync of the krbtgt hash is a strategic loss, because the krbtgt hash is the key to forging Golden Tickets. The chain is direct: DCSync the krbtgt hash, then forge a Golden Ticket to hold Domain Admin access indefinitely. Our Golden Ticket guide covers that second half.

DCSync also pulls the hashes of every user, which feeds offline cracking and pass-the-hash attacks across the environment. In practice, a full DCSync is treated as total domain credential compromise.

Who can reach this point

DCSync requires the replication rights, so it is a technique used by an attacker who has already gained significant privilege. The usual routes to those rights are:

The recurring theme is that DCSync is an escalation and persistence move made from an already-privileged position. Watching for the sudden granting of replication rights to an unusual principal is itself a detection opportunity.

How to detect and defend

Detection depends on treating replication as something to be watched, and defense depends on keeping the replication rights scarce.

Detection signals

• Directory replication events from non-DC sources. Domain controllers log directory service access events when replication of directory changes is requested (event ID 4662 with the replication extended-right GUIDs). A replication request whose source is a workstation or member server, rather than a known domain controller, is the classic DCSync signal.
• Replication requests from unexpected accounts. Legitimate replication comes from domain controller computer accounts. A user account, or a service account with no reason to replicate, requesting directory changes deserves immediate investigation.
• Network replication traffic from unknown hosts. At the network layer, DRS replication (RPC to the directory replication service) originating from an IP that is not a domain controller is anomalous. Building an allowlist of legitimate DC IPs turns this into a clean detection.
• Sudden ACL changes on the domain object. Watch for the granting of Replicating Directory Changes rights, which often precedes a DCSync by an attacker setting up their own access.

Defensive controls

1. Minimize who holds replication rights. Audit the domain object's ACL and confirm that only domain controllers and the expected administrative groups hold Replicating Directory Changes and Replicating Directory Changes All. Remove any principal that does not need them.
2. Audit replication rights on a schedule. These grants drift over time through delegation and application setup. Regular review catches the over-permissioned account before an attacker finds it.
3. Enable and forward directory service auditing. Turn on auditing for directory service access on domain controllers and forward those logs off-host so DCSync leaves a reviewable trail. Our guide to Windows event IDs for security maps the specific events to watch.
4. Restrict which hosts can talk to domain controllers over replication. Network controls that limit DRS traffic to known domain controllers cut off DCSync from arbitrary hosts.
5. Protect the privileged accounts that already hold the rights. Tiered administration, strong authentication, and limiting where Domain Admin credentials are used all reduce the chance an attacker reaches a principal capable of DCSync in the first place. The groups that operate at this level are catalogued in our Threat Group Directory.

The replication protocol underneath

The operation DCSync abuses lives in the Directory Replication Service Remote Protocol, documented by Microsoft as MS-DRSR and exposed over RPC through the DRSUAPI interface. The specific call that moves directory data between peers is IDL_DRSGetNCChanges, usually shortened to GetNCChanges. When one domain controller needs the updates it is missing from another, it binds to the peer's replication interface, presents its credentials, and calls GetNCChanges to pull the changed objects and attributes for a naming context.

A DCSync tool speaks exactly this conversation. It binds to the target domain controller's DRSUAPI endpoint, then issues GetNCChanges asking for the attributes of a specific security principal. Among the attributes returned for a user object are the secret ones: unicodePwd holds the current NTLM hash, ntPwdHistory holds previous NTLM hashes, supplementalCredentials holds Kerberos keys and cleartext-equivalent material, and pwdLastSet gives the age of the password. The domain controller encrypts these secret attributes for transport, and the requesting side decrypts them because a replication peer is expected to. From the attacker's perspective, one well-formed call returns everything needed to authenticate as the target account offline or to forge tickets.

The important detail is that the domain controller makes its decision on authorization, not identity. It checks whether the calling principal holds the replication extended rights on the naming context being requested. It does not verify that the caller is a genuine domain controller, because the protocol has no way to demand that. A member workstation running a DCSync tool and a real replicating domain controller send structurally identical requests. The only thing that separates them is the rights on the account behind the request and the network location it came from, which is why those two properties carry the whole weight of both attack and defense.

A step-by-step walkthrough

Walking through the sequence conceptually makes the technique concrete without needing any specific tool.

1. The attacker reaches a principal with replication rights. This is the precondition. The account might be a compromised Domain Admin, an over-delegated service account, or a normal account whose ACL on the domain object was quietly extended to include the replication rights. Nothing about DCSync itself grants these rights, so this step always happens first.
2. The tool binds to the domain controller's replication interface. Using the compromised credentials, it opens an authenticated RPC connection to the DRSUAPI endpoint on a live domain controller. No interactive logon to the box occurs, and no file is written to it.
3. The tool issues a GetNCChanges request for a chosen account. It names the target principal, commonly krbtgt for maximum impact or a specific Domain Admin, and asks for that object's attributes including the secret ones.
4. The domain controller authorizes and answers. It confirms the caller holds the Replicating Directory Changes rights, gathers the requested attributes, encrypts the secret ones for replication transport, and returns them.
5. The tool decrypts and records the hashes. The returned NTLM hash and Kerberos keys are decrypted client-side and stored. If the target was krbtgt, the attacker now holds the domain's ticket-signing key.
6. The attacker converts the material into access. Extracted user hashes feed pass-the-hash and offline cracking. The krbtgt hash feeds Golden Ticket forgery for long-term persistence.

The whole exchange can complete in seconds and generates only replication traffic and directory service access events, which is what makes disciplined auditing the difference between catching it and missing it.

How DCSync compares to other credential dumping

DCSync is one route to a domain's hashes among several, and the differences explain why defenders treat it as its own problem.

DCSync stands apart because it needs neither local access to the domain controller nor a prior logon by the target user. It reaches the authoritative source of every hash from a distance, using rights rather than an exploit. NTDS.dit extraction gets the same data but requires running on the domain controller, which leaves far more local evidence. LSASS dumping only yields the credentials of accounts that have authenticated on that particular machine. The reach and the low local footprint together are why DCSync is the preferred move once an attacker holds, or can grant themselves, the replication rights.

Detection deep dive: the event 4662 signal

The most reliable host-side evidence sits in event ID 4662, "An operation was performed on an object," logged under directory service access auditing on domain controllers. A DCSync request generates a 4662 recording access to the domain naming context using the control-access rights that correspond to replication. The GUIDs to watch for in these events are stable and worth knowing:

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 is DS-Replication-Get-Changes.
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 is DS-Replication-Get-Changes-All.
• 89e95b76-444d-4c62-991a-0facbeda640c is DS-Replication-Get-Changes-In-Filtered-Set.

A 4662 event referencing these rights is normal when the subject is a domain controller computer account. The same event with a user account or an unexpected service account as the subject is the DCSync tell. The high-value refinement is to combine the event's subject with network context. Legitimate replication originates from domain controllers, so a replication-of-changes request whose network source is a workstation or member server is anomalous regardless of which account it used.

Auditing has to be turned on for this to exist. Directory service access auditing is not always enabled by default at the granularity needed, and the volume can be significant, so many environments learn they had no 4662 trail only during an incident. Enabling the relevant subcategory and forwarding the events off the domain controller is the prerequisite for every detection above. Our guide to Windows event IDs for security maps these to the wider auditing picture.

Common misconceptions

Several beliefs about DCSync lead teams to defend the wrong thing.

• "An attacker needs to be on the domain controller." They do not. That is the entire point of DCSync. Replication rights and network reachability are enough, from any host.
• "Endpoint protection on the domain controller will catch it." Host tooling on the domain controller sees a normal inbound replication conversation. There is no malicious process to flag on the box. The evidence is in auditing and network context, not in a local detonation.
• "Only Domain Admins can do it, so it is covered by protecting those accounts." Protecting privileged accounts matters, but the rights can be delegated to non-admin principals, and misconfigurations grant them to service or application accounts. The correct scope is everyone who holds the replication rights, which is often broader than the admin groups.
• "Blocking the tools stops it." DCSync is a protocol conversation, not a single tool. Any implementation that speaks GetNCChanges with the right permissions works. Detection has to target the behavior, the replication request from a non-domain-controller, not a specific binary.
• "A read-only domain controller is safe to abuse the same way." Read-only domain controllers are designed not to hold most secret attributes and do not replicate them outbound in the same manner, which changes the exposure. The writable domain controllers are the ones that answer a full DCSync.

How the technique developed

DCSync entered common use when tooling made the DRSUAPI replication call scriptable for attackers, turning what had been a protocol detail into a repeatable credential-access technique. Its significance grew because it pairs so cleanly with Golden Ticket forgery: pulling the krbtgt hash by replication and then forging tickets became a standard end-to-end path to durable domain control. Defenders responded by focusing on the two properties the protocol cannot hide, the identity of the requesting principal and the network origin of the request, and by tightening the delegation of replication rights that attackers had been quietly abusing. The technique itself has not needed to change, because it rides a feature that Active Directory cannot remove, which is exactly why it remains a fixture of post-exploitation in Windows domains.

Responding to a confirmed DCSync

Treating a confirmed DCSync as total domain credential compromise sets the right scope for response. The material an attacker pulled does not expire on its own, so containment means invalidating the credentials rather than simply evicting the tool. That involves resetting the krbtgt password twice with the required interval between resets so that tickets signed with the old key are rejected, forcing reset of privileged account passwords, and reviewing every principal that held replication rights for signs of abuse or unauthorized grant. Because the attacker likely reached the replication rights from an already-privileged position, the investigation also has to work backward to how that position was gained, since the same path remains open until it is closed. Rebuilding trust in the domain after a krbtgt exposure is deliberate and slow, which is the strongest argument for keeping the replication rights scarce in the first place.

Frequently asked questions

Does DCSync work against a single domain controller or does it need several? It needs one reachable, writable domain controller that will answer a GetNCChanges request. Replication is a peer feature, so any writable domain controller is a valid target for the request.

Can DCSync pull cleartext passwords? It pulls the stored secret material: NTLM hashes, password history, and Kerberos keys. Where reversible encryption is enabled for accounts, the supplemental credentials can yield cleartext-equivalent data, which is one reason reversible encryption should stay off.

Is the krbtgt account the only high-value target? It is the highest-value single target because its hash enables Golden Ticket forgery, but a full DCSync typically requests every account, which hands the attacker the whole domain's credential material for cracking and reuse.

Will resetting one password stop the impact? Resetting an exposed user's password helps for that account, but a DCSync that captured krbtgt requires resetting the krbtgt password twice, in the prescribed manner, to invalidate forged tickets. A single reset is not sufficient for krbtgt.

How is DCSync different from a Silver Ticket attack? DCSync is a credential-access technique that extracts hashes over replication. A Silver Ticket forges a service ticket using an already-known service account key. They operate at different stages and are not substitutes.

Can network segmentation alone prevent it? Restricting which hosts may speak the replication protocol to domain controllers cuts off DCSync from arbitrary machines, which is a strong control. It works best combined with least privilege on the replication rights, so an attacker who does land on a permitted host still lacks the rights to ask.

What is the fastest way to know if we are exposed today? Audit the domain object's ACL for every principal holding Replicating Directory Changes and Replicating Directory Changes All, and confirm directory service access auditing is enabled and forwarded. Those two checks tell you both who could perform DCSync and whether you would see it.

The bottom line

DCSync is dangerous precisely because it uses a core, legitimate feature of Active Directory. There is no exploit to patch and no malware to detect on the domain controller. The protocol answers the request because the requester holds the rights to ask. Defense follows from that: keep the replication rights in as few hands as possible, audit who holds them, and alert on any replication request that does not come from a real domain controller. Treat a confirmed DCSync as full domain credential compromise and respond accordingly.

Related guides

• Golden Ticket Attack Explained
• Pass the Hash Explained
• Active Directory Security Basics
• Windows Event IDs for Security