If privileged access to a domain controller is obtained by a malicious user, it is also possible that the user will get access to other accounts and credentials. Therefore the user (attacker) can get access to other server systems or the complete network.

Because domain controllers can read from and write to anything in the AD DS database, compromise of a domain controller means that your Active Directory forest can never be considered trustworthy again, unless you can recover using a known good backup and to close the gaps that allowed the compromise.

Source: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack


Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore. (Ten immutable Laws of Security)

At the end of this post I will show how easy it is to get privileged access to a computer and even domain controller just by having physical access to it.


Table Of Contents
  1. Securing Virtualized Domain Controllers with Hyper-V and BitLocker
  2. Getting privileged access to a domain controller by having physical access to and not secured by BitLocker
  3. Getting privileged access to a domain controller by having physical access will fail if BitLocker is enabled
  4. Links


To prevent an attacker can get privileged access just by having physical acccess to a computer, one option is to use BitLocker to encrypt the volumes of the computer.

More about securing domain controller against attacks you will find in the following Microsoft article.

Securing Domain Controllers Against Attack
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack



Securing Virtualized Domain Controllers with Hyper-V and BitLocker

Since Windows Server 2012 you can also virtualize your domain controllers with Hyper-V.

Windows Server 2012 introduces many improvements for virtualized domain controllers (DCs), including safeguards to prevent USN rollback on virtual DCs and the ability to clone virtual DCs. For more information about these improvements, see Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100).

Source: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controllers-hyper-v


In order to decrypt the volumes (virtual hard disks VHD(x) files) from our virtual domain controller, we first need to shutdown the VM and enable the Trusted Platform Module (TPM) for as shown below in the screenshot.

You can use Bitlocker with your domain controllers, since Windows Server 2016 you can use the virtual TPM feature to also give the guest key material to unlock the system volume.

Source: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controllers-hyper-v


Now we can start the VM


To install BitLocker use the Server Manger and select Manage -> Add Roles and Features


BitLocker is a feature, so select BitLocker Drive Encryption here


After the installation we need to reboot the VM

Now we need to configure BitLocker



I will first turn on BitLocker for the OS Volume C:


In case you didn’t had enabled the Trusted Platform Module (TPM) as shown previously, you will get the following error message when trying to turn on BitLocker for the OS Volume.

This device cannot use a Trusted Platform Module. Your administrator must set the Allow BitLocker without a compatible TPM option in the Require additional authentication at start-up policy for OS volumes.


You can enable the following policy to allow turn on BitLocker on the OS volume without TPM, but as it requires to enter each time at startup a password, that makes no sense for a production server and domain controller. Below just to show how it works.

Computer Configuration – Administrative Templates – Windows Components – BitLocker Drive Encryption – Operating System Drives – Require additional authentication at startup



After applying the policy, I can turn on BitLocker for the OS volume and now need to provide a password or USB flash drive.


At the next time I will boot the VM, I will get the following screen to unlock the OS volume before I can boot from.




Now back to the process to turn on BitLocker for the OS volume and enabled Trusted Platform Module (TPM)






After the restart BitLocker is encrypting the selected OS volume.


Finally the Volume is encrypted.


As my virtual domain controller had two volumes, I will do the same for the second Volume D:

I will also to unlock the volume automatically by using the TPM.


The lock icon will indicate that the volumes are now secured and encrypted by BitLocker. Below to be correct the icon is unlocked because the system is running and up.

For encrypted devices secured means just in case someone is stolen the device (hard disk drive) or trying to get access on boot before authentication.

Here the hard drive is locked and encrypted.

In case the system is running and up, the hard disk drives are unlocked and not encrypted. So if an attacker can get access to the system over the network, BitLocker won’t help to protect the data.


From now on the virtual domain controller (also for physical aka bare metal server secured with BitLocker) is secured in case an attacker gets physical access to it.

Below I will do a test, one test is getting privileged access for a domain controller not secured by BitLocker and one test where BitLocker is enabled and the volumes therefore decrypted.




Getting privileged access to a domain controller by having physical access to and not secured by BitLocker

Your rember the quote from the beginning?

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore. (Ten immutable Laws of Security)


You will see we just need a few steps and minutes to get privileged access to our domain controller. In case of a domain controller we can even take over the domain administrator and enterprise admin account.

The steps are the same for all recent windows versions. For Unix-like systems the above law is also true and the steps are different but also done in just a few minutes and similar (e.g. booting a live system and chroot into the root partition of the physical computer)

I will show the steps for a virtual machine, but its the same as for physical computers. The only difference is, that when it is a virtual machine, I will boot from a mounted ISO image instead using a USB-stick to boot from.

I will mount here a Windows 10 ISO Image but you can also use a Windows Server version or any other recent Windows version, it doesn’t matter, we just need to boot a Windows version in a limited state, where only the bare essentials are started (aka Windows RE) to access the actual OS volume from our domain controller.

Windows Recovery Environment (Windows RE)
WinRE is based on Windows Preinstallation Environment (Windows PE), and can be customized with additional drivers, languages, Windows PE Optional Components, and other troubleshooting and diagnostic tools. By default, WinRE is preloaded into the Windows 10 and Windows 11 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016, and later, installations.

Source: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment–windows-re–technical-reference?view=windows-11


Here I will mount a Windows 10 ISO image.


Then I will reboot the machine, to trigger that Windows will automatically boot from the ISO Image or USB-stick after the restart, press and hold the SHIFT-key while selecting below Shut down or sign out – Restart.



