Active Directory Penetration Testing: The Attacker View

Active Directory penetration testing simulates what happens after an attacker gets a foothold on your network. That foothold might come from a phishing email, a stolen laptop or a leaked password. The test then follows the same path an attacker would take from there to Domain Admin. It exists because that path is almost always shorter than IT teams assume, and the weaknesses that make it possible rarely show up on a standard vulnerability scan.

A foothold is rarely the end goal

Attackers do not usually break in and stop at one laptop. Once inside, the next move is almost always the same: find out what Active Directory knows. A single low-privilege account can query the domain for every user, group, computer and permission relationship in the environment. That information is available by design to any authenticated user. Tools such as BloodHound turn that raw data into a graph, and the graph very often reveals a short, unglamorous route to full control: a helpdesk group with an overlooked permission, a service account with a weak, unchanged password, or a forgotten trust relationship from an old migration.

Why this matters more than almost anything else on the network

A joint advisory from the UK’s National Cyber Security Centre, the US CISA and NSA, and cyber agencies in Australia, Canada and New Zealand states this plainly. Once Active Directory is compromised, threat actors gain privileged access to all the systems and users it manages, and responding to that kind of compromise is time consuming, costly and disruptive. Analysis of Mandiant incident response engagements, cited in industry research, puts Active Directory’s involvement in intrusions at around 90 percent. That figure covers both the initial entry point and the escalation route to full control. Ransomware operators lean on it hardest of all. Owning the domain means they can deploy encryption across every connected machine in one push, instead of fighting through systems one at a time.

The techniques testers actually chase

A capable tester walks the same path an attacker would, using a known toolkit of Active Directory attack techniques:

• Kerberoasting, requesting a Kerberos service ticket for an account with a registered service principal name, then cracking it offline to recover a plaintext password without ever touching the domain controller directly again.
• AS-REP roasting, targeting the smaller set of accounts configured without Kerberos pre-authentication, which allows a ticket to be requested and cracked without supplying any password at all.
• Password spraying, trying a small number of likely passwords across many accounts rather than many passwords against one, so lockout policies never trigger.
• DCSync and Golden Ticket abuse, exploiting replication rights or forging Kerberos tickets to impersonate any account in the domain, Domain Admins included.
• Unconstrained delegation and ACL misconfiguration, where a server or account can act on behalf of others in ways nobody intended when the permission was granted.

What makes these dangerous is that none of them depend on unpatched software. They exploit how the domain is configured, so patching alone will never close them. Only someone who actually walks the path, the way Active Directory penetration testing does, will find them before an attacker does.

From attack path to fixed environment

Once a tester reaches Domain Admin, or exhausts the agreed scope, the real value starts: turning the path into something your team can actually act on. That means documenting each step with evidence, showing how the pieces chain together rather than listing them as isolated findings, and prioritising fixes by which links in the chain do the most damage if removed. Breaking one step in a five-step attack path is often enough to stop the whole route working, which is why a good report reads like a story rather than a spreadsheet.

Where this sits alongside your other testing

Internal penetration tests already cover servers, workstations and applications across the network. Active Directory penetration testing narrows that lens specifically onto identity and privilege. The two overlap in practice, since a weakness found on an ordinary workstation is frequently the opening move in a domain attack path. Annual testing is a sensible baseline, though it is worth reading why that baseline sometimes falls short. Run an extra round after anything that changes the trust model: a merger, a new domain trust, or a reshuffle of who sits in your privileged groups. If it has been longer than a year since anyone actually tested your domain, rather than just your perimeter, that gap is worth closing. Aardwolf Security can scope an assessment that fits your environment, and you are welcome to get in touch to talk through timing and cost.

Why Active Directory penetration testing depends on skill, not the tool list

BloodHound, Impacket and Rubeus are widely used and freely available. That means the tools themselves are not what separates a good Active Directory penetration testing engagement from a mediocre one. Two testers can run the same software against the same domain and come back with very different results. One stops at the first obvious finding. The other keeps pulling the thread until they have proven a full path to Domain Admin, because a partial path that looks blocked on paper is sometimes still walkable once you account for a forgotten trust or a stale group membership.

Formal accreditation, such as CREST membership in the UK, is a reasonable proxy for quality. It requires testers to pass rigorous, assessed exams, rather than just claim experience on a CV. That is not a guarantee on its own, so ask to see a sample attack path from a past engagement, redacted for client confidentiality, before you commit. A provider confident in their work will usually have one ready to show, and it is worth knowing the wider red flags when you choose a penetration testing provider.

Scope matters just as much as skill. A test capped at one working day for a multi-domain forest with several thousand users will not have time to do more than scratch the surface, whatever the tester’s ability. Match the time allocated to the actual size and complexity of your environment, not to what fits a fixed quarterly budget line.

Frequently asked questions

Is this just a rebrand of a normal internal test?

No. An internal test is broader and shallower across the whole network. Active Directory penetration testing goes deep on one thing: how privilege and trust actually work inside your domain, and how far a single compromised account can travel.

Can a vulnerability scanner find these issues instead?

Not reliably. Scanners look for missing patches and known vulnerabilities. Attack paths built from permission misconfigurations, weak service account passwords and delegation settings are invisible to that kind of automated check.

What access does the tester start with?

A standard, non-administrative domain account, the same starting point as almost every real-world breach. Handing over elevated access defeats the purpose of the exercise.

Is our business too small for this to be relevant?

No. Domain size changes the scope and duration of the test, not whether the risk exists. A small domain with a handful of overlooked permissions can be compromised just as completely as a large one.

How long does a typical engagement take?

Three to five days for a single, mid-sized domain is common, with more time needed where multiple domains, forests or trusts are involved.