Active Directory Penetration Testing: A Practical Guide

Why Active Directory Deserves Its Own Engagement

A network test answers what is exposed and how far an attacker can pivot. An AD-focused test answers a different question: how the identity layer fails. AD has a unique blast radius. Every workstation, server, application, and cloud federation often trusts the same forest. One overprivileged service account, one vulnerable certificate template, one unsigned domain controller, and the entire estate falls.

Modern AD attacks are well documented and broadly automated. BloodHound, Certipy, and Impacket let testers reproduce decade-old issues in minutes. The objective is not to prove AD is broken; it is to find the specific paths an attacker would take in this environment, demonstrate them safely, and hand engineering teams a list they can fix.

For broader context, see our guides on penetration testing methodology and the difference between red team and pentest engagements.

1. Scoping an Active Directory Engagement

AD scoping is harder than a flat web or network test. Forests have trusts, child domains, hybrid identity, and Tier 0 systems that may or may not be testable. Lock the details down on paper.

• Identity inventory: in-scope forests, domains, child domains, trusts, ADCS deployments, Azure AD or Entra ID synchronisation, federation, and SSO providers.
• Starting position: unauthenticated network access only, low-privileged user, standard workstation foothold, or all three. Document the source IP, account, and host explicitly.
• Tier 0 boundaries: agree which systems are testable (typical), scan-only (sensitive), or fully off-limits (life-safety, financial control). Clarify whether DCSync, golden ticket, and persistence demonstrations are authorised.
• Detection coordination: decide whether the blue team is informed (announced test) or operating blind (purple-style). Note the SIEM and EDR products in use so noisy techniques can be timed appropriately.
• Rules of engagement: testing windows, blackout periods, escalation contacts, allowed and disallowed payloads, denial-of-service limits. Lock them in the scope of work.
• Authorisation: a signed letter of authorisation from a senior stakeholder, not just an IT lead, plus written agreement on emergency stop conditions.
• Deliverable expectations: report depth, retest scope, portal access, attack path diagrams, and time-bound remediation tracking.

2. Unauthenticated Enumeration

Before any credentials, gather what the network leaks for free. Unauthenticated enumeration is fast, low-risk, and often produces the first foothold by itself.

• Identify the domain name and domain controllers from DNS (SRV records, _ldap._tcp, _kerberos._tcp)
• Enumerate users via SMB null sessions, RID cycling, and LDAP anonymous bind where allowed
• Capture broadcast traffic with Responder for LLMNR, NBT-NS, and mDNS poisoning opportunities
• Run mitm6 to test for IPv6 DHCPv6 takeover and downstream relay potential
• Probe for unauthenticated SMB shares, IPC$, and printer shares with anonymous access
• Test LDAP signing, LDAPS channel binding, and SMB signing posture on every domain controller
• Validate Kerberos username enumeration via timing differences in AS-REQ responses (Kerbrute)
• Look for AS-REP roastable accounts (pre-authentication disabled) without any credentials
• Check for Zerologon (CVE-2020-1472), PrintNightmare (CVE-2021-1675), and PetitPotam exposure

3. Authenticated Enumeration and BloodHound

A standard low-privilege user is the realistic starting point for most internal tests. Once that account is in hand, build a complete map of the identity graph.

• Run SharpHound or BloodHound.py with the LDAP, Sessions, ACL, ObjectProps, GPO, Trust, and Container collection methods
• Identify shortest paths from the foothold to Domain Admins, Enterprise Admins, and Tier 0 groups
• Find computers with unconstrained delegation (high-value coercion targets)
• List Kerberoastable accounts and AS-REP roastable users now that authenticated queries are possible
• Enumerate users with sensitive ACLs (GenericAll, GenericWrite, WriteOwner, ForceChangePassword, AddMember)
• Find users with old passwords, password-never-expires, and disabled-but-not-removed accounts
• Check for descriptions or comments that contain credentials (still common, still effective)
• Identify sessions on each host: which privileged users are logged into which workstations
• Map shadow credentials and msDS-KeyCredentialLink eligibility

Capture the BloodHound graph as evidence. Attack chain diagrams in the final report are far more persuasive when they show the same path BloodHound highlighted, not a redrawn abstraction.

4. Kerberos Attacks

Kerberos is the protocol attackers love most. Every well-known weakness is reproducible with off-the-shelf tooling, and the failures are usually configuration, not protocol.

