Active Directory Penetration Testing Playbook

This playbook grew out of my own need for a practical Active Directory field guide that I could use during real penetration tests instead of relying on scattered notes, command collections and memory. Over time, I kept refining it around the way I actually work: establish what access and evidence I have, understand what each result proves, choose the next meaningful branch, and preserve enough context to reproduce the assessment later.

It is my working Active Directory penetration-testing playbook, shared so other practitioners can use it, adapt it and challenge it. Its starting point is the Orange Cyberdefense AD mind map, v2025.03, combined with technical documentation, public research and lessons learned from hands-on assessments. The mind map provides an excellent map of possibilities, but turning those possibilities into a repeatable assessment requires prerequisites, interpretation, evidence, decision points and cleanup.

The purpose of this playbook is therefore not to provide a sequence of commands to execute mechanically. It turns techniques into decisions: what can I test with the access I currently have, what does the result actually prove, what new capability or evidence does it create, and where should I go next? Equivalent tools are alternatives, not steps to run one after another. Each technique has one primary home; credential handling, reporting and cleanup are shared procedures.

This is a field methodology, not a substitute for operator judgment. The source and syntax review covers the baselines in chapter 34, but it is not a claim that every path was executed on every supported Windows build. Patch state, protocol protections, effective permissions and environment-specific architecture decide applicability. Record the versions and results from your own environment. Appendix D distinguishes operational procedures, prerequisite assessments and intentionally external specialist workflows; this document does not claim exhaustive coverage of every payload in the source mind map.

Contents

• 0. How to use this playbook
• 1. Engagement setup and safe execution
• 2. Network discovery and service map
• 3. Domain and Domain Controller discovery
• 4. SMB posture and anonymous access
• 5. LDAP and directory baseline
• 6. Kerberos discovery and credential acquisition
• 7. Name-resolution poisoning, capture and coercion
• 8. Authentication relay decision tree
• 9. Validate every obtained credential
• 10. BloodHound and graph-based attack-path analysis
• 11. Shares, SYSVOL and exposed secrets
• 12. ACL / ACE abuse decision tree
• 13. Group Policy Objects
• 14. Kerberos delegation
• 15. Active Directory Certificate Services
• 16. SCCM / Configuration Manager
• 17. MSSQL in an AD attack path
• 18. LAPS and gMSA
• 19. Trusts, domains and forest boundaries
• 20. Host access and lateral movement
• 21. Local privilege escalation on Windows
• 22. Credential extraction and sensitive Windows material
• 23. DPAPI
• 24. Credential-type routing
• 25. Remote execution: prove, do not over-execute
• 26. Domain replication and domain-dominance primitives
• 27. Ticket forging and persistence
• 28. Legacy and version-specific vulnerabilities
• 29. Hash and credential-material cracking
• 30. What is a finding vs. evidence?
• 31. Reporting workflow
• 32. End-to-end operational checklist
• 33. Quick branch index
• 34. Tool syntax and source-of-truth policy
• Appendix A — Field notebook templates
• Appendix B — Cleanup checklist
• Appendix C — Reporting prompts
• Appendix D — Mind-map coverage
• Appendix E — References and maintenance

0. How to use this playbook

The playbook is state-driven. Do not execute every command mechanically. Enter at the state you actually possess and move between states as evidence changes.

0.1 Result taxonomy

0.2 Minimum evidence record

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

engagement/
  notes.md
  commands.log
  targets.csv
  identities.csv
  credentials.csv
  primitives.csv
  findings.csv
  evidence/
    network/
    relay/
    dns/
    smb/
    ldap/
    kerberos/
    bloodhound/
    adcs/
    sccm/
    mssql/
    hosts/
    screenshots/
    report/

0.3 Credential handling

• Prefer interactive secret entry, protected credential files or credential caches when supported. Quoting a password prevents shell interpretation; it does not hide the password from process arguments, transcripts or tool logs. Expanding an environment variable into an argument does not remove that exposure.
• Keep cleartext passwords, NT hashes, Kerberos caches and PFX files in an encrypted evidence location with least-privilege permissions.
• Do not reuse captured credentials outside scope. Record first use and each target on which the credential was validated.
• Treat machine-account keys, DPAPI keys, certificates and Kerberos tickets as credentials even when they are not passwords.
• When a credential unlocks a new identity or privilege tier, create a new row in the identity/credential inventory before continuing.

0.4 Core decision loop

0.5 Reading technique cards

Entry state refers to S0–S9 above. States describe available capabilities, not a compulsory linear progression. Status describes whether a technique is current or a retained legacy exposure. Result type is the expected useful output, not a claim that every execution succeeds.

Every executed card inherits the evidence fields in section 0.2. Additional evidence lists identify technique-specific artifacts. A failed command is not a negative security result: classify it as BLOCKED or INCONCLUSIVE until authentication, reachability and tool compatibility have been separated from the control being assessed.

0.6 Command conventions and environment

• Replace every <placeholder> before execution. Angle brackets are documentation notation, not literal shell input.
• Linux examples use Bash; Windows examples use Windows PowerShell unless stated otherwise. PowerShell cmdlets require the corresponding modules. Import ActiveDirectory for AD cmdlets and the AD: drive; load the reviewed PowerView script before PowerView functions.
• Quote substituted identities, passwords, DNs, paths and names containing $. A literal single quote inside a value needs shell-specific handling; prefer a prompt instead of improvising escapes.
• impacket-* names follow distribution packaging such as Kali. Upstream/pip installations may expose getST.py, secretsdump.py and other example script names instead. The option semantics belong to the installed Impacket release.
• Resolve DC/service FQDNs through the assessment DNS view. Use actual service hostnames for Kerberos SPNs. Confirm clock offset before troubleshooting Kerberos. Do not change a production clock to make a test work.
• LDAP simple bind carrying a password uses verified TLS: ldaps:// or mandatory StartTLS with -ZZ. Install the environment’s CA chain in the test client. Do not use disabled certificate validation as the normal recipe. Anonymous RootDSE queries do not send a password.
• Global Catalog searches, paged LDAP results, nested memberships and protected accounts can differ from a single-domain query. Record the naming context and collection scope.
• For PowerShell group names, account for OS/domain localization. Prefer known SIDs or resolved DNs when a display name is not stable.

Prepare the working directories on an encrypted assessment volume. These permissions restrict local access; they do not provide encryption.

1
2
3

umask 077
mkdir -p engagement/evidence/{network,relay,dns,smb,ldap,kerberos,bloodhound,adcs,sccm,mssql,hosts,screenshots,report}
cd engagement

All relative evidence paths below are relative to engagement/. Keep raw secret-bearing output separate from redacted notes and report exports.

1. Engagement setup and safe execution

Before touching the environment, capture scope boundaries, permitted credential attacks, permitted coercion/relay, allowed exploitation, prohibited production systems, maintenance windows, and stop conditions. The same technical path can be safe read-only enumeration or a disruptive exploit depending on how it is executed.

1.1 Execution controls and rollback

Scope authorization applies to the whole playbook; card prerequisites list the additional technical conditions. Agree which activities may modify directory objects, trigger authentication, execute code or collect secrets before selecting those branches.

For each modification, preserve the original object/value, identify a restoration method, perform one scoped change and verify restoration. Do not overwrite a concurrent administrator change during cleanup. Revoking a test certificate, deleting a local PFX and invalidating already issued Kerberos tickets are different operations; restoring an ACL does not retract credentials already obtained.

Risk labels concern operational impact, not finding severity: LOW is bounded discovery/read activity, MEDIUM includes broad collection or active authentication triggering, and HIGH includes privileged secret collection, execution or sensitive writes. Record the actual change and secret exposure separately. Read-only does not mean invisible, load-free or harmless to confidentiality.

Share enumeration may probe write access. Use NetExec --no-write-check for a strictly non-writing inventory; a skipped write check is not proof that write access is denied. Automatic host-wide collectors may touch systems beyond the original DC; restrict their target set to scope.

Before interpreting any negative result, check target reachability, authentication identity, DNS/SPN, time, permissions, protocol restrictions and tool errors. Do not record PASS for a technique that was never exercised.

2. Network discovery and service map

AD-NET-01 — Host discovery and TCP service inventory

Status: CURRENT

Entry state: S0
Result type: INFORMATION
Risk of execution: LOW

Goal

Identify live systems and the AD-relevant service surface without assuming that only DCs matter.

Prerequisites

Reachable in-scope network ranges and an approved target/rate list. SYN scans (-sS) require raw-packet privileges; use TCP connect scanning (-sT) when unavailable.

Commands

Host discovery

1

nmap -sn '<CIDR>' -oA evidence/network/ping

Targeted AD ports

1

nmap -Pn -sV -p 53,88,135,139,389,445,464,593,636,3268,3269,3389,5985,5986,9389 '<CIDR>' -oA evidence/network/ad-ports

Full TCP scan for selected hosts

1

nmap -Pn -sS -p- --max-rate '<approved_rate>' '<IP>' -oA 'evidence/network/full-<host>'

TCP inventory does not cover AD-relevant UDP services. On selected hosts, add a bounded UDP pass where required:

1

nmap -Pn -sU -sV -p 53,88,123,137,138,389,464 '<selected_host>' -oA evidence/network/ad-udp

-sU needs raw-packet privileges. UDP open|filtered is inconclusive; correlate application responses. PXE/TFTP and SQL Browser discovery require their own UDP ports and network context. --min-rate is a requested minimum, not a load ceiling; use an explicit approved ceiling such as --max-rate when the objective is to limit traffic.

Parameters

Interpretation

A reachable host and exposed service become inventory facts. AD-relevant ports suggest roles but do not prove them; correlate DNS, LDAP and SMB metadata.

If unsuccessful

No response may mean filtering or host discovery controls rather than absence. Use scoped -Pn checks and pivot visibility before marking unreachable.

Additional evidence

• IP/FQDN mapping
• open ports
• service banners/build information
• scan source and timing
• nmap XML for later correlation

Finding logic

Open AD services are normally inventory, not findings. Unexpected management interfaces, legacy protocols or externally exposed services can become findings.

Next

• AD-DNS-01 — locate the domain and DCs
• AD-SMB-01 — SMB posture
• AD-LDAP-01 — RootDSE/LDAP posture

Alternative branch

• Confirm routing/VPN/pivot
• Check ARP on local segment
• Use known scope hostnames and DNS if provided

AD-SVC-01 — Adjacent enterprise services and management-surface triage

Status: CURRENT

Entry state: S0–S1
Result type: CANDIDATE
Risk of execution: LOW

Goal

Identify non-AD services that commonly hold domain credentials, administer large parts of the estate, or provide a bridge back into Active Directory. Product discovery is a prioritization step, not proof of a vulnerability.

Prerequisites

Discovered in-scope systems; application testing boundaries established for adjacent products.

Commands

Common management/application ports

1

nmap -Pn -sV -p 80,443,1099,1433,3306,5432,8000,8080,8443,9392,5985,5986 '<CIDR>' -oA evidence/network/adjacent-services

HTTP titles and headers on discovered web services

1

nmap -Pn -p 80,443,8000,8080,8443 --script http-title,http-headers '<targets>' -oA evidence/network/http-surfaces

What to prioritize

Interpretation

A discovered service becomes a candidate to map to a product, version, authentication model, administrative boundary and known security posture. It is not automatically a finding and it does not justify running an exploit based only on a banner.

If unsuccessful

No adjacent service was identified through the tested ports and inventory. Do not expand scanning outside scope solely to find an application foothold.

Additional evidence

• host/FQDN and port
• product and version when reliably identified
• authentication method
• domain/service identity if observable
• administrative role or trust boundary
• application-specific scope decision

Finding logic

Report the actual application weakness, exposed credential, excessive privilege or outdated vulnerable build. The mere presence of Exchange, Veeam, GLPI, Java, a database or another management platform is not a finding.

Next

• Route MSSQL to AD-MSSQL-01.
• Route SCCM/PXE to AD-SCCM-01.
• For other products, perform a separate version/configuration assessment within the approved application scope and return any obtained credential through AD-AUTH-01.

AD-WSUS-01 — WSUS update trust and transport assessment

Status: CURRENT

Entry state: S4–S5

Result type: CANDIDATE

Risk of execution: LOW for configuration review

Goal and prerequisites

Identify the configured update authority and who can change it. Use a joined Windows endpoint or a reviewed GPO export; separately obtain WSUS-server configuration when that server is in scope.

Commands — client policy

1
2

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue | Select-Object WUServer,WUStatusServer,UpdateServiceUrlAlternate,AcceptTrustedPublisherCerts
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -ErrorAction SilentlyContinue | Select-Object UseWUServer

Validation

• Resolve the configured update host and identify HTTP versus HTTPS, certificate trust and applicable client policy. Missing registry values can mean a different update-management arrangement; they are not a secure/insecure verdict.
• Map GPO write/link rights, WSUS administration, publishing/approval permissions and server-local administration. Check which controls prevent an unintended principal from changing update source or approved content.
• For a server-certificate path such as ESC17, validate the entire chain: enrollable server-authentication certificate, target name, trusted issuer, traffic-redirection capability and affected update-client/service behavior. A server-authentication certificate alone is not domain compromise.
• Record the boundary and prerequisites. Do not change clients’ update source, publish updates or trigger installations as a default discovery test.

Evidence and next

Record effective policy source, update endpoints, transport/certificate observations and the controlling identities. Route GPO control to AD-GPO-01 and PKI conditions to chapter 15. A live update-execution proof is a separate change-controlled specialist workflow; record that limitation rather than marking it completed.

References

• Microsoft: configuring WSUS clients
• Certipy ESC17

3. Domain and Domain Controller discovery

AD-DNS-01 — Discover AD DNS namespace and DCs through SRV records

Status: CURRENT

Entry state: S0–S1
Result type: INFORMATION
Risk of execution: LOW

Goal

Identify the AD DNS domain, KDCs, LDAP servers and Global Catalog using the discovery mechanism Windows clients use.

Prerequisites

A candidate domain suffix and a resolver with the internal DNS view. Add @<dns_server> to dig when the system resolver is unsuitable.

Commands

DC LDAP SRV

1

dig +short SRV '_ldap._tcp.dc._msdcs.<domain>'

Kerberos SRV

1

dig +short SRV '_kerberos._tcp.<domain>'

Global Catalog

1

dig +short SRV '_gc._tcp.<forest-root>'

Resolver view

1

resolvectl status

Parameters

Interpretation

SRV targets identify authoritative DC/KDC/GC candidates and give canonical hostnames required by Kerberos. Record every DC; do not test only one.

If unsuccessful

An empty answer can mean the wrong DNS suffix/resolver or blocked DNS. Inspect DHCP/VPN DNS settings, reverse DNS and any provided hostnames.

Additional evidence

• AD DNS domain
• DC FQDN/IP
• KDC FQDN/IP
• GC FQDN/IP
• DNS server used

Next

• AD-DNS-02 — zone transfer and DNS posture
• AD-SMB-01 — identify host/domain metadata
• AD-LDAP-01 — RootDSE

Alternative branch

• Inspect DHCP/VPN configuration
• Query PTR records for likely DC IPs
• Use SMB/LDAP metadata from discovered servers

AD-DNS-02 — DNS zone transfer and AD-integrated DNS exposure

Status: CURRENT

Entry state: S1; S3–S4 for authenticated enumeration
Result type: CANDIDATE
Risk of execution: LOW

Goal

Check whether authoritative DNS allows unintended zone transfer and whether authenticated AD-integrated DNS enumeration exposes useful host/service records.

Prerequisites

An authoritative DNS server and zone; a valid domain identity for AD-integrated DNS enumeration.

Commands

AXFR

1

dig AXFR '<domain>' '@<dns_server>'

Authenticated AD DNS enumeration

1

adidnsdump -u '<domain>\<user>' -p '<password>' --dns-tcp '<dc_fqdn>'

Parameters

Interpretation

A successful unauthorized AXFR is normally reportable information disclosure. Authenticated DNS data is expected but feeds host/service discovery and attack-path analysis.

If unsuccessful

AXFR refusal is the expected hardened state. Continue with SRV and authenticated AD DNS enumeration if credentials become available.

