Active directory pentesting: cheatsheet and beginner guide

Often organizations that utilize Active Directory (AD) think that they are secure because of a strong vulnerability management program and patching new threats/vulnerabilities constantly. Their vulnerability scans may come up clean week after week, but are they truly secure? If they are neglecting AD security, then most likely not. 

I have performed penetration tests against many organizations where I was unable to find any directly exploitable services or applications but was able to gain a foothold in Active Directory, take over the domain (or domains), and issue 10 or more high-risk findings related to AD in their penetration test report. 

As a penetration tester, ignoring AD typically results in leaving a massive attack surface on the table. At the same time, organizations not implementing (or with weak) AD security also open themselves up to a plethora of attacks.

Learning Active Directory for beginners 

AD is a vast topic and can be overwhelming when first approaching it. My number one tip for anyone starting with AD is to gain an understanding of the fundamental key components that are present in an AD environment and how they fit together.

Until you understand these key components and can recall from memory the most important ones to enumerate during a penetration test (users, groups, computers, Organizational Units (OUs), Access Control Lists (ACLs), Group Policy Objects (GPOs), local administrator access, etc.), it will be challenging to follow along with any AD training course. 

Below is a list of key components we recommend learning about in-depth before diving deeper into AD and the key focuses for enumeration. If you are starting out, we recommend the Introduction to Active Directory module on HTB Academy. It will take you from zero knowledge of AD to a decent, well-rounded understanding of the fundamentals.

Once you have this core knowledge under your belt, you can move into our other specialized modules, such as Active Directory Enumeration and Attacks. If you are not yet conformable with the Windows Command Line, we recommend the Introduction to Windows Command Line module as will teach you the necessary fundamentals needed to navigate Windows systems from the command line.

Recommended read: What is Active Directory? 

Definition of key components 

Object

An object can be defined as ANY resource present within an Active Directory environment such as OUs, printers, users, domain controllers, etc.

Attributes

Every object in Active Directory has an associated set of attributes used to define its characteristics. A computer object contains attributes such as the hostname and DNS name.

All attributes in AD have an associated LDAP name that can be used when performing LDAP queries, such as displayName for Full Name and given name for First Name.

Schema

The Active Directory schema is essentially the blueprint of any enterprise environment. It defines what types of objects can exist in the AD database and their associated attributes. It lists definitions corresponding to AD objects and holds information about each object. For example, users in AD belong to the class "user," and computer objects to "computer," and so on. 

Each object has its own information (some required to be set and others optional) that are stored in Attributes. When an object is created from a class, this is called instantiation, and an object created from a specific class is called an instance of that class. For example, if we take a computer named RDS01. This computer object is an instance of the "computer" class in AD.

Domain

A domain is a logical group of objects such as computers, users, OUs, groups, etc. We can think of each domain as a different city within a state or country. Domains can operate entirely independently of one another or be connected via trust relationships.

Forest

A forest is a collection of Active Directory domains. It is the topmost container and contains all AD objects, including but not limited to domains, users, groups, computers, and Group Policy Objects (GPOs). A forest can contain one or multiple domains and be thought of as a state in the US or a country within the EU. Each forest operates independently but may have various trust relationships with other forests.

Tree

A tree is a collection of Active Directory domains that begins at a single root domain. A forest is a collection of AD trees. Each domain in a tree shares a boundary with the other domains. A parent-child trust relationship is formed when a domain is added under another domain in a tree. Two trees in the same forest cannot share a name (namespace). 

Let's say we have two trees in an AD forest: inlanefreight.local and ilfreight.local. A child domain of the first would be corp.inlanefreight.local while a child domain of the second could be corp.ilfreight.local. All domains in a tree share a standard Global Catalog which contains all information about objects that belong to the tree.

💡If you're interested in learning how to defend active directory, check out our guide on Active Directory hardening, in which a SOC analyst defends AD from our Head of Security's attempts to perform a Golden Ticket attack. 

Container

Container objects hold other objects and have a defined place in the directory subtree hierarchy.

Leaf

Leaf objects do not contain other objects and are found at the end of the subtree hierarchy.

15 important tools for Active Directory Pentesting