The virtual machine will boot from the Windows 10 ISO image


Select Troubleshoot


Select Command Prompt


The command prompt will show up and the selected volume X:\ is from the Windows RE environment (ISO Image or USB -stick)


We now need to change to the OS volume, to first determine what volumes exists on the machine, we can use the following command.

x:\windows\system32>wmic logicaldisk get caption


Normally on my virtual domain controller the OS volume had assigned the drive letter C:\ and as description SYSTEM, but here the Windows RE environment will set the drive letters on its own, so you can not know what drive letter was assigned to the OS volume.

We need to try all of them till we found the following folder structure, so the OS volume from the domain controller here is E:\.

Btw. here you can also see the description from the volume named SYSTEM as mentioned, but this you wouldn’t know if its not your own machine.


You can also change directory (cd Users) into the Users folder to check what local user profiles exists on it.


But now in order to get privileged access to our domain controller, we first need backup the Utilman.exe tool in the System32 folder.

Utilman.exe is at the logon screen the following Icon at the right bottom which opens normally some settings to ease the handling of the computer.
https://support.microsoft.com/en-us/windows/make-your-pc-easier-to-use-1c313f8f-8bc3-4e1c-c1c8-efe173a94845


What we now will do below in short, we make sure, that behind this Icon from now on an elevated command prompt will show up which we using to reset the credentials from local users stored in the Local Security Authority (LSA) on each windows computer.


So first we will back up the Utilman.exe tool or just deleting it, an attacker wouldn’t need it anymore. After that we make a copy of the command prompt tool and name it Utilman.exe.

x:\windows\system32>move Utilman.exe Utilman.exe.bak
x:\windows\system32>copy cmd.exe Utilman.exe


Most is already done and we can exit the command prompt and reboot the computer normally. Remove the ISO or USB-stick.


At the logon screen we now will click on the Ease of access icon and an elevated command prompt should appear instead of the ease of access dialog before our changes, sometimes you have to click a few times on it till it appears.


To list the local users on the system you can enter the following command

C:\Windows\system32>net user

In case the computer is a domain controller, it will list all domain users as below for my lab environment.


We are interested to get privileged access from a domain admin account, therefore we can determine which users we see above are members in the domain admins group by executing the following command.

Btw. the following steps to reset the password will work for all domain users.

C:\Windows\system32>net group “Domain Admins”

The command net group can be used only on a Windows Domain Controller!


Or to be sure to get access to the whole AD Forest we can check which user is assigned as Enterprise Admin by executing.

C:\Windows\system32>net group “Enterprise Admins”

Enterprise Admins
EAs are granted rights and permissions that allow them to affect forest-wide changes. These are changes that affect all domains in the forest, such as adding or removing domains, establishing forest trusts, or raising forest functional levels. In a properly designed and implemented delegation model, EA membership is required only when first constructing the forest or when making certain forest-wide changes such as establishing an outbound forest trust.

Source: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b–privileged-accounts-and-groups-in-active-directory#enterprise-admins

So for my lab environment this is both times the user account named superuser.


Further information about that user you can check with the following command.

C:\Windows\system32>net user <username>


Now as we know the user account we want to take over, we can reset the password for by using the following command.

C:\Windows\system32>net user superuser <enter a new password here>


Finally we can close the command prompt and logon to the domain controller by using that account and password.


From that point, the legitimate domain administrator is locked-out and the password is synchronized to all other domain controller.

All by just having unrestricted physical access to the computer!




In case this computer is a normal member of a domain or standalone, normally you would be interested to reset the local administrator account.

You can use of course all other accounts also, but then it makes sense to first check which of them is member of the local administrators group to get the full access rights for the computer.

To list all local groups
C:\Windows\system32>net localgroup

To view members of the local Administrators group
C:\Windows\system32>net localgroup Administrators


You can also add an existing user to the local Administrators group as follows.

C:\Windows\system32>net localgroup Administrators <username> /add


The steps to reset the password of a local user are same as before on the domain controller, first we list the local users, below I will use a Windows 10 membership computer (virtual machine) from my lab environment.

C:\Windows\system32>net user


The built-in Administrator account is by default disabled.


So we need to reset the password and also enable the account by executing the following commands.
(first set the password to meet the password policy requirements)

C:\Windows\system32>net user Administrator <enter a new password here>
C:\Windows\system32>net user Administrator /ACTIVE:yes





Getting privileged access to a domain controller by having physical access will fail if BitLocker is enabled

By trying the same as before when BitLocker was disabled, we are now not able to access the OS volume from our domain controller if BitLocker is enabled.

You remember the steps before?

First we was booting from a Windows 10 ISO Image.


Windows RE is started an we selected here Troubleshoot


Then we selected Command Prompt


The command prompt before were BitLocker is turned off, was shown up.


Now as BitLocker is turned on (enabled), the command prompt cannot access all volumes and will show up the following dialog.

Here we need to enter the recovery key to access the hard disk drive, the OS volume from our domain controller is and therefore are not able to manipulate files on it.


We can skip here all devices secured with BitLocker, but finally are not able to get privileged access without access to the hard disk drive the OS volume is stored.




Links

Securing Domain Controllers Against Attack
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack

BitLocker and Active Directory Domain Services (AD DS) FAQ
https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-and-adds-faq?source=recommendations

BitLocker: How to deploy on Windows Server 2012 and later
https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server

Virtualizing Domain Controllers using Hyper-V
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controllers-hyper-v