Finding logic

Unauthenticated zone transfer of internal AD zones is normally a finding. Ordinary authenticated AD DNS reads are not.

Next

• Add discovered hosts/services to target inventory
• Look for management, CA, SCCM, SQL and legacy systems

Alternative branch

• Continue SMB/LDAP/Kerberos discovery

AD-DNS-03 — AD-integrated DNS write permissions and controlled-record validation

Status: CURRENT

Entry state: S4 or S7
Result type: PRIMITIVE
Risk of execution: LOW for query / MEDIUM for controlled write

Goal

Determine whether the current principal can create or modify records in AD-integrated DNS. A writable DNS node can become an authentication-redirection primitive and may compose with NTLM/Kerberos relay paths, but ordinary authenticated DNS read access is not a finding.

Prerequisites

A domain identity, the exact AD DNS partition/zone and an engagement-owned test name. Read the current node and preserve its state before any write.

Commands

Read/query a candidate record with krbrelayx dnstool.py

1

python3 dnstool.py '<dc_fqdn>' -u '<DOMAIN>\<user>' -p '<password>' --zone '<domain>' -r '<record_fqdn>' -a query

List DNS zones without modification

1

python3 dnstool.py '<dc_fqdn>' -u '<DOMAIN>\<user>' -p '<password>' --print-zones

Controlled write proof — use a unique engagement-owned hostname and remove it immediately after validation

1

python3 dnstool.py '<dc_fqdn>' -u '<DOMAIN>\<user>' -p '<password>' --zone '<domain>' -r '<test_record_fqdn>' -a add -d '<operator_controlled_ip>'

Cleanup

1

python3 dnstool.py '<dc_fqdn>' -u '<DOMAIN>\<user>' -p '<password>' --zone '<domain>' -r '<test_record_fqdn>' -a ldapdelete

Parameters

• positional host — DNS/DC hostname, IP or LDAP connection target used by dnstool.py.
• -u/--user — DOMAIN\username authentication identity.
• -p/--password — password or supported LM:NTLM material; omit when interactive prompting is preferable.
• --zone — zone to inspect when it differs from the automatically selected current-domain zone.
• -r/--record — target record FQDN.
• -a/--action — query, add, modify, remove, resurrect or ldapdelete in current krbrelayx source.
• -d/--data — address written for an A record.
• -dc-ip — explicit DC address when name resolution and LDAP routing differ.
• -dns-ip — DNS server used for DNS-side serial/query operations.

Interpretation

A successful controlled write proves that the principal can influence name resolution in the tested DNS partition/zone. The next question is not “can I write DNS?” but which security boundary can that write cross? Map clients/services that resolve the affected name and whether the record can redirect authentication into an approved relay/capture path.

If unsuccessful

Failure to create/modify the test node means this principal did not prove a DNS-write primitive at that location. Do not infer that every DNS node is protected; ACLs may differ between existing nodes, zones and partitions.

Additional evidence

• principal and SID
• DNS partition/zone
• exact record DN/FQDN
• original state
• temporary record value
• create/modify result
• cleanup result
• affected resolution path, if any

Finding logic

Authenticated ability to create ordinary dynamic records can be normal depending on deployment. Promote it only when permissions are broader than intended or when a controlled record can materially redirect a sensitive service/authentication path.

Next

• AD-NTLM-04 — determine whether the redirected authentication has a compatible relay destination
• AD-NTLM-05 — validate LDAP/LDAPS relay protections
• AD-BH-02 — record the DNS primitive as a manually validated edge/path

Alternative branch

• Continue SMB/LDAP/Kerberos discovery

Reference

• krbrelayx dnstool.py current source: AD-integrated DNS interaction through LDAP.

4. SMB posture and anonymous access

AD-SMB-01 — SMB metadata, signing and SMBv1

Status: CURRENT

Entry state: S0–S1
Result type: PRIMITIVE
Risk of execution: LOW

Goal

Determine SMB dialect, signing posture, hostname/domain metadata and identify relay candidates.

Prerequisites

Reachable SMB targets from the scoped asset list.

Commands

NetExec SMB inventory

1

nxc smb '<CIDR>'

Signing candidate list

1

nxc smb '<CIDR>' --gen-relay-list evidence/relay/smb.txt

Nmap SMB protocols

1

nmap -Pn -p445 --script smb-protocols,smb2-security-mode '<CIDR>' -oA evidence/smb/posture

Parameters

Interpretation

SMB signing not required creates a relay target candidate, not an exploit by itself. SMBv1 or obsolete dialects create separate legacy-risk leads.

If unsuccessful

Signing required blocks ordinary SMB-to-SMB NTLM relay to that server. It does not rule out HTTP, LDAP, AD CS, MSSQL or other relay paths.

Additional evidence

• host/IP
• Windows/build info
• domain/workgroup
• SMB dialect
• signing state
• SMBv1 state

Finding logic

SMB signing not required is commonly reportable when NTLM is in use and relay impact is credible. Demonstrated relay materially strengthens severity.

Next

• AD-NTLM-04 — build relay target sets
• AD-NTLM-02/03 — find/coerce an authentication source

Alternative branch

• Continue HTTP/LDAP/AD CS relay posture
• Continue authenticated enumeration

Status: CURRENT

Entry state: S0–S1
Result type: ACCESS
Risk of execution: LOW

Goal

Determine whether SMB exposes shares, files, users or RPC information without a valid domain credential.

Prerequisites

Reachable SMB service; distinguish null authentication from guest mapping in the returned identity.

Commands

Anonymous listing

1

smbclient -U '%' -N -L '//<target>/'

NetExec null auth

1

nxc smb '<target>' -u '' -p '' --shares --no-write-check

Guest-style validation

1

nxc smb '<target>' -u guest -p '' --shares --no-write-check

Parameters

Interpretation

Record exactly which identity the server mapped the session to and which shares/files are readable or writable. Anonymous read of sensitive data or anonymous write usually becomes a finding.

If unsuccessful

No anonymous access. Do not stop SMB testing; repeat with each obtained credential.

Next

• Search readable shares for deployment/configuration/credential material
• If writable, assess whether the share participates in user/admin workflows before attempting any write-based coercion

Alternative branch

• AD-LDAP-01 — anonymous LDAP
• AD-KRB-01 — Kerberos username enumeration

5. LDAP and directory baseline

AD-LDAP-01 — RootDSE and anonymous LDAP bind

Status: CURRENT

Entry state: S1
Result type: INFORMATION
Risk of execution: LOW

Goal

Learn naming contexts and determine whether useful directory data is exposed anonymously.

Prerequisites

DC LDAP endpoint; derive the domain base DN from RootDSE before the subtree query.

Commands

RootDSE

1

ldapsearch -x -H 'ldap://<dc_fqdn>' -s base -b "" namingContexts defaultNamingContext rootDomainNamingContext dnsHostName supportedCapabilities

Anonymous domain query

1

ldapsearch -x -H 'ldap://<dc_fqdn>' -b "<base_dn>" "(objectClass=user)" sAMAccountName

Parameters

Interpretation

RootDSE normally exposes discovery metadata. If anonymous bind can enumerate domain objects/attributes beyond expected RootDSE data, capture the exact scope and sensitivity.

If unsuccessful

Anonymous directory search is blocked as expected; keep RootDSE discovery data and return with credentials.

Finding logic

RootDSE metadata alone is not a finding. Anonymous access to users/groups/attributes or sensitive objects may be.

Next

• Derive <base_dn> and forest root
• AD-LDAP-02 — authenticated directory inventory when credentials exist

Alternative branch

• AD-KRB-01 — Kerberos username validation
• AD-SMB-02 — RPC/SMB anonymous paths

AD-LDAP-02 — Authenticated users, groups, computers and privileged groups

Status: CURRENT

Entry state: S4
Result type: INFORMATION
Risk of execution: LOW

Goal

Build a clean identity/object inventory before chasing individual attack techniques.

Prerequisites

Valid domain identity, domain base DN and a working authenticated LDAP channel.

Commands

NetExec LDAP users

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' --users

Active users

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' --active-users

LDAP search

1

ldapsearch -LLL -x -H 'ldaps://<dc_fqdn>' -D "<user>@<domain>" -W -E pr=1000/noprompt -b "<base_dn>" "(&(objectCategory=person)(objectClass=user))" sAMAccountName userAccountControl memberOf servicePrincipalName pwdLastSet lastLogonTimestamp

The example uses paged results (-E pr=1000/noprompt) to avoid mistaking the first server-limited page for a complete inventory. lastLogonTimestamp is replicated with update lag; it is not an exact last-logon timestamp. memberOf alone is not a complete effective group-token expansion.

Parameters

Interpretation

Creates the identity inventory used by password policy, Kerberoasting, delegation, ACL, stale-account and privilege analysis.

If unsuccessful

Authentication/LDAP failure must be distinguished from permissions, channel binding, signing, DNS and clock issues.

Next

• AD-KRB-04 — Kerberoasting
• AD-BH-01 — graph collection
• AD-ACL-01 — ACL analysis
• AD-DELEG-01 — delegation inventory

Alternative branch

• Validate credential independently over SMB/Kerberos
• Try LDAPS where policy requires it
• Check time/DNS and LDAP signing/channel-binding requirements

6. Kerberos discovery and credential acquisition

AD-KRB-01 — Username enumeration through Kerberos pre-authentication behavior

Status: CURRENT

Entry state: S1
Result type: INFORMATION
Risk of execution: LOW

Goal

Validate candidate usernames without requiring passwords, using KDC response differences.

Prerequisites

Correct Kerberos realm, reachable KDC and a scoped username candidate list.

Commands

Kerbrute

1

kerbrute userenum -d '<domain>' --dc '<dc_fqdn>' --safe -o evidence/kerberos/userenum.log users.txt

Parameters

Interpretation

A KDC response consistent with an existing principal makes the username valid for subsequent AS-REP checks, policy analysis and carefully governed authentication testing.

If unsuccessful

A rejected candidate is removed from the active username list. Large negative rates may indicate wrong realm/domain naming.

Finding logic

Username enumeration is usually a supporting observation rather than a standalone high-severity finding.

Next

• AD-KRB-02 — AS-REP roasting
• AD-PASS-01 — password/lockout policy

Alternative branch

• Generate candidates from naming conventions, SMB/RPC, email-format OSINT permitted by scope, or directory data if another credential exists

Reference

• https://github.com/ropnop/kerbrute

AD-KRB-02 — AS-REP roasting

Status: CURRENT

Entry state: S1–S2; S4 for authenticated discovery
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Identify users for which Kerberos pre-authentication is disabled and retrieve crackable AS-REP material.

Prerequisites

Reachable KDC and candidate usernames; the target account must not require Kerberos pre-authentication.

Commands

Impacket with user list

1

impacket-GetNPUsers '<domain>/' -dc-ip '<dc_ip>' -usersfile users.txt -no-pass -request -format hashcat -outputfile evidence/kerberos/asrep.hashes

NetExec

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user_or_list>' -p '<password_or_empty>' --asreproast evidence/kerberos/asrep.hashes

Parameters

Interpretation

An AS-REP hash is credential material, not yet a password. Preserve it, record the principal and crack only within the agreed password-audit scope.

If unsuccessful

No tested account had the required pre-authentication condition, or enumeration method/permissions were insufficient.

Finding logic

An account configured without Kerberos pre-authentication is normally reportable, especially when crackable credentials are demonstrated.

Next

• AD-CRACK-01 — offline cracking
• If cracked: validate credential and enter S3/S4

Alternative branch

• AD-PASS-01 — policy and governed spray
• If credentials later exist: AD-KRB-04 — Kerberoasting

Reference

• https://github.com/fortra/impacket

AD-KRB-03 — Timeroasting computer and trust accounts

Status: CURRENT

Entry state: S1
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Use the authenticated Windows NTP mechanism exposed by a Domain Controller to request crackable material for computer or trust accounts that use weak/non-random passwords. This path does not require a domain credential.

Prerequisites

DC UDP/123 reachability and a bounded RID/rate/time budget. No domain credential is required.

Commands

Collect MS-SNTP material by RID enumeration

1

python3 timeroast.py -o evidence/kerberos/timeroast.hashes '<dc_fqdn_or_ip>'

Offline cracking

1

hashcat -m 31300 --username evidence/kerberos/timeroast.hashes '<wordlist>'

Parameters

Interpretation

A $sntp-ms$... result is offline-crackable credential material for a computer or trust account. It is not a plaintext password and does not imply the account uses a weak password; the security impact appears when the material is cracked or when weak machine/trust-account password management is otherwise demonstrated.

If unsuccessful

No usable response was collected for the tested RIDs/service path. This does not prove every machine or trust account has a strong password.

Additional evidence

• DC/FQDN and IP
• RID/account mapping where known
• $sntp-ms$... artifact
• collection rate/tool version
• cracking result and effort

Finding logic

Timeroasting capability by itself is a protocol property. Report weak/default/non-random machine or trust-account passwords when cleartext recovery or equivalent evidence proves the account secret is weak.

Next

• AD-CRACK-01 with Hashcat mode 31300.
• If cracked: AD-AUTH-01 and map the machine/trust account’s actual rights.

Alternative branch

• Continue AS-REP, policy/spray, anonymous and relay/coercion branches.

Reference

• https://github.com/bvcyber/Timeroast

AD-PASS-01 — Password and lockout policy before authentication testing

Status: CURRENT

Entry state: S3–S4
Result type: INFORMATION
Risk of execution: LOW

Goal

Determine lockout threshold/window, minimum length, history and fine-grained password policies before any spray.

Prerequisites

A readable domain policy and, where used, the resultant fine-grained policy for each tested identity; request policy from the owner if unavailable.

Commands

NetExec domain policy

1

nxc smb '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' --pass-pol

PowerShell domain policy

1

Get-ADDefaultDomainPasswordPolicy

Fine-grained policies

1

Get-ADFineGrainedPasswordPolicy -Filter *

Resolve the policy applied to a particular user

1

Get-ADUserResultantPasswordPolicy -Identity '<user>'

No returned PSO means the default domain policy applies only after successful query and confirmed absence of a resultant fine-grained policy. Permission/query errors are not that result. Coordinate the attempt budget with other testers; a delay alone does not establish a safe cadence.

Parameters

Interpretation

You now have the safety envelope needed to decide whether spraying is permissible and at what cadence. Fine-grained policies mean one global threshold is not sufficient.

If unsuccessful

If policy cannot be read, do not guess a spray cadence. Obtain policy through another approved method or skip spraying.

Finding logic

Weak password/lockout policy can be reportable independently; do not infer password quality solely from policy.

Next

• AD-PASS-02 — lockout-aware spray only if explicitly permitted

Alternative branch

• Skip spray; continue AS-REP, anonymous access, poisoning/coercion or credential exposure paths

AD-PASS-02 — Lockout-aware Kerberos password spray

Status: CURRENT

Entry state: S2 plus known policy
Result type: CREDENTIAL
Risk of execution: MEDIUM

Goal

Test a very small approved set of passwords across validated accounts without vertical brute-force behavior.

Prerequisites

Validated users, resultant lockout policies, excluded identities and a coordinated attempt budget. Account for other operators and existing failed attempts; --safe reacts to observed lockout and cannot guarantee prevention.

Commands

Kerbrute spray

1

kerbrute passwordspray -d '<domain>' --dc '<dc_fqdn>' --safe --delay '<ms>' users.txt '<password>'

Parameters

Interpretation

A valid login is a reusable credential. Stop testing that identity unnecessarily; record it and begin authenticated enumeration.

If unsuccessful

Record a protected reference to the tested password and the timestamp so the attempt is not repeated inside the observation window. Keep the cleartext out of ordinary notes.

Finding logic

A weak or default password demonstrated on a domain account is reportable. Multiple affected users may indicate systemic password hygiene failure.

Next

• Validate credential over the minimum necessary protocol
• AD-LDAP-02 and AD-BH-01

Alternative branch

• Reconcile the agreed attempt budget and observation/reset window before any further spray; do not assume a fixed delay guarantees safety
• Continue independent non-password branches

Operational notes

