DSRM password change
The Directory Services Restore Mode (DSRM) administrator password was changed on a domain controller — Security event 4794.
What it detects
The Directory Services Restore Mode (DSRM) administrator password was changed on a domain controller — Security event 4794. DSRM is the local administrator account a DC falls back to when Active Directory is offline, and its password is set once at promotion and then, on most estates, never touched again.
Changing it is a known persistence step: with the DSRM password known and the DsrmAdminLogonBehavior registry value flipped, an attacker can log on to the DC as a local administrator with credentials that do not live in AD, survive every domain password reset, and bypass the controls that watch domain accounts. 4794 is the only trace the change leaves.
MITRE ATT&CK mapping
- T1098Account Manipulation· Persistence
False positives and triage
Rare by design, which is what makes it worth a high severity on a single event. Legitimate changes happen when a DC is promoted, when an organisation rotates the DSRM password as part of a hardening baseline, or when an administrator syncs it to a domain account with ntdsutil "set dsrm password" "sync from domain account". All three are scheduled, documented work. An unplanned 4794, especially from a session that was not expected to be on a domain controller, warrants the question of who had that session and why.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/windows/dsrm_password_change.yaml, licensed under the Apache License 2.0.
id: windows.credential.dsrm_password_change
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [windows]
mitre_techniques: [T1098]
description: |
The Directory Services Restore Mode (DSRM) administrator password was changed on a
domain controller — Security event 4794. DSRM is the local administrator account a
DC falls back to when Active Directory is offline, and its password is set once at
promotion and then, on most estates, never touched again.
Changing it is a known persistence step: with the DSRM password known and the
`DsrmAdminLogonBehavior` registry value flipped, an attacker can log on to the DC as
a local administrator with credentials that do not live in AD, survive every domain
password reset, and bypass the controls that watch domain accounts. 4794 is the
only trace the change leaves.
match:
native_event_id: '4794'
source_channel: Security
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Rare by design, which is what makes it worth a high severity on a single event.
Legitimate changes happen when a DC is promoted, when an organisation rotates the
DSRM password as part of a hardening baseline, or when an administrator syncs it
to a domain account with `ntdsutil "set dsrm password" "sync from domain account"`.
All three are scheduled, documented work. An unplanned 4794, especially from a
session that was not expected to be on a domain controller, warrants the question
of who had that session and why.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.