arrow_back All resources
// Resources

Active Directory Penetration Testing: From Foothold to Domain Admin

Published June 6, 2026

An Active Directory penetration test simulates an attacker who is already inside your network — through a phished employee, a compromised laptop, or a planted device — and traces the real path from that low-privileged foothold to Domain Admin. It maps the privilege-escalation and lateral-movement routes through your Windows domain and proves exactly how an intruder would turn one ordinary account into control of everything. Because Active Directory authenticates access to almost every system in a typical enterprise, it is the single most consequential thing to test, and a single weak path through it can hand over the entire estate.

If you run on-premise Windows infrastructure, this is the assessment that answers the question that actually matters in a breach. It is a core part of an infrastructure penetration test; here is what the engagement looks like from the inside.

Why Active Directory is the prize

Active Directory (AD) is the central nervous system of most corporate networks. It decides who can log into which server, open which file share, and run which application — single sign-on across the whole estate. That central role is also its risk: compromise AD and you compromise the organization in one move. An attacker who reaches Domain Admin doesn’t need to break into systems one by one; the domain already trusts them everywhere. This is why ransomware crews and nation-state actors alike make AD their first objective, and why it deserves a test of its own rather than being lumped in with a generic network scan.

The assumed-breach starting point

A credible AD test does not waste the engagement trying to break in from the internet. It uses the assumed-breach model: we start from where real incidents start — a standard domain user account or a device on the internal network, the equivalent of one employee clicking a phishing link. This is deliberate. Empirically, that is how almost every major breach begins, so the high-value question is not “can an attacker get in?” but “once a single user is compromised, how far can they reach?” Starting from a foothold puts the entire engagement budget into answering that.

The attack chain we walk

From that foothold, the test follows the same chain a real intruder would. Each link is a place to stop them.

1. Enumeration and attack-path mapping. The first move is to understand the terrain. Tools like BloodHound (with the SharpHound collector) ingest the domain’s users, groups, sessions, and — critically — the ACLs (access-control relationships) between them, then compute the shortest paths from our foothold to Domain Admin. AD environments accumulate these relationships over years; BloodHound surfaces the non-obvious chains a human would miss.

2. Credential attacks. With the map in hand, the goal is more credentials:

  • Kerberoasting — any domain user can request a Kerberos service ticket (TGS) for accounts that run services (those with an SPN). That ticket is encrypted with the service account’s password hash, which can be cracked offline. Service accounts often have weak, never-rotated passwords and high privileges, making this one of the most reliable escalation routes.
  • AS-REP Roasting — accounts configured without Kerberos pre-authentication leak a crackable hash to any unauthenticated requester. A fast win where it exists.
  • Password spraying — trying one common password against many accounts (rather than many passwords against one) to find weak credentials without triggering lockouts.

3. Lateral movement. Credentials in hand, the attacker spreads sideways:

  • Pass-the-Hash / Pass-the-Ticket — authenticating with a stolen NTLM hash or Kerberos ticket without ever knowing the plaintext password.
  • NTLM relay and authentication coercion — techniques like PetitPotam and the printer bug coerce a machine (even a Domain Controller) into authenticating to the attacker, whose session is then relayed to a privileged service. A frequent path straight to domain compromise.

4. Privilege escalation. The map from step 1 usually reveals a chain of small misconfigurations that ladder up to admin:

  • ACL abuse — dangerous rights like GenericAll, WriteDACL, or WriteOwner over a privileged object let an attacker reset a password, add themselves to a group, or take ownership.
  • Delegation abuse — unconstrained, constrained, and resource-based constrained delegation (RBCD) misconfigurations that allow impersonation of any user, including Domain Admins.
  • Active Directory Certificate Services (ADCS) — misconfigured certificate templates (the ESC1–ESC8 family) that let a low-privileged user enroll a certificate impersonating a high-privileged account — one of the most impactful modern AD attack classes.
  • DCSync — abusing replication rights to ask a Domain Controller for every user’s password hash, including the krbtgt account.

5. Domain dominance. Reaching Domain Admin or the krbtgt hash means total control — and the ability to forge Golden Tickets for persistent, near-undetectable access. At this point the test demonstrates full compromise and stops; the value is in the proven path, not in causing damage.

The misconfigurations that hand it over

The same root causes show up again and again, and they are all fixable:

  • Service accounts with weak passwords and excessive privileges (the Kerberoasting goldmine).
  • Over-privileged groups and stale accounts that were never cleaned up.
  • No tiering between administrative and everyday accounts, so one workstation compromise reaches a Domain Admin’s credentials.
  • Missing LAPS, leaving identical local-admin passwords across every machine.
  • Dangerous ACLs and delegation left over from old projects.
  • Default-vulnerable ADCS templates.

What you get out of it

An AD pentest delivers something a vulnerability scan never can: the actual attack path. The report shows the specific chain from initial foothold to Domain Admin — this account, this misconfiguration, this ticket — with each step reproducible and each finding rated for severity (see how we score with CVSS). Crucially, breaking any single link in the chain stops the whole attack, so remediation is prioritized around the cheapest, highest-impact fixes. You come away knowing not just that weaknesses exist, but the exact route an attacker would take and where to cut it.

This is grey-box testing by nature — we need that initial foothold to be realistic; see types of penetration testing for why, and our methodology for how each engagement runs.

The bottom line

Active Directory is the master key to most enterprises, so it earns a dedicated test built on the assumed-breach model: start from a single compromised user, then prove the path to Domain Admin through enumeration, credential attacks like Kerberoasting, lateral movement, and privilege escalation. The deliverable is the real attack chain and the prioritized fixes that break it.

Running on-premise Windows? Get in touch and we’ll scope an Active Directory assessment for your domain.

Frequently asked questions

What is Active Directory penetration testing? add

Active Directory penetration testing is an internal security assessment that simulates an attacker who already has a foothold inside your network — a phished employee, a compromised laptop, or a rogue device — and attempts to escalate from that low-privileged position to full control of the Windows domain (Domain Admin). It maps the real privilege-escalation and lateral-movement paths through your AD environment and shows exactly how an intruder would get from one account to the keys of the entire estate.

Why is Active Directory such a high-value target? add

Active Directory is the central authentication and authorization system for most corporate networks — it controls who can access nearly every server, application, and file share. Because of that central role, compromising Active Directory usually means compromising the entire organization at once: one path to Domain Admin can unlock every system the domain governs. That is why attackers prioritize it and why testing it specifically matters.

What is the assumed breach model? add

The assumed breach model starts the test from the position of an attacker who has already gotten inside — typically with a standard domain user account or a device on the internal network — rather than spending the engagement trying to break in from the internet. It reflects reality: most serious incidents begin with a single phished user or compromised endpoint, so the valuable question is not 'can they get in?' but 'once they are in, how far can they go?'

What does an Active Directory pentest find? add

Common findings include weak or reused service-account passwords exposed via Kerberoasting, accounts without Kerberos pre-authentication (AS-REP roasting), dangerous ACL and delegation misconfigurations that allow privilege escalation, Active Directory Certificate Services flaws, credential reuse enabling lateral movement, missing tiering between admin and user accounts, and stale over-privileged accounts. Each is reported as part of a concrete attack path from initial foothold to Domain Admin.

Have a system that needs testing?