Detecting DCSync Attacks

DCSync is credential theft without touching the domain controller. Instead of dumping LSASS on a DC, the attacker asks a DC for password hashes using the same replication protocol domain controllers use to sync with each other — and if they hold the right replication permissions, the DC hands over the hashes of anyone, including krbtgt and domain admins. The detection is precise: a replication request from something that is not a domain controller. This guide ships that signal and the least-privilege fix.

DCSync maps to MITRE ATT&CK T1003.006 — OS Credential Dumping: DCSync, yielding T1078 — Valid Accounts at the highest level. It sits alongside Kerberoasting, NTLM relay, and AD CS abuse in the Active Directory attack surface — and it is often the final step after them.

What is a DCSync attack?

Domain controllers keep each other in sync by replicating directory data, including secrets, over the MS-DRSR protocol. DCSync abuses that: an attacker who holds the replication extended rights sends a replication request to a DC as if they were another DC, and the DC returns the requested account’s password hashes — NTLM hashes, Kerberos keys, everything. No malware runs on the DC; it is a legitimate protocol used illegitimately.

The prize is usually krbtgt (whose hash forges Golden Tickets) or domain admin accounts. DCSync is typically the payoff after an earlier escalation granted the replication rights, which is why detecting the replication request itself is such a valuable backstop.

What does DCSync look like, and how is it reached?

The unifying fact: replication is a DC-to-DC operation, so a replication request from a workstation or a user account is definitionally abnormal. That is the whole detection.

How to detect DCSync

Enable auditing of directory service access, then alert on the replication request from a non-DC account.

title: Directory Replication Requested by a Non-DC Account
id: 7a3d1f92-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'   # DS-Replication-Get-Changes-All
  filter_dc:
    SubjectUserName|endswith: '$'                # exclude DC machine accounts
  filter_known_dcs:
    SubjectUserName|contains: 'DC0'              # tune to your DC naming/allowlist
  condition: selection and not (filter_dc and filter_known_dcs)
falsepositives:
  - Domain controllers (allowlist their machine accounts precisely)
  - Approved directory-sync services (e.g. Entra Connect) — allowlist explicitly
level: high

What does DCSync actually give the attacker?

“Password hashes” undersells it, and the full inventory changes the response decision.

A successful replication request returns the credential material the directory holds:

• NTLM hashes for every account in the domain. Immediately usable for pass-the-hash, and offline crackable for anywhere the plaintext is reused.
• Kerberos keys, including AES. These forge tickets directly, without needing the plaintext.
• Password history. Where a rotation policy produces predictable variations, history exposes the pattern rather than a single secret.
• The krbtgt key — the Golden Ticket. With it, an attacker mints Kerberos TGTs for any user, including accounts that do not exist, valid until krbtgt is properly reset.
• Trust account keys. These forge inter-realm tickets, which extends the compromise across domain and forest trusts. This is the one most often missed: DCSync on one domain can become authentication into a trusting domain you were treating as a separate blast radius.

Two things it does not directly hand over, which is worth knowing so the response is scoped accurately: gMSA passwords and LAPS local-administrator passwords are read through their own LDAP attributes and require their own rights. An attacker with enough privilege to obtain replication rights very likely has those too — but they are separate operations with separate telemetry, and they are worth checking rather than assuming in either direction.

The practical conclusion: DCSync is not a credential-theft incident, it is a domain compromise. Every account’s credentials are disclosed simultaneously, and the trust keys mean the boundary of the incident may extend past the domain where it was detected.

Who legitimately holds replication rights?

Before hunting for anomalies, establish the baseline, because the legitimate list is short and predictable.

That fourth row deserves attention. Directory-sync service accounts hold exactly the rights DCSync needs, they are non-interactive, they are often excluded from monitoring as “known noisy,” and the server they run on is frequently managed as a regular member server rather than as Tier 0. An attacker who compromises that host inherits domain-wide credential access without needing to escalate in Active Directory at all.

Three things follow:

• Treat the directory-sync server as Tier 0. It holds a credential equivalent to domain compromise, so it belongs in the same tier as the domain controllers.
• Allowlist the sync account by name, and alert on it doing anything unusual — replicating from a different source host, at an unusual time, or targeting accounts outside its normal scope. Excluding it entirely converts it into the safest possible route for an attacker.
• Enumerate the actual holders rather than assuming the defaults. Domain object ACLs accumulate grants over years — a monitoring product, a migration tool, an audit appliance. Each one is a DCSync path, and the list is almost never what people expect.