There are a plethora of tools for enumerating and attacking Active Directory environments, both from a Linux and a Windows testing machine. Below is a list of what I consider to be the top ten necessary tools to have present on a Linux testing machine and five more that I would have ready for once I get access to a Windows host in the environment. 

There are many, many other tools (an extensive list can be seen in the Active Directory Enumeration & Attacks module) that we may need depending on what we run into during the assessment, but this list is what I use on pretty much any Active Directory-focused penetration testing engagement from start to finish.

Base Linux machine toolkit: 

1. BloodHound.py & BloodHound GUI - Tool for enumerating Active Directory and creating graphical representations of possible attack paths. Check out the Active Directory BloodHound module for more on these tools.

2. Impacket Toolkit - Various scripts for interacting with Active Directory, from enumeration and attacks to remote access and everything in between.

3. Kerbrute - Tool for enumerating valid Active Directory usernames and performing password spraying attacks.

4. Responder/Pretender - Tools for performing poisoning attacks against various network protocols to gather password hashes for relaying attacks or offline password cracking.

5. CrackMapExec - A multi-use Active Directory enumeration and attack tool that can be used with various protocols, including SMB, WinRM, LDAP, RDP, and more. It contains many modules for enumerating and attacking individual Windows hosts and Active Directory environments. There is an excellent module, Using CrackMapExec, on HTB Academy for practicing with this tool. 

6. Rubeus - A C# toolkit for interacting with and abusing the Kerberos protocol.

7. Certipy - A tool for enumerating and attacking Active Directory Certificate Services (AD CS).

8. PKINITtools - Various small tools for working with PKINIT (a pre-authentication mechanism for Kerberos 5). They are handy when performing attacks against AD CS.

9. Hashcat - A tool for performing offline password cracking. Very useful for the various types of password hashes we will collect during an AD pentesting engagement. Practice this powerful tool via the Cracking Password with Hashcat module on HTB Academy.

10. Evil-winrm - A powerful tool for remotely authenticating to hosts via WinRM using an NTLM password hash, cleartext password, or Kerberos authentication.

Windows box tools:

1. Mimikatz - A very powerful tool for extracting password hashes and other credential information from Windows hosts. It can be used in various AD attacks. 

2. PingCastle - An excellent tool for auditing Active Directory security from the top down. Sometimes finds issues that other tools miss. Useful for recommending further AD hardening steps for customers in their pentest report. 

3. Certify - A C# tool for enumerating and attacking AD CS, similar to Certipy.

4. PowerView - A powerful PowerShell tool for enumerating and attacking AD. It can be used to dig very deep into various AD objects and for some attacks (i.e., Keberoasting). This tool is no longer supported by the authors in favor of C# tradecraft but remains a powerful and extremely handy tool to keep in your arsenal. A fork of the tool was made to add additional features, and it is worth checking out. Dig deep into this tool with the Active Directory PowerView module on HTB Academy. 

5. SharpHound - The C# data collector for the BloodHound tool. There is also a PowerShell version and AzureHound for enumerating Azure environments. Check out the Active Directory BloodHound module for in-depth training on these collectors and the BloodHound GUI tool. 

As mentioned in the descriptions, some of these tools have dedicated modules on HTB Academy; others are covered in-depth in modules such as Active Directory Enumeration & Attacks. Stay tuned for many more AD-focused modules on HTB Academy as well!

We will discuss the “why” behind each of these tools in the next section, where we will see several sample approaches for starting a penetration test in an AD environment with and without being provided credentials by the client. Every environment is different, so certain tools may not be necessary, and everyone has their own style/approach, but these can be thought of as “high percentage” tools and techniques that will be employed more often than not.

An overview of the Active Directory enumeration and pentesting process

Methodologies for attacking Active Directory will vary from pentester to pentester, but one thing that will be true across all internal assessments is that we will start from either: 

• An uncredentialed standpoint: No AD user account and just an internal network connection.

• A credentialed standpoint: Typically a low privileged, standard AD user account. 

So depending on how the client wants us to start the assessment, our initial steps will differ. Beginning with an AD user account is generally “easier” because we can move right into enumerating the vast attack surface that is AD. But, lucky for us, there are multiple ways to obtain a valid AD user account.

 

