Windows Event ID 4794 — DSRM Admin Password Set

MITRE ATT&CK

Why It Matters

The DSRM account is a local administrator account on every domain controller, designed for offline AD recovery. Critically, it is independent of Active Directory itself — it works even when AD services are stopped or the DC is booted into Directory Services Restore Mode. Attackers who reach Domain Admin level use Event 4794 to establish a DSRM backdoor: by setting a known DSRM password and enabling network logon for DSRM (registry: DsrmAdminLogonBehavior = 2), they gain a persistent local admin credential on the DC that survives password resets of all domain accounts, AD object cleanups, and even domain rebuilds on the same hardware. This technique is used by APT groups specifically because it is resilient against standard incident response. There is no legitimate reason to change the DSRM password outside of a documented DC rebuild or disaster recovery drill — any 4794 outside that context is a confirmed incident.

Key Fields

Investigation Tips

1. 1.Zero-tolerance policy: any 4794 not matching a documented DC build or DR test procedure is a critical incident. Immediately verify with the responsible team whether this was authorized — do not assume it was.
2. 2.Check DsrmAdminLogonBehavior registry value (HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior): value 2 enables DSRM for network logon even when AD is online — a value of 2 set alongside a 4794 means the attacker has created a fully weaponized network-accessible backdoor on the DC.
3. 3.Correlate with the DC compromise chain: 4794 typically follows credential dumping (4663 on LSASS), log clearing (1102), or mass privilege grants (4728). Check 60–120 minutes of events before the 4794 on the same DC.
4. 4.Check 4624 for DSRM account logons: if the attacker immediately tests their backdoor, look for logons with Account Name matching the local DC Administrator account from unexpected source IPs shortly after the 4794.
5. 5.Incident response: changing the domain account passwords does NOT invalidate the DSRM backdoor. To remediate: (1) reset DSRM password to a unique random value via ntdsutil, (2) set DsrmAdminLogonBehavior back to 0, (3) audit all DC administrative access during the compromise window.

Detection Logic (KQL)

Microsoft Sentinel (KQL) — any 4794 event is a high-fidelity alert; no threshold needed. The second query checks whether DSRM was also enabled for network logon via registry.

// Any DSRM password change — alert immediately, no threshold
SecurityEvent
| where EventID == 4794
| project TimeGenerated, SubjectAccount, TargetAccount,
    Computer, SubjectLogonId
| extend Alert = "DSRM password changed — verify against DR documentation"
| sort by TimeGenerated desc

// Correlate with log clearing (DC compromise pattern)
SecurityEvent
| where EventID in (4794, 1102)
| summarize Events=make_list(EventID), Times=make_list(TimeGenerated) by Computer
| where Events has "4794" and Events has "1102"
| extend Alert = "DSRM change + log clear on same DC = high-confidence compromise"

Related Event IDs