How to detect DSRM backdoor attacks

Threat snapshot

Every Domain Controller ships with a built-in local administrator account that exists entirely outside of Active Directory's normal authentication infrastructure. This is the Directory Services Restore Mode (DSRM) account, created at DC promotion time and intended solely for use when the DC is booted into recovery mode to perform Active Directory database repairs. Under normal operating conditions, the DSRM account cannot be used to log on to a running DC over the network. It is, by design, a break-glass account accessible only from the physical console in a degraded boot state.

The DSRM backdoor attack changes that. By setting a single registry value on a domain controller, an attacker with local administrator or domain administrator access can enable network logon using the DSRM account while the DC is fully operational. The registry change takes under a second. Once set, the DSRM account becomes a persistent, domain-independent backdoor: an account that exists outside of AD, cannot be disabled via normal AD user management, is not subject to domain password policies, does not appear in any AD user enumeration, and survives a complete domain compromise remediation that does not specifically address the DC's local SAM.

This is one of the most durable persistence mechanisms available to an attacker who has achieved domain controller access. Domain admin password resets, krbtgt double resets, and even full AD forest recovery procedures leave the DSRM backdoor intact unless it is explicitly detected and remediated. This page covers the three indicators Log360 monitors to catch DSRM backdoor establishment and use.

DSRM backdoor, at a glance

How DSRM backdoor attacks work

The DSRM backdoor has two distinct phases: enabling network logon for the DSRM account via a registry change, and optionally synchronizing or resetting the DSRM password to a value the attacker controls. Both phases leave forensic traces that Log360's detection rules target.

The DsrmAdminLogonBehavior registry key

The core of the DSRM backdoor is a single registry value: HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior. This key controls how the DSRM account can be used on a running DC. By default it either does not exist or is set to 0, which means the DSRM account can only be used when the DC is booted into DSRM mode. Setting it to 1 allows DSRM logon only when AD DS services are stopped. Setting it to 2 is the backdoor: it allows DSRM logon at any time, including while the DC is fully operational with all domain services running.

Setting this value to 2 requires a registry write to a sensitive LSA key, which is an administrative operation on the DC. Under normal operations, this key is never written to in production. Its modification is immediately suspicious regardless of who or what performs the write. Mimikatz, Empire, and other post-exploitation frameworks include modules specifically for setting this value as a persistence step after domain compromise.

Log signals: Windows Security Event 4657 (registry value modified) for the DsrmAdminLogonBehavior key path. Sysmon Event 13 (registry value set) for the same path. Either event on a domain controller with a new or changed value for this key is the primary detection signal for the DSRM registry tamper.

DSRM password synchronization and reset

Once network logon is enabled, the attacker needs credentials that work for the DSRM account. Two approaches are used. The first is synchronization: the ntdsutil utility (a legitimate DC management tool) includes a "set dsrm password" command that can sync the DSRM account's password to match a domain account's current password hash. Attackers sync the DSRM password to a domain administrator account they control, meaning the DSRM account and the DA account share a password. If the DA password is later reset during incident response, the DSRM password is unaffected unless the sync is explicitly rerun.

The second approach is a direct reset: the attacker sets the DSRM password to a value they choose using ntdsutil's "reset password on server" command. This produces a DSRM account with a completely independent, attacker-known password that is stored only in the DC's local SAM, not in Active Directory. This credential survives double krbtgt resets, all domain admin password changes, and even Active Directory forest recovery procedures unless the local SAM is explicitly reset.

Log signals: Windows Security Event 4794 (attempt to set the DSRM administrator password) is the key event for DSRM password changes. This event fires on any attempt to modify the DSRM password, whether successful or not, and is the most reliable forensic indicator that the DSRM credential is being established as a backdoor. The anomaly rule covers cases where the timing or context of the password change deviates from baseline administrative behavior.

DSRM account use for persistence

Once the registry change is made and the password is set, the DSRM account can be used to authenticate to the DC over the network (SMB, WMI, RDP) using the .\Administrator logon syntax, which specifies the local SAM account rather than the domain account. This authentication uses NTLM rather than Kerberos, since the DSRM account is not a domain account and has no Kerberos principal. The combination of NTLM authentication to a DC (unusual in most environments) using the built-in local administrator account is the behavioral signature of DSRM account use.

Log signals: Windows Security Event 4624 (logon Type 3, NTLM authentication) with the account name Administrator and the logon process NtLmSsp on a domain controller. The source workstation field will show the attacker's machine. This authentication pattern is nearly unique to DSRM use in well-configured environments where local account NTLM to DCs is otherwise blocked.

Real-world campaigns

APT campaigns: DSRM as post-compromise persistence after domain takeover