Why Event 4662 may not be logging what you think

The detection depends on 4662 carrying the replication GUIDs, and there are two independent configuration requirements. Missing either produces silence rather than an error.

1. The audit subcategory. Audit Directory Service Access must be enabled on domain controllers. It is not on by default in every configuration.
2. The SACL on the domain object. Event 4662 is generated because a system access control list on the object requests auditing for that access. Without an appropriate SACL on the domain root, the replication access occurs and generates no event. This is the requirement that is missed most often, because the subcategory being enabled feels like the whole job.

Verify empirically rather than by reading configuration. In a lab, or with a controlled test in production, perform a legitimate replication and confirm a 4662 appears containing 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2. If it does not, no amount of rule tuning helps.

Be aware of the volume tradeoff as well. Auditing directory service access broadly generates an enormous number of events on a busy domain controller. The SACL should be scoped so you get the replication accesses you need without ingesting every directory read in the environment — an unscoped configuration is usually switched off within a month for cost reasons, which is a worse outcome than a narrow one that survives.

Add a second, independent detection. The replication request is an MS-DRSR (DRSUAPI) RPC call, and DRSGetNCChanges traffic to a domain controller from a host that is not a domain controller is visible at the network layer. That gives you a detection that does not depend on the DC’s audit configuration at all — useful precisely because an attacker at this privilege level can change that configuration.

The ACL grant is the earlier and better signal

DCSync fires at the end of the kill chain. By the time the replication request appears, the attacker already holds rights that only a highly privileged principal could have granted — which means they were effectively domain admin before your high-fidelity detection fired.

The earlier signal is the grant itself. Event ID 5136 records modification of a directory object, and a change to the nTSecurityDescriptor attribute on the domain head is where the replication right appears. Alert on it:

• Modifications to the domain object’s security descriptor are rare, deliberate, and consequential. This is close to an ideal alerting candidate.
• The alert fires when the attacker is establishing capability, not when they are using it — potentially hours or days earlier.
• It also catches the misconfiguration case: a well-meaning administrator granting a monitoring product broad rights, which is the origin of a meaningful share of the paths an attack graph finds.

Run the standing audit alongside it. Enumerate the principals holding Get-Changes and Get-Changes-All on a schedule and diff the result against the previous run. Attack-path tools report this by default, and the recurring diff is what catches a grant made by someone with legitimate rights and no ill intent — which is how most of these appear.

How do you actually reset krbtgt?

If DCSync is confirmed, the krbtgt key is compromised and Golden Tickets are possible until it is properly rotated. The procedure has a detail that determines whether it works at all.

Active Directory retains the current and the previous krbtgt password. Tickets signed with the previous key are still accepted — deliberately, so that a rotation does not instantly break every outstanding ticket. Consequently, a single reset does not invalidate the attacker’s key: it simply moves it into the previous slot, where it remains valid.

Two resets are required. The interval between them is the part that goes wrong:

1. Reset once. The compromised key becomes the previous key and still works.
2. Wait for full replication convergence across every domain controller, and for outstanding tickets to age out — the guidance is to allow at least the maximum ticket lifetime, commonly 10 hours, and longer in a large or poorly converged forest.
3. Reset a second time. The compromised key is now displaced entirely.

Resetting twice in quick succession, before replication converges, is the classic failure: domain controllers end up disagreeing about the key, and authentication breaks domain-wide. This is a genuinely disruptive outage, and it happens under exactly the time pressure an incident creates. Microsoft publishes a script for this specific reason; use it rather than resetting the account by hand, and confirm replication health before the second reset rather than trusting a timer.

Read-only domain controllers have their own krbtgt accounts requiring separate treatment, and trust keys should be rotated too if trust account keys were disclosed — otherwise the cross-domain path this attack opened remains open after the domain itself is remediated.

How to test your DCSync detection

In an isolated AD lab you own:

1. Grant a test account the replication rights and run a DCSync tool against a lab DC; confirm Event ID 4662 with the replication GUIDs fires and the rule alerts.
2. Confirm normal DC-to-DC replication (from allowlisted machine accounts) does not alert.
3. Confirm an approved sync service, once allowlisted, stays quiet.
4. Verify the alert escalates when the target is krbtgt.

How to prevent DCSync

• Audit domain-object ACLs regularly (BloodHound flags dangerous replication rights).
• Alert on ACL grants of replication rights as a leading indicator.
• Harden the escalation paths that lead here — AD CS and NTLM relay.

How do you respond to confirmed DCSync?

