08 Mar 2020

Active Directory - Physical Disk Access to Domain Administrator in just a few minutes.

If you get access to the unencrypted disk of a domain controller you can take NTDS.dit away and do horrible things with it offline. The most common approach seems to be extracting the secrets from the directory. I recommend ropnops blog for more detail.

Here’s a slightly different route you could take if you find yourself in that position. Keep in mind: the number of people who have access to virtual hard disks in an organization is usually reasonably large.

All you really need for this to work is access to the disk of a single domain controller.

From a security perspective, the “fix” for this is encrypted domain controller disks. (There is also a setting that will stop the application of local policy which you could configure at the domain level.)

The foundation of the technique is the often overlooked fact that even domain controllers process local group policy (by default). The local GP folder is hidden. But similar to all the other machines, the policy lives here: C:\Windows\System32\GroupPolicy

If you can manipulate the files associated with the local group policy of a single domain controller while it is offline, when it starts up it will apply changes. Local GP scripts will run in the context of a domain controller system account.

Brief Steps

  1. Mount the Domain Controller disk
  2. Copy in a modified “GroupPolicy” folder that contains a startup script
  3. Start the Domain Controller

More Detail

Step 1:

The first thing to do is mount the domain controller disk.

If you’re testing this using VMWare workstation just open the virtual settings on the virtual domain controller, select the disk, and select “mount”.

If you’d prefer, vmware-mount should work as well with something like vmware-mount [driveletter:] [path-to-vmdk] [options].

(I’ve seen VMWare get a little funny when mounting disks. If you have trouble with “access denied” or something similar, just attach the disk to another virtual machine as a second disk temporarily rather than the host machine. You’ll get the same effect).

Step 2:

Once mounted, the goal is to replace the “GroupPolicy” folder (C:\Windows\System32\GroupPolicy) on the mounted disk with one you’ve pre-prepared to contain a startup script.

Here’s an example you can download and use right away. Just save this folder, then replace the local group policy on your victim mounted disk with this one. Feel free to modify the script in the “GroupPolicy\Machine\Scripts\Startup” directory to do different things. I don’t blame you for not trusting the example (there’s nothing wrong with it, but i get it), I put the extra steps at the bottom of this post so you can pre-create the folder yourself.

Unmount the disk.

Step 3:

Restart the machine.

When it starts and applies local policy you should have a new Domain Administrator account (mine is called “test123” because I was wondering if this still worked):

newDA

Done!


Creating your own “GroupPolicy” folder

If you decide to create your own “GroupPolicy” folder there’s really nothing to it. It’s a good idea to have it done and ready before you start though, especially if you are restarting a domain controller without notice to do this.

Just create a lab domain controller (or any server really). Then, configure a new script in:

C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup

The script can do whatever you like, but for this simple example let’s just create a new domain admin:

net user /add test123 P@ssw0rd123 /domain
net localgroup administrators test123 /add /domain

Open gpedit.msc (the local group policy editor).

Navigate to “Computer Settings” > “Windows Settings” > “Scripts” > “Startup”.

Inside the startup scripts section just click ‘add’ to create the policy linking your script to the policy.

Once you’ve done all that, just save the C:\Windows\System32\GroupPolicy folder somewhere for safe keeping.

You’re done.

The important note is that the script on its own is not enough, there are some other hidden files in there that tie the script to a local group policy; the things that make the domain controller process the script and configure it in the local registry as a startup item.

They are hidden files so here’s a visual:

hiddenfiles


Appendix: The places you can poke around this stuff:

The folder you should replace on the domain controller: C:\Windows\System32\GroupPolicy

The scripts directory of local group policy: C:\Windows\System32\GroupPolicy\Machine\Scripts\Startup

The place the policy will end up stamping as a startup item: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup\0\0

Thanks!
Chad Duffey

Security Engineer