• Do not use username==password or seasonal/common-password testing unless explicitly authorized.
• Kerbrute documentation warns that failed pre-authentication attempts can contribute to lockout.

Reference

• https://github.com/ropnop/kerbrute

AD-KRB-04 — Kerberoasting

Status: CURRENT

Entry state: S4
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Find service accounts with SPNs and request service tickets suitable for offline password-strength analysis.

Prerequisites

Valid domain identity and reachable LDAP/KDC; identify service accounts and encryption types before choosing a cracking mode.

Commands

Impacket

1

impacket-GetUserSPNs '<domain>/<user>' -dc-ip '<dc_ip>' -request -outputfile evidence/kerberos/tgs.hashes

Rubeus Windows

1

Rubeus.exe kerberoast /outfile:tgs.hashes

Parameters

Interpretation

A $krb5tgs$... value is credential material. Prioritize privileged/service-critical principals, old passwords and RC4-capable paths while respecting cracking scope.

If unsuccessful

No roastable SPN users were discovered through this credential/context; continue ACL, delegation, AD CS and shares.

Finding logic

A service account merely having an SPN is normal. Report weak service-account passwords, excessive privilege, avoidable RC4 exposure or demonstrated compromise path.

Next

• AD-CRACK-01 — offline cracking
• If cracked: validate and re-run BloodHound/privilege mapping as the service account

Reference

• https://github.com/fortra/impacket

AD-KRB-05 — Service-ticket requests through a no-preauthentication account

Status: CURRENT

Entry state: S2 with a confirmed no-preauthentication account

Result type: CREDENTIAL

Risk of execution: LOW with a bounded candidate list

Prerequisites

A known account that does not require pre-authentication, a reachable KDC and a scoped list of candidate service-account names. This is a separate branch from ordinary authenticated Kerberoasting; it is not available from an arbitrary valid username.

Command — Impacket 0.13.1

1

impacket-GetUserSPNs -no-preauth '<asrep_user>' -usersfile 'service-users.txt' -dc-host '<dc_fqdn>' -dc-ip '<dc_ip>' -no-pass -outputfile 'evidence/kerberos/no-preauth-tgs.hashes' '<domain>/'

-no-preauth selects the account enabling this flow. -usersfile supplies service-account candidates; it does not enumerate the directory. Record returned material by account and encryption type, then use AD-CRACK-01. Failure for one candidate is not proof that the domain has no service accounts or that standard authenticated Kerberoasting is prevented.

Reference: GetUserSPNs source, 0.13.1

AD-KRB-06 — AS-REQ preauthentication material in an authorized capture

Status: CURRENT

Entry state: Scoped network capture or authorized observation point

Result type: CANDIDATE

Risk of execution: LOW for offline inspection

Procedure

1. Open the authorized PCAP in Wireshark and filter kerberos.msg_type == 10 for AS-REQ traffic.
2. Inspect preauthentication data. PA-ENC-TIMESTAMP material is a different artifact from a roastable AS-REP response; record the account, realm, encryption type, frame and capture point.
3. If an offline audit is required, use a reviewed converter supporting that exact preauthentication/encryption format and compare its output against the installed cracker’s example hashes. Do not assign AS-REP mode 18200 to AS-REQ material by name similarity.
4. Preserve conversion provenance and route any recovered password through AD-AUTH-01.

Packet visibility is a prerequisite. Switched-network placement, protected Kerberos transport or a capture outside the authentication path may yield no material. This card does not require creating an ARP/DHCP MITM and does not establish a vulnerability merely because encrypted preauthentication is observable.

Reference: Wireshark Kerberos fields

7. Name-resolution poisoning, capture and coercion

AD-NTLM-01 — Passive LLMNR/NBT-NS/mDNS observation

Status: CURRENT

Entry state: S0
Result type: INFORMATION
Risk of execution: LOW

Goal

Determine whether broadcast/multicast name-resolution fallback exists before actively poisoning it.

Prerequisites

An interface on the relevant segment and privileges to bind the listener. Analyze mode suppresses poisoning responses; do not assume every configured listener is disabled.

Commands

Responder analyze mode

1

sudo python3 Responder.py -I '<interface>' -A -v

Parameters

Interpretation

Observed fallback name-resolution requests show that poisoning may be technically possible; record request names and source hosts.

If unsuccessful

No traffic during the observation window does not prove the protocols are disabled; usage is event dependent.

Finding logic

Passive observation alone is not a finding. Enabled LLMNR/NBT-NS combined with exploitable captured authentication supports a stronger finding.

Next

• If active poisoning is in scope: AD-NTLM-02
• Identify whether sources are privileged/admin workstations or servers

Alternative branch

• Move to explicit coercion checks rather than waiting indefinitely

Adjacent MITM branches

For ARP or DHCPv6-based redirection, first document the segment, IPv6/DHCP/DNS roles and whether the observation point can see the relevant traffic. Confirm the compatible relay destination before selecting an active redirection method. These methods change network behavior and are not interchangeable with Responder analyze mode. This playbook covers the prerequisite/relay decision; implementation-specific active ARP/DHCPv6 procedures remain external specialist workflows in Appendix D.

Reference

• https://github.com/lgandx/Responder

AD-NTLM-02 — Active name-resolution poisoning and NTLM capture

Status: CURRENT

Entry state: S0–S1
Result type: CREDENTIAL
Risk of execution: MEDIUM

Goal

Demonstrate that fallback resolution can be poisoned and causes clients to authenticate to an attacker-controlled service.

Prerequisites

A scoped source segment/allow-list, capture listener and bounded runtime. Review Responder.conf and active services before starting.

Commands

Responder active

1

sudo python3 Responder.py -I '<interface>' -v

Parameters

Interpretation

Captured NetNTLM material is an offline cracking artifact. Relay uses the live authentication exchange; a saved response cannot simply be replayed against an unrelated server challenge. Do not call it an NT hash; it is a challenge/response artifact.

If unsuccessful

No captured authentication. Stop after the agreed observation period and use targeted coercion/relay posture checks.

Finding logic

Name-resolution poisoning exposure becomes materially reportable when authentication can be captured or relayed; identify the exact protocol and source host.

Next

• AD-NTLM-04 — relay if compatible target exists
• AD-CRACK-01 — offline cracking of NetNTLMv1/v2 when authorized

Alternative branch

• AD-NTLM-03 — targeted coercion

Operational notes

• Basic poisoning does not require WPAD or DHCP modes. -w, -P, -d and --dhcpv6 enable distinct behaviors with different impact; use them only when the specific technique is approved and verify the installed Responder.py -h/Responder.conf first.

Reference

• https://github.com/lgandx/Responder

AD-NTLM-03 — Coercion surface discovery

Status: CURRENT

Entry state: S1 or S4
Result type: PRIMITIVE
Risk of execution: MEDIUM

Goal

Identify RPC/HTTP mechanisms that can force a machine or service to authenticate to an operator-controlled listener.

Prerequisites

A target allow-list and reachable RPC services; authentication requirements differ by coercion method. Discovery is not proof of a delivered authentication.

Commands

Coercer scan

1

coercer scan -t '<target>' -u '<user>' -p '<password>' -d '<domain>'

NetExec coerce module discovery

1

nxc smb '<target>' -d '<domain>' -u '<user>' -p '<password>' -M coerce_plus

Parameters

Interpretation

A reachable coercion method is an authentication-source primitive. Pair it with a separately validated relay destination; do not fire indiscriminately at production servers.

If unsuccessful

The tested coercion methods were unavailable/blocked for this target/context. Continue other source systems and non-NTLM paths.

Finding logic

A coercion primitive alone may be informational; combined with relayable authentication and privilege impact it becomes a clear attack path.

Next

• AD-NTLM-04 — choose a relay destination
• AD-ADCS-04 — evaluate AD CS HTTP endpoints
• AD-NTLM-05 — LDAP protections

Alternative branch

• AD-KRB-04 / AD-ACL-01 / AD-ADCS-01 authenticated branches

Reference

• https://github.com/p0dalirius/Coercer
• https://github.com/Pennyw0rth/NetExec

8. Authentication relay decision tree

AD-KRB-RELAY-01 — Kerberos relay and WebDAV/WebClient prerequisites

Status: CURRENT

Entry state: S7
Result type: PRIMITIVE
Risk of execution: MEDIUM for discovery / HIGH for active relay

Goal

Identify whether a Kerberos-authentication source can be relayed to a matching service hostname and whether Windows WebClient/WebDAV provides a useful authentication trigger in a specific attack path. Kerberos relay is not interchangeable with NTLM relay: SPN, hostname and service matching rules are central to whether the path works.

Prerequisites

A specific Kerberos trigger, compatible SPN/hostname path and relay destination. WebClient presence alone does not establish these conditions.

Commands

Check the NetExec WebDAV module on an authenticated target

1

nxc smb '<target>' -d '<domain>' -u '<user>' -p '<password>' -M webdav

Review the installed krbrelayx mode/options

1

python3 krbrelayx.py -h

Controlled LDAP destination with automatic escalation/dumping disabled

1

python3 krbrelayx.py -t 'ldap://<target_fqdn>' --no-dump --no-da --no-acl

Parameters

Interpretation

A running/reachable WebClient or another Kerberos-authentication source is only a prerequisite. A complete primitive requires a compatible trigger, SPN/hostname conditions, a relay destination and an identity whose resulting authorization is useful.

If unsuccessful

The tested WebDAV/WebClient or Kerberos relay prerequisite was unavailable in this context. Continue NTLM relay, delegation, ACL and AD CS branches rather than trying to force a protocol downgrade.

Additional evidence

• authentication source and protocol
• source identity expected/observed
• SPN/hostname used
• relay destination and service
• WebClient/WebDAV state when relevant
• resulting authenticated identity and authorization

Finding logic

Do not report “WebDAV enabled” or “Kerberos relay possible” without the conditions that make the path security-relevant. Report the underlying name/SPN/control weakness and demonstrated authorization impact.

Next

• Prove the minimum useful authorization on the relay destination.
• Feed any new primitive into AD-BH-02 / AD-ACL-01 / AD-AUTH-01 as appropriate.

Reference

• https://github.com/dirkjanm/krbrelayx
• https://github.com/Pennyw0rth/NetExec

AD-NTLM-04 — Build relay source/destination compatibility matrix

Status: CURRENT

Entry state: S1–S4
Result type: PRIMITIVE
Risk of execution: LOW

Goal

Do not launch relay blindly. Determine source protocol, destination service, signing/channel-binding requirements, identity privilege and expected action.

Prerequisites

Source/destination inventory and separate observations for protocol protections and identity rights.

Build the matrix from existing evidence

• SMB destination candidates: AD-SMB-01, using evidence/relay/smb.txt.
• LDAP signing and LDAPS channel binding: AD-NTLM-05.
• AD CS enrollment endpoints/templates: AD-ADCS-01 and AD-ADCS-04.
• Source protocol, identity, trigger and destination authorization: record one row per viable combination.

Interpretation

You have at least one plausible (authentication source → relay destination → useful action) tuple. Record it explicitly before exploitation.

If unsuccessful

No compatible relay route was identified. Mark relay tested and continue Kerberos/ACL/delegation/AD CS paths rather than weakening the target to make relay work.

Finding logic

The matrix itself is analysis. Report the underlying missing protection and the demonstrated impact.

Next

• Use the minimum-impact relay action that proves privilege
• AD-NTLM-06/07/AD-ADCS-04 depending on destination

Operational notes

• SMB signing required blocks ordinary SMB relay to that host; it says nothing about LDAP/HTTP/ICPR/MSSQL targets.
• LDAP signing and channel binding are distinct controls; LDAPS plus channel binding affects relay viability differently from plain LDAP.

AD-NTLM-05 — LDAP signing, LDAPS channel binding and NTLM relay protection

Status: CURRENT

Entry state: S1–S4
Result type: INFORMATION
Risk of execution: LOW

Goal

Determine whether LDAP/LDAPS authentication protections prevent NTLM relay to directory services. Keep LDAP signing and LDAP channel binding conceptually separate.

Prerequisites

Reachable LDAP/LDAPS endpoints; record failed or ambiguous posture probes rather than treating every banner as a definitive policy read.

Commands

NetExec host posture

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>'

In current NetExec releases, the LDAP host banner performs built-in checks for LDAP signing and LDAPS channel binding. Record both values independently.

Additional channel-binding validation when the installed release provides the module

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' -M ldap-checker

Inspect installed module options

1

nxc ldap -M ldap-checker --options

Parameters

Interpretation

A configuration that permits relay-compatible NTLM binding is a destination candidate. The final exploitability still depends on the incoming authentication type and what the relayed identity may modify.

If unsuccessful

Required signing/channel binding or NTLM restrictions can remove LDAP/LDAPS as a relay destination while leaving other relay destinations unaffected.

Additional evidence

• DC/FQDN
• LDAP and LDAPS reachability
• signing assessment
• channel-binding assessment
• NTLM restriction observations
• tool/version

Finding logic

Report the specific missing protection and demonstrated consequence. Do not state that “LDAP signing disabled” automatically means Domain Admin compromise.

Next

• AD-NTLM-07 — controlled LDAP/LDAPS relay proof.
• Map the relayed identity’s exact writable objects before making changes.

Alternative branch

• AD-ADCS-04 — check AD CS relay destinations.
• AD-NTLM-06 — SMB relay destinations where signing is not required.
• Continue Kerberos and directory-object paths.

Reference

• https://github.com/Pennyw0rth/NetExec
• https://github.com/fortra/impacket

AD-NTLM-06 — SMB relay with ntlmrelayx

Status: CURRENT

Entry state: S7
Result type: ACCESS
Risk of execution: HIGH

Goal

Relay captured/coerced NTLM authentication to an SMB destination that does not require signing and prove the minimum authorized impact.

Prerequisites

Live relay-compatible NTLM authentication, a non-signing SMB destination, a scoped listener and known useful destination rights for the incoming identity.

Commands

Relay to allow-listed targets

1

impacket-ntlmrelayx -tf evidence/relay/smb.txt -smb2support -socks

Parameters

Interpretation

A successful relay proves that the source identity can be authenticated to the destination. Determine effective privilege before any command execution.

If unsuccessful

Failure can result from signing, identity authorization, NTLM restrictions, EPA/channel binding, session state or target incompatibility.

Finding logic

Demonstrated NTLM relay is a strong finding. Report source mechanism, destination weakness, relayed identity and achieved privilege separately.

Next

• If SOCKS session is low privilege: enumerate only
• If administrative: prove one minimal-impact action and stop
• Return new access/credential state to AD-BH-01

Alternative branch

• Re-evaluate source/destination compatibility
• Do not repeatedly coerce production hosts

Reference

• https://github.com/fortra/impacket

AD-NTLM-07 — LDAP/LDAPS relay impact

Status: CURRENT

Entry state: S7
Result type: PRIMITIVE
Risk of execution: HIGH

Goal

Assess whether a relayed identity can perform a useful LDAP write such as RBCD, group modification or shadow credentials.

Prerequisites

Live compatible NTLM authentication and LDAP/LDAPS protection conditions that permit relay. Source protocol, MIC and channel binding can independently block the path.

Commands

Authentication-only baseline with automatic LDAP dumping and escalation disabled

1

impacket-ntlmrelayx -t 'ldaps://<dc_fqdn>' -smb2support --no-dump --no-da --no-acl

Parameters

Interpretation

Successful relayed LDAP authentication proves acceptance of this source/protocol combination; it does not prove a useful write. This command does not open an interactive shell. If an interactive proof is required, select --interactive deliberately and preserve the resulting session identity and exact operation. Do not feed only a captured NetNTLM string into this flow.

If unsuccessful

Signing/channel binding/NTLM policy or identity rights prevented useful relay.

Finding logic

LDAP relay exposure is best reported with the actual writable object/action and resulting privilege path.

Next

• AD-ACL-04 — RBCD if computer object is writable
• AD-ACL-03 — shadow credentials if KeyCredentialLink is writable
• AD-ACL-02 — group/ACL rights where authorized

Alternative branch

• AD-ADCS-04 — AD CS web relay
• Continue non-relay branches

Operational notes