Starting out (uncredentialed)

In my experience, the customer will usually ask the tester to start from an anonymous position on the network to see how far an attacker who can gain internal network access can move laterally and vertically. There are several ways we can obtain a valid AD user account. Let’s look at a few.

💡Note: The examples here also assume that stealth is not a consideration for the assessment, but rather we are helping the customer to identify as many issues as possible across their AD environment. 

1. A quick win is often running a tool such as Responder or Pretender to perform either LLMNR/NBT-NS Response Spoofing or DNS Spoofing over IPv6 to obtain NTLMv1 or NTLMv2 (more common nowadays) password hashes to either crack offline using Hashcat or perform an SMB Relay attack to dump domain data or gain local admin access to a host. 

2. If we find that one or more domain controllers are configured to allow SMB NULL sessions or LDAP anonymous binds, we can dump a list of all AD users along with the domain password policy and mount a password spraying attack using a tool such as Kerbrute. If we are fortunate enough to obtain the domain password policy, we are generally safe with multiple password spray attempts, provided that we are operating within the bounds of the password policy and not locking accounts out. We only need one hit (successful password spray) to begin our AD enumeration/attacks.

3. If the first two options are not working, we can build our own user list to enumerate valid AD user accounts with Kerbrute. I typically start by scraping the target company’s LinkedIn page using linkedin2username and testing for valid accounts against that list. I will usually get some hits here. Once I know the username format (i.e., jsmith or john.smith), I can proceed to perform further enumeration using one of the lists, such as jsmith.txt, from the statistically-likely-usernames GitHub repo. Armed with this list, I can perform 1-2 password spray attempts with a common password such as Welcome1 and then the season + year or month + year (i.e., Spring2023 or March2023). Not knowing the password policy, I usually would not go any further, so I will sometimes ask the client if they are willing to provide it. If not, then I will move on to not risk locking out one or many AD user accounts.

4. If none of the above work, perhaps we can find a system vulnerable to a known exploit that we can land a SYSTEM shell on. If the machine is domain-joined, then this is just as good as any AD user account to start performing our enumeration.

5. Any number of attacks that can be used to coerce NTLM authentication. One example is PetitPotam which sometimes can be used to perform an NTLM relaying attack without requiring valid AD user credentials if AD CS is present and configured on a domain controller instead of a separate server.

There are many other ways that we may obtain a foothold in AD. We won’t cover all of them here; the above are some of the most common “easy wins” and “low-hanging fruit”. Now let’s look at how we can start if we’re given a valid AD user account. The following steps would also typically be how I would proceed after obtaining a valid AD user account. 

💡Note: Even if the client has you start with credentials, it is worth running through the steps above to show them any additional attack vectors in their network (such as weak credentials, unpatched systems, or network protocols that allow for credential theft).

Starting out (with credentials)

1. When we have a valid AD user account, the first step is typically to get a lay of the land. We can do this very effectively with BloodHound and begin to map out attack paths, such as hosts we may have local admin on or potential users/computers to target. We could also use PowerView or many other tools to enumerate information about key AD objects and their permissions. 

2. Active Directory Certificate Services (AD CS) presents a vast attack surface, so it's always worth checking to see if it is present and then enumerating for possible misconfigurations using Certipy or Certify. When present, a misconfiguration could quickly lead to Domain Admin level access, or complete administrative control over the AD domain.

3. We could also perform “roasting” attacks such as Kerberoasting or ASREPRoasting. The success of these attacks depends on an account having a weak password set, but if we can obtain and crack a password hash, we may gain access to an account that can help us move further toward our goal or even go direct to Domain Admin. (Related read: What is Kerberos security and authentication?)

4. We could potentially perform a DACL attack, exploit a misconfigured GPO, leverage group membership that allows for Remote Desktop (RDP) access to a host and then escalate privileges, find a password in a user or computer’s description field, or find a password in a Group Policy preferences file.

5. Often we can pull off more advanced Kerberos delegation attacks such as Resource- Based Constrained Delegation (RBCD), relaying to AD CS using PetiPotam, the Shadow Credentials attack, and others that are outside the scope of this post. 

