We all know the classic RID 500 administrator account, the one who’s able to use NTLM authentication even with “Protected user” membership and is your go to during delegation attacks but there’s a kink in this lateral movement free for all; The Domain Controller doesn’t actually work the that way.
The Domain Controller functions differently to other computers in that the default local Administrator that exists on other systems by default is not enabled. The default local Administrator on the Domain Controller in fact plays a specific role that it doesn’t on other systems; Its used exclusively for disaster recover.
The DSRM Admin or Directory Services Restore Mode Administrator is the local Administrator on your Domain Controller. This account is used for Diseaster recovery when you AD tenancy is offline and recovering other nightmare scenarios that your Domain Controller may encounter. This is the sole function of the local Administrator on your domain controller and thus it does not need, and indeed have, the ability to interactively log in locally or over the network on a Domain Controller.
Lets look at a 2019 functional environment with a 2019 servers on a normal AD joined computer and Domain Controller.
When we query the standard computer for localusers and their sids this is what we get:
Notice how the Local Administrator(rid 500) is enabled. Now lets make the same check on the Domain Controller:
I do want to point out that if you notice, there’s a name that shows up at the end that doesn’t on a standard server but more on that later : )
What this stands to reason is that since both systems have the rid 500 Administrator enabled then they both will be able to access their respective systems without issue but it doesn’t!
Lets use mimkatz to dump the SAM, which contains local user cached credentials(which will give us the Local Administrators hash)
On our normal AD computer:
Now lets do the same on our DC:
Perfect! Now we have both local Administrators NTLM hashes. Remeber my earlier comment about the elusive RID 500 administrator not being bound by the conditions in the protected users group and thus we can authenticate with NTLM
On our normal server, we will be able to use the rid 500 administrator to dump lsa secrets remotely via nxc:
This is nothing special as the local administrator is fully able to authenticate over NTLM as well as being able to access the LSA secrets. Now lets try this on our Domain Controller:
We aren’t able to log in using Administrator and the ntlm hash we got from the SAM. That’s where this registry entry comes in:
HKLM\System\CurrentControlSet\Control\Lsa
Here lays the answer(and a stealthy persistence method). The DSRMAdmin or the traditional/default built in Local Administrator on the DC isnt allowed to have a local interactive login or network login due to the above registry key lacking an entry for the DsrmAdminLogonBehaviour subkey. In fact by default this key doesn’t exist:
Lets change that by running
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehaviour /t REG_DWORD /d 2 /f
Note that it can either be 0. 1 or 2. 0 or non exsistent is the default behvaior and with a value of 1 the DSRM admin will be able to have an interactive session and with a value of 2 they can preform network authentication.
We can switch over to nxc now and test it out with the same hash and arguments as used earlier before the registry change:
and now it worked! The significance of this is nothing new; in fact Sean metcaff and Benjamin Delphi had documented this almost a decade ago. It is a lethal persistence mechanism as with the hash of the DSRMAdmin, and a single registry edit, an attacker can hit up the Domain Controller with the hash for a while until someone thinks to change the accounts password.
I wanna circle back to a point I made earlier; when we listed local users on the Domain Controller, we notice that the machine account shows up, DC$. This is in contrast to server in which its own machine account doesn’t show up as a local user.
This is actually a result of the fact that the DC doesn’t hold a traditional SAM, instead its storing its user accounts in the AD database(NTDS.DIT), While standard servers have a fully structured SAM that keeps the domain accounts(like the machine account) separate from the local accounts(like the rid 500 Administrator)
We can see this in fact when we use the DC$ machine hash that we got earlier and use it with impacket-secertsdump, we end up automatically being able to use the DCs machine account to dump the AD database:
The first error we see is of interest as it notes that secretsdump couldn’t use its traditional method of access the SAM/LSA and so instead it switches over to using Directory Replication Service Method instead. This works because the DC$ object has the ability to preform Domain Controller Replication(it has the DS-Replication-Get-Changes permission).
This is a by product of Domain Controllers needing to be able to sync and replicate writable data within them(including passwords) to ensure integrity within the domain.
These two unique quirks of how Domain Controllers local accounts differ from standard servers are routinely missed. I see a range of clients, co workers, and other professionals online mix up how the Domain Controller handles its own local Administrator, machine account and how they can be weaponized!