• Avoid ntlmrelayx automatic escalation switches on production unless the engagement explicitly requires them; controlled manual proof produces cleaner evidence.

Reference

• https://github.com/fortra/impacket

9. Validate every obtained credential

AD-AUTH-01 — Credential validation and privilege tagging

Status: CURRENT

Entry state: S3 or S6
Result type: ACCESS
Risk of execution: LOW

Goal

Validate a password/hash/ticket/certificate against the minimum number of protocols and tag the identity with actual privilege instead of assuming it.

Prerequisites

Known credential type and source principal; a single approved target appropriate to that identity and protocol.

Commands

Password SMB

1

nxc smb '<target>' -d '<domain>' -u '<user>' -p '<password>'

NT hash SMB

1

nxc smb '<target>' -d '<domain>' -u '<user>' -H '<nt_hash>'

Kerberos SMB

1

KRB5CCNAME='<ticket.ccache>' nxc smb '<target_fqdn>' -k --use-kcache

WinRM

1

nxc winrm '<target>' -d '<domain>' -u '<user>' -p '<password>'

Parameters

Interpretation

Record protocol-specific access and whether NetExec marks administrative rights. A credential valid on one protocol does not automatically imply another.

If unsuccessful

A failed protocol can be disabled or restricted even when credentials are correct. Validate against DC Kerberos/LDAP or another known service before calling the credential invalid.

Next

• AD-BH-01
• AD-SHARE-01
• AD-ACL-01
• AD-ADCS-01
• AD-DELEG-01

Alternative branch

• Check domain format, DNS, clock skew, account restrictions and allowed logon types

10. BloodHound and graph-based attack-path analysis

AD-BH-01 — Collect BloodHound data

Status: CURRENT

Entry state: S4
Result type: INFORMATION
Risk of execution: LOW for DC-only collection; MEDIUM for broad host/session collection

Goal

Build a graph of group membership, sessions, local admin relationships, ACLs, delegation, trusts and other attack edges.

Prerequisites

Valid domain identity, working DNS/LDAP and a collector compatible with the deployed BloodHound edition. Remote host/session collection has additional connectivity and access requirements.

Install the CE ingestor package bloodhound-ce for the shown bloodhound-ce-python command. The legacy bloodhound package exposes bloodhound-python; do not silently substitute its output into a CE workflow. Use a SharpHound build supported by the deployed CE version.

Commands

SharpHound from Windows

1

SharpHound.exe -c DCOnly --outputdirectory . --zipfilename bloodhound.zip

BloodHound.py Community Edition collector

1

bloodhound-ce-python -d '<domain>' -u '<user>' -p '<password>' -ns '<dc_ip>' -c DCOnly --zip

Parameters

Interpretation

Import results and tag the current controlled principal(s) using the deployed CE interface. DCOnly omits host-derived session/local-access observations; collect those separately when required. Search shortest paths to high-value groups/hosts, but also inspect individual edge semantics and freshness.

If unsuccessful

Collector failure is usually DNS/auth/connectivity/permissions or collection-method specific. A failed collector does not mean the graph has no path.

Finding logic

A BloodHound path is not automatically a finding; each edge must be validated and translated into the underlying misconfiguration.

Next

• AD-BH-02 — triage high-value paths
• AD-ACL-01
• AD-DELEG-01
• AD-LAPS-01

Alternative branch

• Collect LDAP-only data
• Use SharpHound from a joined workstation if remote collection is restricted

Operational notes

• BloodHound data can contain sensitive relationship and session information; protect it as engagement evidence.

Reference

• https://bloodhound.specterops.io
• https://github.com/SpecterOps/SharpHound

10.1 BloodHound triage order

• Mark every compromised principal and host as owned.
• Find shortest paths from owned principals to Domain Admins, Enterprise Admins, DCs, PKI/CA servers and tier-0 management systems.
• Inspect outbound object-control edges from owned principals: GenericAll, GenericWrite, WriteDACL, WriteOwner, AddMember, ForceChangePassword, AddKeyCredentialLink, AddAllowedToAct, GPO-control edges, LAPS/gMSA read rights.
• Inspect delegation edges and computer-account creation possibilities.
• Inspect local administrator paths to servers that hold privileged sessions or deployment credentials.
• Validate every promising edge with a native/LDAP query before exploiting it; stale graph data is common.

AD-BH-02 — Validate and prioritize BloodHound attack paths

Status: CURRENT

Entry state: S4–S8
Result type: ATTACK PATH
Risk of execution: LOW

Goal

Turn graph edges into a short list of technically valid, testable paths. BloodHound is a relationship engine; it is not proof that every edge is currently exploitable.

Prerequisites

Current collection and a correctly identified controlled principal/host. Record collection timestamp and missing datasets.

Commands

Use BloodHound CE queries and the object details pane to inspect shortest paths, outbound object control and high-value targets; names such as owned/compromised and high value/tier zero vary with the CE interface. Validate important LDAP rights separately with the relevant ACL section before changing anything.

Parameters

Interpretation

A graph path is a hypothesis composed of concrete edges. It becomes an attack path only after the relevant edges are current, reachable and usable by the owned principal.

If unsuccessful

No path in the current collection can mean genuinely good separation, incomplete collection, stale data, missing domains or an unmarked owned principal.

Additional evidence

• start principal
• target principal/host/group
• ordered edge list
• collection timestamp
• manual validation for each security-relevant edge
• screenshot/export only where useful to explain the path

Finding logic

Do not report “BloodHound found a path” as the root cause. Report the misconfigured ACL, delegation, local-admin assignment, session/tier problem, certificate template or other underlying edge.

Next

• Validate the first actionable edge in the corresponding chapter.
• Stop traversing once sufficient business/security impact is proven.
• Re-run graph analysis after gaining a new identity or host.

Alternative branch

• Check collection completeness and DNS/domain coverage.
• Continue independent AD CS, SCCM, MSSQL, shares and host-local branches.

Reference

• https://bloodhound.specterops.io

Status: CURRENT

Entry state: S4
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Locate business/deployment shares and identify exposed credentials, scripts, configs, backups and key material without indiscriminate downloading.

Prerequisites

A valid identity, selected SMB targets and a bounded share/path search scope.

Commands

Share listing

1

nxc smb '<CIDR>' -d '<domain>' -u '<user>' -p '<password>' --shares --no-write-check

Inventory paths in one selected share

1

nxc smb '<target>' -d '<domain>' -u '<user>' -p '<password>' --spider '<share>' --depth 3

Interactive client

1

smbclient '//<target>/<share>' -U '<domain>/<user>'

For whole-host metadata inventory, spider_plus is an alternative and scans all readable shares; its exclusion option in NetExec 1.5.1 is EXCLUDE_FILTER, not EXCLUDE_DIR. It does not search file contents by default. Keep the selected-share example as the normal starting point. Use --content with a bounded path/pattern only when content inspection is required.

Parameters

Interpretation

Readable deployment/config/backup files may yield credentials or architecture information. Writable shares may enable a separate coercion or execution path only if a consuming workflow exists.

If unsuccessful

No useful accessible shares for this credential. Repeat only when privilege state changes.

Finding logic

Report excessive share access or exposed secrets, not merely the existence of common administrative shares.

Next

• Add recovered credential/key/PFX to credential inventory
• If write access: identify actual consumer before any payload placement
• AD-GPP-01 for SYSVOL cpassword

AD-GPP-01 — Legacy Group Policy Preferences cpassword

Status: LEGACY

Entry state: S4
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Check SYSVOL for legacy GPP XML containing reversible cpassword values.

Prerequisites

Readable SYSVOL, or a scoped offline copy whose source and timestamp are known.

Commands

Impacket

1

impacket-Get-GPPPassword '<domain>/<user>:<password>@<dc_fqdn>'

Search SYSVOL

1

grep -Rni "cpassword" '<mounted_sysvol_path>'

Interpretation

Recovered cpassword material can be decrypted because the AES key is public. Treat the recovered password as a credential and determine scope of reuse.

If unsuccessful

No legacy cpassword material in accessible SYSVOL.

Finding logic

Any recoverable GPP password is reportable and often high impact depending on the affected identity.

Next

• Validate recovered identity
• Re-run BloodHound as the new principal

Alternative branch

• Continue other secret sources

Reference

• https://github.com/fortra/impacket

12. ACL / ACE abuse decision tree

ACL abuse should be driven by the exact controlled attribute/right, not by a generic “GenericWrite = own target” assumption. First identify (controlled principal → right → target object → writable attribute/action → resulting privilege).

AD-ACL-01 — Enumerate object-control rights

Status: CURRENT

Entry state: S4
Result type: PRIMITIVE
Risk of execution: LOW

Goal

Find rights controlled by an owned principal over users, groups, computers, OUs, GPOs, domain objects and PKI objects.

Prerequisites

A resolved principal SID, target DN and readable security descriptor. Include nested group membership when reasoning about effective access.

Commands

BloodHound

Use outbound object-control edges from the owned principal and validate each edge in the object details/edge documentation before exploitation.

NetExec DACL read module

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' -M daclread -o TARGET='<target>' ACTION=read

Parameters

Interpretation

Record the exact ACE: trustee SID, target DN, object type/GUID, inherited/direct status and right. Map only to actions the right genuinely enables.

If unsuccessful

No useful control edges for the current owned principal; revisit after obtaining another identity.

Finding logic

Excessive ACL delegation becomes reportable when it crosses trust/tier boundaries or directly enables privilege escalation.

Next

• AD-ACL-02 group control
• AD-ACL-03 shadow credentials
• AD-ACL-04 RBCD
• AD-GPO-01
• AD-ADCS-02 where target is PKI

Reference

• https://github.com/Pennyw0rth/NetExec-Wiki/blob/main/ldap-protocol/read-dacl-right.md

AD-ACL-02 — Group membership / password-control edges

Status: CURRENT

Entry state: S7
Result type: ACCESS
Risk of execution: HIGH

Goal

Validate whether an owned principal can add members to a privileged group, change another user password, take ownership or rewrite the target DACL.

Prerequisites

Validated effective group/password/DACL right, the exact target and a reversible proof. Existing protected-object behavior must be understood.

Commands

Native group membership where explicitly authorized

1

net rpc group addmem "<group>" "<user_to_add>" -U "<domain>/<operator>%<password>" -S '<dc_fqdn>'

Interpretation

The modified group membership or controlled account demonstrates the privilege escalation path. Remove test changes immediately and record before/after state.

If unsuccessful

The ACE may be stale, inherited differently, blocked by protected-object behavior or not confer the assumed action.

Finding logic

Unauthorized control over privileged users/groups is normally high/critical depending on target. Prefer demonstrating with a reversible test account or read-only validation if possible.

Next

• Validate resulting token/access after replication
• Rollback membership/ACL change
• Re-run BloodHound

Alternative branch

• Re-read effective DACL and object protection
• Try another valid action for the exact right

Operational notes

• Do not reset real user passwords merely to prove ForceChangePassword if a lower-impact validation can establish the same control.

AD-ACL-03 — Shadow Credentials / msDS-KeyCredentialLink

Status: CURRENT

Entry state: S7
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

Use write access to msDS-KeyCredentialLink to obtain certificate-based authentication as the target account without changing its password.

Prerequisites

Effective write access to the target msDS-KeyCredentialLink and working PKINIT/key-trust prerequisites, including a suitable DC certificate. Preserve the original attribute values.

Commands

Read the existing attribute first

1

certipy shadow list -u '<user>@<domain>' -p '<password>' -account '<target>' -dc-ip '<dc_ip>'

Certipy automated flow

1

certipy shadow auto -u '<user>@<domain>' -p '<password>' -account '<target>' -dc-ip '<dc_ip>'

Parameters

Interpretation

Successful certificate-based authentication yields reusable credential material and proves control of the target identity. Verify cleanup and preserve before/after attribute state.

If unsuccessful

The right may not apply to the attribute, target may not support the flow, PKINIT prerequisites may be absent, or directory protections may block modification.

Finding logic

Writable KeyCredentialLink on a privileged identity is a strong privilege-escalation finding.

Next

• Inventory only artifacts actually returned by shadow auto, normally recovered hash/ticket material. Do not assume it saved a reusable PFX.
• Verify restoration of the original KeyCredentialLink values. Removing the temporary key invalidates that key-trust path but does not retract an already issued TGT or a recovered account secret.
• Validate any still-usable credential through AD-AUTH-01.

Alternative branch

• Validate exact ACE/attribute
• Consider other rights enabled by the same ACE

Reference

• https://github.com/ly4k/Certipy
• https://github.com/ShutdownRepo/pywhisker

AD-ACL-04 — Resource-Based Constrained Delegation through computer-object control

Status: CURRENT

Entry state: S7
Result type: ACCESS
Risk of execution: HIGH

Goal

Use write permission on a computer object to configure which principal may act on its behalf, then request an impersonated service ticket.

Prerequisites

Effective RBCD-attribute write on the target, a controlled service principal with usable keys/SPNs, and an impersonated identity permitted to delegate. Creating a computer is optional if a suitable principal already exists.

Commands

Create controlled computer only if MAQ/scope permits

1

impacket-addcomputer -method LDAPS -computer-name '<controlled>$' -computer-pass '<controlled_password>' -dc-host '<dc_fqdn>' '<domain>/<user>:<password>'

Write RBCD

1

impacket-rbcd -delegate-from '<controlled>$' -delegate-to '<target>$' -action write -dc-ip '<dc_ip>' '<domain>/<user>:<password>'

Request service ticket

1

impacket-getST -spn 'cifs/<target_fqdn>' -impersonate '<authorized_test_admin>' -dc-ip '<dc_ip>' '<domain>/<controlled>$:<controlled_password>'

Use a computer/service principal with a verified SPN; the example explicitly selects LDAP-based creation rather than relying on SAMR defaults. Creation and RBCD writes are separate changes. Preserve the entire original msDS-AllowedToActOnBehalfOfOtherIdentity security descriptor and restore it without removing pre-existing delegates.

Parameters

Interpretation

A valid service ticket for the target under an impersonated privileged identity proves the RBCD path. Restore the original attribute and remove any test computer account created for the proof.

If unsuccessful

Check computer-account creation rights, exact object ACL, SPN, time/DNS and S4U constraints.

Finding logic

Ability for a low-privilege identity to configure RBCD on a sensitive server is usually high severity.

Next

• Use the ticket only for the minimal target service needed to prove impact
• Rollback RBCD and test computer
• Re-run graph

Alternative branch

• Try another controlled principal that already has an SPN
• Return to ACL map

Reference

• https://github.com/fortra/impacket

AD-ACL-05 — GenericWrite/GenericAll/WriteProperty on users and groups

Status: CURRENT

Entry state: S7
Result type: PRIMITIVE
Risk of execution: LOW for validation / HIGH for object modification

Goal

Translate broad object-control edges into the exact primitive they grant instead of treating every GenericWrite or GenericAll edge as the same attack.

Prerequisites

A validated ACL edge and resolved object/property GUIDs; distinguish attribute writes, extended rights, ownership and DACL control.

Decision matrix

Read-only validation

1

Get-Acl 'AD:<distinguished_name>' | Format-List

1

impacket-dacledit -action read -principal '<controlled_principal>' -target '<target_object>' -dc-ip '<dc_ip>' '<domain>/<user>:<password>'

Interpretation

The edge is a usable primitive only after you confirm the right applies to the intended object/property and is not blocked by inheritance, protected objects, AdminSDHolder behavior or a tool interpretation error.

If unsuccessful

Treat the graph edge as unconfirmed. Recollect ACLs, inspect inherited/object-specific GUIDs and test the exact DN before choosing another abuse path.

Additional evidence

• source principal SID
• target DN/SID
• ACE type and object GUID
• inherited vs explicit
• effective property/right
• safe proof performed
• rollback, if a write was executed

Finding logic

Report the effective privilege escalation consequence, not merely “GenericWrite exists”. Severity follows the target and resulting control path.

Next

• Password-control edge → AD-AUTH-01 after an approved reset
• SPN-write edge → AD-KRB-04
• KeyCredentialLink → AD-ACL-03
• Computer/RBCD → AD-ACL-04
• Group membership → AD-BH-02 and privilege re-evaluation

