TL;DR

·      AD pentesting is different from traditional app testing, focusing on
misconfigurations, permissions, and relationships.

·      The goal is to move from a foothold to the Domain Controller (DC) by
escalating privileges and leveraging lateral movement.

·      Key steps after gaining a foothold: escalate privileges, enumerate
permissions, map the network, and pivot.

·      Common tools: SharpUp, BloodHound, Mimikatz, Rubeus, PowerView.

·      OpSec is crucial—use quieter tools and techniques to avoid detection.

·      The process involves strategic mapping, privilege escalation, credential
dumping, and exploiting trust relationships.

Introduction

This article is intended for individuals beginning their journey into Active Directory (AD) pentesting and is put together from personal experience gained while pursuing the CRTP certification. The goal is not to provide a deep, all-in-one technical breakdown, but rather a quick and practical read that gives an idea of what to expect and helps set things in the right direction. It’s meant to build the proper mindset for approaching AD environments, offer a foundational understanding of how attacks typically flow,
and highlight the areas most targeted. Hopefully by understanding the right mindset early on, this should serve as a head start, helping avoid the trial-and-error process of figuring things out the long way.

Mindset

The mindset required for Active Directory (AD) pentesting is quite different from traditional application security testing. These differences also demand a change in methodology when approaching an AD environment.

Perspective

The first major shift is in perspective—application pentesting is usually conducted from an outsider’s point of view, attempting to break into asystem from the perimeter. In contrast, AD pentesting typically starts from an internal, low-privileged foothold that’s either obtained through techniques like phishing or pre-assigned as part of the engagement.

Nature Of Vulnerabilities

Another key difference lies in the nature of the vulnerabilities. In application security, flaws are often rooted in the code—think injection attacks, authentication bypasses, or logic flaws. But in AD, it’s less about exploitable software and more about misconfigurations. While traditional internal network pentests may focus on outdated software and unpatched systems, AD pentesting revolves around weak permissions, overly permissive group memberships, and flawed trust relationships. Many attacks—such as Kerberoasting or DCSync—abuse features that function as intended. They don’t rely on traditional exploits; instead, they take advantage of how the environment is configured, exploiting design flaws and weak operational practices.

Environment

Unlike applications, which are finite and functionally scoped, AD environments are interconnected ecosystems. The attacker must think in terms of relationships across users, computers, services, and groups. While chaining vulnerabilities is common across all forms of security testing, AD pentesting heavily emphasizes lateral movement—navigating and abusing relationships rather than targeting isolated exploits.

Long Game

Unlike application pentests that can result in individual high-impact wins, AD attacks are strategic and incremental. Pentesters must adopt a long-game approach—gathering information, chaining missteps, and thinking of abusing relationships to move deeper into the network.

Methodology

The core idea behind Active Directory (AD) pentesting is to move from a starting
point (foothold) to the final target (Domain Controller). All the other systems in the environment—especially those with high-value users or roles—are considered stepping stones. These intermediate machines help us gradually escalate our privileges and move closer to the Domain Controller (DC).

Once we gain access to the network as a low-privileged user, the first goal is to elevate privileges on the current machine to local administrator. This is important because it allows us to perform actions like credential dumping, which helps with further movement across the network. If local privilege escalation isn’t possible on the foothold, we look to pivot to other machines and try to find one where we can gain local admin access. 

After Gaining a Foothold – Key Directions to Explore

1. Privilege Escalation on the Foothold Machine

·      Try to move from a low-privileged user to local admin.

·      This enables techniques like credential dumping, process injection,
and deep enumeration of the environment.

2. Permission Enumeration

·      Check what permissions the current user has, including group memberships and DACLs (Discretionary Access Control Lists).

·      Enumerate permissions of the foothold machine itself—some systems
have rights over other machines.

3. AD Enumeration

·      Identify other computers in the domain.

·      Identify machines where high-privileged users are logged in. Then, check if your current user or system has any level of access or control over those machines. If so, you may be able to dump their account hashes and use techniques like Pass-the-Hash to move forward.

·      Check if the foothold user has local admin access on other machines.

·      Identify delegation settings like Unconstrained, Constrained, or Resource-Based Constrained Delegation (RBCD), which can often be abused for privilege escalation.

4. Build a Map of Knowns and Unknowns

·      Create a list of what you currently know: users, computers, permissions,
relationships, and access levels.

·       Then note what’s missing or unclear—these are your “unknowns.”

·      Mapping out these knowns and unknowns helps you understand how things
are connected and where the gaps are. This will help you identify the next
target, which may be the “missing link” between you and the Domain Controller.

5. Pivot Step-by-Step

·      Start with the first machine in your list of knowns where the foothold user has an exploitable path.

·      Once you gain access, repeat the enumeration process.

·      Use new access to fill in the unknowns, uncover more relationships, and
move deeper into the network.

