Recently, I gave a presentation to coworkers explaining some of the basics of Active Directory (AD) pentesting. The presentation focused on vulnerabilities that could be easily checked (and exploited) within the first few hours of a pentest. Since I figured that this information might be useful to anyone working Active Directory security, offensively or defensively, I decided to turn that presentation into a blog post. The result is the following.
This blog post contains the following chapters:
The following information is neither detailed nor comprehensive. It is meant as a surface-level overview and "cheatsheet".
I encourage everyone reading this to do their own research and familiarize themselves with the topics presented here,
understanding how and why the described exploits work.
In the spirit of chaos, the first part of the presentation about Active Directory pentesting was about something that technically does not require an Active Directory infrastructure at all: Windows clients. Specifically, attacks that could be performed with physical access to such a client. There are several scenarios where exploitation is relatively easy, without having to resort to opening up the client physically. These scenarios I am going to focus on are:
The first scenario is also the easiest to exploit. All that's needed is a bootable USB stick with a live-bootable
operating system. I personally like to use Ventoy
to set up the USB stick and then just drop a live-bootable linux distro onto it, for example Grml.
Next, reboot the victim Windows client, spam the boot key (ESC, F1, F12 or something else, depending on the device/firmware) and select the bootable USB.
Once booted, mount the Windows partition.
This can for for example be found by using the command fdisk -l. The type of the partition is Microsoft basic data.
The create a mount point like mkdir /mnt/windows and mount the partition like mount /dev/nvme0n1p3 /mnt/windows (where /dev/nvme0n1p3 should be replaced with the correct partition identified in the previous step).
Sometimes some issues will come up with the way Windows hibernates. Sometimes, adding -o remove_hiberfile to the end of the mount command can fix the issue.
At other times, executing something like ntfsfix /dev/nvme0n1p3 is necessary before the partition can be successfully mounted.
Once mounted, the mount point contains all of the data on the Windows partition, freely read-writeable.
If access to data is the only goal, it has thus been achieved.
Other things to do are stealing secrets or placing a backdoor for the Windows system.
The first can be achieved by copying the files SAM, SECURITY and SYSTEM, which reside in the Directory
C:\Windows\System32\config, to a linux system that has impacket
installed. Then execute python secretsdump.py -sam SAM -security SECURITY -system SYSTEM LOCAL (in the directory with the aforementioned files)
and the script will print the password hashes of the local users in a format that can (usually) be used for authentication without having to crack them first
using a technique called Pass-the-Hash.
To place a backdoor, it is easiest to replace an executable that can be called before a login.
One of these executables is Utilman.exe, which is a toolkit for accessibility features residing in C:\Windows\System32.
It can be replaced with a shell by executing cp cmd.exe Utilman.exe in the aforementioned directory.
After rebooting into windows and arriving at the login screen, pressing Win+U will open a command prompt in the context of NT Authority\SYSTEM,
the most powerful user on any windows system. The shell can then be used to perform actions on the system, such as creating
a new local administrative account using the commands net user NewAdmin NewPassw0rd /add and net localgroup Administrators NewAdmin /add.
The process for this is similar to that without Secure Boot, just that a configuration is necessary that can pass Secure Boot.
Ventoy cannot be used in such a scenario. Instead, a single OS with Secure Boot support needs to be installed on the boot stick.
Examples for linux distros that support Secure Boot out of the box are Ubuntu and Linux Mint.
A problem that can occur is that the UEFI requires a password to select a different boot medium. In that case, the following
exploit might help.
If Full Disk Encryption is enabled on the client, the process is a bit more involved. One exploit that can be used when Bitlocker is in place (the most common FDE for Windows) is called BitPixie. The process is fully explained in the linked blog post, but I'll try to shorten it to the most important bits here.
As mentioned above, in some cases, password hashes can be extracted from Windows system.
If these hashes are in the NTLM format, they can usually be used immediately without needing to crack them, using a technique called Pass-the-Hash.
Pass-the-Hash is useful in different scenarios and can be performed using different tools.
One use for Pass-the-Hash is Lateral Movement in an infrastructure with password reuse.
If the password for the local Administrator account is the same on every system, getting the NTLM hash from a single system
is enough to gain access to all other systems.
Let's say we extracted the local Administrator's NTLM hash using one of the aforementioned techniques and have access to a network
where the victim client usually resides (and a general understanding of the IP range in use).
We can then check for Lateral Movement opportunities with tools like NetExec:
There are several exploitable vulnerabilities in misconfigured ADCS setups.
They follow the naming scheme ESC[number] and at the time of writing this there are over 15 of them.
For the sake of this blog post, the focus shall be on three of them (ESC1, ESC4 and ESC8), because they
are rather common, easy to exploit and very powerful.
Tools like Certify and
Certipy can be used to detect
and exploit these vulnerabilities.
Certipy only.
ESC8 requires relaying authentication, the conditions for which can for example be set up with something like PetitPotam or Coercer. Before coercing (or waiting for an authentication to reach the system otherwise), ESC8-relaying can be set up with:
A best practice when administrating Windows infrastructures is to use Domain Admin accounts as rarely as possible and only when operating on a Domain Controller. When this best practice is not followed and Domain Admin accounts log onto a system where a potential attacker has local administrative permissions, this can be exploited in several ways. Two of which are described in the following
WDigest is a deprecated authentication protocol created by Microsoft. It can be (re-)enabled by setting a specifc registry key:
With this key set, if someone (e.g. a domain administrator) logs onto the system, the password of the account is stored in cleartext in the Local Security Authority Subsystem Service (LSASS) and can be read for example with mimikatz:
Another way to take over locally logged on accounts is by using Scheduled Tasks.
Such accounts can for example be identified by executing the command query user.
Given administrative privileges, Scheduled Tasks can then be created to run in the context of any currently logged on user.
These tasks can then also be triggered manually and immediately.
While this scenario is increasingly rare, it's probably still worth mentioning.
Exploitation requires two Domain Controllers (DCs) that don't have SMB Signing enabled.
Then, exploitation is simple.
Step 1:Set up impacket to relay authentication to the second DC:
A rather widespread type of attack, Attacker-in-the-Middle also works against Active Directory infrastructures. To achieve an Attacker-in-the-Middle position, tools like Responder, mitm6 or bettercap can be used:
Kerberoasting is an attack that relies on the following facts:
A seasoned pentester can check for all of these vulnerabilities and, if they exist, exploit them within the span of a few hours,
and this includes initial reconnaissance, checking all vectors and taking notes.
A red-teamer or attacker with a singular goal could see success within minutes.
And the result is often complete domain takeover.
So for any aspiring Active Directory pentesters, I think this is a good start.
And for any blue teamers or system administrators, protecting against these attacks and fixing these vulnerabilities is a good start to cover the basics.