Alternative branch

• Return to AD-ACL-01 and validate other edges

13. Group Policy Objects

AD-GPO-01 — GPO control and GPO-link rights

Status: CURRENT

Entry state: S7
Result type: PRIMITIVE
Risk of execution: LOW

Goal

Identify whether an owned principal can modify a GPO linked to privileged computers/users or can create/link a GPO to a sensitive OU.

Prerequisites

A candidate GPO/link/OU control edge and the target scope. Inspect both the AD Group Policy Container and SYSVOL Group Policy Template permissions.

Commands

BloodHound

Inspect GPO-control and GP-Link-related paths from owned principals, then validate the effective object/GPO/link rights directly.

PowerView conceptual validation

1

Get-DomainGPO -Identity '<gpo>' | Get-DomainObjectAcl -ResolveGUIDs

Validate GPC and GPT permissions, link placement, security and WMI filtering, inheritance and the actual receiving computer/user context. A writable AD object, writable SYSVOL path and ability to link a new GPO are different capabilities. A displayed ACL is evidence to interpret, not an effective-access computation.

Interpretation

Control is meaningful only when the GPO applies to a security-relevant scope and the attacker-controlled settings can execute in that context. Record GPO GUID, links, enforced/block-inheritance state and security filtering.

If unsuccessful

No useful GPO control for the current principal; continue OU/object ACL paths.

Finding logic

Unauthorized modification/link rights over GPOs affecting servers, admins or DCs are high-impact findings.

Next

• Prefer read-only proof of GPO write rights
• If exploitation is authorized, use a reversible benign setting/test account and force/update only in an agreed window

Operational notes

• Avoid using production startup scripts, scheduled tasks or local-group changes as a proof unless explicitly required; GPO can affect large populations unexpectedly.

AD-DNSADMIN-01 — DNSAdmins and DNS Server administrative control

Status: CURRENT

Entry state: S4 or S7
Result type: PRIMITIVE
Risk of execution: LOW for membership/configuration validation / HIGH for service/plugin modification

Goal

Identify whether an owned principal has administrative control over Microsoft DNS Server through DnsAdmins or equivalent local/service permissions. Historically, DNS Server plugin configuration can result in code loading in the DNS service context, but changing it can disrupt a DC/DNS server and must not be used as a casual proof.

Prerequisites

Resolved DNS servers, effective DNS administration rights and the server/service role; group membership alone is not proof of code execution.

Commands

1

Get-ADGroupMember -Identity 'DnsAdmins' -Recursive

1

Get-ADGroup 'DnsAdmins' -Properties member

On an explicitly approved DNS server, configuration can be inspected with native DNS administration tooling appropriate to the installed Windows Server version. Prefer read-only configuration evidence plus group membership over changing a plugin path.

Interpretation

Membership or equivalent effective rights can represent a path to highly privileged DNS servers, frequently DCs. Confirm the exact server role and service identity before assigning impact.

If unsuccessful

No DnsAdmins path for the current identity. Continue GPO/delegation/ACL analysis.

Additional evidence

• owned principal
• nested membership path
• DNS server host(s)
• whether DNS service runs on a DC
• effective administrative rights

Finding logic

Unexpected low-privilege membership/control over DNS administration is reportable. Do not claim SYSTEM/DA impact solely from the group name; demonstrate the actual service/server boundary or explain the validated prerequisite chain.

Next

• AD-BH-02 — model nested group/control path
• AD-LAT-01 — determine approved administrative access to DNS server
• Stop before service/plugin modification unless explicit high-impact exploitation is required

14. Kerberos delegation

AD-DELEG-01 — Delegation inventory

Status: CURRENT

Entry state: S4
Result type: CANDIDATE
Risk of execution: LOW

Goal

Enumerate unconstrained delegation, constrained delegation, protocol transition and RBCD relationships.

Prerequisites

Authenticated domain enumeration and access to delegation attributes.

Commands

Impacket

1

impacket-findDelegation '<domain>/<user>:<password>' -dc-ip '<dc_ip>'

BloodHound

Inspect AllowedToDelegate, AllowedToAct and unconstrained-delegation edges, then confirm the corresponding AD attributes before use.

Parameters

Interpretation

Classify each result by delegation type, principal, target SPN and privilege of the delegating account. Do not conflate unconstrained, classic constrained and RBCD.

If unsuccessful

No useful delegation configuration visible to this credential.

Next

• AD-DELEG-02 — unconstrained
• AD-DELEG-03 — constrained
• AD-ACL-04 — RBCD

AD-DELEG-02 — Unconstrained delegation impact

Status: CURRENT

Entry state: S8 plus delegation configuration
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

Determine whether a trusted-for-delegation host can receive and retain forwardable TGTs of privileged users.

Prerequisites

Administrative access to an unconstrained-delegation host and a permitted authentication source whose TGT can actually be delegated. Rubeus monitor requires elevation for other sessions.

Commands

Rubeus monitor on controlled Windows host

1

Rubeus.exe monitor /interval:5

Parameters

Interpretation

A privileged TGT appearing on a compromised unconstrained-delegation host is credential material and may enable domain compromise. Prove only with an authorized test/admin identity if possible.

If unsuccessful

No suitable privileged authentication occurred or delegation protections/account settings prevented a forwardable ticket.

Finding logic

Compromise of an unconstrained-delegation server plus realistic privileged authentication path is typically high/critical.

Next

• Protect/export only minimum ticket evidence
• Validate resulting access without broad lateral movement
• Stop once domain impact is proven

Alternative branch

• Assess constrained/RBCD and Protected Users/delegation restrictions

Operational notes

• Do not coerce real Domain Controllers or administrators solely to manufacture a critical path unless the engagement explicitly authorizes it.

AD-DELEG-03 — Constrained delegation / S4U

Status: CURRENT

Entry state: S6–S7
Result type: ACCESS
Risk of execution: HIGH

Goal

Use a compromised principal configured for constrained delegation to request service tickets on behalf of another user within its allowed SPNs.

Prerequisites

Usable keys for a delegating principal, exact allowed backend SPN and a delegable test user. The example assumes a usable S4U2Self-to-S4U2Proxy path; Kerberos-only constrained delegation may require an existing forwardable evidence ticket.

Commands

Impacket S4U

1

impacket-getST -spn '<allowed_spn>' -impersonate '<test_user>' -dc-ip '<dc_ip>' '<domain>/<delegating_account>'

Parameters

Interpretation

The example prompts for the account password. For an NT hash, supply -hashes ":<nt_hash>" and omit the password component; for AES, use -aesKey. <allowed_spn> is the complete service/FQDN value, not a value to which another hostname must be appended.

A successful S4U path normally combines S4U2Self (the delegating service obtains a service ticket to itself on behalf of a user) with S4U2Proxy (that ticket is used to request a ticket to an allowed backend SPN). Protocol transition, commonly associated with TRUSTED_TO_AUTH_FOR_DELEGATION, changes whether a non-Kerberos client authentication can enter this flow. A service ticket issued for the impersonated user demonstrates impact only for the service/SPN actually authorized. altservice-style substitution is protocol/version-specific and must be validated separately.

If unsuccessful

Check whether protocol transition is permitted, whether the requested user can be delegated, and whether the SPN matches allowed delegation targets.

Finding logic

Low-privilege compromise of a constrained-delegation principal can be high impact depending on target service/host and delegated users.

Next

• Use the ticket against only the allowed target service
• Record exact SPN and impersonated identity

Alternative branch

• Return to delegation configuration and user protections

Reference

• https://github.com/fortra/impacket

15. Active Directory Certificate Services

Treat AD CS as its own trust system. Track CA → template → enrollment rights → issuance requirements → subject/SAN behavior → EKU/application policy → authentication path → resulting identity. A template being “vulnerable” according to a scanner is a candidate until the current principal can actually enroll and authenticate in a way that changes security state.

AD-ADCS-01 — Enumerate enterprise CAs, templates and web/RPC enrollment endpoints

Status: CURRENT

Entry state: S4
Result type: CANDIDATE
Risk of execution: LOW

Goal

Build the PKI inventory and identify certificate templates or CA settings that may provide an escalation path.

Prerequisites

Directory credentials and connectivity to LDAP plus the CA interfaces needed for complete enumeration. Record unreachable CA checks as incomplete.

Commands

Certipy current baseline

1

certipy find -u '<user>@<domain>' -p '<password>' -dc-ip '<dc_ip>' -stdout -vulnerable

Full output for evidence

1

certipy find -u '<user>@<domain>' -p '<password>' -dc-ip '<dc_ip>' -json -output evidence/adcs/certipy

Parameters

Interpretation

For every candidate, record CA, template, enrollment principals, manager approval/signature requirements, subject-name flags, EKUs/application policies and CA interface availability.

If unsuccessful

No obvious path for the current principal. Re-run after privilege changes and inspect CA/object ACLs and web enrollment separately.

Finding logic

Scanner labels are not enough. Promote to finding only after validating the exact vulnerable condition and affected principals.

Next

• AD-ADCS-02 — template/CA ACL
• AD-ADCS-03 — certificate request path
• AD-ADCS-04 — web/RPC relay

Reference

• https://github.com/ly4k/Certipy

AD-ADCS-02 — AD CS ACL and configuration validation

Status: CURRENT

Entry state: S4 or S7
Result type: PRIMITIVE
Risk of execution: LOW

Goal

Determine whether the current principal can change a template, CA-related AD object or CA security setting into an exploitable state.

Prerequisites

CA/template inventory and effective management or directory rights. Include disabled templates when assessing template control.

Commands

Certipy enumeration

1

certipy find -u '<user>@<domain>' -p '<password>' -dc-ip '<dc_ip>' -stdout

Collection choice

Do not filter to -enabled during the control-plane review: control over an unpublished template may matter when combined with publication rights. Avoid -hide-admins when expected administrators themselves are the controlled identities. Record the effective ACL rather than only scanner labels.

Interpretation

Rights such as WriteDACL/WriteOwner/GenericAll on templates/PKI objects or CA-management rights can form ESC4/ESC5/ESC7-style paths. Preserve the original configuration before any modification.

If unsuccessful

No writable PKI control plane for the current principal; evaluate enrollment misconfiguration rather than modification.

Finding logic

Low-privilege write/control over authentication-capable certificate infrastructure is typically high/critical depending on reachable identity.

Next

• If proving ESC4-style impact: make one minimal reversible template change, request proof certificate, then restore
• If CA rights: avoid destructive CA configuration changes; prove permission where possible

AD-ADCS-03 — Validate an ESC1 certificate-template path

Status: CURRENT

Entry state: S7
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

Validate ESC1 by requesting a certificate for an approved test identity and proving the resulting mapping. Other ESC classes have different requirements and are not covered by blindly reusing this request.

Prerequisites

A validated ESC1 template published by the chosen CA, enrollment rights, suitable authentication EKU, controllable subject/SAN and no blocking issuance requirement; obtain the test identity UPN and SID.

Commands

Request

1

certipy req -u '<user>@<domain>' -p '<password>' -dc-ip '<dc_ip>' -target '<ca_fqdn>' -ca '<ca_name>' -template '<template>' -upn '<target_user>@<domain>' -sid '<target_sid>'

Authenticate

1

certipy auth -pfx '<certificate.pfx>' -dc-ip '<dc_ip>'

Parameters

Interpretation

Issued PFX plus successful authentication proves the template/CA path. Record certificate serial, subject/SAN, template, requester, CA and authentication result. Revoke/remove test artifacts when agreed.

If unsuccessful

A scanner candidate may fail because issuance requirements, CA policy, EKU/application policy, mapping rules, strong certificate binding or permissions block the path.

Finding logic

An enrollment path from a low-privileged principal to authentication as a privileged identity is critical in many environments.

Next

• AD-CERT-01 — store/use certificate credential
• Stop escalation after proving intended privilege
• Document remediation at template/CA/mapping layer

Alternative branch

• Re-evaluate exact ESC conditions rather than trying random flags

Operational notes

• This request follows the Certipy 5.1.0 ESC1 workflow. Validate the issued SID extension/SAN and the authenticating DC behavior. On updated DCs, the September 2025 changes removed support for the old StrongCertificateBindingEnforcement compatibility override. Do not infer exploitability from an old registry recipe. See Microsoft KB5014754.

Reference

• https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference
• https://github.com/ly4k/Certipy/releases

Status: CURRENT

Entry state: S7
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

Determine whether NTLM authentication can be relayed to AD CS web or RPC enrollment and converted into a certificate for the relayed identity.

Prerequisites

A live compatible authentication source, reachable enrollment endpoint, enrollment rights for the relayed identity and an appropriate template. Evaluate HTTP EPA and RPC encryption requirements separately.

Commands

Certipy relay

1

certipy relay -target 'http://<ca_fqdn>'

Impacket web relay pattern

1

impacket-ntlmrelayx -t 'http://<ca_fqdn>/certsrv/certfnsh.asp' --adcs --template '<template>' -smb2support

Parameters

Interpretation

A certificate issued for a coerced/relayed machine or user becomes credential material and proves an ESC8/related relay path.

If unsuccessful

NTLM disabled, EPA/channel binding, enrollment authentication restrictions, unavailable endpoint or template rights may block relay.

Finding logic

Coercion + relay to AD CS producing an authentication certificate is typically high/critical, especially for DC machine accounts.

Next

• AD-CERT-01
• Use minimum certificate-auth proof
• Document both coercion source and AD CS destination controls

Alternative branch

• Evaluate RPC/ICPR and other relay targets if in scope
• Continue non-relay AD CS template paths

Reference

• https://github.com/ly4k/Certipy
• https://github.com/fortra/impacket

15.1 ESC triage matrix

Treat an ESC label as a hypothesis that still needs its complete prerequisite set. Current Certipy documentation covers ESC1 through ESC17; some classes are direct template/CA misconfigurations while others require graph context, host access, patch state or a second service condition.

Operational rule

• Preserve Certipy’s exact finding/remarks output and the tool version.
• Verify graph-dependent ESCs with directory ACLs/BloodHound rather than treating a scanner label as complete proof.
• Verify patch-dependent ESCs against the CA/DC patch state and current certificate-mapping enforcement.
• Stop after the minimum certificate/authentication proof needed to demonstrate the privilege boundary.

Reference

• https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation

16. SCCM / Configuration Manager

AD-SCCM-01 — SCCM site-system and role discovery

Status: CURRENT

Entry state: S4
Result type: INFORMATION
Risk of execution: LOW

Goal

Identify management points, distribution points, site servers and SCCM-related directory objects because management infrastructure often crosses workstation/server trust boundaries.

Prerequisites

Authenticated directory access and in-scope Configuration Manager infrastructure or a reason to test for its presence.

Commands

SCCMHunter discovery

1

python3 sccmhunter.py find -u '<user>' -p '<password>' -d '<domain>' -dc-ip '<dc_ip>'

NetExec LDAP search baseline

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' -M sccm

Interpretation

Record SCCM server roles, site code and reachable interfaces. Treat discovered management infrastructure as high-value targets for permission and credential-exposure review.

If unsuccessful

No SCCM footprint found through this method; confirm software/host inventory before marking not present.

Finding logic

Presence of SCCM is not a finding. Excessive SCCM administrative rights, exposed NAA credentials, unsafe PXE or site-system compromise paths are.

Next

• AD-SCCM-02 — PXE/NAA and role permissions
• Map local admin relationships to SCCM servers

AD-SCCM-02 — PXE / Network Access Account exposure

Status: CURRENT

Entry state: S0–S1 or S5–S8
Result type: CREDENTIAL
Risk of execution: MEDIUM

Goal

Determine whether SCCM PXE/boot media or configuration exposes reusable Network Access Account or related credential material.

Prerequisites

PXE distribution point access or an already acquired variables file. Record whether the workflow requires local broadcast access, direct DP access or filesystem access.

Commands

Inspect installed SCCM tooling

1

python3 sccmhunter.py -h

PXE-enabled Distribution Point discovery/extraction workflow documented by PXEThief

1

python3 pxethief.py 2 '<distribution_point_ip>'