Kerberoasting

Request TGS tickets for every account with a Service Principal Name (GetUserSPNs.py or Rubeus). Crack offline with Hashcat (mode 13100). Service accounts using passwords shorter than 25 characters or based on common patterns are routinely cracked. Report the cracked accounts, the password complexity, and recommend gMSA migration.

AS-REP roasting

For accounts where Kerberos pre-authentication is disabled, request the AS-REP and crack offline (Hashcat mode 18200). This works without credentials when usernames are known. Report every roastable account; even one cracked low-privilege user often unlocks the next stage.

Unconstrained delegation

Hosts with TRUSTED_FOR_DELEGATION cache TGTs of every user who authenticates to them. Coerce a Domain Admin or DC computer account to authenticate (PrinterBug, PetitPotam, DFSCoerce) and extract the cached TGT for impersonation. Document the path including the coercion technique used.

Constrained delegation and RBCD

Constrained delegation (S4U2Self plus S4U2Proxy) and resource-based constrained delegation can be abused to impersonate any user (including protected accounts where the protections are not configured). Resource-based constrained delegation takeover via machine account quota (default 10) is a frequent finding even in modern environments.

NoPac and Zerologon

CVE-2021-42278 and CVE-2021-42287 (NoPac, sAMAccountName spoofing) and CVE-2020-1472 (Zerologon) remain present on unpatched DCs in older estates. Validate carefully (do not change the DC machine password without explicit authorisation).

5. Active Directory Certificate Services (ADCS)

ADCS is the highest-yield attack surface in modern AD. SpecterOps and others have catalogued ESC1 through ESC15+ and Certipy makes enumeration trivial. Test every CA in scope.

6. Credentials, GPOs, and SYSVOL

Credential reuse and forgotten credentials are still the path of least resistance. Search systematically.

• Search SYSVOL for cpassword (Group Policy Preferences) values; decrypt with the well-known AES key
• Read GPO XML for scheduled tasks, mapped drives, scripts, and service installations referencing credentials
• Inspect logon scripts under NETLOGON for plaintext passwords and connection strings
• Hunt file shares for backup files, password vaults, and configuration files (web.config, app.config, .env, .ps1)
• Check SCCM/MEMCM PXE boot variables and network access account credentials
• Test for password reuse between local administrator and domain accounts (including unscoped LAPS)
• Look for credentials cached on jump hosts, terminal servers, and Citrix endpoints
• Inspect AD object descriptions, comments, and notes for accidental credential leaks

7. Lateral Movement and Privilege Escalation

With a credential or hash, pivot deliberately. Track every step so the report shows the full chain, not isolated weaknesses.

• Pass-the-hash, pass-the-ticket, and overpass-the-hash where authorised
• Lateral execution via WMI, WinRM, SMB, and DCOM (psexec, wmiexec, smbexec, evil-winrm)
• Local privilege escalation: missing patches, unquoted service paths, weak service permissions, AlwaysInstallElevated
• Token impersonation and SeImpersonatePrivilege abuse (Juicy/Rotten/God Potato variants)
• Credential dumping via LSASS, SAM, LSA secrets, DPAPI, browsers, and RDP credential cache
• DPAPI master key extraction to recover stored secrets across user profiles
• BloodHound path replay: each edge in the shortest path becomes a finding entry
• Sensitive data access proof: file shares, source code, backup systems, payment systems, identity providers

8. Persistence and Detection (Where Authorised)

Persistence demonstrations should always be coordinated and time-boxed. The objective is to validate detection and recovery, not to leave artefacts in production. Confirm written authorisation before any of the techniques below.

• Golden ticket forgery using krbtgt hash (validate detection of suspicious ticket lifetimes)
• Silver ticket forgery for service-specific persistence
• DCSync to extract krbtgt and other privileged hashes (replication permission abuse)
• SID history injection across trusts (forest takeover scenarios)
• AdminSDHolder modifications and shadow admin creation
• Skeleton key, DSRM password reuse, and registry-based persistence on DCs
• Document each technique, the detection result, the time of action, and the cleanup step

For programmes that want broader adversary simulation rather than identity-only depth, see the comparison between red team and penetration test engagements.

9. Hybrid Identity and Trusts

Most enterprises run hybrid identity. The trust between on-premises AD and Entra ID is a frequent attack path that belongs in scope wherever it exists.

