Red Teaming

Domain Persistence: DSRM

In this post, we are going to discuss one more Mitre Attack Technique for Tactic ID TA0003 which is used by various of APTs & threat Actors for creating a permanent backdoor in the domain controller. We will check how to use Directory Services Restore Mode (DSRM) for conducting a persistence attacker on the Domain controller.

Table of Content

Lab Setup Requirement

What is DSRM Password

  • DSRM Persistence
  • Extract the Hashes
  • Change the DSRM Registry Key Value

Pass the DSRM Hash

Mitigation & Workaround Solution

Lab Setup Requirement

  • 1 Domain Server 2016 & mimikatz
  • 1 Domain client & mimikatz

Note: A domain controller contains two Administrator accounts, one “AD Administrator Account” use to login into the domain controller that is managed by LSASS and another is hard-coded “Local Administrator Account” stored in their SAM database.

What is DSRM Password

All domain controllers have a hard-coded local Administrator account stored in their SAM file. This account and local database are not used or generally available when the domain controllers are running normally.

While Active Directory Domain Controller is configured, the wizard prompts ask to enter a DSRM password for the local administrator. This password provides the administrator with a back door to the database in case something goes wrong later.

DSRM Persistence

DSRM persistence is possible where the systems do not change the DSRM password after AD installation or do not follow the standard of changing passwords regularly for DSRM.

At Domain Controller

As per the cyber kill chain, 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.

Here, you can choose any of the methods to access the domain controller at least once, then inject the mimikatz to obtain a password hash for a local Administrator account.

Extract the Hashes

If you will observer the following image, you will notice that I have pulled out password hashes for Local Administration from the SAM file & AD Administrator account by injecting LSA injection.

 All you need to do is just run the mimikatz with Administration privilege and execute these commands given below:


Extract local Administrator Password Hash


Extract AD Administrator Password Hash

lsadump::lsa /patch

Conclusion: I have two different hashes for each administrator account but we password hash for local administrator account.

Change the DSRM Registry Key Value

Once you have the local administrator password hash you need to make some changes inside the Windows registry that will allow you (attacker) to login into Domain Controller using DSRM hashes without rebooting the server.

Very first confirm the registry key value for DsrmAdminLogonBehaviour with the help of the following command:

Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\"

Here, it shows DsrmAdminLogonBehaviour Value=0 that will not allow login into DC using DSRM hash.

Set DsrmAdminLogonBehaviour value=2 with the help of the following command:

Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehaviour" -Value 2 -Verbose

Note: If DsrmAdminLogonBehaviou registry key is not present inside the HKLM:\System\CurrentControlSet\Control\Lsa\ then create a new key and set the value with the help of the following command:

New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehaviour" -Value 2 -PropertyType DWORD -Verbose

Conclusion: The DSRM persistence is now ready for use.

Pass the DSRM Hash

At Client System

To access the domain controller CMD through the client system, run mimikatz with administrator privilege and execute the following command:

sekurlsa::pth /user:Administrator /domain:ignite.local /ntlm:32196B56FFE6F45E294117B91A83BF38

Note: Use the hash value of the local Administrator in the above command

This will provide you (attacker) the Administrator privilege cmd shell of the Domain controller 😊

Mitigation & Workaround Solution

  • Check & monitor the DsrmAdminLogonBehaviour value is not set to 2 inside the Registry key.
  • DSRM passwords are changed regularly at least once a month.

Author: Aarti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

One thought on “Domain Persistence: DSRM

Leave a Reply

Your email address will not be published. Required fields are marked *