ADDOM-020: DSRM Password Configuration
- Platform
- Active Directory
- Category
- AD Domain & Forest Configuration
- Severity
- Medium
- Zero Trust pillar
- Governance (weight 1)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
Guerrilla reads the registry value DsrmAdminLogonBehavior under HKLM\System\CurrentControlSet\Control\Lsa on every reachable domain controller. The expected REG_DWORD values are 0 (DSRM account can only log on when the DC is booted into DSRM), 1 (DSRM account can log on when the local AD DS service is stopped), and 2 (DSRM account can always log on, including over the network, the dangerous setting). The check fails when the value is 2 or when the value is missing on a DC that has DsrmAdminLogonBehavior tampering history. The cmdlet also inspects the LastPasswordChange timestamp on the DSRM account where available via Get-ADDSRMPassword instrumentation, reports the age of the DSRM password per DC, and flags cases where the same DSRM password hash appears on multiple DCs (uniformity is a strong indicator that no per-DC rotation has occurred since promotion).
Why it matters
The DSRM account is a local administrator on the domain controller. It is stored in the registry SAM hive (not NTDS.dit) and is the recovery backstop when AD DS will not start. Microsoft introduced DsrmAdminLogonBehavior in Windows Server 2008 specifically because the DSRM hash is recoverable from any prior DC compromise: it sits in the SAM, it is rarely rotated, and on most networks the same string was typed into every DC promotion wizard. With DsrmAdminLogonBehavior = 2 the attacker can authenticate to a DC over SMB or RDP as a local administrator without ever needing a domain credential, then perform DCSync, dump LSASS, or push a backdoor service. With DsrmAdminLogonBehavior = 0 the same hash is essentially useless for remote access, the attacker would need physical or out-of-band console access and the ability to reboot the DC into DSRM mode. The misconfiguration also enables a persistence pattern: a previously-domain-admin attacker can extract the DSRM hash, lose all domain credentials in a password reset, and still return to the DC weeks later if DsrmAdminLogonBehavior was set to 2 during the original compromise.
Attack path
The attack chain starts with the attacker obtaining the DSRM password hash. Common sources are: an offline NTDS.dit and SYSTEM hive copy (the SYSTEM hive contains the boot key needed to decrypt SAM, and a backup operator with VSS rights can produce both), a memory dump of a domain controller (LSASS or the SAM cache), or simply a prior Domain Admin compromise where the attacker ran reg save HKLM\SAM. Mimikatz (lsadump::sam) and impacket secretsdump.py both surface the DSRM hash directly. With the hash in hand, the attacker checks DsrmAdminLogonBehavior. If set to 2, the attacker can pass-the-hash to the DC using the local Administrator account name and the DSRM NTLM hash (impacket psexec.py, wmiexec.py, smbexec.py, or Mimikatz sekurlsa::pth) and obtain local SYSTEM on the DC. From there, the attacker drops a service, registers a scheduled task as SYSTEM, runs Mimikatz lsadump::dcsync to extract the krbtgt hash and forge golden tickets, or installs a Skeleton Key. Because DSRM is a local SAM account, no domain authentication event is generated, the only artifact is a 4624 logon event with logon type 3 (network) showing the DSRM account name authenticating from the attacker host. Sean Metcalf publicly demonstrated this end-to-end persistence chain in 2015 and it remains a recurring finding in Mandiant incident response engagements.
How Guerrilla assesses it
Guerrilla enumerates domain controllers via Get-ADDomainController -Filter * and connects to each over WinRM (or falls back to remote registry where allowed). On each DC, it reads HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior and records the REG_DWORD value. The check then enumerates the System event log for source Directory-Services-SAM and event ID 16969 (DSRM password change events written when ntdsutil set dsrm password runs), extracts the most recent change time per DC, and computes the age in days. Where the auditor has read access, the cmdlet pulls the DSRM account hash via remote registry SAM enumeration and compares the hash digest across DCs to flag identical DSRM passwords reused across the fleet. Output includes per-DC values for DsrmAdminLogonBehavior, last DSRM password change date, password age in days, and a uniqueness flag.
Recommended value
DSRM password unique per DC, rotated annually, and stored securely. DsrmAdminLogonBehavior set to 0 to prevent network DSRM logon
Remediation
Reset DSRM passwords using 'ntdsutil > set dsrm password' on each DC. Set the registry value DsrmAdminLogonBehavior to 0 at HKLM\System\CurrentControlSet\Control\Lsa to prevent DSRM account from being used for network logon. Document and securely store passwords
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| degraded | WARN |
| known-bad | FAIL |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- IA-5(1), AC-6
- ANSSI
- R10
- CIS AD Benchmark
- 1.2.4
- MITRE ATT&CK
- T1003, T1078.002