Extract crackable protected-media material from an already obtained variables file

1

python3 pxethief.py 5 '<boot.var>'

Verify the exact mode behavior with the installed PXEThief/PXEThief-derived release before use.

Interpretation

Recovered SCCM credential material must be decrypted/cracked as appropriate, then validated and scoped. An NAA often has broad read access but should not be assumed privileged.

If unsuccessful

No recoverable PXE/NAA material using the tested path.

Finding logic

Recoverable reusable SCCM credentials or insecure PXE configuration is reportable; severity depends on privilege/reuse.

Next

• Validate credential
• Search shares/repositories accessible to the NAA
• Re-run BloodHound

Alternative branch

• Review SCCM RBAC and site-system local privilege if access exists

Operational notes

• PXE/SCCM tooling evolves rapidly; preserve tool version and help output rather than relying on copied historical syntax.

16.1 SCCM decision taxonomy

SCCM/Configuration Manager should be treated as a management-plane trust system rather than as one vulnerability. A useful current taxonomy is the Misconfiguration Manager matrix:

Use the current Misconfiguration Manager technique IDs when documenting a precise SCCM weakness; the matrix evolves and individual CRED-*, ELEVATE-*, EXEC-*, RECON-* and TAKEOVER-* techniques have different prerequisites and remediations. Do not collapse every SCCM issue into “SCCM compromise”.

Reference

• https://github.com/subat0mik/Misconfiguration-Manager
• https://github.com/garrettfoster13/sccmhunter

AD-MSSQL-01 — Discover SQL servers, integrated authentication and linked servers

Status: CURRENT

Entry state: S3–S4
Result type: ACCESS
Risk of execution: LOW

Goal

Identify SQL instances where the domain credential works, determine server/database roles, impersonation and linked-server relationships.

Prerequisites

Reachable SQL instance accepting the supplied identity; discovery of a port does not establish a usable login.

Commands

NetExec auth

1

nxc mssql '<target>' -d '<domain>' -u '<user>' -p '<password>'

Impacket client

1

impacket-mssqlclient -windows-auth '<domain>/<user>:<password>@<target>'

Parameters

Interpretation

Record SQL login, server roles, IMPERSONATE rights and linked servers. SQL access is a separate privilege domain; sysadmin may lead to OS execution if enabled/authorized.

If unsuccessful

No SQL access for this credential; do not brute-force databases unless explicitly scoped.

Finding logic

Over-privileged SQL logins, unsafe impersonation chains and linked servers crossing security tiers can be reportable.

Next

• Enumerate impersonation/linked servers read-only
• Only test command execution if sysadmin/approved and needed to prove impact

Alternative branch

• Continue AD CS/trust/ACL paths

Reference

• https://github.com/fortra/impacket
• https://github.com/Pennyw0rth/NetExec

AD-MSSQL-02 — SQL impersonation and linked-server trust chains

Status: CURRENT

Entry state: S4 plus SQL access
Result type: PRIMITIVE
Risk of execution: LOW for enumeration / HIGH for OS command execution

Goal

Turn a valid SQL login into a graph of SQL security contexts and linked servers, then determine whether a database trust crosses an AD/domain/server privilege boundary.

Prerequisites

A working SQL login. Remote execution through a linked server depends on link configuration, mapped security context and RPC OUT for EXEC AT.

Commands

Enumerate linked servers with the current NetExec module

1

nxc mssql '<sql_target>' -d '<domain>' -u '<user>' -p '<password>' -M enum_links

Enumerate impersonation candidates

1

nxc mssql '<sql_target>' -d '<domain>' -u '<user>' -p '<password>' -M enum_impersonate

Read-only query through a specific linked server

1

nxc mssql '<sql_target>' -d '<domain>' -u '<user>' -p '<password>' -M exec_on_link -o LINKED_SERVER='<linked_server>' COMMAND='select @@servername'

@@servername confirms the destination server, not the effective security identity. Record SYSTEM_USER, ORIGINAL_LOGIN() and USER_NAME() in the relevant SQL context as well. Distinguish server logins from database users; dbo is not a server-level sysadmin role.

Parameters

• -M enum_links — enumerate linked servers configured on the authenticated instance.
• -M enum_impersonate — list SQL principals that the current login can impersonate in supported NetExec releases.
• -M exec_on_link — execute a SQL query through a chosen linked server.
• LINKED_SERVER= — linked server identifier returned by enumeration.
• COMMAND= — SQL statement sent through that link; use harmless identity/context queries first.

Interpretation

Create a chain such as DOMAIN\\user → SQL01 login → impersonated login or database-user context → SQL02 linked server → service account/host boundary. A linked server by itself is not a vulnerability; dangerous inherited context or tier crossing is.

If unsuccessful

No usable impersonation/link path for that login. Record tested instances and continue other AD paths.

Additional evidence

• source SQL instance
• authenticated Windows/SQL login
• effective server/database role
• impersonatable login(s)
• linked server(s)
• remote execution context from harmless @@servername/identity query

Finding logic

Report excessive SQL impersonation or linked-server trust when it crosses intended privilege boundaries. Enabling xp_cmdshell is configuration-changing and should not be the default proof.

Next

• Re-run AD-MSSQL-01 against newly exposed server contexts
• AD-AUTH-01 if reusable service-account credentials are obtained
• AD-LAT-01 only when OS execution is explicitly needed and approved

18. LAPS and gMSA

AD-LAPS-01 — Identify principals that can read LAPS passwords

Status: CURRENT

Entry state: S4 or S7
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Determine whether the owned principal can read Windows LAPS or legacy Microsoft LAPS passwords for computers.

Prerequisites

Directory access to computer objects and the appropriate password-read/decryption rights. Windows LAPS encrypted values require more than ordinary attribute readability.

Commands

NetExec LDAP module

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' -M laps

NetExec host use

1

nxc smb '<target>' -d '<domain>' -u '<reader>' -p '<password>' --laps

Parameters

Distinguish legacy ms-Mcs-AdmPwd, Windows LAPS cleartext JSON (msLAPS-Password) and encrypted values (msLAPS-EncryptedPassword). Record the managed local account name. Attribute readability does not imply decryption of encrypted Windows LAPS data; the tool must support that path and the principal must be authorized.

Interpretation

Each readable local administrator password is a host-scoped credential unless reuse/misconfiguration proves otherwise. Map exactly which principal can read which computer password.

If unsuccessful

No readable LAPS values for the current identity.

Finding logic

Excessive LAPS read delegation can create lateral-movement paths; LAPS itself is a security control, not a weakness.

Next

• Validate only on the matching host
• Map local admin access and privileged sessions
• Re-run graph with newly controlled host

Reference

• https://github.com/Pennyw0rth/NetExec/blob/main/nxc/modules/laps.py

AD-GMSA-01 — Read gMSA managed passwords

Status: CURRENT

Entry state: S4 or S7
Result type: CREDENTIAL
Risk of execution: LOW

Goal

Determine whether the current principal can read msDS-ManagedPassword for a group managed service account and derive usable Kerberos/NT credentials.

Prerequisites

Readable gMSA objects and effective managed-password retrieval rights, normally exercised over a protected LDAP connection.

Commands

NetExec

1

nxc ldap '<dc_fqdn>' -d '<domain>' -u '<user>' -p '<password>' --gmsa

gMSADumper

1

gMSADumper.py -u '<user>' -p '<password>' -d '<domain>' -l '<dc_fqdn>'

Parameters

Interpretation

Derived managed-password material is a credential for the gMSA. Determine its group memberships, SPNs, local rights and service hosts before using it.

If unsuccessful

Current principal cannot read relevant gMSA passwords.

Finding logic

Overbroad gMSA read permissions are reportable when the service account has material privilege.

Next

• AD-AUTH-01
• AD-KRB-04/service-account privilege mapping
• BloodHound

Status: CURRENT

Entry state: S4–S5
Result type: CANDIDATE
Risk of execution: LOW for discovery / HIGH for credential extraction

Goal

Identify Microsoft Entra Connect / legacy Azure AD Connect synchronization infrastructure because compromise of a synchronization server can bridge on-premises AD and cloud identity. Do not assume every sync deployment has the same credential material or privilege model; versions and sync modes matter.

Prerequisites

Directory inventory or host access to a suspected sync server; establish whether Entra Connect Sync or a different synchronization product is used.

Directory/host indicators

• Server naming/description referring to Entra Connect, Azure AD Connect, AADConnect, ADSync or synchronization.
• Windows service ADSync on a suspected server.
• Microsoft Azure AD Sync / Microsoft Entra Connect Sync installation artifacts.
• SQL LocalDB/SQL instance and ADSync configuration associated with the sync engine.
• Directory accounts historically associated with synchronization, while recognizing that naming conventions have changed across versions/deployments.

Commands on an approved suspected host

1

Get-Service ADSync -ErrorAction SilentlyContinue

1

Get-CimInstance Win32_Service -Filter "Name='ADSync'" | Select-Object Name,State,StartName,PathName

1

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue | Where-Object { $_.DisplayName -match 'Entra Connect|Azure AD Connect|Azure AD Sync' } | Select-Object DisplayName,DisplayVersion,InstallLocation

Interpretation

Treat the server as a high-value identity-system asset. Determine sync mode, service identity, local administrators, database location and cloud/on-premises privileges before any extraction attempt.

If unsuccessful

No sync engine found on the tested host. Continue searching inventory/CMDB/AD descriptions only if hybrid identity is known to be in scope.

Additional evidence

• sync server FQDN
• product/version
• ADSync service identity
• local admin principals
• sync mode if known
• cloud tenant identifier if in scope

Finding logic

Presence of Entra Connect is not a finding. Weak local administrative boundaries, exposed sync credentials, excessive service-account rights or an attack path from ordinary users into the sync server can be critical.

Next

• AD-BH-02 — identify who can administer/log on to the sync server
• AD-LAT-01 — validate access only with authorized credentials
• AD-CRED-01/AD-CRED-02 only if credential extraction from this identity-system asset is explicitly approved

AD-DMSA-01 — Delegated Managed Service Account posture and BadSuccessor-era permissions

Status: CURRENT

Entry state: S4
Result type: CANDIDATE
Risk of execution: LOW for read-only inventory

Goal

Identify delegated Managed Service Accounts (dMSAs) in Windows Server 2025 environments and review who can create, migrate, link or control them. The 2025 BadSuccessor direct escalation path was assigned CVE-2025-53779 and patched; do not assume an unpatched-era technique applies to a maintained environment.

Prerequisites

Directory visibility and DC build/schema inventory. Assess Windows Server 2025 support and patch state even if no existing dMSA is found.

Commands

Read-only Active Directory inventory

1

Get-ADServiceAccount -Filter * -Properties 'msDS-DelegatedMSAState','msDS-ManagedAccountPrecededByLink','PrincipalsAllowedToRetrieveManagedPassword' | Select-Object Name,ObjectClass,DistinguishedName,'msDS-DelegatedMSAState','msDS-ManagedAccountPrecededByLink',PrincipalsAllowedToRetrieveManagedPassword

Review ownership and delegated rights on containers/OUs that can host service accounts

Use the AD: security-descriptor inspection in AD-ACL-05 for each candidate dMSA and its parent container. Include object-creation rights even where the container currently has no dMSA objects.

Interpretation

A dMSA object is architecture information. Security relevance comes from effective rights: who can create or modify dMSA objects, control migration/link attributes, retrieve managed credentials, or control the OU/container in which those objects live.

If unsuccessful

Absence of existing dMSAs does not by itself exclude a dMSA-creation path. Record DC versions, schema support, patch state and object/container creation rights. Mark the specific historical exploit inapplicable only when its prerequisites are demonstrably absent or patched; assess ordinary delegated control separately.

Additional evidence

• dMSA DN/SID
• migration state/link attributes
• password-retrieval principals
• owner/DACL of the dMSA and parent container
• DC build and CVE-2025-53779 patch state where relevant

Finding logic

Do not report dMSA deployment itself. Report unintended object/container control, credential-read rights, or an actually reachable escalation path. Treat old BadSuccessor PoCs as version-specific and gated by patch state.

Next

• AD-ACL-01 for exact object/container control.
• AD-AUTH-01 only if a reusable service-account credential is legitimately obtained.
• AD-BH-02 for the resulting graph path.

Reference

• https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview

19. Trusts, domains and forest boundaries

AD-TRUST-01 — Enumerate domain and forest trusts

Status: CURRENT

Entry state: S4
Result type: INFORMATION
Risk of execution: LOW

Goal

Map trust direction, type, transitivity, SID filtering and reachable domains before attempting cross-domain paths.

Prerequisites

Authenticated access to trusted-domain objects in each permitted domain and the ActiveDirectory module for the PowerShell examples.

Commands

PowerShell trust inventory — ActiveDirectory module

1

Get-ADTrust -Filter * -Properties * | Format-List Name,Source,Target,Direction,TrustType,ForestTransitive,SelectiveAuthentication,SIDFilteringForestAware,SIDFilteringQuarantined

Direct LDAP query — trusted-domain objects are stored below the domain System container

1

ldapsearch -LLL -x -H 'ldaps://<dc_fqdn>' -D '<user>@<domain>' -W -b 'CN=System,<base_dn>' '(objectClass=trustedDomain)' cn flatName trustPartner trustDirection trustType trustAttributes securityIdentifier msDS-SupportedEncryptionTypes

Parameters and attributes

• Get-ADTrust -Filter * — returns trusted-domain objects visible to the current directory context.
• -Properties * — requests non-default trust properties so direction/filtering information is not silently omitted.
• trustDirection — direction encoded on the TDO; interpret it from the perspective of the domain that stores the object.
• trustType — trust implementation/type, not a privilege level.
• trustAttributes — bit field describing properties such as forest-transitive or quarantined behavior.
• securityIdentifier — SID of the trusted domain where present.
• CN=System,<base_dn> — documented location of trusted-domain objects in the domain naming context.

Interpretation

Create a trust matrix. Direction matters: a trust object does not mean the current domain can authenticate everywhere. Record selective authentication and SID filtering.

If unsuccessful

No additional trust visible; confirm forest root/child domains through naming contexts/GC.

Finding logic

Trust relationships are architectural facts. Weak SID filtering, overbroad cross-trust ACLs or privileged credential reuse become findings.

Next

• Collect BloodHound data in each permitted domain
• Search cross-domain ACL/group membership and local admin edges
• If child-domain compromise exists, assess parent escalation prerequisites

Alternative branch

• Continue current-domain coverage

AD-TRUST-02 — Validate cross-domain and forest attack paths

Status: CURRENT

Entry state: S4–S9
Result type: ATTACK PATH
Risk of execution: LOW for mapping / HIGH for cross-domain escalation proof

Goal

Convert a discovered trust into a concrete path: which identity from which source domain can authenticate to which target resource, under which filtering/authentication constraints, and what effective privilege results?

Prerequisites

Known trust direction, SIDs, filtering and selective-authentication conditions; in-scope source and destination resources.

Validation order

1. Establish trust direction from the TDO perspective.
2. Record SelectiveAuthentication, SID filtering/quarantine and forest-transitive properties.
3. Collect domain SIDs and privileged group SIDs separately for every domain.
4. Identify cross-domain group membership, foreign-security principals and ACLs.
5. Check Allowed to Authenticate where selective authentication is enabled.
6. Validate service access with an existing authorized identity before attempting ticket manipulation.
7. Treat child-to-parent, SIDHistory/ExtraSIDs and ticket-forging techniques as separate high-impact proofs, not assumptions.

Useful PowerShell inventory

1

Get-ADForest | Format-List RootDomain,Domains,GlobalCatalogs,Sites

1

Get-ADDomain | Format-List DNSRoot,DomainSID,ParentDomain,ChildDomains,PDCEmulator

1

Get-ADTrust -Filter * -Properties * | Format-Table Source,Target,Direction,TrustType,ForestTransitive,SelectiveAuthentication,SIDFilteringForestAware,SIDFilteringQuarantined -AutoSize

Interpretation

A trust becomes security-relevant when the owned identity can cross it and obtain access/control that violates the intended tier/domain boundary. Record the complete identity translation and authorization edge.