This is a domain-compromise response, and its defining characteristic is that the usual containment instincts are insufficient. You cannot isolate your way out of disclosed credentials.

1. Identify which accounts were replicated. The 4662 events name the objects accessed. If the request was domain-wide, treat every credential in the domain as disclosed and stop trying to scope it more narrowly — the effort is better spent elsewhere.
2. Establish how the rights were obtained. This is the actual intrusion. The replication is the payoff; the ACL grant, the escalation, or the compromise of a sync server is the incident. Work backwards to it before doing anything irreversible.
3. Remove the illegitimate rights immediately, and audit every other principal at the same time. An attacker who granted themselves one path frequently granted a second.
4. Rotate krbtgt twice with convergence between resets, per the procedure above. Until this completes, Golden Tickets remain forgeable and every other remediation is provisional.
5. Reset credentials on a plan, worst-first. Tier 0 accounts, service accounts, then the general population. Service accounts are where this stalls, because rotating them breaks applications nobody has documented — which is a reason to have that inventory before an incident, not a reason to skip them.
6. Rotate trust keys if trust accounts were in scope, and notify the owners of trusting domains. This is the step that most often falls through an organisational gap, because the affected environment belongs to someone else.
7. Hunt for persistence established with the disclosed credentials. Golden Tickets, Silver Tickets, certificate-based persistence via AD CS, and new accounts. Certificate-based persistence is the one that survives every password reset, which makes it the highest-priority hunt after the rotation.
8. Decide honestly whether the forest is recoverable in place. Where an attacker held domain dominance for an extended period, a full rebuild is sometimes the shorter path. It is a large decision and it should be made deliberately rather than arrived at after months of incomplete remediation.

Step 7 deserves emphasis because it defeats the obvious remediation. An attacker who used their domain access to obtain or forge certificates holds credentials that are unaffected by resetting every password in the environment, and that remain valid for the certificate’s lifetime. A DCSync response that stops at credential rotation can leave the intruder’s access completely intact — and looking clean.

Order matters throughout. Removing the rights before understanding how they were obtained tells the attacker they are detected while they still hold working credentials for every account in the domain. Where the intrusion is recent and contained, move fast; where the attacker has clearly been present for some time, a short period of controlled observation to map their access is usually worth more than the hours it costs.

Common DCSync detection mistakes

• Not auditing directory service access. No 4662, no detection.
• Alerting on all 4662. Filter to the replication GUIDs; allowlist DCs.
• Forgetting sync services. Entra Connect replicates legitimately — allowlist it.
• Missing the ACL-grant precursor. The rights are granted before they’re used.
• Enabling the audit subcategory but not the SACL. Both are required; with only one, the access happens and no event is generated. Verify with a real replication, not by reading config.
• Excluding the directory-sync account entirely. It holds exactly the rights DCSync needs, and a blanket exclusion makes it the safest route an attacker could pick.
• Managing the sync server as a member server. It holds a domain-compromise-equivalent credential and belongs in Tier 0.
• Relying only on DC-side auditing. An attacker at this privilege level can change it. A network detection on DRSGetNCChanges from a non-DC is independent of the DC’s configuration.
• Scoping the incident to the domain. Trust account keys forge inter-realm tickets, so trusting domains are in scope until proven otherwise.
• Resetting krbtgt once. The old key moves to the previous slot and remains valid; two resets are required.
• Resetting krbtgt twice in quick succession. Without replication convergence between them, domain controllers disagree about the key and authentication breaks domain-wide.
• Forgetting RODC krbtgt accounts and trust keys. They rotate separately, and skipping them leaves the cross-domain path open after the domain looks remediated.

DCSync detection checklist

1. Enable auditing of directory service access (Event ID 4662).
2. Alert on 4662 with the replication GUIDs (1131f6aa / 1131f6ad).
3. Allowlist domain controller machine accounts and approved sync services precisely.
4. Escalate when the targeted account is krbtgt or a domain admin.
5. Audit and remove replication rights from non-DC principals.
6. Monitor ACL changes on the domain object for granted replication rights.
7. Protect Tier 0 accounts; plan a double krbtgt reset for suspected DCSync.
8. Test with a lab DCSync and confirm normal replication stays quiet.

The takeaway

Detecting DCSync is a single high-fidelity rule: Event ID 4662 carrying the replication GUIDs from a non-domain-controller account, with your DCs and sync services allowlisted. Remove the replication rights from everything that isn’t a DC, and watch the ACLs that grant them. Continue with NTLM relay detection and AD CS abuse detection, or browse the full Detection Engineering pillar.