Directory Services Restore Mode Password Reset – Event IDs to Monitor


Attackers will usually strive to spend additional periods on the machine in order to achieve their goals. Persistence attack is a phase that comes after the initial foothold where an attacker will strive to create a permanent backdoor to establish a connection in the future. In DC Windows servers, there is one concept for DSRM which is used by attackers to persist there.

What is DSRM:

  • Directory Services Restore Mode (DSRM) is a special boot mode for repairing or recovering Active Directory. It is used to log on to the computer when Active Directory has failed or needs to be restored.
  • Safe Mode and DSRM are two different things. Active Directory will still try to start in Safe Mode, but you will be unable to log on if it fails. Instead we use DSRM.
  • Administrators create a Directory Services Restore Mode (DSRM) local administrator account with a password that rarely changes during a Domain Controller (DC) deployment.
  • The DSRM account is a “Administrator” account that signs in with the DSRM mode when the server boots up in order to restore AD backups or recover the system after a failure.

Also Read: Latest IOCs – Threat Actor URLs , IP’s & Malware Hashes


  • DSRM is only needed when Active Directory is so damaged that you cannot log on using your normal AD Administrator password.
  • Use DSRM when doing a domain-wide restore or a forest-wide restore when AD is so damaged that it will not boot normally.

How to Log on with a DSRM account:

  • After booting DSRM, click on Switch User -> Other User. When prompted for the logon account name type .\Administrator
  • The initial logon prompt will show the account name MyDomain\Administrator, where MyDomain is the name of the domain. This is incorrect and will not work. You must click on Switch User and manually type the name .\Administrator.
  • You can use commandline tool ntdsutil to reset the DSRM password for the “.\Administrator” account if you forget it. This necessitates the availability of an Active Directory server.
  • If Active Directory is also not working, you can use a typical desktop PC lost-password recovery tool to reset the DSRM password.

Windows Event ID for DSRM:

Event ID: 4794

Name: An attempt was made to set the Directory Services Restore Mode administrator password

Event Description:

This event generates every time Directory Services Restore Mode (DSRM) administrator password is changed. This event generates only on domain controllers.

Mitre Attack Technique:

Various APTs and threat actors use Mitre Attack Technique for Tactic ID TA0003 to create a permanent backdoor in the domain controller.

How attackers use DSRM:

  • Administrators generally do not follow the recommendation of changing DSRM passwords on a regular basis since they set it while configuring Active Directory.
  • Adversaries could exploit the DSRM account to keep their persistence and access to the Active Directory of the organization.
  • Practically adversaries will be waiting for the loophole to put their head inside an organization. So this is good choice for them to stick and poke their foothold. In order to establish a connection in the future, attackers will seek to develop a permanent backdoor.
  • After establishing the connection, the attacker will change the DSRM account password by running the command “ntdsutil” on every DC. We can also change the password remotely against every DC by replacing “null” with DC name as mentioned in the below screenshot.
  • When a user exploits the DSRM password, attacker can utilize it to log on to the DC as a local administrator across the network.
  • Using an open-source credential dumping tool, such as Mimikatz with the commands “lsadump::sam” and “lsadump::lsa /patch” an attacker can extract both the local administrator and AD administrator password hashes.

“Mimikatz – “lsadump::sam” query screenshot to extract password hash”

“Mimikatz – “lsadump::lsa /patch” query screenshot to extract password hash”

  • After obtaining the local administrator password hash and without rebooting the server, the attacker can alter the Windows registry to log into the DC using DSRM hashes.

Also Read: Latest Cyber Security News – Hacker News !

  • Under HKLM\System\CurrentControlSet\Control\Lsa, the attacker can confirm the “DsrmAdminLogonBehavior” registry key value and set possible REG DWORD values as illustrated below:
  • 0 – the default value. Can use the DSRM administrator account only if the DC starts in DSRM.
  • 1 – Use the DSRM administrator account to log on if the local AD DS service is stopped.
  • 2 – Always use the DSRM administrator account (This setting is not recommended because password policies do not apply to the DSRM administrator account).

Logging on to a DC with the DSRM account according to registry key value:

  1. Restart in Directory Services Restore Mode (bcdedit /set safeboot dsrepair) ( DsrmAdminLogonBehavior to 0)
  2. Access DSRM without rebooting:
    • Set the registry key DsrmAdminLogonBehavior to 1
    • Stop the Active Directory service
    • Logon using DSRM credentials on the console.
  3. Access DSRM without rebooting:
    • Set the registry key DsrmAdminLogonBehavior to 2
    • Logon using DSRM credentials on the console.

Pass-the-Hash attack via DSRM:

  • This account is particularly noteworthy because, being a valid local administrator account, it may be used to authenticate to the DC over the network by setting “DsrmAdminLogonBehavior” regkey to the value 2.
  • Furthermore, the attacker does not need to know the actual password; only the password hash is required. This means that once an attacker gets the DSRM account’s password hash, they can use Pass-the-Hash to gain valid admin access to the DC throughout the network.
  • The Mimikatz commands listed below will assist them in achieving their objectives:
    1. Mimikatz  “privilege::debug”
    2. Mimikatz “privilege::debug” “sekurlsa::pth /domain:ADSDC03 /user:Administrator /ntlm:7c08d63a2f48f045971bc2236ed3f3ac” exit

Also Read: Common Vulnerabilities and Exposures – New CVE’s

How a blue team can defend DSRM attack:

  • The only practical and effective way of mitigation for this attack is to make sure that the DSRM account passwords are unique for each Domain Controller and that they are changed on a regular basis, at least as frequently as other account passwords.
  • The Registry Key HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior should not exist or be set to 1.
  • Likewise, keep in mind the DsrmAdminLogonBehavior registry key isn’t set to 2 – it doesn’t exist by default. Setting this regkey to 1 forces the admin to stop the Directory Services service for DSRM logon to work.
  • Enable a rule based on Event ID 4657 ( A registry value was modified ) – Audit creation/change of HKLM:\System\CurrentControlSet\Control\Lsa DsrmAdminLogonBehavior.
  • Always monitor 4794 events and trigger alerts when they occur.


The DSRM account nowadays provides an excellent attack mechanism for obtaining domain credentials. If an attacker can gain knowledge of the DSRM account password on a Domain Controller with the “DsrmAdminLogonBehavior” regkey set to 2, the DSRM account can be used to authenticate across the network via pass-the-hash to the DC for forcing NTLM authentication. This enables an attacker to retain Domain Controller admin rights when all domain user and computer passwords are changed. So monitoring the above-mentioned points will add value to the security monitoring.

Happy Hunting!

Previous articleWhat is the MITRE ATT&CK Framework? How Is It Useful
Next articleThreat Hunting using Proxy Logs – Soc Incident Response Procedure
Anusthika Jeyashankar
Ambitious Blue Teamer; Enthused Security Analyst


Please enter your comment!
Please enter your name here