DSRM backdoor establishment has been documented in multiple APT intrusions as a late-stage persistence action taken after domain compromise is achieved. The pattern is consistent: the attacker achieves domain admin access, performs their primary objective (data theft, lateral movement to other environments), and then establishes DSRM persistence as a failsafe. If the primary compromise is detected and domain admin credentials are reset, the DSRM backdoor on one or more domain controllers provides re-entry without requiring a new exploitation path. The DSRM backdoor is specifically valuable in this role because it is not visible through standard AD user account monitoring: the DSRM account does not appear in Active Directory Users and Computers, is not enumerable via LDAP, and does not have a corresponding AD object.

Mimikatz and Empire: built-in DSRM backdoor modules

Mimikatz includes the lsadump::setntlm and associated commands that can set the DSRM password directly from memory. The Empire post-exploitation framework includes a dedicated DSRM persistence module (persistence/misc/set_dsrm_accounts) that automates both the registry change and the password synchronization in a single operation. The presence of these purpose-built modules in widely used offensive frameworks means DSRM backdoor establishment is a documented and accessible technique for any attacker who achieves domain admin access, not only nation-state actors.

Post-ransomware persistence

Several ransomware operators have been documented establishing DSRM backdoors on domain controllers as a post-encryption persistence mechanism. The intent is clear: if the victim organization recovers from the ransomware attack and rebuilds their AD environment, the DSRM backdoor on any DC that was not fully rebuilt provides re-entry for a follow-up extortion demand or a second encryption event. This use case makes DSRM detection critical not only during active incident response but also during post-incident validation, where every DC's DsrmAdminLogonBehavior registry value and DSRM password change history should be audited as part of recovery verification.

Business impact

• Persistence that survives standard remediation. The DSRM backdoor is specifically designed to survive the remediation actions that incident response teams perform after domain compromise: domain admin password resets, krbtgt password resets, account disablement, and GPO cleanup. Unless the specific registry value and DSRM password change are identified and reversed on every affected DC, the backdoor remains fully functional after the rest of the incident has been remediated.
• Invisible to AD monitoring. The DSRM account does not appear in Active Directory. It cannot be found by LDAP enumeration, does not show up in AD Users and Computers, does not appear in Azure AD Connect synchronization, and is not included in any AD audit report. An organization's entire identity governance and monitoring infrastructure is blind to this account by design. Only specific DC-level registry and SAM monitoring surfaces it.
• Domain controller as re-entry point. Because domain controllers hold privileged positions in enterprise networks, DSRM-based re-entry to a single DC immediately gives the attacker a platform for lateral movement, DCSync operations, and further domain compromise. A single undetected DSRM backdoor on one DC out of a forest of ten is sufficient for complete domain re-compromise.
• Delayed discovery amplifies damage. DSRM backdoors discovered weeks or months after a primary incident mean that the organization's assumption of successful remediation was incorrect for that entire period. Any sensitive operations performed on domain-joined systems during that window must be treated as potentially observed by the attacker, significantly broadening the scope of breach assessment and notification obligations.

Detecting DSRM backdoor attacks with Log360

Log360's three detection rules for DSRM backdoor cover each of the three distinct forensic signals the attack produces: the registry modification that enables network logon, the authentication events that indicate the DSRM account is being used, and the anomalous password change events that indicate the DSRM credential is being established or rotated. For these rules to fire, Windows Security audit logging must be enabled on domain controllers with Object Access (for registry events) and Account Logon categories enabled. Sysmon deployment with registry event logging (Event 13) strengthens coverage for the registry tamper rule.

Attack chain visibility

The DSRM backdoor is a late-stage persistence action. By the time it is established, the attacker typically has domain admin access and has completed their primary objective. The sequence below shows what the full chain looks like in the logs, from the initial registry tamper through to DSRM-based re-entry after remediation.

Sequence A: DSRM backdoor establishment during active domain compromise

Sequence B: DSRM re-entry after failed incident remediation

Investigation playbook

DSRM alerts require immediate escalation regardless of which of the three rules fires. Any indication that the DSRM backdoor has been established or used means a domain controller has been persistently compromised, and the assumption that prior incident remediation was complete must be revisited.

Step 1: Triage - identify which signal fired and its implications

Step 2: Audit all domain controllers immediately