This process continues in a loop—foothold → privilege escalation → enumeration → lateral movement → repeat—until you finally reach and compromise the Domain Controller. AD pentesting is all about smart mapping, strategic movement, and making connections across the domain.

Common Tools and Techniques

Active Directory pentesting relies on a combination of smart enumeration, privilege abuse, and lateral movement. Here are some of the most used tools and techniques you’ll come across during an assessment:

Enumeration Tools

Before exploiting anything, you need good intel. Enumeration tools help map out the domain, users, permissions, and potential attack paths. These are essential for understanding how the environment is structured and where to move next.

·      net, whoami, dsquery, PowerView – For gathering basic AD information like
user accounts, group memberships, domain trusts, and more.

·      Seatbelt, SharpUp, winPEAS, linPEAS – Help identify local privilege escalation
opportunities by collecting system-specific information like service
configurations, user privileges, and vulnerable settings.

·      BloodHound (with SharpHound) – Visualizes AD relationships by collecting data on users, groups, sessions, permissions, and trusts. It’s widely used to identify privilege escalation paths and lateral movement opportunities across the domain.

Kerberoasting

Kerberoasting is a technique that abuses how Kerberos works in AD. Any domain user can request a service ticket (TGS) for services running under user accounts. These tickets are encrypted with the service account’s password hash. You can extract these tickets and attempt to crack the hashes offline to recover plaintext passwords, potentially revealing high-privileged credentials like SQL service accounts or domain admins.

Tools: Rubeus, Impacket, or GetUserSPNs.py.

Pass-the-Hash (PtH)

This technique allows an attacker to authenticate using NTLM hashes instead of plaintext passwords. If you can dump the hash of a privileged user, you can use it to access other systems without cracking it. This is useful for lateral movement and privilege escalation.

Tools: Mimikatz, Evil-WinRM, psexec.py.

Credential Dumping

Dumping credentials from memory or disk is key to AD movement. Once local admin access is gained, tools like Mimikatz can extract cleartext passwords, hashes, Kerberos tickets, and more. This often gives you access to other systems or users.

Tools: Mimikatz, lsass
dump, procdump + pypykatz.

DCSync

DCSync is a powerful technique where an attacker simulates the behavior of a Domain Controller and asks another DC to replicate credentials. If the current user has replication rights (like Replicating Directory Changes permissions), you can pull password hashes of any user in the domain, including the domain admin or KRBTGT account.

Tools: Mimikatz, Impacket’s
secretsdump.py.

Ticket Attacks

Ticket attacks in Active Directory take advantage of Kerberos authentication to forge
access tokens. A Golden Ticket is a forged Ticket Granting Ticket (TGT) created using the KRBTGT account’s hash, allowing full domain access. A Silver Ticket is a forged service ticket (TGS) used to access specific services without contacting the Domain Controller. A Diamond Ticket involves modifying a real, valid TGT to escalate privileges while preserving legitimate ticket structure. These attacks are powerful for maintaining persistence and lateral movement.

Tools: Mimikatz, Rubeus.

These tools and techniques work best when used together, as part of a well-planned strategy. AD pentesting isn’t about finding one big vulnerability—it’s about combining small weaknesses to eventually take over the domain.

Staying OpSec-Safe During AD Pentesting

When pentesting an Active Directory (AD) environment—especially in a mature or heavily monitored network—stealth is critical. Many common tools, commands, and techniques can trigger alerts, shut down your access, or even burn the entire operation.

It’s also important to understand that red teaming is not the same as traditional pentesting. In a red team engagement, the goal isn’t just to find vulnerabilities—it’s to simulate a real-world attack while avoiding detection by the blue team. That means your actions must not only be effective but also quiet and unnoticeable.

To help you stay under the radar, here are some key habits for keeping your operations OpSec-safe:

Be Smart with Your Tools & Commands

·      Use winrs instead of PowerShell Remoting:
PowerShell remoting (Invoke-Command, Enter-PSSession, etc.) is often logged and detected by Microsoft Defender for Identity (MDI) and Microsoft Defender for Endpoint(MDE).  Replace it with winrs, which is quieter and less likely to trigger alerts.

·      Avoid noisy recon commands like whoami and hostname:
 Instead, use built-in environment variables:

o  PowerShell: $env:COMPUTERNAME, $env:USERNAME

o  CMD: set computername, set username

·      Prefer LDAP-based tools over net commands:
Commands like net user, net group, and others are simple and effective—but they’re also noisy. These legacy commands generate logs that stand out and can quickly catch the attention of monitoring tools. Instead, use LDAP-based
enumeration tools like PowerView, ADFind. It’s used constantly by legitimate
systems and services. So, when you stick to LDAP queries, your activity blends
in with normal traffic—making it far less likely to raise any red flags.

Choose Safer Credential Dumping Methods

LSASS holds juicy credentials, but it’s also one of the most heavily monitored processes. Touching it directly is risky. Instead, consider these quieter sources:

·      SAM Hive (Registry) – For local user account hashes

