Under the EDRadar: ADExplorer on Red Teams

Active Directory (AD) is the heart of many corporate networks, and as a penetration tester, understanding how to navigate and manipulate it is essential. In this guide, we will explore the powerful tool ADExplorer and uncover its various applications for offensive purposes. ADExplorer is part of Mark Russinovich’s Sysinternals suite, which is largely used for legitimate actions, and offers a range of functionalities for both system administrators and pentesters.

Getting Started

First, make sure you have ADExplorer downloaded on your local machine / compromised machine, you can download any of the Sysinternals suite tools from the following link.

http://live.sysinternals.com/

I won’t go into the process of proxying your traffic through a C2 beacon and port forwarding in this post or using Pass-The-Hash (PTH) to inject a hash into a process and running ADExplorer with an NTLM hash instead of a password. I will share some info around those processes at a later date. For now I will assume you have access to a compromised machine or domain credentials (don’t have GUI access? I will cover a way to get a snapshot from the command line). Lets get started and I will take you through a brief process of getting ADExplorer running and a few key areas to look at when utilising ADExplorer.

Getting Started

Once you have downloaded or executed ADExplorer you will be presented with the following:

Enter the following in the fields:
Connect to: Domain Controller IP
User: Domain User
Password: Domain User Password
(If you are executing this in the context of a valid user already on a domain computer you can leave these blank)
Enter the path of a previous snapshot to load. If you have a previous snapshot that was already captured you can load it here and query the AD offline.

Note: If you are on a domain joined machine with valid credentials, you can just hit “OK”.

Taking Snapshots

If you want to create a snapshot of the AD, you can accomplish this via the “Create Snapshot…” option. Doing this not allow you to interact with ADExplorer until the snapshot is complete.

In the next section we will have the option to set a description, specify the output and the maximum utilisation of the domain controller:

Depending on the domain size, this can take a quite a long time and can end up being quite a large file. I’ve had snapshots over 7GB and snapshot times take over 6 hours. To this day, the only time I have been detected across the network taking a snapshot was over a VPN which had minimal use. Going from a VPN that has maybe 1-2 users a day to all of a sudden someone using over 5GB can be a dead giveaway. The detection wasn’t from the LDAP queries but from the high VPN utilisation. Learn from my mistakes.

Once this process is complete you can then view this snapshot in ADExplorer offline or convert it to a BloodHound collection.

No GUI Access?

Not a problem, it is actually possible to take a snapshot using the command line only. If you have access into a network, you can drop ADExplorer.exe on the local machine and execute option one (1) or if you have internet access you can execute option two (2):

Option one (1):
ADExplorer.exe -snapshot "" <domain_snapshot.dat>
Option two (2):
\\live.sysinternals.com\Tools\adexplorer.exe -snapshot "" <domain_snapshot.dat>

Once you get the snapshot (it will be in the current working directory you executed the above command in) you can exfiltrate it and load the snapshot on your local machine to enumerate the domain offline. For brief information on using Sysinternals Live see this page.

ADExplorer Tips:

Kerberoastable Users:

The first tip is to look for Kerberoastable users in the domain. Kerberoasting is a technique used by pentesters to extract the kerberos hash and crack service account passwords that are encrypted using the Kerberos protocol. These service accounts are sometimes referred to as Service Principal Names (SPNs).

To find Kerberoastable users you can search for the following:

samAccountType = 805306368
servicePrincipalName = not empty

Just keep in mind if there is a good EDR used on the domain controller – requesting the ticket for these Kerberoastable users will raise and alert, so gauge whether it is worth it or not. Also note that the krbtgt account will be disabled and you won’t be able to request the ticket for it.

Enumerate Users:

An easy way to find the users within the domain and get further details around their account can be found under CN=Users. Once you start looking through these users you can also get further information around them through their description, primary Group ID etc. This will help when trying to figure out which users would be worth targeting or not.

Sites and Services:

In the early phase of the penetration test, you won’t have much of an idea of what exists in the Active Directory environment. A good place to start is the sites and services. You can get a good idea for all the subnets that exist in the environment (or I guess you could just Nmap every internal IP… /s). In this environment, we don’t have the subnets as it wasn’t included (it has to be specifically implemented, it won’t be added by default) so don’t expect to see it every time but the below screenshot shows where you would find it.

Credentials:

I know we went through the details of users previously but user descriptions isn’t the only place to find clear text credentials for an account. I like to begin the search from the users container and search for descriptions that aren’t empty:

If you are on a domain with a large amount of users (recently I was on an engagement and it had close to a million domain user accounts, in this case, obviously, we don’t have time to manually comb through every description) you can modify the query to search for password, or any term you might think useful in the description:

Another way we can potentially pull out passwords is the attribute “userPassword”. I find that this is very often overlooked on engagements, it is a very quick check you can perform with a high upside. The likelihood of seeing this is rare but I have seen it before a handful of times. In this environment, it doesn’t exist, but for context this is how you would search for it:

This can also be done for unixUserPassword:

A short list of fields to search for are:

• UserPassword
• UnixUserPassword
• unicodePwd
• msSFU30Passwor
• os400Password

Domain Details

There is also a large amount of useful domain details that you can gather that will help in the later stages of the engagement.
Just a quick glance at the type of useful information we can get is:

• LockoutThreshold: Amount of times you can attempt to login on a domain account before the lockout period begins (useful to know for password spraying)
• maxPwdAge: This attribute in Active Directory represents the maximum password age policy. This policy specifies the maximum amount of time, in days, that a user can keep a password before they are required to change it. Why is this useful? If the maxPwdAge is 30 days and you find clear text credentials in an SMB share from 90 days ago, its possible these credentials won’t work.
• ms-DS-MachineAccountQuota: This is actually very useful to know on an engagement. By default, every domain user account can add up to ten (10) machine accounts to the active directory environment. Why might you want to do this? Well if you need some accounts to burn for specific tasks, you can potentially use these (just remember they will be tied back to whatever account created them) or if you have to exploit a Resource Based Constrained Delegation attack, you’ll need a machine account for it. Perhaps the domain computers group is part of a privileged group, and the list of reasons to create a domain computer account goes on.

Trusts

If you find yourself in an environment that has multiple domains within a forest or you’re part of a child domain (basically a subdomain under a parent domain), you can search for the objectClass “trustedDomain”:

In this case we do have a trust in the domain, if you double click it, it will provide a lot more useful information:

From this output we can see that we are a child domain of the sevenkingdoms.local and the trust relationship is represented by an integer of 3, bidirectional trust.

How do we know this? We can look at the specific information from Microsoft:

ADExplorer is a valuable tool for penetration testers seeking to enumerate Active Directory. It offers a range of functionalities that can assist in various offensive scenarios. While we’ve touched on the basics of using ADExplorer in this guide, there is much more to explore and leverage in your assessments.

Remember that using ADExplorer for reconnaissance can uncover critical details about the Active Directory environment, including user accounts, groups, group memberships, domain policies, trust relationships, and potential vulnerabilities. As you delve deeper into your penetration tests, ADExplorer can be an indispensable asset for understanding the network’s structure and identifying potential points of exploitation while potentially going under the radar of some security implementations.

If you have any other cool techniques with ADExplorer that you think I should include, add them below in the comments and I’ll include them.