If unsuccessful

A trust that exists but does not produce useful authorization for the tested identity remains architecture information, not a finding.

Additional evidence

• source/target domain and SIDs
• trust direction/type/attributes
• source identity SID
• target resource/object
• authorization edge/group/ACE
• authentication result
• resulting privilege

Finding logic

Report the concrete cross-boundary authorization weakness. Avoid generic findings such as “domain trust exists”.

Next

• AD-BH-02 in the target domain/forest
• AD-AUTH-01 for any newly usable identity
• AD-LAT-01 for authorized service/host access

Alternative branch

• Continue current-domain coverage

19.1 Cross-domain escalation rules

• The forest, not an individual domain within it, is the AD security boundary. Treat full control of a writable child-domain DC as a forest-level risk. Validate the concrete escalation mechanism rather than assuming every historical ExtraSIDs command will work. Cross-forest trusts are a separate boundary with different filtering rules.
• Golden-ticket ExtraSIDs/SIDHistory-style escalation is a high-impact proof and should be attempted only when explicitly approved.
• External/forest trusts may expose resources without granting directory control. Enumerate actual ACLs and local rights across the trust.
• Selective authentication can prevent logon even when a trust exists; “Allowed to Authenticate” becomes a relevant ACL.
• When forest control is already demonstrated through a safer path, do not execute additional ticket-forging paths solely for completeness.

20. Host access and lateral movement

AD-LAT-01 — Determine remote management paths

Status: CURRENT

Entry state: S3–S6
Result type: ACCESS
Risk of execution: LOW

Goal

Identify where the current credential has interactive or administrative access over SMB, WinRM, WMI, RDP or MSSQL without immediately executing commands.

Prerequisites

Previously validated credential and a scoped target list derived from identity-to-host relationships. Authentication sweeps can create failed-logon events and lockout risk.

Commands

SMB privilege sweep

1

nxc smb '<CIDR>' -d '<domain>' -u '<user>' -p '<password>'

WinRM privilege sweep

1

nxc winrm '<CIDR>' -d '<domain>' -u '<user>' -p '<password>'

RDP auth check

1

nxc rdp '<CIDR>' -d '<domain>' -u '<user>' -p '<password>'

Interpretation

Record each host/protocol and administrative status. Prefer the least invasive management protocol if a shell is required.

If unsuccessful

Credential may still have application/database/share rights even with no remote shell.

Finding logic

Lateral-movement ability is usually the consequence of excessive privilege/credential reuse, not a standalone protocol finding.

Next

• AD-HOST-01 — local privilege and secret sources
• Update BloodHound owned hosts

Alternative branch

• Return to directory-level paths

AD-LAT-02 — Pass-the-Hash / Kerberos ticket reuse

Use the single canonical validation procedure in AD-AUTH-01, selecting the NT-hash or Kerberos-cache variant. Chapter 24 maps each credential type to its restrictions. This branch does not require repeating authentication sweeps already recorded for the same identity, host and protocol.

After success, record only newly demonstrated host/service access and continue with AD-HOST-01. After failure, check credential type, ticket lifetime/SPN, NTLM restrictions and target authorization before attempting another protocol.

21. Local privilege escalation on Windows

AD-HOST-01 — Local privilege and configuration audit

Status: CURRENT

Entry state: S5
Result type: CANDIDATE
Risk of execution: LOW

Goal

On an authorized shell, inventory token privileges, services, scheduled tasks, writable paths, UAC/AppLocker/WDAC policy and local administrators before using exploit code.

Prerequisites

A Windows shell in the identity being assessed, a reviewed local PrivescCheck copy and a record of elevation state.

Commands

Identity/token

1

whoami /all

Local groups

1
2

whoami /groups
Get-LocalGroupMember -SID 'S-1-5-32-544'

Privilege audit

1

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command ". .\PrivescCheck.ps1; Invoke-PrivescCheck"

For application-control policy, continue with AD-HOST-03 after recording the current token.

Run the privilege audit in the user context whose boundary is being assessed. PrivescCheck deliberately skips or gates checks when elevated to avoid misleading ACL results. ExecutionPolicy Bypass affects that process policy; it is not a bypass of WDAC, AppLocker or every enforced policy.

Interpretation

A concrete local misconfiguration/privilege becomes a candidate. Validate it manually before exploitation.

If unsuccessful

No obvious local privilege path; search credential material and domain privileges rather than spraying local exploits.

Finding logic

Report the underlying service/file/registry/privilege misconfiguration, not merely the output of an automated PEAS-style tool.

Next

• AD-HOST-02 — SeImpersonate if present
• Service/task/path-specific proof
• AD-CRED-01 — credentials if admin is achieved

Alternative branch

• AD-SHARE-01/AD-ACL-01 from domain context

AD-HOST-02 — SeImpersonate / SeAssignPrimaryToken privilege

Status: CURRENT

Entry state: S5
Result type: ACCESS
Risk of execution: HIGH

Goal

Determine whether a service account token privilege can be converted to SYSTEM through an appropriate local impersonation primitive.

Prerequisites

A service/token context holding the relevant privilege and an OS-compatible local authentication/impersonation primitive. A present but disabled privilege may still be enableable by the process.

Commands

Confirm privilege

1

whoami /priv

Interpretation

Possession of a relevant token privilege is a prerequisite, not proof of SYSTEM access. A disabled privilege is not necessarily absent: a process may be able to enable a privilege already present in its token. Select a technique compatible with OS patch level and service context; prove SYSTEM with a benign command.

If unsuccessful

Do not run potato-family exploits without the prerequisite privilege/path.

Finding logic

Excessive service-account local privilege can be reportable; severity depends on the initial access boundary and host value.

Next

• Use one scope-approved contemporary technique such as PrintSpoofer/GodPotato only after validating compatibility
• After SYSTEM: AD-CRED-01 if credential access is authorized

Alternative branch

• Check service DACLs, scheduled tasks, writable binaries, installer policies and credentials

Operational notes

• Potato-family exploit compatibility changes with Windows builds and mitigations; installed tool documentation and OS validation are mandatory.

AD-HOST-03 — UAC, AppLocker and WDAC boundary assessment

Status: CURRENT

Entry state: S5
Result type: CANDIDATE
Risk of execution: LOW for policy inventory / HIGH for bypass validation

Goal

Determine whether UAC token boundaries and application-control policy materially restrict the current compromised context before selecting any local bypass technique. Avoid generic “UAC bypass” or “AppLocker bypass” testing without first proving the relevant policy/token condition.

Prerequisites

A Windows shell and access to the effective application-control/token policy for the tested context.

Commands

Reuse the token inventory from AD-HOST-01; recollect only if the process identity or elevation state changed.

UAC policy

1

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA

Effective AppLocker policy

1

Get-AppLockerPolicy -Effective | Format-List

Device Guard / WDAC-related state

1

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Format-List *

Interpretation

Separate the questions:

• Is the current identity already a local administrator but running with a filtered/non-elevated token?
• Is UAC enabled and what elevation boundary applies to this session?
• Is AppLocker/WDAC actually enforced for the executable/script type and user context being tested?
• Does an allowed execution path cross the intended security boundary?

A policy gap is a candidate until an unauthorized execution/elevation outcome is demonstrated.

If unsuccessful

No useful policy/token gap was identified. Do not cycle through public bypasses merely for completeness; continue service/task/path and credential/domain paths.

Additional evidence

• user SID/group membership
• token integrity/elevation state
• UAC configuration
• effective AppLocker rules
• WDAC/Device Guard state
• exact allowed/blocked execution test if one is performed

Finding logic

UAC is not a security boundary equivalent to separate credentials, and membership in local Administrators is not itself a UAC vulnerability. Report an application-control or privilege-boundary weakness only when policy intent is clear and the tested context can cross it in a security-relevant way.

Next

• Use one build/policy-compatible proof that demonstrates the minimum required execution/elevation impact.
• If SYSTEM/admin is reached: AD-CRED-01 only when credential access is approved.

22. Credential extraction and sensitive Windows material

AD-CRED-01 — SAM / LSA / cached credentials

Status: CURRENT

Entry state: S8
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

When administrative access is explicitly in scope, determine whether local registry secrets reveal local password hashes, service secrets or cached domain logons.

Prerequisites

Administrative access to the selected member host and required remote registry/SMB access, or already acquired matching SAM/SECURITY/SYSTEM hives.

Commands

Remote Impacket

1

impacket-secretsdump '<domain>/<user>:<password>@<target>'

Offline hives

1

impacket-secretsdump -sam SAM -security SECURITY -system SYSTEM LOCAL

Parameters

Interpretation

Classify each artifact: local NT hash, LSA secret, cached domain credential, machine-account secret. Do not assume every output line is reusable over the network.

If unsuccessful

Protection, permissions, credential isolation or missing hives prevented extraction.

Finding logic

Credential material accessible from a compromised low-tier host becomes important when it crosses tiers or is reused elsewhere.

Next

• AD-LAT-02 for reusable hashes
• AD-DPAPI-01 for DPAPI-linked secrets
• Re-run BloodHound for newly compromised identities

Alternative branch

• AD-DPAPI-01
• Ticket/certificate stores

Reference

• https://github.com/fortra/impacket

AD-CRED-02 — LSASS credential material

Status: CURRENT

Entry state: S8
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

If explicitly permitted, determine whether an administrative compromise exposes reusable logon secrets/tickets in LSASS despite Credential Guard and modern protections.

Prerequisites

Administrative host access, recorded Credential Guard/PPL state and a selected collection method compatible with the build and engagement limits.

Commands

Reuse the Device Guard query from AD-HOST-03 and preserve the protection state before selecting a collection method.

Check SecurityServicesRunning for Credential Guard and investigate LSASS PPL separately. Device Guard status alone does not prove that LSASS dumping is blocked. If no collection attempt was made, record PREREQUISITES_REVIEWED, not TESTED_NO_FINDING.

Interpretation

Any recovered cleartext/hash/ticket must be tied to a logon session, user, source host and privilege. Stop after obtaining sufficient proof; do not dump every endpoint.

If unsuccessful

An actual collection failure needs attribution: Credential Guard, PPL, EDR, permissions, tool incompatibility and absence of useful sessions are different outcomes. Only an observed and explained protection result supports a positive control conclusion.

Finding logic

The report should focus on why a lower-trust compromise exposed higher-trust credentials, not on “Mimikatz worked”.

Next

• Validate only the highest-value newly exposed identity
• Update attack graph

Alternative branch

• DPAPI, service secrets, tickets and application credential stores

Operational notes

• This playbook intentionally does not prescribe a single LSASS-dumping binary because tool/EDR interaction changes quickly and may be disruptive.

AD-CRED-03 — Search accessible host data for configuration secrets

Status: CURRENT

Entry state: S5
Result type: CANDIDATE
Risk of execution: LOW when scoped and read-only

Goal

Search locations already accessible to the current user for credentials, tokens, connection strings and deployment secrets before moving to memory dumping. File/configuration exposure is often safer to prove and easier to remediate than invasive credential extraction.

Prerequisites

Access to the selected user/application locations; inventory readable paths before content collection.

High-value locations

• user profile documents/scripts/history
• PowerShell history
• unattended/setup files
• application/web configuration files
• scheduled-task scripts
• deployment/automation scripts
• mapped shares and locally cached configuration
• browser/application credential stores, with DPAPI handling delegated to AD-DPAPI-01

Commands

1

Get-ChildItem "$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine" -Force -ErrorAction SilentlyContinue

1

Get-ScheduledTask | Select-Object TaskName,TaskPath,State,@{N='User';E={$_.Principal.UserId}},@{N='RunLevel';E={$_.Principal.RunLevel}}

1

Get-CimInstance Win32_Service | Select-Object Name,StartName,PathName,State

For content searching, restrict patterns and directories to the engagement scope; avoid recursive whole-disk searches on production servers without need.

Interpretation

Classify each secret by type and owner, then validate it through AD-AUTH-01 rather than blindly reusing it. A path or username alone is information; a readable reusable secret is credential exposure.

If unsuccessful

No obvious accessible file/config secret found. Continue DPAPI or other explicitly approved credential paths only when justified.

Additional evidence

• file/config path
• owner/ACL
• secret type, redacted in ordinary notes
• identity/service associated with it
• validation result

Finding logic

Readable reusable credentials/tokens by an unintended principal are normally reportable. Severity depends on reachable privilege and reuse.

Next

• AD-AUTH-01
• AD-DPAPI-01 if the secret is DPAPI-protected

23. DPAPI

AD-DPAPI-01 — DPAPI master keys and application secrets

Status: CURRENT

Entry state: S5–S8 or scoped offline evidence

Result type: CREDENTIAL

Risk of execution: HIGH for live secret collection; offline parsing does not modify the source host

Goal

Determine whether an already accessible protected secret can be decrypted, preserving the link between blob, master key, owner and decryption prerequisite.

Prerequisites

A selected blob, its matching master-key file and an applicable decryption route. Identify user versus machine/SYSTEM context before choosing keys. A domain user backup key is not a substitute for machine DPAPI material; newer application-specific protection can add further conditions.

Procedure

1. Record the application, owner SID, source paths and master-key GUID. Work on a copy of the selected evidence.
2. Select the existing decryption prerequisite: user password/hash where applicable, recovered master key, domain backup key for backed-up user master keys, or machine-context material.
3. Decrypt the matching master key, then only the selected artifact type. Do not run all-user triage merely to answer a one-credential question.
4. Record recovered material in the protected inventory and return to AD-AUTH-01 if authentication validation is relevant.

Commands — offline examples

Decrypt a domain-user master-key file using an already obtained domain backup key:

1

impacket-dpapi masterkey -file '<masterkey_file>' -pvk '<domain_backup_key.pvk>'

Decrypt a Credential Manager file with its recovered master key:

1

impacket-dpapi credential -file '<credential_file>' -key '<decrypted_masterkey_hex>'

masterkey and credential are different input formats. The -key value above is recovered key material, not the account NT hash or the .pvk filename. Preserve any application-specific entropy requirement when parsing generic DPAPI blobs.

Live collection alternative

NetExec exposes --dpapi in nxc smb --help; it is not established by searching the module list with -L. Its collection scope may include multiple profiles and secrets. dploot has separate user, machine and artifact-specific subcommands. Choose one that matches the agreed evidence scope and the installed version; a help command alone is not a completed DPAPI assessment.

Interpretation and evidence

Successful decryption proves exposure of the selected secret under the documented key/access conditions. Failure can mean mismatched files, missing keys/entropy or additional protection, not a general absence of recoverable secrets. Record source owner/path, GUID, key provenance, artifact type and a redacted result. DPAPI itself is not a vulnerability; report the access or tier-separation failure that made the secret available.

Next

AD-AUTH-01 for usable credentials; AD-CERT-01 for certificates/private keys; AD-DPAPI-02 only if domain backup-key acquisition is separately required.

References

• Impacket DPAPI implementation, 0.13.1
• dploot
• Microsoft: domain DPAPI backup keys

AD-DPAPI-02 — Domain DPAPI backup key

Status: CURRENT

Entry state: S9
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

When Tier-0/domain-level access is already proven and extraction is explicitly approved, determine whether the domain DPAPI backup key can be obtained as impact evidence. This key can recover backed-up DPAPI master keys for domain users, with broad retrospective exposure implications. It is not a universal machine/SYSTEM DPAPI decryption key; machine-context recovery uses separate material such as DPAPI_SYSTEM.

Prerequisites

Domain Administrator-equivalent backup-key retrieval rights, a selected DC and a protected destination for the exported key.

Commands

1

dploot backupkey -d '<domain>' -u '<admin>' -p '<password>' -t '<dc_fqdn_or_ip>'

Parameters

Interpretation

The exported domain backup key (commonly written as key.pvk) is Tier-0 credential material. Possession materially broadens the ability to decrypt DPAPI-protected data for domain users when the corresponding backed-up master keys and protected blobs are available. Do not bulk-decrypt client data merely because the key was obtained.

If unsuccessful

The current identity/path could not retrieve the backup key. Do not weaken controls or repeat invasive retrieval attempts once domain impact is otherwise established.

