The DC That Phoned Home: Hunting DCSync Credential Theft

Case file TH-008. The domain admin passwords were changed on Friday. By Monday, the attacker was back in with full domain dominance — and nobody had phished anyone or exploited anything new over the weekend. The evidence was hiding in plain sight in the directory replication logs: a helpdesk workstation in HR had been quietly asking the domain controller for every password hash in the domain, and the domain controller had been politely handing them over.

This is DCSync. An attacker who holds the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights — on the domain object, on a user, or via membership in a privileged group — can impersonate a domain controller and request replication of credentials, including the krbtgt account. Mimikatz's lsadump::dcsync turned this into a one-liner years ago, and it remains the quietest way to steal an entire directory: no LSASS access, no malware on the DC, just a legitimate protocol doing exactly what it was designed to do.

This hunt looks for replication that comes from somewhere it shouldn't.

The hypothesis

If an attacker is stealing credentials via DCSync, then directory replication traffic will originate from a host or account that is not a legitimate domain controller or sync engine — and that source will have no historical baseline of replication activity, or will suddenly replicate far outside its normal pattern.

Data you'll need

Source	What it gives you
IdentityDirectoryEvents (ActionType == "Directory Services replication")	Defender for Identity's view of every replication request: source device, IP, and actor account.
SecurityEvent, Event ID 4662 on DCs	Object-access audit showing the replication extended rights GUIDs being exercised — the ground truth.
Defender for Identity alerts	"Suspected DCSync attack (replication of directory services)" — useful, but don't rely on it alone.
Splunk: index=wineventlog	Forwarded DC security logs; filter 4662 on the two replication GUIDs below.

Prerequisite that decides everything: Event 4662 only fires if Audit Directory Service Access is enabled on your domain controllers. If it isn't, the KQL hunt on IdentityDirectoryEvents is your primary lens — verify the auditing gap and fix it as part of the response.

Hunting with KQL

This query builds a 30-day baseline of who replicates normally, then flags any replication in the last day from a source with no such history — excluding your known DCs and sync accounts.

// Hunt H-DCSYNC-01: replication from sources with no historical baseline
let KnownDCs = dynamic(["DC01", "DC02"]);              // <-- fill in yours
let KnownSyncAccounts = dynamic(["MSOL_", "ADSync", "svc-backup"]);
let Baseline =
    IdentityDirectoryEvents
    | where Timestamp between (ago(30d) .. ago(1d))
    | where ActionType == "Directory Services replication"
    | extend Actor = tostring(parse_json(AdditionalFields)["ACTOR.ACCOUNT"])
    | summarize SyncCount = count(), ActiveDays = dcount(startofday(Timestamp))
        by DeviceName, IPAddress, Actor
    | where SyncCount > 10 or ActiveDays > 5;
IdentityDirectoryEvents
| where Timestamp > ago(1d)
| where ActionType == "Directory Services replication"
| extend Actor = tostring(parse_json(AdditionalFields)["ACTOR.ACCOUNT"])
| where isnotempty(Actor)
| where DeviceName !in (KnownDCs)
| where not(Actor has_any (KnownSyncAccounts))
| join kind=leftanti (Baseline) on DeviceName, IPAddress, Actor
| summarize Syncs = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            Targets = make_set(DestinationDeviceName, 20)
        by DeviceName, IPAddress, Actor
| order by Syncs desc

What this does, in plain English: it learns what normal replication looks like for a month — domain controllers replicating with each other, Entra Connect syncing — and then asks a simple question about the last 24 hours: who replicated that has never (or barely ever) done so before, and isn't on the allowlist? DCSync from an attacker's workstation has no baseline. Legitimate replication always does.

Walkthrough: how the query reads the evidence

• ActionType == "Directory Services replication" is Defender for Identity's normalized record of a replication request hitting a DC — the exact operation DCSync abuses.
• parse_json(AdditionalFields)["ACTOR.ACCOUNT"] extracts the account performing the replication. In a DCSync attack, this is the compromised account, not a machine account.
• The Baseline subquery is the false-positive killer: anything that replicated more than 10 times (or on more than 5 days) in the last month is, by definition, part of normal operations.
• join kind=leftanti keeps only current replication sources absent from the baseline — the statistical definition of "new and unexpected."
• The allowlists (KnownDCs, KnownSyncAccounts) handle your environment's known-good replicators; the baseline handles everything else, including the sync tool you forgot was installed.