6. Sometimes we are getting nowhere and must resort to digging around shares for juicy data, such as a user that keeps all their passwords in a .txt file or spreadsheet; a web.config file with an MSSQL service account password; a VMDK backup of a host that we can pull the local administrator password hash from and re-use across other systems, and more. PowerView or CrackMapExec can be used for this purpose, but one of my favorite tools for digging in shares is Snaffler. Another excellent tool for digging into shares and performing a permissions audit on shares is PowerHuntShares. Similar to how we mentioned PingCastle earlier, we can use this tool to provide extra, more granular data for our clients so they can work on their file share permissions which can be very difficult to maintain correctly, especially in large environments. 

We’ve seen multiple ways to gain a foothold in AD from an anonymous perspective on the network and what steps we can take if we are given a valid AD user (or after obtaining a foothold). The approaches in these lists are not exhaustive, as the paths we take will vary from assessment to assessment, but the examples should be a great starting point for anyone looking to get a leg up during their AD-focused pentests. Any organization running Active Directory can also use these examples as a sort of “self checkup” to see how well they are protected against common and less common tactics used by penetration testers and malicious actors.

Active directory cheat sheet of commands and tips 

Putting together a cheat sheet for AD commands is a complex task, as there are so many important commands to be aware of! In the cheat sheet below, I’ve picked a small sample of commands that follow a logical flow from the beginning to the end of an assessment and also fit the (credential and uncredentialed) attack methodology examples I gave earlier in the blog post. The commands we run during an assessment vary based on the target environment and personal style, but these are a small subset of “high percentage” commands/variations of commands that I see run on most internal network assessments where AD is in play.  

 

 

Final word on reporting and documentation 

During an internal penetration test at a client's headquarters, a particularly hostile network administrator was skeptical of our abilities since the kickoff call. He stated that previous penetration tests from other companies had slowed the network down massively due to inexperienced and reckless testers.

Less than 20 minutes into testing, this network admin had sent emails to the entire distribution list and came over to my desk telling me that our scans had slowed the network to a halt. Eventually, we discovered that this was caused by the debug mode being enabled on every network device, which combined with normal Nmap scans, caused slowdowns. Once this was disabled, testing proceeded without issues.

In this case, our documentation backed up our actions and forced the customer to investigate further. If we didn’t have any (or had poor) documentation, the blame could have easily been placed on us, and it could have greatly impacted the client relationship and our firm’s reputation.

Decimating a network’s defenses alongside our team members is fun. But it’s not the core reason why customers hire us to hack them. When undergoing penetration tests, what clients really want is an assessment or penetration testing report to provide them with a snapshot of their environment, its defenses, and their preparedness to deal with threats at that moment in time.

That information (the good and the bad) will be used to determine:

• Remediations they need to apply.

• Hiring and resource budgets for their security team. 

• The new defensive tools and processes they can invest in.

• Cybersecurity training they should acquire for the coming year.

So whether you lean towards internal or external testing or are looking to become a penetration tester, strong reporting and documentation skills are critical throughout any engagement. Staying organized from the beginning of an assessment (especially when it involves a large AD environment) is vital.

This will make it easier to go back and find enumeration data when in the attack phase, assist with the iterative testing process, help with answering client questions, and be highly worth it once it comes time for reporting. Hone your Active Directory penetration testing chops and combine them with strong organization, documentation, and reporting skills, and you will go far!

Author bio: Ben Rollin (mrb3n), Head of Information Security, Hack The Box Ben Rollin has over 13 years of information security consulting experience focusing on technical IT Audits, risk assessments, web application security assessments, and network penetration testing against large enterprise environments. He has a strong interest in Active Directory security and focuses time on research in this area as well as remaining current with the latest tactics, techniques, and procedures (TTPs). Ben has a bachelor's degree in Business Administration, as well as several industry certifications including Certified Information Systems Security Professional (CISSP), Certified Information Systems Auditor (CISA), Offensive Security Certified Expert (OSCE), and Offensive Security Certified Professional (OSCP). Feel free to connect with him on LinkedIn.