·      SECURITY Hive / LSA Secrets – For service account passwords and cached domain credentials

·      DPAPI-Protected Files – For saved browser data, credentials, and Azure tokens

·      PSReadline History – Often contains credentials or mistyped secrets in plain text

Be Tactical with Kerberos Ticket Attacks

·      Avoid Domain Admins:
These accounts are highly sensitive and constantly watched. Instead, go after privileged service accounts or delegated admins, which are usually less guarded.

·       Golden Tickets: Use With Caution

o  Always use AES keys instead of NTLM/RC4 for lower detection rates

o  Golden Tickets skip the Kerberos AS-REQ/AS-REP process, making them moresuspicious in logs

o  Use only when necessary and keep lifetimes short

·       Prefer Silver Tickets

o  These target services (like CIFS, MSSQL, etc.) and avoid Domain
Controllers altogether

o  Less likely to be detected because they don’t involve the KDC

o  RC4 can be used here, especially for older service accounts still using
it

·       Use Diamond Tickets for Stealth

o  Modify real, captured TGTs instead of forging new ones

o  Since the original ticket passed through AS-REQ/AS-REP, it blends in
naturally and is far less suspicious

Minimize Noise During Enumeration

·      Kerberoast One Account at a Time: 
 Bulk Kerberoasting is a red flag. Instead,
identify high-value SPNs and target them individually.

·      Don’t Touch LSASS Unless You Must:
 Exhaust registry and file-based credential
sources before considering LSASS dumping.

·      Even klist Can Be Loud:
 Some EDRs flag the klist command. If needed, run it via Rubeus using a loader to stay quiet.

OpSec isn’t just about hiding—it’s about being intentional. Every action you take can either blend in or stand out. Choosing the right tools, using native alternatives, and thinking like a blue team defender will let you explore more, escalate better, and operate longer.

A Basic AD Attack Path

The attack path used in this example is just a basic, straightforward
one. In real-world scenarios, the path can go in different directions depending
on the environment, available privileges, and opportunities for lateral
movement. The actual flow of an AD attack may involve more complexity, with
attackers taking advantage of various misconfigurations, vulnerabilities, or
trust relationships to reach the Domain Controller.

Let’s say you’re inside a company’s internal network after a successful
phishing attack. You land on an employee’s Windows machine as a low-privileged
domain user.

Step 1: Settling Into the Foothold

You check the basics:

·       Who am I?
 (Instead of noisy commands like whoami, you use PowerShell’s quieter: $env:USERNAME, $env:COMPUTERNAME)

·       What am I running on?
 (Seatbelt gives you a full breakdown of OS
info, processes, services, UAC settings, and more.)

You’re just a normal user. No admin rights yet.

Step 2: Escalating Privileges Locally

You run SharpUp to look for misconfigurations.

Boom—there’s a service running with SYSTEM privileges, but the binary
path is unquoted and writable by you. You replace it with your payload and
restart the service.

Now, you’re local admin on this machine.

Step 3: Dumping Credentials

With admin rights, you dump credentials.

Instead of going for LSASS (too noisy), you check:

·      The SAM hive for local accounts.

·      The LSA secrets for cached domain creds.

·      You also peek at PSReadline history—and jackpot! A developer had stored
a password in cleartext while testing.

You now have a password for another user, who seems more privileged.

Step 4: Mapping the Network

Time to plan your next move.

You deploy SharpHound to collect AD data, then load it in BloodHound.
You see that this newly found user has local admin rights on another server.

That’s your next stop.

Step 5: Lateral Movement

You use Pass-the-Hash with the cracked NTLM hash from earlier to access
the next server using Evil-WinRM.

You’re now in.

Step 6: Discovering Domain Escalation Paths

On the new server, BloodHound reveals something critical:
 Your current user has GenericAll permission
over a group that includes a user with DCSync rights.

You update group membership using PowerView, wait for the change to
apply, and then use Mimikatz’s DCSync feature to replicate all the hashes in
the domain—including the KRBTGT hash.

Step 7: Domain Dominance

With the KRBTGT hash in hand, you forge a Golden Ticket using Mimikatz.

You now have unlimited access across the domain, disguised as a Domain
Admin.

You’ve won. And you never touched LSASS directly or ran a single noisy
net command.

Conclusion

Now that the foundation is in place, the next step is to explore each stage of an AD attack in detail—such as recon, lateral movement, and privilege escalation. More focused articles on these topics will be published soon.

It’s important to note that the tools mentioned here are not the only set of tools available. Take the time to explore other tools as well. While the ones highlighted here are some of the most commonly used and effective in AD pentesting, there may be better alternatives that suit individual preferences or specific environments. Experimenting with different tools can help identify what works best for each unique situation.

Hopefully, this article has provided a helpful head start. With the right mindset from the beginning, the learning process will be faster and more efficient, allowing you to avoid
unnecessary mistakes as you progress.