Example: what a true positive looks like

Field	Value	Why it matters
DeviceName / IPAddress	WS-HR-114 / 10.4.18.62	An HR workstation — not a DC, not a sync server, never replicated before
Actor	svc-print	A print service account with replication rights it should never have
Syncs / window	4,812 requests in 20 minutes, 02:10–02:30	Bulk pull of the directory at 2 AM — the signature of a full DCSync dump
Targets	DC01	Replication requested from the primary domain controller

Hunting with Splunk

The ground-truth version: Windows Event 4662 on the domain controllers, filtered on the two extended-right GUIDs that DCSync must exercise. No GUID match, no replication — this is as close to definitive as log-based detection gets.

index=wineventlog EventCode=4662
| where like(Properties, "%1131f6aa-9c07-11d1-f79f-00c04fc2dcd2%")
     OR like(Properties, "%1131f6ad-9c07-11d1-f79f-00c04fc2dcd2%")
| rename ComputerName as dc, SubjectUserName as requestor, IpAddress as src_ip
| stats count as replication_requests, earliest(_time) as first_seen,
        latest(_time) as last_seen, values(dc) as dcs by requestor, src_ip
| where NOT match(requestor, "(?i)^(MSOL_|ADSync|svc-backup)")
| sort - replication_requests

What this does, in plain English: it scans DC security logs for anyone exercising the DS-Replication-Get-Changes (...f6aa...) or DS-Replication-Get-Changes-All (...f6ad...) rights, then rolls the events up by requesting account and source IP. High request counts from a non-sync account are DCSync until proven otherwise.

Example hit

requestor=svc-print  src_ip=10.4.18.62  replication_requests=4812
first_seen=2026-09-27 02:10:04  last_seen=2026-09-27 02:30:41  dcs=DC01

Validating the hit

1. Confirm the source isn't legitimate. Is the device a DC, an Entra Connect server, or a backup product with replication rights? If yes, tune the allowlist. If it's a workstation, escalate.
2. Interrogate the actor account. How did svc-print get replication rights? Check the DACL on the domain object and group memberships — attackers grant themselves Get-Changes-All via DCSync-enabling ACEs, and the grant itself is logged in 4662/5136.
3. Look for what came after. DCSync is a means, not an end: hunt for Golden Ticket indicators (TGTs with anomalous lifetimes, krbtgt logons from unusual hosts), new privileged accounts, and lateral movement from the source workstation.
4. Scope the theft. A successful DCSync yields every hash, including krbtgt. Assume full directory compromise for any account that existed during the replication window — scope the response accordingly, not optimistically.

Tuning out false positives

• Entra Connect / AD Connect sync: the MSOL_ and ADSync accounts replicate constantly by design — allowlist them permanently.
• DC-to-DC replication: both endpoints are domain controllers replicating on schedule; the baseline subquery absorbs this automatically.
• New DC promotions: a freshly promoted DC replicates heavily for the first time and has no baseline. Correlate with change records before panicking.
• Backup and DR tools: some backup products request replication rights. They replicate on a schedule from known hosts — allowlist by host and account, never by account alone.

What to do next

• Isolate the source host immediately and disable the compromised account. Treat the workstation as fully compromised.
• Reset the krbtgt password twice to invalidate any Golden Tickets, then force a full password reset across the domain — DCSync means every hash is burned.
• Remove the attacker's foothold: strip the rogue replication ACEs from the domain object DACL and audit privileged group memberships for additions made during the intrusion window.
• Find the entry point: determine how the actor account was compromised in the first place (the DCSync is step three of the attack, not step one) and hunt for persistence — scheduled tasks, new services, shadow credentials.
• Close the visibility gap: enable Audit Directory Service Access on all DCs if it wasn't on, and promote this hunt to a scheduled detection rule.

When the directory itself is the credential store, replication is exfiltration. Watch who asks. — Amit Vijayan