Detecting DSRM Admin Logon and Skeleton Key Persistence

Two domain-controller persistence techniques are worth separate treatment. The Directory Services Restore Mode (DSRM) account is a local administrator on every DC; setting DsrmAdminLogonBehavior lets it log on while the DC is online. Skeleton Key patches LSASS so that a master password authenticates as any user alongside the real one. They are rare in the wild, high in impact, and detectable from changes only privileged administrators should ever make.

Signals at a Glance

DSRM Abuse

By default the DSRM account can only be used when a DC is booted into Directory Services Restore Mode. Setting DsrmAdminLogonBehavior to 2 lets it authenticate on a running DC, which gives an attacker a local administrator credential that survives domain password resets. Two events matter: the registry change and the password set. The value is rarely touched in production, so any change is suspect:

title: DSRM Administrator Logon Behavior Changed
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    TargetObject|endswith: '\Control\Lsa\DsrmAdminLogonBehavior'
  condition: selection
level: high
# tune/validate: should be near-zero on healthy DCs; alert on any value other than 0.

Event 4794 is generated when someone sets the DSRM password, normally with ntdsutil during DC recovery planning. Alert on it and require a change ticket. To verify state across the DC fleet, check the value directly and look for DSRM account logons:

# PowerShell: run on each DC
$v = (Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Lsa' -ErrorAction SilentlyContinue).DsrmAdminLogonBehavior
"DsrmAdminLogonBehavior: " + $(if ($null -eq $v) { 'not set (default 0)' } else { $v })

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4794 } -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, @{n='Message'; e={ $_.Message.Split("`n")[0] }}

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4624 } -MaxEvents 5000 -ErrorAction SilentlyContinue |
  Where-Object { $_.Properties[5].Value -eq 'Administrator' -and $_.Properties[6].Value -eq $env:COMPUTERNAME } |
  Select-Object TimeCreated
# tune/validate: confirm property indexes against your Windows version before relying on them.

Skeleton Key

Skeleton Key injects a patch into LSASS on a domain controller, so that a shared password is accepted for any account alongside the real one. It lives in memory only and is removed by a reboot, but it works only against RC4 authentication, which gives defenders two angles. Hunt the installation and the side effects:

• Alert on LSASS access on domain controllers from anything other than a short allowlist of security tooling. Sysmon Event 10 with a high-privilege GrantedAccess mask is the main source.
• Where LSA protection (RunAsPPL) is enabled, the public tool needs a kernel driver to bypass it. Alert on new driver services (7045 with a kernel ServiceType, Sysmon 6) on DCs and block known vulnerable and malicious drivers.
• Watch for RC4 (0x17) Kerberos tickets for accounts whose attributes and history show AES, since Skeleton Key forces a downgrade.
• Look for authentication anomalies that have no credential explanation, such as successful logons for many accounts from one source shortly after LSASS tampering on a DC.
• Reboot and rebuild logic matters: a reboot clears the patch, so treat any DC with confirmed tampering as compromised and investigate how the attacker obtained domain admin first.