Active Directory Penetration Testing: How Engagements Work

Active Directory penetration testing runs through five phases.
1. Scoping the starting position.
2. Gaining an initial foothold.
3. Harvesting credentials.
4. Escalating privilege.
5. Proving domain dominance.
Each phase builds on the last one's findings. The report prioritises fixes based on which finding collapses the most paths to domain control.

Active Directory Penetration Testing

Most breaches involving Active Directory don't start with an exploit. They start with a low-privilege foothold and a domain that was never designed to stop someone working outward once they're inside.

Active Directory penetration testing exists to find that path before someone else does. More importantly, these tests must be done as a connected engagement, not a set of isolated checks. Our internal network testing traces that path the way attackers would. Scope, foothold, and then everything that foothold makes possible.

How Active Directory Penetration Testing Gets Scoped

An AD pentest starts with a conversation about our starting position, not a list of techniques to run. Some organisations want to know what a compromised laptop on the corporate network can access. Others want to simulate a malicious insider with valid but limited credentials. The starting point changes what the test proves, so it has to be agreed on before testing begins.

The scope also covers what's off-limits. That includes production systems that can't tolerate disruption and any privilege escalation path risks you already know about. It also covers whether the monitoring team gets advance warning or is tested blind. 

None of this is boilerplate. Getting it wrong produces a test that either proves nothing useful or causes an unwanted outage.

Initial Foothold

Every engagement needs a starting point inside the network. How that starting point is created depends on the scope agreed on. Some engagements start with a foothold already granted, like a low-privilege domain account handed over to simulate a compromised employee device. 

Others start from zero, with the tester expected to find a way in through the same categories a real attacker would use. That means exposed services, weak initial authentication, or a misconfigured endpoint reachable from inside the network.

The category matters more than the specific technique here. The same weaknesses tend to recur across different environments, even when the exploit changes yearly. A tester's job in this instance is to establish that a foothold is achievable. From there, we move to what that foothold makes possible.

Credential Harvesting

Once a tester has a foothold, the next phase works out what credentials that position can reach. This covers examining what's cached locally, what other systems the compromised host trusts, and what network services can be coaxed into revealing usable secrets.

In many cases, credential harvesting happens through kerberoasting. Our breakdown of Kerberoasting detection covers how that technique works and what a SOC needs to catch it. What matters at the engagement level is that harvesting rarely stops at one credential. Each one found tends to lead to the next, mapping out fresh Active Directory attack paths as it goes.

Privilege Escalation

This is where an AD pentest really earns its budget. When you escalate privileges, you can turn stolen credentials or a foothold's permissions into something more valuable. That could be administrative rights on a system, control over a service account, or a path toward the domain.

A pentester works through several broad categories. That includes exploiting trust relationships between systems and abusing legitimate delegation features. It also means using permissions that were never meant to grant this much access. Golden and Diamond Tickets are a common route in, and they look legitimate to an unprepared SOC. 

This phase of the engagement is where those techniques get tested against your specific environment.

Domain Dominance

Domain dominance is the point at which a tester demonstrates control over the domain itself, not just a single system within it. This finding tends to focus a client's attention. It shows what the entire chain of smaller issues leads to once someone follows it through.

Reaching this point isn't the goal on its own. It exists to prove the path is real. It also shows which of the smaller findings along the way would have stopped it if fixed. A report that ends at domain dominance without naming the real chokepoint isn't very useful. You want a report that shows you exactly where the chain could have been broken.

Active Directory Penetration Testing Isn't Five Isolated Checks

On paper, this looks like five separate stages: scope, foothold, harvest, escalate, dominate. Treat them as five independent checks, and the engagement loses its value. 

What matters is how a finding in one phase becomes the input for the next. A cached credential from harvesting becomes the key to an escalation path. That escalation path becomes the route to domain dominance.

A report that lists five clean phases and stops there doesn’t tell you much. You want one that shows you how these stages connect, where their domain is exposed, and in what order an attacker would reach it.

Turning Findings Into Remediation Priority

An engagement usually surfaces more findings than any team can fix at once, so the findings report needs to do more than list them. Findings that sit early in the attack chain tend to deliver more security improvement per fix. That's especially true when they block multiple escalation paths at once.

That's the judgement call a report needs to make explicit. Not just what was found, but also which fixes collapse the most active directory attack paths back to a single, fixable root cause. Besides the report ranking the findings’ critical impact, working through a findings list within this context can help you prioritise which ticket to open first.

Most Domains Have Unmapped Trust Relationships 

Every domain accumulates trust relationships and legacy permissions that nobody fully maps as they build up. Active Directory penetration testing traces those relationships the way an attacker would, then shows you where the chain can be broken.

Let’s Scope Your AD Penetration Test

Questions About Active Directory Engagements

What Does an AD Pentest Cover?

It covers the entire path from an initial foothold to domain-level control; credential harvesting, privilege escalation, and lateral movement between systems. The goal is to show which combination of findings gives an attacker a working route to the domain, not just listing a bunch of weaknesses.

How Is It Different From a General Internal Network Pentest?

An internal pentest looks at the network as a whole, including systems that sit outside the Active Directory. An AD pentest narrows in on domain trust relationships, group policy, and the identity infrastructure most internal attack paths rely on.

What's the Difference Between an Attack Path and a Vulnerability?

A vulnerability tends to be a single flaw, like a missing patch or a weak permission on one object. An attack path is the chain that connects several such issues into something an attacker can exploit.

How Long Does an Active Directory Engagement Usually Take?

Timing depends on domain size, the number of trust relationships in scope, and the starting position agreed on during scoping. Rather than quoting a fixed figure, we work this out during a scoping call, so the engagement matches your environment's real complexity.

Do You Cover NTLM and Kerberos Migration Risk in the Same Engagement?

Yes, where it's in scope. An AD pentest will test wherever your environment still leans on NTLM instead of modern Kerberos authentication and flags that gap as part of the findings.

Ready to Close the Gaps in Your Domain?

Active Directory accumulates complexity fast, and most of it stays invisible until someone traces it end to end. Our pentesters scope every engagement around your environment's real starting position.

Book a Free Consultation

Want to Read More?