• Identify the synchronisation method: Entra Connect (PHS, PTA, federation) and the privileged sync account location
• Test Entra Connect server hardening: it usually has DCSync rights and is a Tier 0 system in practice, even when not labelled as one
• Look for Seamless SSO weaknesses, primary refresh token theft, and device registration abuse
• Check ADFS (where still used) for actor token forgery and certificate compromise risk
• Map cross-forest and cross-domain trusts; validate SID filtering on every trust
• Identify legacy two-way external trusts that grant unnecessary lateral access

10. Reporting and Remediation Tracking

AD findings often chain. A weak Kerberoastable service account leads to ESC1 enrolment leads to DCSync. A list of isolated CVSS scores hides that story. Structure the deliverable so engineering can follow the path and prioritise the chokepoints.

• Executive summary with business impact, attack narrative, and the chokepoints that break each chain
• Technical findings with reproduction commands, evidence, and CVSS scores validated using the CVSS calculator
• BloodHound shortest path screenshots that match the attack chain in the narrative
• Per-finding remediation guidance distinguishing root cause from compensating control
• Mapping to compliance frameworks (PCI DSS 11.4, ISO 27001 A.9 and A.12.6.1, SOC 2 CC6, NIST SP 800-53 IA controls)
• Prioritisation using CVSS plus EPSS plus asset tier, with Tier 0 findings always at the top
• Delivery in a portal that supports retest workflows and persistent remediation status, not just a static PDF

SecPortal's findings management ships with templates for common AD findings (Kerberoasting, AS-REP roasting, ESC1 through ESC8, unconstrained delegation, NTLM relay, weak password policy), AI-generated executive and technical reports, and a branded client portal so identity and infrastructure teams remediate without losing context. See the report template for the full structure.

11. Between Engagements: Hardening and Monitoring

Annual AD pentests find the issues. Continuous hygiene keeps them found. Pair the engagement with ongoing controls and detection so the next test does not surface the same drift.

• Adopt a clean tiering model (Tier 0 / Tier 1 / Tier 2) and enforce it with authentication policies
• Replace service account passwords with group managed service accounts (gMSA) where possible
• Enforce SMB signing and LDAP channel binding domain-wide; retire NTLMv1 and LM
• Disable LLMNR and NBT-NS via GPO; deploy DNS-only name resolution
• Audit ADCS templates monthly against the ESC catalogue using Certipy in audit mode
• Deploy LAPS (or Windows LAPS) for every workstation and server
• Monitor for Kerberoasting requests, DCSync, AS-REP requests for non-roastable accounts, and golden ticket indicators
• Schedule recurring authenticated scans and continuous monitoring so configuration drift is caught quickly

For programme-level structure, see building continuous security monitoring and the vulnerability management programme guide.

The Quick AD Pentest Checklist

A condensed version to use during the engagement.

1. Lock scope to forests, domains, trusts, ADCS, hybrid identity; document Tier 0 boundaries
2. Confirm signed authorisation and emergency stop conditions before any traffic
3. Capture broadcast traffic and test LLMNR, NBT-NS, mDNS, IPv6 takeover
4. Verify SMB signing, LDAP signing, LDAPS channel binding on every DC
5. Probe for Zerologon, PrintNightmare, NoPac, PetitPotam (validate before triggering)
6. Run Kerbrute against likely usernames; pull AS-REP roastable accounts unauthenticated where possible
7. From a low-priv account, run SharpHound with full collection methods and analyse paths
8. Kerberoast every SPN, AS-REP roast every disabled-preauth account, crack offline
9. Enumerate unconstrained, constrained, and resource-based delegation
10. Run Certipy find on every CA; validate every ESC candidate before reporting
11. Coerce DC authentications and test NTLM relay to ADCS Web Enrolment (ESC8)
12. Search SYSVOL, GPOs, NETLOGON, file shares, SCCM for credentials
13. Demonstrate lateral movement across BloodHound shortest paths with full evidence
14. Validate hybrid identity boundary: Entra Connect server tiering and trust posture
15. Run authorised persistence demonstrations only with written approval and detection coordination
16. Score findings with CVSS, prioritise with EPSS plus asset tier, deliver in a portal that supports retest
17. Schedule continuous authenticated coverage between assessments

Frequently Asked Questions About Active Directory Pentesting