Sep 10 2015

Sneaky Active Directory Persistence #11: Directory Service Restore Mode (DSRM)

The content in this post describes a method by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for 5 minutes.

I presented on this AD persistence method in Las Vegas at DEF CON 23 (2015).

Complete list of Sneaky Active Directory Persistence Tricks posts

 

The Directory Restore Mode Account

Every Domain Controller has an internal “Break glass” local administrator account to DC called the Directory Services Restore Mode (DSRM) account. The DSRM password set when DC is promoted and is rarely changed. The primary method to change the DSRM password on a Domain Controller involves running the ntdsutil command line tool.

Beginning with hotfix KB961320 on Windows Server 2008, there is now the option to synchronize the DSRM password on a DC with a specific domain account. Note that this must be performed every time the password is changed; it does not create an automatic sync partnership.

Changing the DSRM Account Password:

Run the following command on every DC (or remotely against every DC by replacing “null” with DC name)

  • NTDSUTIL
  • set dsrm password
  • reset password on server null
  • <PASSWORD>
  • Q
  • Q

Synchronize the DSRM Account Password with a Domain Account (2k8 & newer):
In an elevated CMD prompt where you have logged on as a Domain Admin, run:

NTDSUTIL
SET DSRM PASSWORD
SYNC FROM DOMAIN ACCOUNT <your user here>
Q
Q


Using DSRM to Backdoor Active Directory

What’s interesting about the DSRM password is that the DSRM account is actually “Administrator”. This means that once an attacker has the DSRM password for a Domain Controller (or DCs), it’s possible to use this account to logon to the Domain Controller over the network as a local administrator.

We can confirm this with Mimikatz by creating a new AD user with a known password. Set the DSRM acount password sync from the domain user account and compare the hashes.

DSRMTest NTLM Password Hash: 2b391dfc6690cc38547d74b8bd8a5b49
Administrator (500) Local Account NTLM Password Hash: 2b391dfc6690cc38547d74b8bd8a5b49

The second graphic shows a local Administrator account on the DC called “Administrator” with the same password hash as the DSRMTest domain user account.

SneakyPersistence-DSRM-Mimikatz-DSRMTeast-And-Administrator

Note: The local SAM file is located here: C:\Windows\System32\config\SAM

 

Using DSRM Credentials

Once you know the DSRM account password (local Administrator account on the DC), there are a few tricks to how it can be used.

Logging on to a DC with the DSRM account:

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

Access DSRM without Rebooting:

PowerShell New-ItemProperty “HKLM:\System\CurrentControlSet\Control\Lsa\” -Name “DsrmAdminLogonBehavior” -Value 2 -PropertyType DWORD

The registry value is located at HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior. Its possible values are:

  • 0 (default): You can only use the DSRM administrator account if the DC is started in DSRM.
  • 1: You can use the DSRM administrator account to log on if the local AD DS service is stopped.
  • 2: You can always use the DSRM administrator account (This setting isn’t recommended, because password policies don’t apply to the DSRM administrator account).

The capability of DSRM account credential is explored further in the post “Sneaky Active Directory Persistence #13: DSRM Persistence v2“.

 

Using DSRM Credentials over the network

It is possible to use the DSRM Credentials over the network.

When Windows 2000 and Active Directory were released, DSRM being limited to console logon was a good security method. Today, however, there are several methods to logon to a system “at the console”:

  1. Virtualization Client
    1. VMWare Remote Console (TCP 903)
    2. Hyper-V VM Connection (TCP 5900)
  2. Out of Band Management (Lights Out, etc)
  3. Network KVM
  4. Remote Desktop Client when connecting to the “Console” which is “mstsc /console” prior to Windows Server 2008 and “mstsc /admin” with Windows Server 2008 and newer. Tested on Windows Server 2008 R2. Windows Server 2012R2 seems to refuse DSRM logon via RDP console.

SneakyPersistence-DSRM-RDP-MSTSC-Admin

SneakyPersistence-DSRM-RDP-MSTSC-Admin-ADSDC01-Administrator-03

Once logged in as the local DC’s DSRM account (DC local admin), we can confirm we are on a DC and that this is the DC’s local administrator account. not a domain account.

SneakyPersistence-DSRM-GetDC-ADSDC01-Whoami-DSRM

Further proof that this is not a domain account.

SneakyPersistence-DSRM-Not-A-Domain-Admin-On-DC

 

Detection

  • Monitor event logs relating to DSRM password change and usage
    • 4794: An attempt was made to set the Directory Services Restore Mode administrator password (requires account management/user management subcategory auditing enabled in 2008 R2 and newer).
  • Monitor the registry location and alert on values of 1 or 2
    • HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior

 

References:

 

(Visited 33,404 times, 1 visits today)

Sean Metcalf

I improve security for enterprises around the world working for TrimarcSecurity.com
Read the About page (top left) for information about me. :)
https://adsecurity.org/?page_id=8