Additional evidence

• domain/DC
• identity used and privilege basis
• protected evidence reference for the exported key
• tool/version
• one minimal authorized decryption proof if required

Finding logic

Obtaining the backup key with legitimate Domain Admin-equivalent rights is usually impact evidence of Tier-0 compromise, not a separate vulnerability. The underlying finding is the path that provided those rights. If a lower-trust identity can retrieve it, that permission failure is independently critical.

Next

• Stop broad collection.
• If required, validate one scoped DPAPI artifact with AD-DPAPI-01.
• Treat dependent exposed secrets as rotation candidates during remediation.

Alternative branch

• Continue only the credential paths needed to prove the already identified finding.

Reference

• https://github.com/zblurx/dploot

24. Credential-type routing

AES-key-to-TGT conversion

1

impacket-getTGT -aesKey '<aes_key>' '<domain>/<user>' -dc-ip '<dc_ip>'

Inspect an existing cache

1
2

export KRB5CCNAME='/secure/path/user.ccache'
klist

Convert a Kerberos credential container when needed

1

impacket-ticketConverter '<ticket.kirbi>' '<ticket.ccache>'

Conversion changes the container, not the ticket principal, privileges, service scope or validity. Preserve the original file and verify the converted cache before reuse.

AD-CERT-01 — Certificate credential handling: PKINIT, Schannel and identity mapping

Status: CURRENT

Entry state: S6
Result type: CREDENTIAL
Risk of execution: MEDIUM

Goal

Given a PFX or certificate/private-key pair, determine which AD identity it maps to and whether it provides Kerberos PKINIT and/or LDAP Schannel authentication under the environment’s current certificate-mapping policy.

Prerequisites

Certificate and matching private key; an issuer trusted for the relevant authentication purpose and a compatible identity mapping.

Commands

Inspect the public certificate without exporting the private key

1
2

certipy cert -pfx 'identity.pfx' -nokey -out 'identity.crt'
openssl x509 -in 'identity.crt' -noout -text

Attempt certificate authentication

1

certipy auth -pfx '<identity.pfx>' -dc-ip '<dc_ip>'

For the public certificate export, -nokey suppresses private-key output and -out chooses the file. openssl x509 -noout -text displays decoded certificate fields. A bare certipy cert -pfx ... may export the private key to stdout and is not the inspection recipe.

For a certificate compatible with LDAP Schannel mapping, the explicit alternative is:

1

certipy auth -pfx '<identity.pfx>' -dc-ip '<dc_ip>' -ldap-shell

An LDAP shell is authenticated access, not an authorization to modify arbitrary objects. PKINIT failure does not establish Schannel success; evaluate each mapping path independently.

Parameters

Interpretation

Successful certificate authentication proves the certificate is a reusable credential for the mapped AD identity. If the workflow returns a TGT or NT-hash-equivalent material, inventory each artifact separately; they have different use and lifetime.

If unsuccessful

Failure may come from certificate expiration/revocation, missing authentication EKU/application policy, account mapping, strong certificate binding, absent PKINIT support, wrong CA trust, DNS/time or a mismatch between certificate and private key. It does not automatically invalidate the original AD CS misconfiguration.

Additional evidence

• PFX evidence reference, never inline secret in notes
• subject and SAN
• issuer and serial number
• template if known
• validity period
• EKU/application policies
• mapped principal
• authentication method and result

Finding logic

A certificate is credential material. The reportable weakness is normally how an unauthorized principal obtained an authentication-capable certificate/private key or why mapping allowed impersonation.

Next

• Store resulting TGT/ccache/hash as separate credential records.
• AD-AUTH-01 — validate only necessary target access.
• Re-run BloodHound/ACL analysis as the certificate-backed principal.

Alternative branch

• Re-check the exact AD CS ESC/mapping prerequisites.
• Test Schannel/PKINIT only when the certificate characteristics support that path.
• Do not repeatedly request new certificates without understanding the failed mapping.

Reference

• https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference

AD-CERT-02 — Discover certificates and private-key material on an accessed host

Status: CURRENT

Entry state: S5
Result type: CANDIDATE
Risk of execution: LOW for inventory / HIGH for private-key export

Goal

Identify authentication-capable certificates already present on a compromised/authorized host before requesting new certificates. Existing certificates can outlive passwords and may map to privileged users, computers or services.

Prerequisites

Access to the intended certificate store. Certificate visibility, key presence, key usability and key exportability are separate questions.

Commands

Current-user certificate store

1

Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject,Issuer,Thumbprint,NotBefore,NotAfter,HasPrivateKey,EnhancedKeyUsageList

Local-machine certificate store — requires rights to read the relevant store

1

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Issuer,Thumbprint,NotBefore,NotAfter,HasPrivateKey,EnhancedKeyUsageList

Native certificate-store view

1

certutil -user -store My

1

certutil -store My

Interpretation

For each certificate, map subject/SAN, EKUs, validity, private-key availability and identity mapping. HasPrivateKey=True does not automatically mean the key is exportable or usable by the current process.

If unsuccessful

No relevant certificate in the tested store/context. Continue AD CS enrollment analysis rather than searching arbitrary private-key files without scope.

Additional evidence

• store/location
• subject/SAN
• issuer/CA
• thumbprint
• EKUs/application policies
• validity period
• private-key presence/exportability if explicitly tested
• mapped AD identity

Finding logic

A certificate existing on its intended host is not a finding. Unintended read/export access, weak private-key protection or a certificate that enables privilege beyond the host/user boundary can be reportable.

Next

• AD-CERT-01 — determine PKINIT/Schannel use and mapping
• AD-AUTH-01 — tag the certificate credential and identity
• AD-PERSIST-02 only when persistence implications need to be documented

Alternative branch

• Continue remote-execution/domain-dominance decision tree

25. Remote execution: prove, do not over-execute

Once administrative access is established, prefer the execution mechanism that is least disruptive and easiest to attribute/clean. The goal is usually to prove the access boundary, not deploy a payload.

26. Domain replication and domain-dominance primitives

AD-DOM-01 — DCSync rights validation

Status: CURRENT

Entry state: S7–S9
Result type: CREDENTIAL
Risk of execution: HIGH

Goal

Determine whether the controlled principal has directory replication rights sufficient to request password replication data.

Prerequisites

Effective replication rights on the domain naming context, reachable DRS RPC and a named test account. Inspect Replicating Directory Changes and Replicating Directory Changes All; filtered-set behavior can add conditions.

Commands

Targeted proof

1

impacket-secretsdump -just-dc-user '<authorized_test_account>' '<domain>/<user>:<password>@<dc_fqdn>'

Parameters

Interpretation

Successful replication of a single approved account proves DCSync capability. Avoid a full -just-dc dump unless the engagement explicitly needs it.

If unsuccessful

The principal lacks required replication rights, DRS path is blocked, or authentication context is insufficient.

Finding logic

Unintended DCSync capability is generally critical because it can expose domain credential material without code execution on a DC.

Next

• Stop after minimum proof unless full credential-impact validation is explicitly required
• Identify the ACE/group granting replication rights
• Preserve targeted evidence

Alternative branch

• Return to ACL/domain-object control and other tier-0 paths

Reference

• https://github.com/fortra/impacket

AD-DOM-02 — Full-domain credential collection

Status: CURRENT

Entry state: S9
Result type: CREDENTIAL
Risk of execution: HIGH — full-domain credential collection

Goal

If DC administrative compromise is already proven and extraction is explicitly in scope, obtain directory credential material through an approved remote/offline method.

Prerequisites

A justified full-domain collection requirement and effective replication rights for the shown method. Offline database extraction is a separate workflow.

Commands

Remote method only when approved

1

impacket-secretsdump '<domain>/<admin>:<password>@<dc_fqdn>' -just-dc

Parameters

Interpretation

Directory hashes/keys prove full credential compromise. At this point additional escalation is usually unnecessary; move to impact/reporting.

If unsuccessful

Use the failure to identify protections/permissions rather than trying multiple disruptive extraction approaches by default.

Finding logic

A path that allowed an initially low-privileged actor to reach this stage is the main finding; “NTDS dumped” is impact evidence.

Next

• Stop uncontrolled credential collection
• Document affected scope and reset/remediation implications

Alternative branch

• If domain control is otherwise proven, do not force an extraction solely for completeness

27. Ticket forging and persistence

Persistence techniques belong in the playbook because compromise assessment is incomplete if long-lived trust material is ignored. In a normal penetration test, demonstrate prerequisites and impact rather than leaving persistence. Forged tickets, certificate trust, replication-based changes and LSASS/DC modifications have very different prerequisites and cleanup implications; treat them as separate capabilities rather than interchangeable “persistence”.

AD-PERSIST-01 — Golden ticket prerequisite validation

Status: CURRENT

Entry state: S9
Result type: ACCESS
Risk of execution: LOW for existing-evidence review; HIGH for live forging

Goal

Understand whether compromise of the krbtgt key plus the domain SID would permit forged TGTs.

Prerequisites

Attributable current krbtgt key material and correct domain identity. Record key version and encryption type; do not imply that a specific forged ticket has been accepted without testing it.

Commands

Prerequisite inventory only

Record the domain SID and whether current krbtgt key material was legitimately obtained during the approved test. Do not forge a ticket by default.

Interpretation

Possession of the relevant current krbtgt key and domain context establishes compromise of the ticket-signing trust. A particular accepted forged TGT still depends on valid account/PAC and current KDC/service validation conditions. A live forged ticket is usually unnecessary once those prerequisites are proven.

If unsuccessful

Without the correct krbtgt material, this persistence path is unavailable.

Finding logic

Exposure of krbtgt material means domain-wide Kerberos trust is compromised and normally requires a controlled double reset during remediation.

Next

• Move to report/incident-style remediation guidance
• Only forge a test ticket if explicitly required by scope

Alternative branch

• Other persistence classes should not be tested merely to “have one”

AD-PERSIST-02 — Certificate-based persistence and Golden Certificate prerequisites

Status: CURRENT

Entry state: S6 or S9
Result type: CREDENTIAL
Risk of execution: LOW for existing-evidence review; HIGH for key export or forging

Goal

Determine whether long-lived authentication certificates or CA private-key compromise could survive password resets, and whether compromise of a CA signing private key would create Golden Certificate capability.

Prerequisites

An existing authentication certificate/private key or independently established access to a trusted CA signing key.

Commands

Use AD-CERT-01 for certificate inspection and AD-CERT-02 for host-store discovery. Record issuer, serial, validity, mapping, key access and revocation behavior once; reference that evidence here.

Interpretation

A valid authentication certificate/private key can remain usable until expiry, revocation or mapping changes. Compromise of the CA signing private key is substantially broader: it creates Golden Certificate capability, allowing certificates to be forged under an already trusted CA until that trust/key material is remediated.

If unsuccessful

Certificate cannot authenticate under current mapping/protection or has been revoked/expired.

Finding logic

Severity follows the mapped identity and trust scope. A compromised CA signing key can be critical; a single low-privilege user certificate is not automatically a critical finding.

Next

• Record certificate identity/serial/validity
• Coordinate revocation/CA remediation
• Do not issue additional persistence certificates

Alternative branch

• No further persistence action required

Reference

• https://github.com/ly4k/Certipy

27.1 Persistence and forged-credential capability matrix

The following items are coverage targets, not a checklist of payloads to deploy. In production testing, proving the prerequisite secret/right is normally sufficient.

Decision rule

If Domain/Enterprise Admin, DC code execution, CA private-key access or krbtgt material is already demonstrated, additional persistence mechanisms rarely add report value. Record the additional capabilities implied by the obtained control, then stop unless the scope explicitly requires a persistence-resilience exercise.

28. Legacy and version-specific vulnerabilities

Keep this chapter separate from normal AD methodology. First prove that the affected product/version/configuration exists and that vendor mitigations are absent. Many historic AD vulnerabilities are no longer realistic on maintained estates, and running old exploit scripts blindly creates noise and risk.

28.1 Zerologon

Treat a positive scanner as a critical candidate. The classic exploitation flow can alter a DC machine account credential and can disrupt the domain if cleanup fails. Do not execute it simply to prove severity when a non-destructive validated scanner plus patch evidence is sufficient.

28.2 GPP cpassword

Unlike many legacy CVEs, old GPP XML may remain in SYSVOL years after the original patch because the patch prevents creation of new password-bearing preferences but does not magically remove existing files. Keep this read-only check in normal coverage.

29. Hash and credential-material cracking

AD-CRACK-01 — Offline cracking decision

Status: CURRENT

Entry state: S6
Result type: CREDENTIAL
Risk of execution: LOW to the target environment

Goal

Crack only material whose cleartext recovery will answer an engagement question: password quality, reuse, or privilege escalation. First identify the format exactly; similar-looking Windows/Kerberos artifacts are not interchangeable.

Prerequisites

Attributable offline-verifiable material, an exact format and an agreed compute/time/wordlist budget.

Commands

NT hash — Hashcat names mode 1000 NTLM

1

hashcat -m 1000 nt-hashes.txt '<wordlist>'

LM

1

hashcat -m 3000 lm.txt '<wordlist>'

NetNTLMv1

1

hashcat -m 5500 netntlmv1.txt '<wordlist>'

NetNTLMv2

1

hashcat -m 5600 netntlmv2.txt '<wordlist>'

MS Cache 2 / DCC2

1

hashcat -m 2100 dcc2.txt '<wordlist>'

AS-REP etype 23

1

hashcat -m 18200 asrep.txt '<wordlist>'

Kerberoast TGS etype 23 / RC4

1

hashcat -m 13100 tgs-etype23.txt '<wordlist>'

Kerberos TGS etype 17 / AES128

1

hashcat -m 19600 tgs-etype17.txt '<wordlist>'

Kerberos TGS etype 18 / AES256

1

hashcat -m 19700 tgs-etype18.txt '<wordlist>'

Timeroast / MS SNTP

1

hashcat -m 31300 --username timeroast.hashes '<wordlist>'

Parameters

Interpretation

Recovered cleartext becomes a credential only after it is tied back to the correct principal/source artifact. Record the originating artifact and never lose the link between cracked password and identity. DCC2/MS Cache 2 and NetNTLM challenge/response material are offline password-verification formats; they are not NT hashes that can simply be passed directly for normal pass-the-hash authentication.

If unsuccessful

“Not cracked” does not mean a strong password; it means the selected attack, masks/rules/wordlist and allotted effort did not recover it. Record the effort rather than converting a cracking failure into a security conclusion.

Additional evidence

• material type/mode
• principal and source artifact
• cracking strategy and runtime/effort
• recovered cleartext in protected credential storage
• validation result

Finding logic

Report weak/reused passwords and the account/configuration that exposed offline-verifiable material, not “Hashcat cracked a hash”.

Next

• AD-AUTH-01
• Password reuse analysis within scope

Alternative branch

• Record effort/time/strategy and continue other attack paths

Operational notes

• For unusual formats, verify the current Hashcat mode rather than copying a number from historical notes.
• $sccm$aes128$... PXE/SCCM material is tooling-specific. Use the SCCM/PXE tool’s current conversion/cracking guidance; do not invent a stock Hashcat mode when the current tooling does not define one.
• Modern Kerberos estates may yield AES-encrypted ticket material; do not assume every roastable TGS will be RC4/etype 23.

29.1 Common format recognition

30. What is a finding vs. evidence?

31. Reporting workflow

For every reportable issue, separate root cause, evidence, attack path and impact. This prevents a report from becoming a list of tool output.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

## AD-XX — <finding title>

### Severity
<Critical / High / Medium / Low / Informational>

### Affected assets / principals
- <object or host>

### Root cause
<What is configured incorrectly and where.>

### Evidence
- <exact observation>
- <relevant object DN / ACL / policy / template / protocol setting>
- <minimal command/output reference>

### Attack path
1. Initial state: <low privilege / network only / compromised workstation>
2. <validated primitive>
3. <credential or access gained>
4. <resulting privilege>

### Impact
<What the demonstrated path allows in business/security terms.>

### Recommendation
<Fix root cause first; include hardening that breaks the demonstrated path.>

### Retest
<Exact condition that must no longer be true.>