• Query the DsrmAdminLogonBehavior registry value on every DC in the domain. Use a domain-wide registry query via PowerShell: Invoke-Command -ComputerName (Get-ADDomainController -Filter * | Select -Expand Name) -ScriptBlock { Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa" -Name DsrmAdminLogonBehavior -ErrorAction SilentlyContinue }. Any DC where this value is 1 or 2 has been tampered with.
• Query Windows Security Event 4794 (DSRM password change) on all DCs for the past 90 days. Any Event 4794 not correlated with a documented maintenance operation is evidence of DSRM backdoor credential establishment on that DC.
• Query Event 4624 (Type 3, NtLmSsp, account name Administrator) on all DCs for the past 90 days. Any NTLM network logon to a DC using the local Administrator account while the domain was operational indicates DSRM use.
• Treat every DC where any of these indicators are present as a compromised host that requires full forensic review, not just the DC that triggered the initial Log360 alert.

Step 3: Investigate using the Incident Workbench

• Click on the affected DC hostname in the alert to open the Incident Workbench. Use the Process analytics tab to inspect the full process tree at the time of the registry change or DSRM logon. The process tree shows what spawned the tool that made the registry change, providing the upstream compromise chain: how the attacker got to the DC in the first place.
• Use Advanced Threat Analytics on the source IP used for the DSRM logon (if the Potential Compromise rule fired) to check threat feed risk scores and determine whether this IP is associated with known attack infrastructure or C2 services.
• Check the User analytics tab for the domain admin account used in the session prior to the DSRM registry change. If that account shows prior anomalous logon patterns, it was compromised before this session, giving you the initial access path.
• Save the Incident Workbench session to an incident. DSRM backdoor incidents require executive and legal notification in most organizations; the saved session provides the evidence record for those communications.

Step 4: Determine the full scope of DC compromise

• For every DC where the DsrmAdminLogonBehavior key is set to 2 or where Event 4794 was recorded outside a maintenance window, perform a full review of Security event logs for the period from the earliest suspicious indicator to the present. Specifically look for: DCSync operations (Event 4662 with replication permissions), new user account creation, group membership changes, GPO modifications, and new scheduled task creation.
• Determine whether Mimikatz or similar tools were executed on the DC. Sysmon Event 1 logs from the DC, if available, provide process creation history. Memory forensics via a live response tool may be necessary if Sysmon was not deployed on the DC at the time of the compromise.
• Assess whether the DSRM backdoor has been in place long enough for the attacker to have obtained persistent access via other means (new user accounts, shadow credentials, certificate-based access) that would also need to be cleaned up.

Step 5: Collect evidence and build the timeline

• Export Windows Security Events 4657, 4794, and 4624 (Type 3, NtLmSsp, Administrator) from all DCs for the investigation period.
• Export Sysmon Event 13 (registry value set) logs from affected DCs if Sysmon is deployed.
• Preserve the current state of the DsrmAdminLogonBehavior registry key on all DCs before remediation, as evidence of the tampering.
• Export the Incident Workbench session timeline as the primary evidence record for executive reporting, compliance documentation, and any breach notification assessment.

Response and remediation

Immediate containment

• Reset the DsrmAdminLogonBehavior registry value to 0 on every affected DC immediately. Use Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa" -Name DsrmAdminLogonBehavior -Value 0. If the key does not exist by default on your DCs, deleting it entirely achieves the same result. Verify the change on all DCs in the domain, not just the one that triggered the alert.
• Reset the DSRM password on every affected DC. Use ntdsutil to set the DSRM password to a new, strong, randomly generated value: ntdsutil "set dsrm password" "reset password on server [DC-NAME]" quit quit. Store the new DSRM passwords in the organization's privileged access management vault. Do this on every DC, not just the ones where suspicious activity was detected, because the attacker may have set the backdoor on DCs that did not yet generate log events.
• Isolate any DC where active DSRM logon was detected (Potential Compromise rule fired) from the network immediately. A DSRM logon to a running DC is confirmed unauthorized access. The DC should be treated as a compromised host and brought offline for forensic review.
• Perform a domain-wide credential reset as part of DSRM remediation. Because the attacker had domain admin access sufficient to set the DSRM registry key, they almost certainly obtained domain credentials during the same session. Double krbtgt reset, all tier-0 account password resets, and service account rotation should accompany DSRM remediation.

Response actions by trigger

Post-incident hardening

• Add the DsrmAdminLogonBehavior registry key to continuous monitoring. Configure Log360 to alert on any write to this key on any DC. This key should never change in production; any modification is an immediate incident.
• Implement a formal DSRM password management policy. Store DSRM passwords for all DCs in a PAM vault. Rotate them on a defined schedule (at minimum annually) and after any incident involving DC access. Document every legitimate DSRM password change with a change management ticket that can be used to distinguish authorized from unauthorized Event 4794 occurrences.
• Deploy Sysmon with registry monitoring on all domain controllers. Sysmon Event 13 (registry value set) targeting the LSA key path provides a more reliable and detailed record of registry changes than Windows Security Event 4657 alone, particularly the process and parent process that made the change.
• Restrict local account NTLM authentication to domain controllers. Use a Group Policy or Windows Defender Firewall rule to block NTLM authentication to DCs from all sources except designated management servers. This prevents DSRM logon from arbitrary attacker-controlled hosts even if the registry key is set and the password is known.

False positive tuning