The night a domain controller replicated every password (Event 4662)

The scenario is fictional (10.0.0.0/8). Event and PowerShell details are from the book, not tested live. Detection only.

A domain controller holds everyone's credentials. That night it handed them over voluntarily: the attacker simply asked to replicate.

What you'll learn

• Why DCSync works and the log it leaves (4662)
• Three replication GUIDs and the decisive condition: requester isn't a DC
• A PowerShell check from the book, false positives
• Recovery: reset krbtgt twice

The story at a glance (SIEM timeline)

Time	Host	Event
09:12:40	WS01	lsass access
09:14:05	FS01	4624 Type 3 NTLM, Administrator, source WS01
09:14:30	FS01	5140 ADMIN$
09:15:50	DC01	SMB from FS01
09:16:20	DC01	4662 replication GUID
09:18	WS01	log ingestion stops

Administrator normally logs in only via the bastion; from WS01 it suggests pass-the-hash.

The signal

4662 containing 1131f6aa, 1131f6ad or 89e95b76, requested by an account that is not a domain controller.

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4662} |
  Where-Object { $_.Message -match '1131f6aa|1131f6ad|89e95b76' -and
                 $_.Message -notmatch 'DC0\d\$' }

Adjust the DC naming pattern to your environment; test on a lab domain first.

False positives

DC-to-DC replication (exclude DC machine accounts) and sync tools like Azure AD Connect (allow-list the account and fix its source IP).

Recovery

Assume all credentials are exposed: reset krbtgt twice, with a wait between resets.

Next: the same user's credentials, in the cloud.

---

Adapted from chapter 23 and Scenario B of my Japanese book on server defense.