0.1 Master Notes

Back to the index | Attack Strategy Map

Use these notes to understand why an attack works, recognize its prerequisites, interpret results and decide what to try next. Open the linked operational procedures for commands. Source section/page references identify topics in the supplied 2025 PEN-200 edition; the explanations here are original summaries.

Use the method guides for complete study entries: outcome, recognition, prerequisites, prerequisite discovery, mechanics, baseline/variants, worked example, verification, failure and next transitions. This page keeps the shared concepts that connect those entries: evidence and access claims, effective permissions, identity/material types, privileged consumers, authentication versus authorization and network reachability. Method-specific commands remain synchronized with their owning operational procedures.

0.1.1 Contents

• Discovering and recognizing attack opportunities
• Finding attack surfaces
• Enumeration and attack selection
• Extracting opportunities from services
• Scan coverage and uncertain results
• Credentials and changing access
• Web behavior to access
• Public exploit selection and adaptation
• Shells and file transfer
• Payload delivery and execution controls
• Privilege escalation
• Active Directory attack reasoning
• Tunnels and network reachability
• Integrated attack control, stagnation and recovery
• Evidence and reproducibility

0.1.2 Discovering and recognizing attack opportunities

A useful recognition clue is not just a fact worth memorizing. It is an observation obtained from a particular access position through a reproducible investigation. Start with the capability you actually have, choose a relevant location or interface, perform a scoped discovery action, and identify the exact output detail that makes a method worth considering.

Use this sequence: starting access → investigation location → discovery action → observation → candidate method → missing-condition check → selection. Each topic workflow supplies a first pass; each method's recognition section shows how a clue can emerge, what synthetic evidence might resemble, and what it does not prove.

Keep the scope of the observation attached to the conclusion. A query of the current host does not enumerate a remote destination. A valid password does not establish authorization to execute commands. A writable script does not establish that a privileged consumer will execute it. A banner does not establish the affected configuration. A truncated directory query does not establish absence.

Separate discovery from confirmation. “An unquoted service path exists” can justify investigating writable earlier path components; it cannot replace that permission check. “An account has a directory flag” can justify investigating an identity transition; enabled state, KDC behavior, credential requirements and connectivity still constrain the result.

Classify the decision as enabled after the relevant validation, ruled out in the tested context, or inconclusive because decisive evidence is missing. A timeout, incomplete query or inaccessible setting normally leaves uncertainty; it is not automatically a negative result. A disproven condition rules out this route from this context, not every other attack against the host.

The guide examples are synthetic teaching evidence, not transcripts or lab validation. Some combine abbreviated command-style fields with explicitly labelled observations from preceding investigation; do not expect an exact tool-format match. Attempt the unanswered recognition cases before consulting the guides, and explain the missing check as well as the attack name.

0.1.2.1 Put collection early, then follow the finding

After a foothold, confirm identity and runtime, then use a reviewed collector such as LinPEAS or winPEAS early to find leads. Manual competence means understanding and verifying the selected finding, not postponing useful collection until every manual technique has been exhausted. A useful sudo rule or readable credential can be followed immediately; finishing every collector is not a prerequisite.

Use the named object to choose the next test: sudo -l for an allowed operation; namei/stat/getfacl for a Linux path; sc qc/sc sdshow and icacls for a Windows service; pspy or task/unit inspection for a transient privileged consumer. A color, graph edge or writable file does not substitute for that check. Follow the linked procedure when its conditions hold; otherwise choose another observed lead.

See the Linux first pass and Windows first pass. Supplements: PEASS-ng, pspy, Hexdump Linux and Hexdump Windows.

0.1.2.2 Tool lookup follows the task

Use the tools/scripts index to reach a complete procedure by tool name. The command-first organization is informed by 0xsyr0/OSCP; our recognition examples and permission/context explanations remain alongside the procedures. Verify syntax against the owning tool: a community sheet can describe an older release. For example, current PrivescCheck uses -Report for formats, whereas older examples can use a separate -Format option.

A credential transition also has a context: RunasCs can create a process with another account, while logon type 9 supplies outbound credentials without changing the local identity. Therefore local whoami is useful for the former and insufficient to validate the latter. Application-store recovery similarly depends on the profile and decryption context available to LaZagne; a recovered value must still be matched to an identity and service.

0.1.3 Finding attack surfaces

An attack surface is the set of reachable behaviors an attacker can interact with from a particular source position. For the first network pass, represent every candidate as:

SOURCE -> TARGET | TRANSPORT/PORT | OBSERVED STATE | APPLICATION EVIDENCE | ACCESS CONTEXT | COVERAGE LIMIT

This prevents several common reasoning errors. A TCP and UDP endpoint with the same number are different surfaces. A service reachable from an internal host may be filtered from Kali. A port-based name is not application proof. A listening application is not automatically vulnerable, and a vulnerable build may still lack the configuration or access prerequisite needed by an exploit.

0.1.3.1 The four questions are separate

Treat a scan as a measurement, not a verdict. Its conclusion is bounded by source, destination, time, transport, ports, discovery mode, scan type and network conditions. Record those dimensions whenever a result changes the investigation.

0.1.3.2 Why the states occur

TCP supplies explicit connection signals. In a SYN scan, SYN/ACK normally supports open, RST normally supports closed, and silence or selected ICMP errors can lead to filtered. A connect scan asks the operating system to complete an ordinary connection; it is the practical choice when raw packets are unavailable or the path is a TCP proxy. Neither technique is invisible, and neither proves a vulnerability.

UDP has no handshake. A UDP reply supports open; ICMP port-unreachable supports closed; other unreachable errors can support filtered. Silence cannot distinguish a listening application that ignores the probe from a device that drops it, so Nmap may report open|filtered. A protocol-aware probe can resolve that ambiguity only if it elicits a response.

Nmap has six states. open, closed and filtered are the usual first-pass results. unfiltered means a port is reachable by the chosen probe but that probe cannot decide whether it is open or closed. open|filtered and closed|filtered explicitly preserve two unresolved possibilities. These states describe Nmap's observation from one source; they are not permanent properties of the target.

0.1.3.3 A complete first pass

1. Confirm authorization, the exact target/list, source host, interface and route. Do not expand an assigned list into a surrounding subnet.
2. Use discovery for prioritization, but scan an assigned known-running host with discovery bypass when the discovery stage is the only blocker.
3. Get a quick TCP view, then cover TCP ports 1-65535. The default selection is 1,000 common ports, not the contiguous range 1-1000.
4. Probe discovered ports for application identity. Follow application evidence even when it contradicts the conventional port label.
5. Check UDP separately. Begin with a bounded common-port sample, then test protocol-relevant or objective-relevant ports. Record sample size and ambiguity.
6. Verify only uncertainties that change a decision. Use a focused response-reason check, a simple TCP connection, or the same endpoint from another source position.
7. Build a queue of service-specific tests. Preserve incomplete TCP, UDP and application-identification work as explicit return items.

Prioritize by expected information or access gained per unit of effort. High-value early tests commonly include anonymous or supplied-credential access, exposed files/configuration, directly browsable web applications, informative unauthenticated protocol queries and exact product/configuration checks for plausible public exploits. A surprising high port can outrank a familiar low port when its application behavior is more actionable.

Re-run network discovery when the route, source host, tunnel or target availability changes. Re-enumerate application behavior when credentials, identity or privilege changes. After a foothold, inspect local listeners because loopback-only and internally bound services cannot appear in the original external scan. Do not repeat a disproven scan unchanged merely because exploitation stalled.

0.1.3.4 Worked interpretation: from results to a queue

Assume a common TCP scan of the documentation address 192.0.2.25 reports open TCP/22 and TCP/80 plus filtered TCP/445. A later full TCP scan also finds TCP/8000. Version probes suggest OpenSSH on 22, Apache HTTP on 80 and a Werkzeug/Python HTTP application on 8000. A top-20 UDP sample identifies responsive DNS on UDP/53 and reports UDP/161 as open|filtered.

The defensible conclusions are:

• Full TCP closed a coverage gap by finding port 8000; the common selection never established that all other TCP ports were closed.
• Version probes strengthened application identity but did not prove vulnerability, configuration or usable authentication.
• Responsive UDP/53 is an observed endpoint. UDP/161 remains inconclusive, and the UDP scan still covers only its stated sample.
• Filtered TCP/445 establishes neither an open SMB listener nor Windows/domain identity.
• A reasonable first queue places the custom-looking high-port web application and responsive DNS ahead of credential-gated SSH, while preserving UDP/161 and TCP/445 as conditional return items. Supplied credentials, objectives or a new route can change that order.

Block 1's reference boundary stops at the queue, but Study Unit 1 continues immediately into service enumeration. DNS records, SMB shares, FTP/NFS files, SNMP objects, database rights and remote-access authorization belong to Block 2; web paths/behavior, credential attacks and public-exploit adaptation retain their later boundaries.

Sources: supplied PEN-200 2025 edition, sections 6.4.2-6.4.3, pp142-156; Nmap port-scanning states, service/version detection, and output controls. The Hexdump live enumeration cheatsheet supplies concise Nmap, Windows and proxied-connect examples; the workflow above adds the necessary coverage and interpretation boundaries. Procedures: Stage 01 and discovery/scanning cheatsheet.

0.1.4 Enumeration and attack selection

An open port establishes a reachable endpoint. It does not establish a vulnerability. A service name may be a conventional port label rather than the result of an application probe. A banner supplies a candidate identity; application behavior, configuration and access conditions decide which attacks are plausible.

Work through observation -> hypothesis -> prerequisite -> discriminating test -> interpretation -> next action. For each candidate path, ask:

• What observation supports it?
• What permission, feature, access or configuration must exist?
• What is the cheapest useful test of that prerequisite?
• Which result would disprove the hypothesis?
• What new access or information would success provide?

Choose tests that change a decision. Increasing the amount of output is useful only when it closes a meaningful coverage or interpretation gap.

Keep evidence labels distinct:

For example, SMB exposure alone establishes neither Windows nor domain membership nor a domain-controller role. Those are separate claims requiring separate evidence.

Source route: PEN-200 Ch 6, particularly sections 6.4.3-6.4.4. See service identification and results and next actions.

0.1.5 Extracting opportunities from services

Service enumeration asks what a confirmed application will disclose or permit in the current access context. The reusable model is:

SERVICE -> AUTHENTICATION CONTEXT -> NAMESPACE -> OBJECT -> EFFECTIVE RIGHT -> OPPORTUNITY

The namespace is what the protocol organizes: SMB shares, FTP directories, DNS records, SNMP OIDs, database schemas, or remote-session endpoints. Listing that namespace before grabbing individual objects reduces blind guessing and exposes authorization boundaries.

0.1.5.1 Keep the four privilege claims separate

A common failed attack path jumps from writable to code execution. The missing questions are: which component consumes the object, from what exact path, under which identity, with what syntax, and what triggers it? A writable FTP directory, SMB share, NFS export or database file path is only an input primitive until those conditions are proven.

0.1.5.2 Authentication context is part of the result

Anonymous, null, guest, local-account and domain-account access are different experiments. A service may accept the connection while silently mapping the caller to guest. Record both the identity supplied and the identity/effective permissions observed. Re-enumerate after obtaining a new legitimate identity because authenticated views often expose new shares, records, tables or remote-session rights.

Failures also occur at different layers:

1. route or listener failure;
2. protocol negotiation/version failure;
3. authentication failure;
4. authorization or object-level denial;
5. client-side TLS, host-key, name-resolution or format failure.

Changing passwords cannot repair a route failure, and changing tools cannot grant a denied permission. Diagnose the layer before choosing the fallback.

0.1.5.3 What each service is good at revealing

0.1.5.4 DNS and SNMP are graph expanders

DNS records and SNMP management objects often reveal endpoints that the original scan did not name or could not see. Their main value is not a direct shell: it is transforming an IP-only map into a host/service/role graph. Each in-scope hostname, address, interface, route or local listener becomes a new hypothesis and may require a new source position. Preserve whether it was directly observed, inferred from naming, or merely possible.

For DNS, distinguish authoritative data from recursive answers and NXDOMAIN from NOERROR with no answer. A successful AXFR is a bulk disclosure; refusal only closes that route. For SNMP, a returned OID proves a working version/community and exposed MIB view. No response can still be filtering, loss, version mismatch, community mismatch or an unavailable OID.

0.1.5.5 Remote services are identity validators, not password oracles

SSH, RDP and WinRM can validate one legitimately acquired credential and may provide a session, but broad guessing belongs to the credential-attack block. Separate the local/domain identity, authentication mechanism and service-specific right. An SMB login can succeed while RDP denies interactive logon; a password can be correct while WinRM rejects the account because it lacks endpoint rights.

0.1.5.6 Database primitives cross a security boundary

Database queries normally operate inside the database authorization model. Features such as MySQL LOAD_FILE/INTO OUTFILE, PostgreSQL server-side COPY, and MSSQL xp_cmdshell cross toward the host only when explicit rights, configuration and filesystem conditions align. Their paths refer to the database server, and their operating-system actions run as the database service account or configured proxy. Database root, sa, sysadmin or superuser is not automatically OS root/SYSTEM.

0.1.5.7 Worked attack path: one service produces the next test

Assume a hypothetical assigned host exposes DNS, SMB, MSSQL and RDP:

1. An AXFR is refused, but targeted DNS queries return files01.example.test and sql01.example.test. Confirmed: names and addresses. Not confirmed: roles are accurately described by names.
2. Anonymous SMB lists Public and reads a deployment backup. Confirmed: anonymous read of that object. The backup contains a database username and password; the values remain private evidence.
3. The credential authenticates to MSSQL. IS_SRVROLEMEMBER('sysadmin') returns 0, but the user can read an application table. Confirmed: database access and bounded data read. Disproven: sysadmin through role membership.
4. The same identity passes an RDP authentication-only check but an interactive session reports missing logon rights. Confirmed: credential accepted in the tested RDP context. Not confirmed: desktop access.
5. A share is writable, but no privileged consumer or trigger is identified. Confirmed: write primitive. Inconclusive: code execution.

This is progress even without a shell: the service graph now contains confirmed names, one readable artifact, a database identity, application data, a valid RDP authentication context and an explicit authorization blocker. The next test should target the blocker or a new evidence-backed route, not repeat the same login with another client.

0.1.5.8 The complete surface-to-opportunity loop

Study Blocks 1 and 2 as one feedback system while keeping their evidence claims separate:

source/route -> endpoint -> application -> service queue
             -> access context -> namespace/object -> effective right
             -> information/access -> new host/identity/route/listener
             -> re-enter the relevant discovery or authenticated-enumeration step

A new hostname, address, interface, route or listener changes the network graph and returns to Block 1 from the relevant source position. A new credential or identity usually keeps the endpoint map but changes the authorization view, so return to Block 2's authenticated enumeration. A web application hands off to the combined web-behavior/weakness unit; a credible product/configuration exploit candidate hands off to public-exploit adaptation; verified execution hands off to session establishment.

Sources: supplied PEN-200 2025 edition, DNS pp136-142, SMB/SMTP pp156-160, SNMP pp161-164, database enumeration pp282-285 and WinRM pp514-516. The Hexdump live enumeration section supplies concise DNS, SMB, SNMP and RDP examples; these notes add privilege boundaries and output interpretation. Current syntax and mechanics were checked against Samba smbclient, Samba rpcclient, BIND zone-transfer documentation, Linux showmount, MySQL secure_file_priv, SQL Server xp_cmdshell, and PostgreSQL COPY. Procedures: Stage 02 and service opportunity cheatsheet.

0.1.6 Scan coverage and uncertain results

Discovery asks whether a host appears reachable. Port scanning asks about endpoints. Service probing asks what application responds. A failure at one layer does not automatically answer the others.

Nmap's default common TCP ports differ from a contiguous low-port range. A full TCP port scan covers TCP ports 1-65535; it provides no UDP coverage. Discovery bypass assumes hosts are online and must not be interpreted as evidence that they responded.

A SYN scan interprets SYN/ACK as open, RST as closed, and certain ICMP responses or silence after retries as filtered. A connect scan uses the operating system's connection mechanism. Neither method guarantees invisibility or complete results under all network conditions.

A closed result indicates rejection in that context. A filtered result leaves listener state unresolved. UDP silence may mean filtering or a service that ignores the probe; an application-specific response may resolve the ambiguity. Preserve uncertainty when the test cannot resolve it.

Results depend on the source host, route and filtering. A port reachable from an internal Windows host may be unreachable from Kali. Record where each test originated before comparing results.

Validate further when uncertainty changes the required answer or next action. Do not turn every incidental scanner label into another investigation.

Source route: PEN-200 sections 6.4.2-6.4.3, pp142-156; official Nmap port-scanning documentation. Procedures: TCP scanning, UDP scanning, and Windows network checks.

0.1.7 Credentials and changing access

Authentication and authorization answer different questions: whether an identity is accepted, and what that identity may do. A valid password does not imply administrative access. An authentication failure does not by itself prove that a password is wrong: account context, protocol, account state and service reachability can also matter.

0.1.7.1 Credential material is a typed capability

Passwords, private keys, stored hashes, captured challenge-responses and tickets have different prerequisites and supported uses. Establish the identity, source, local/domain context and cryptographic format before selecting a method. An NT hash can sometimes authenticate directly over NTLM; a Net-NTLMv2 response cannot. A Kerberos ticket is bound to realm, validity, service/SPN and cryptographic material; it is not a universal password replacement. A protected SSH key must first be unlocked, but doing so still does not prove that its public key is authorized for a particular account.

A password is portable only to services that accept that identity and authentication method. An application token is normally bound to one application and its authorization state. A DCC2 cached-domain verifier is an offline cracking target rather than an ordinary pass-the-hash credential. Kerberos roast material is a verifier to crack; a ccache or .kirbi file is already a ticket container whose usefulness depends on client principal, realm, TGT/TGS type, SPN, validity, time, DNS and reachability.

0.1.7.2 Online testing and offline recovery answer different questions

An online attempt asks whether a reachable service accepts an identity and authentication method now. Its result can be affected by lockout, rate limiting, network position, local/domain naming, service policy and account state. Start with one high-confidence credential and the normal protocol client. Dictionary attacks hold the identity constant and vary passwords; password spraying holds a password constant and varies identities. Both are noisy and require an authorized scope plus lockout/rate knowledge.

Offline recovery asks whether candidate plaintext reproduces copied verifier material. It does not contact the service or prove that the account remains enabled. Salts prevent identical passwords from sharing a reusable precomputed result; iterations and memory-hard KDFs increase cost per candidate. The measured rate must match the actual format and hardware.

Some material supports direct use without plaintext. An unlocked SSH key proves possession of the private key but not server authorization. An NT hash may be accepted by an NTLM-capable client, while a Net-NTLMv2 response is tied to a challenge-response exchange and must be cracked or relayed live under compatible conditions. Importing a Kerberos cache proves only that the client can read it.

0.1.7.3 Cracking is an economic and modeling problem

Offline cracking is an economic decision. Identify the exact format, estimate the candidate keyspace and measured cracking rate, and prefer targeted candidates/rules derived from policy and context. Converting a KeePass database, archive, document or key with a *2john helper extracts verifier material; it does not alter the original file or guarantee recovery. Hashcat/John mode selection must match the complete format, including Kerberos encryption type.

Candidate priority should follow evidence: exact recovered/default candidates, organization/user/product words, observed policies and mutations, a small wordlist with rules, a known mask or hybrid, then broader dictionaries. Exhaustive search is justified only when the measured keyspace fits the assessment. Preview generated candidates: a technically valid rule in the wrong order can miss the human pattern, and too many independent rules can multiply the workload beyond its value.

Format recognition uses provenance as well as appearance. A 32-hex string is not automatically an NT hash. A parser rejection usually means wrong mode, malformed/truncated input, an unsupported cipher/KDF or a converter mismatch—not a strong password. Preserve original artifacts and complete converter output; make tool-specific copies for transformations such as removing a filename prefix.

0.1.7.4 Diagnose authentication by layer

Keep credential transitions explicit:

SOURCE ARTIFACT -> FORMAT -> CLAIMED IDENTITY -> AUTHENTICATION PROTOCOL -> DESTINATION SERVICE -> AUTHORIZATION -> NEW ACCESS

This prevents common category errors: calling an offline crack a login, calling SMB authentication local-admin access, calling a ticket import lateral movement, or treating a captured response as a reusable NT hash. Credential Guard/LSA protections can remove some live-secret paths without eliminating file, DPAPI, ticket, service-account or directory-right paths.

Diagnose failures from route and service inward: reachability, protocol/TLS, identity syntax, account state, supported authentication method, material correctness, then authorization. If authentication succeeds but a share, session or command is denied, retain the valid-identity finding and enumerate rights or another relevant service. If a key unlocks but SSH rejects it, separate passphrase recovery from username/server/authorized-key policy. If a ticket loads but fails, inspect expiry, SPN, realm, clock, DNS and service authorization.

Every access change creates another enumeration opportunity:

Source route: PEN-200 Ch 16 pp442-493 and Ch 22-24; getSH Password Cracking, Hexdump Windows hash notes, Hashcat documentation and John documentation. Procedure: credential classification, cracking and reuse.

0.1.8 Web behavior to access

0.1.8.1 Model the application before selecting an attack

A web target is not just an IP and port. Its effective identity includes scheme, host header or virtual host, port, path, method, parameters, content type, cookies or tokens, role and workflow state. Changing any one of these may reach different code or produce different authorization decisions. Preserve a known-good request before mutating it so that a response difference can be attributed to the changed input.

Map ordinary functionality first: pages, forms, links, redirects, downloads, reports, exports, uploads, account actions and administrative features. Then inspect HTML, comments, JavaScript, network requests, cookies and response headers for routes, parameter names, APIs, object identifiers and component clues. Check conventional discovery sources such as robots.txt, sitemap.xml, API specifications, backups and exposed repository metadata, but treat scanner or filename hits as candidates until their content and behavior are verified.

Content discovery, virtual-host discovery and parameter discovery answer different questions:

• content discovery changes the path while preserving the host;
• virtual-host discovery changes the Host value while preserving the destination address;
• parameter discovery changes an input name or value on a known route.

Status code alone is weak evidence. Compare status, length, redirect location, content type, stable body markers and response time against a random-path or invalid-object baseline. Soft-404 pages, wildcard virtual hosts, authentication redirects and rate limiting otherwise create convincing false positives.

APIs require the same request-state discipline. Enumerate endpoints and accepted methods, then infer the expected schema from application traffic, JavaScript or an exposed specification. A 405 Method Not Allowed can disclose valid methods; a validation error can disclose required fields. Test authentication, object ownership, role enforcement and server-side field handling separately.

0.1.8.2 Think in primitives and transitions

Name the capability actually demonstrated:

input control -> server behavior -> primitive -> useful artifact or effect -> verified access

A path change is not yet file read. File read is not code execution. An uploaded file is not necessarily reachable or executable. SQL query influence is not automatically operating-system execution. Browser script execution is not a server shell. Each transition requires its own evidence and prerequisites.

Useful primitives include:

• read: disclose files, records, source, configuration, credentials or keys;
• write: place or alter data at a predictable location;
• execute: cause an interpreter, shell, database feature or application runtime to perform an attacker-controlled action;
• authenticate or impersonate: gain a valid identity, session or browser context;
• authorize incorrectly: access another object or a privileged function without the required rights.

The best next action usually converts the current primitive into a durable access transition: configuration disclosure into credentials, a writable web path into server-side execution, command execution into a reliable session, or an authorization flaw into privileged functionality.

0.1.8.3 File handling primitives

Directory traversal exists when attacker-controlled path components escape an intended directory and the application fails to canonicalize and constrain the final path. Test a known, harmless file and vary separators, depth, absolute paths and encoding only when the baseline suggests server-side file access. Client or proxy normalization can erase ../; preserve the raw path when required. Decisive evidence is recognizable file content, not a generic success status.

Local file inclusion passes attacker-controlled input to a server-side include or load operation. Its effect depends on the language and function: it may disclose a file, render it, or evaluate compatible content. PHP stream filters can turn otherwise interpreted source into encoded disclosure. Inclusion becomes execution only when attacker-controlled executable content can be placed in an includable file, such as a writable log or session file, and the runtime evaluates it. Remote file inclusion additionally requires remote-resource inclusion to be enabled and reachable.

For uploads, identify the checks and the final storage behavior independently: filename, extension, MIME type, magic bytes, image re-encoding, size, renaming, destination path, retrieval route and execution handler. Start with a harmless marker. Prove storage and retrieval before testing execution. Distinct exploit paths include direct executable upload, filter/parser mismatch, controllable filename or path, overwrite of a security-relevant file, and an uploaded file later consumed by an inclusion flaw. A reported upload success without a retrievable artifact is inconclusive.

0.1.8.4 Injection primitives

Command injection crosses a boundary from application data into shell or process syntax. Begin with a benign output marker. If output is hidden, use a bounded time delay or another controlled side effect and repeat against a baseline to reduce noise. Separators, quoting, operating system, invoked shell and filtering affect syntax. After execution is demonstrated, verify identity and environment before choosing a payload or session method.

Manual SQL injection begins by proving that input changes query behavior. Error-based observations expose parser or database clues. Authentication bypass changes a query's truth condition. UNION extraction requires a compatible column count and data types. Boolean-blind testing compares reliably different true and false responses; time-based testing compares repeated delayed and control requests. Keep the original request, change one element at a time and use stable response markers. Database-to-operating-system execution is a separate transition requiring a specific DBMS, privileges, enabled features and sometimes a writable or executable path.

Automated exploitation tools do not replace this model and may be prohibited in a particular assessment. The current OSCP+ exam guide prohibits SQLmap and other automatic exploitation tools; retain manual SQL-injection procedures and recheck the current guide before an exam.

0.1.8.5 Authorization and browser context

For insecure direct object reference, keep the same authenticated session and change only the object identifier. Distinguish object existence from authorization by comparing owned, unowned and nonexistent objects. Repeat across read, update and delete operations because enforcement can differ by method.

Function-level authorization asks whether a lower-privileged identity can invoke an administrative route or operation directly. Test server enforcement rather than relying on hidden UI controls. Mass assignment occurs when the server binds client-supplied fields to protected object properties; add one plausible protected field at a time and verify the resulting server-side state with a separate read.

Cross-site scripting executes in a victim's browser origin, not on the server. Confirm the context and whether the data is reflected, stored or DOM-processed. Its attack value depends on who renders it, the victim's authority, same-origin restrictions and available privileged actions. Demonstrate the smallest safe proof appropriate to a lab, then reason separately about the privileged request it could cause. Do not call script execution a server foothold.

0.1.8.6 WordPress and SSRF boundaries

For WordPress, separate deployment identity from vulnerability claims. Core, plugin and theme files, REST routes and versioned assets reveal candidates; active/enabled state, exact version, configuration and current role determine whether a path is usable. Post-authentication capability mapping matters more than the word “admin”: media upload, plugin installation, theme editing and user management are distinct server-enforced permissions.

Server-side request forgery exists only when the application server dereferences an attacker-controlled destination. Prove this with a controlled listener, then compare a known-open and known-closed internal destination. Browser-side requests, reflected URLs and open redirects do not establish SSRF. The application controls DNS, source address, redirects, proxying and network namespace, so Kali's own ability to reach a destination is not decisive. Internal content read is a network/read primitive, not command execution.

0.1.8.7 Failure-guided next decisions

• Uniform lengths across random paths suggest a soft 404; filter by stable body markers before trusting discovery.
• Uniform virtual-host responses suggest wildcard routing; compare title, length and unique content.
• 403 means a resource or route may exist but access is denied; investigate authentication, role, method and request context rather than assuming absence.
• 405 changes the method hypothesis; inspect Allow and application traffic.
• A file-read test that returns only the normal template may have been normalized, blocked, rendered or aimed at the wrong parameter.
• An upload that is stored but served as inert content lacks an execution handler; look for a distinct inclusion, overwrite or parser path.
• Injection tests with unstable timing are inconclusive until repeated controls separate application latency from a deliberate delay.
• A SQL payload that changes an error but not data flow proves only parser/query influence, not a full extraction or execution path.

Source route: supplied PEN-200 Ch 8 pp201-244, Ch 9 pp245-279 and Ch 10 pp285-300; current OSCP+ exam guide; Burp Proxy and Repeater; Hexdump's live modules/web notes for Burp, SQL injection, traversal, file inclusion, upload and discovery; and the reviewed getSH Web route. Procedures: HTTP mapping, web file handling, command and SQL injection, access control and XSS, and WordPress/SSRF.

0.1.9 Public exploit selection and adaptation

A public exploit is executable third-party code plus a collection of assumptions. The useful question is not “does this CVE have a PoC?” but does this exact component, build, configuration, architecture, authentication state and mitigation profile satisfy the PoC's prerequisites? A banner match produces a candidate. Exploitability requires the vulnerable feature and execution path to exist in the observed environment.

Treat source provenance and code review as attack prerequisites. Record the source URL, EDB-ID/CVE or repository commit and a hash of the original file. Prefer readable source from a reputable or verified source, but still inspect it for destructive operations, unexpected privilege requirements, third-party network calls, embedded commands/payloads, file writes, hard-coded targets and false success conditions. Unknown code should not receive sudo merely because its author requested it. Use an isolated, reversible environment when the remaining uncertainty justifies execution risk.

Separate the exploit runtime from the target payload. A remote exploit can run as Python on Kali while delivering a Windows x64 payload; a local exploit generally must execute in a target-compatible format and architecture. Compilation errors, undefined references, Python 2/3 incompatibility, missing dependencies and Exec format error describe the attacker's toolchain or produced binary before they say anything about target vulnerability.

Minimal adaptation is an evidence discipline. Change target address/port, HTTP scheme/base path/virtual host, authentication/session/CSRF handling, callback coordinates, command/payload, paths and timing only when observed behavior contradicts the PoC's assumption. Preserve the original and review a diff. For web PoCs, reproduce the real request and print the received status, final URL, headers and a bounded body fragment before rewriting a parser. An IndexError often means a redirect, failed login, changed CSRF value or error page replaced the response the exploit expected.

Existing memory-corruption PoCs remain in scope only as adaptations. Understand the exact vulnerable build, target architecture/profile, recorded return-address/module assumptions, offset, payload space, bad characters and crash behavior. Replace the callback or payload when those constraints are documented. Dedicated offset discovery, debugger drills and shellcode development remain excluded by learner choice.

Use an increasing proof ladder: prerequisites → vulnerable path reached → harmless bounded effect → repeatable command execution → callback → usable verified session. A PoC's printed success message, HTTP 200, uploaded filename, crash or incoming TCP connection proves only its own layer. Save the original source, modifications and reasons; the current exam guide requires the original URL, modified code, highlighted changes and explanations when an exploit is changed.

Source route: supplied PEN-200 Ch 13 pp375-392 and Ch 14 pp393-415; current OSCP+ Body of Knowledge; SearchSploit manual; Python/Requests/compiler and Metasploit documentation. Procedure: public exploit selection and adaptation.

0.1.10 Shells and file transfer

Command execution, connection establishment and interactive-session quality are three separate claims. Direct execution may be sufficient for one bounded action. Reverse shells require target egress to a listener; bind shells require Kali to reach a target listener; authenticated SSH/WinRM/RDP requires both accepted credentials and remote-logon authorization.

The complete state model is delivery → execution → connection → usable session. Delivery means the request or bytes reached the intended consumer. Execution means a harmless command or controlled side effect occurred in the vulnerable context. Connection means the listener observed the expected peer. Session means commands return and host/identity can be verified. Preserve the last confirmed state instead of replacing payload, listener and exploit simultaneously.

A missing callback should be diagnosed in order: prove delivery and harmless execution, verify every parser/quoting/interpreter layer, match operating system/architecture/format and staged state, verify the listener bind, test the route from the target context, examine concrete security-control evidence, then repair session/TTY behavior. A correct payload cannot compensate for an unreachable listener, and a successful TCP connection does not prove a usable shell. Packet evidence localizes the boundary: no SYN suggests execution/route/LHOST trouble; a SYN without listener response points to bind/firewall; a completed handshake followed by close suggests crash, handler mismatch or control interference.

Netcat is a family rather than one stable command interface. Traditional/OpenBSD-style nc -lvnp PORT is common on Kali; Nmap Ncat documents the listening port as a positional argument (ncat -lvn 0.0.0.0 PORT) and supports --exec. Confirm the installed flavor instead of assuming -e, -p or TLS behavior. Staged payloads require a handler that understands and sends the next stage; an ordinary raw Netcat listener may accept the connection yet never obtain a command channel. Stageless payloads are larger but usually simpler and more stable.

Quoting failures arise from parser composition. HTTP/SQL/template syntax may feed an application runtime, then /bin/sh -c, cmd /c or PowerShell, then the final payload command. Test a small command at each layer and encode for the consumer at that layer. PowerShell -EncodedCommand requires UTF-16LE Base64; this solves transport/quoting and is neither encryption nor proof of antimalware evasion.

TTY repair changes terminal behavior, not privilege. A PTY, raw local terminal and correct TERM can restore job control and full-screen behavior; they do not make an unstable network path reliable. Verify host, identity, privilege and network position immediately after a session appears. Prefer a working authenticated native service over an improvised shell when it already meets the objective.

Security-control diagnosis must be evidence-based. Distinguish missing/changed files, quarantine, process-creation denial, script-content blocking, process crashes, callback filtering, application control, constrained language, permissions and dependencies. Encoding, renaming and a different port do not establish evasion. Deep AV bypass and custom shellcode development remain deferred; this unit retains only the control mechanics needed to choose the next supported session method.

Choose file transfer by direction, available protocol and current access. The host running the HTTP/SMB/SSH/Netcat listener and the host initiating the connection must be explicit. Use a writable destination and verify the file arrived intact. A successful HTTP response or completed copy does not establish byte integrity; compare hashes when integrity matters. Payload generation likewise requires an explicit OS, architecture, format, execution method and callback route.

Source route: PEN-200 pp257-259, Ch 13-14 pp375-415, selected Ch 15 pp416-441, Ch 19 PTY examples and Ch 21.2 pp671-683; reviewed getSH Useful Stuff/Tool Cheatsheet material; Ncat, Metasploit/msfvenom, PowerShell and Defender documentation. The live Hexdump modules contain no dedicated existing-exploit or shell-reliability module, so no unrelated module was imported. Procedures: file transfer and shells/payloads.

0.1.11 Payload delivery, execution controls and framework boundaries

Payload troubleshooting extends the shell state model into artifact → delivery → trigger → parser/loader → execution → connection → handler → session. The first missing transition owns the next test. A delivered document is not opened; an opened document is not code execution; a child process is not a callback; a TCP connection is not a protocol-compatible handler; and a session is not verified until host and identity are read inside it. Changing several layers together destroys this diagnostic evidence.

Client-side attacks add application and human gates. The target operating system and installed application must support the chosen artifact, the file must reach the intended security zone, and the permitted user action must reach an executable sink. Office macro attacks require a macro-capable file, code stored in the delivered document, a trigger such as AutoOpen/Document_Open, policy that allows execution and a compatible child command. Internet-sourced Office macros are now commonly blocked by default using Mark of the Web; a historical “Enable Content” prompt is not a universal current assumption. Protected View, MOTW, Trusted Locations/publishers and organizational GPO are separate decisions.

The Windows Library-file pattern is a two-stage delivery mechanism rather than an exploit by itself. A .Library-ms description causes Explorer to present a referenced location such as a WebDAV share; a second shortcut or file still needs a user action and a compatible command. WebDAV access, payload download and callback are three independent network paths. Modern Windows/application policy may block any stage, and Windows can serialize a library location after opening it, so preserve a clean source artifact and verify the final delivered copy.

Artifact compatibility is a consumer contract. On Linux, ELF class/machine, dynamic loader, shared libraries, execute permissions, mount options, shebang and line endings explain many apparent payload failures. On Windows, OS bitness is distinct from the consumer process bitness; a 32-bit process on a 64-bit OS still requires matching injected code or DLLs. Direct executables, service programs, DLLs, MSI packages, PowerShell scripts and embedded exploit payloads have different loaders, entry behavior and constraints. A renamed EXE does not become an MSI, and service error 1053 can follow execution of a program that does not implement the service-control protocol.

PowerShell execution policy, language mode, AMSI, application control, antimalware and permissions are not synonyms. Execution policy controls script-loading conditions and is defense in depth; GPO scopes can override process/user choices. AMSI exposes supported script/content to an antimalware provider after common decoding paths. AppLocker or WDAC controls permitted code based on its policy. Defender or another endpoint product may inspect files, scripts, memory, behavior and network activity. Diagnose from exact errors, status, threat history, resource paths and event logs; missing cmdlets or logs are inconclusive.

On-disk and in-memory describe where a technique operates, not whether it is undetectable. Base64 fixes representation, an encoder can satisfy bad-character constraints, and a changed filename changes a name; none proves evasion. A clean external scanner result neither proves target execution nor protects a private sample from disclosure. For this speedrun, the baseline response to a confirmed control is to select the least complex already-supported execution path—direct command, native interpreter, authenticated management service or simple command shell. Deep shellcode development, process-injection implementation and generalized AV-bypass recipes remain excluded by learner choice.

Metasploit separates module, payload, handler, job and session state. An exploit module still requires exact product/build/configuration and target-profile prerequisites. Module rank indicates expected stability, not vulnerability. A staged payload sends a small loader that requires a matching handler to deliver the stage; the slash/underscore naming distinction commonly exposes staged versus single payloads. The payload generator, handler payload, transport, listener coordinates and architecture must agree. Handler output is evidence: no bind, a connection without a session and a short-lived session imply different failed boundaries.

Current OSCP+ rules make tool selection part of the attack. msfvenom and exploit/multi/handler are allowed across targets, except that Meterpreter remains subject to the one-target restriction. Any Auxiliary, Exploit or Post module—or Meterpreter payload—locks Metasploit use to one selected target even when check or the attempt fails. Metasploit pivoting and automatic exploitation are prohibited. Manual/source-reviewed exploitation remains the reusable baseline; choose and record the restricted target deliberately.

Source route: supplied PEN-200 Ch 12 pp343-374, selected Ch 15 pp416-441 and Ch 21 pp653-704; current OSCP+ BOK and exam guide; Microsoft Office macro/MOTW, PowerShell security, Defender and AppLocker documentation; Rapid7 Metasploit documentation; and the live Hexdump client-side/Metasploit resource index. Procedure: payload execution obstacles.

0.1.12 Privilege escalation

Treat escalation as a permissions and execution problem: what can the current identity influence, which privileged process consumes it, and what triggers that process? A writable file is useful only when the relevant privileged execution path actually uses it.

For each candidate, verify the controlled object, effective permissions, privileged consumer, execution identity, trigger and outcome. This same model applies to sudo rules, SUID binaries, capabilities, cron, services, scheduled tasks, unquoted paths, DLL loading and GPOs. Automated enumerators produce candidates; their highlighted output does not establish exploitability.

0.1.12.1 Linux selection logic

Begin with identity/groups, OS/kernel/architecture, processes, listeners, mounts, environment and credentials. Then prioritize recovered credentials and exact sudo rules, writable objects consumed by root, nonstandard SUID/SGID binaries and dangerous capabilities. Privileged groups, sockets, mounts and local-only services follow when their associated resource exists. Software and kernel exploits remain evidence-last. This is a confidence-and-cost ordering, not a claim that every host follows the same path.

Linux access checks depend on effective identity and resource type. File read/write/execute permissions and directory list/create-or-delete/traverse permissions are different. A non-writable file can sometimes be replaced through a writable-and-searchable parent directory. ACLs, supplementary groups, namespaces and mandatory access controls can change the result suggested by mode bits. Mount options also change attacks: nosuid suppresses SUID/SGID and file-capability elevation, noexec blocks direct execution and ro blocks modification. Inspect the whole path and mount rather than stopping at ls -l.

Credentials appear in histories, shell startup files, environment variables, application/deployment configuration, backups, keys and process arguments. /proc/PID/cmdline and environ can expose additional context, but process lifetime and procfs/ptrace restrictions may hide it. Every recovered value needs an identity, type and service context before reuse; moving to another local user is useful only when that identity exposes new files, groups, sudo rules or consumers.

Accessible SSH-agent, tmux/screen and other UNIX sockets can expose a live authenticated/session context, but a pathname or owning process is not sufficient: the current identity must be able to connect and the reused context must confer useful access.

Parse a sudo rule as run-as identity + executable path + argument constraint + authentication tag + environment policy. NOPASSWD removes an authentication step but does not broaden the allowed command. SETENV, env_keep, secure_path and NOEXEC affect environment or execution-based escapes. A GTFOBins entry is applicable only when its privilege mode and required arguments match the observed rule and the binary retains privilege. AppArmor/SELinux can block one technique without invalidating every other sudo route.

SUID changes effective identity to the file owner's identity; SGID changes effective group. Legitimate SUID programs are intended to perform a narrow privileged operation, so their presence alone is ordinary. Prioritize custom/nonstandard files, writable binaries or parent paths, arbitrary file operations, relative helper calls, plugin/config inputs and exact vulnerable versions. Some shells drop effective privilege unless explicitly told to preserve it.

Capabilities split root powers into smaller units. File notation such as cap_setuid+ep supplies the capability to the permitted set and raises it into the new process's effective set, subject to bounding, namespace, mount and program behavior. cap_setuid, cap_setgid, DAC bypass capabilities, cap_sys_ptrace, cap_sys_admin, cap_setfcap and cap_sys_module usually deserve early review. The technique must invoke the exact capability-bearing binary; a different interpreter path has no inherited finding.

For cron, systemd timers and services, prove the full execution chain: exact definition, referenced script/binary/config/environment/plugin, working directory and search behavior, privileged identity and schedule/reload/restart trigger. Cron may use a different shell, PATH and working directory from the interactive session. A writable unit or script is still incomplete when no privileged process will reload or execute it. Tools such as pspy reveal short-lived commands and UIDs, but their output still needs an effective-permission check.

PATH hijacking requires a relative command plus an earlier attacker-writable directory in the privileged consumer's effective search path. The current shell's PATH is irrelevant when sudo, cron, systemd or the program constructs another value. Wildcard injection requires shell expansion of attacker-controlled filenames, a utility that interprets those filenames as options, compatible option order, the correct working directory and a privileged trigger. Sudoers wildcards and shell wildcard expansion are related sources of argument control but have different matching semantics.

Loader-based attacks require a privileged dynamically linked consumer and a controllable selected library or search location. Secure-execution mode strips or ignores many loader environment variables for SUID/SGID programs. readelf can inspect dependencies and RPATH/RUNPATH without relying on ldd behavior against an untrusted executable.

Root-run interpreted scripts have analogous import/include search paths. A writable module or sourced file is useful only when the privileged interpreter resolves that exact file first. Backup, logrotate, package-maintenance and other hooks likewise follow the ordinary controlled-input and trigger model; their mere presence is not a separate shortcut.

Docker group or socket access is commonly root-equivalent only when it reaches a rootful daemon that accepts a host bind mount. Rootless mode, user namespaces, authorization plugins, SELinux and image availability can change the result. LXD/LXC similarly requires daemon rights, a usable image and permission to create a privileged container/device. Groups such as disk, shadow, adm, systemd-journal and libvirt are clues whose actual file, device, log or daemon access must be established.

NFS escalation requires more than a mounted export: useful paths commonly require writable access, no_root_squash, client-side root control and target-side execution where SUID is effective. Root-only loopback or UNIX-socket services are additional consumers, but ownership alone does not establish a privileged operation.

Automated enumerators are breadth aids. LinPEAS highlights candidates; its -a mode adds longer/noisier checks including process monitoring and password attempts, so ordinary execution is the baseline. LSE supports progressive verbosity, and pspy specializes in recurring process observation. Convert every highlight into the same object → permission → consumer → identity → trigger ledger and verify it with native commands.

Kernel/software selection must match the actual component, distribution build and patch/backport state, architecture, configuration, namespace/capability prerequisites, mitigations, dependencies and recovery risk. A version string, SearchSploit title or successful compilation does not prove vulnerability. Prefer deterministic permission/configuration paths and apply the public-exploit audit before any local exploit.

0.1.12.2 Windows selection logic

Windows access decisions begin with the current process or thread token. It contains the user SID, enabled/disabled/deny-only group SIDs, assigned privileges and their state, integrity level and restrictions. A process normally uses its primary token; an impersonating thread can instead use a client's impersonation token. AdjustTokenPrivileges can enable or disable a privilege already present in the token, but cannot add an absent privilege.

Administrator membership is not equivalent to an elevated process. Under ordinary UAC behavior, an administrator may run with a medium-integrity filtered token while a separate administrator token is available through elevation. Mandatory Integrity Control is evaluated in addition to the object's DACL and normally prevents a lower-integrity process from writing to a higher-integrity object. A UAC bypass therefore usually raises an already-administrative filtered context; it is not a general standard-user-to-administrator primitive. runas supplies another identity but does not inherently defeat token filtering.

File/directory, registry, service-object, Service Control Manager, task and process ACLs protect different objects. A writable service executable does not prove SERVICE_CHANGE_CONFIG; a modifiable service object does not prove the binary is writable; start and stop are separate service rights. Evaluate the exact ACE against the current enabled SIDs, requested right, inheritance and integrity boundary. Parent-directory delete/create rights can permit file replacement even where the file itself is not directly writable.

Start with token groups/privileges/integrity, OS build and architecture, credentials, services, tasks, processes, drivers, sessions and network state. Prefer CIM because WMIC is deprecated and can be absent. Get-HotFix exposes CBS/QFE data rather than every update, so a missing KB is not proof that a vulnerability is unpatched.

Credential discovery should follow observed applications and identities. PowerShell's in-memory history, PSReadLine history file, transcripts and script-block/module logs are different artifacts; clearing session history does not clear every source. Credential Manager entries are target/context-bound, and DPAPI blobs require a compatible protecting user or machine context. Every password, key, hash or token returns to the credential-classification and authorization workflow.

Service abuse has four main control planes: service configuration, the configured executable/script, an earlier executable prefix from an unquoted command line, or a DLL/config/plugin/helper consumed by the service. Each path still requires a higher service identity and a usable restart, start, boot or dependency trigger. For an unquoted path, enumerate the exact prefixes Windows attempts and prove that an earlier missing prefix is creatable. A path merely containing spaces is not a finding.

DLL selection is more complex than a short directory list. Modern Windows may apply DLL redirection, API sets, side-by-side manifests, the loaded-module list, KnownDLLs, package dependencies and application-specified search flags before ordinary application/system/current/PATH directories. Safe DLL search mode is enabled by default. Prove the exact requested DLL, architecture, chosen writable location, necessary exports/behavior, privileged consumer and trigger; runtime NAME NOT FOUND evidence is far stronger than a writable directory guess.

Scheduled tasks require the exact action, arguments, working directory, principal, run level and trigger plus control of a consumed object. RunLevel Highest means the configured principal's highest available token, not SYSTEM. A successful request from schtasks /run does not prove that the action ran or that its effect was privileged. Machine Run keys, all-users startup entries and writable PATH directories follow the same consumer-and-trigger reasoning.

AlwaysInstallElevated is useful only when both the machine and current-user policy values are enabled. It is an installer-policy misconfiguration rather than a generic UAC bypass.

SeImpersonatePrivilege is a prerequisite category, not a universal exploit. Impersonation tools need a controlled server endpoint, a compatible privileged client/coercion, a sufficient impersonation token, the correct OS/architecture/runtime and a process-creation path. PrintSpoofer, GodPotato and related tools use different trigger mechanics; switch tools only when the alternative satisfies a different available prerequisite. Success is a verified privileged process, not the tool's banner.

Backup and restore privileges alter specific file/registry operations only when enabled and used through backup/restore-aware APIs. SAM and SYSTEM hives yield local credential material for Block 5; they do not themselves create a SYSTEM shell or grant domain/remote authorization. SeDebugPrivilege, SeLoadDriverPrivilege, SeTakeOwnershipPrivilege and SeManageVolumePrivilege likewise require a useful object/consumer and can be limited by protected processes, driver signing, build compatibility or missing follow-on rights.

Automated enumerators provide candidates. winPEAS emphasizes breadth, PrivescCheck evaluates misconfigurations in the current token context, Seatbelt is a targeted host/user survey, and PowerUp is a useful but archived codebase. Convert every highlight to controlled input → effective right → privileged consumer → run-as identity → trigger → verified effect. A blocked tool is an environment limitation, not proof that the host has no paths.

Prefer deterministic credential and permission/configuration paths, then exact privileged application vulnerabilities, then exact third-party driver issues, with kernel exploitation last. Match build, architecture, cumulative-update state, component configuration, mitigations, exploit source and stability. Verify whoami /all, host and required objective evidence after every attempt, then re-enumerate the new token's accessible credentials, services, tasks, sessions, listeners and routes.

Source route: PEN-200 Ch 18 pp550-582 for Linux and Ch 17 pp494-549 for Windows; current OffSec BOK; reviewed getSH privilege-escalation route; Hexdump PATH hijacking and Windows modules; Microsoft token, MIC, service, DLL-search, task and installer-policy documentation; upstream sudoers, Linux capabilities, systemd, Docker, LinPEAS, LSE, pspy, PrivescCheck, Seatbelt, AccessChk, PrintSpoofer and GodPotato documentation. Procedures: Linux and Windows.

0.1.13 Active Directory attack reasoning

A collector's effects come from its exact options, defaults and dependencies. A menu title or an “enumeration” label is insufficient: linWinPwn adds startup discovery/authentication handling before a selected menu action, and its automatic chain invokes additional attack routines. The direct Kali first pass selects directory-only graph collection, readable inventory, an effective-rights query and version-aware share checks without that wrapper. It is a set of reference commands for later practice, not evidence of independent competence.

Distinguish asking about a permission from exercising it. bloodyAD get writable searches effective attribute/security-descriptor/child-class information; it does not prove a useful execution consumer or perform a modification. Newer NetExec share enumeration requests access masks on existing share roots; older default implementations tested writes by creating temporary artifacts, requiring --no-write-check to suppress that behavior. A displayed WRITE label therefore needs version-specific interpretation. BloodHound DCOnly omits host RPC/session collection, whereas linWinPwn's all,LoggedOn also queries remote registry and can trigger service startup. Authentication, audit logs, local credential databases and LDAP referrals remain relevant even for read-oriented collection. Source-check a changed version before treating the same command string as equivalent behavior.

The AD surface helpers automate selected native directory reads and current-host inspection while retaining the distinction between a clue and a validated path. A service principal name does not prove recoverable credentials; a delegation attribute does not prove control of the relevant identity; a returned ACE does not establish effective access. Read the recorded query gaps before treating a missing finding as negative evidence. The helper's next-check report links back to manual prerequisite validation rather than selecting or executing an exploitation chain.

The collectors run automatically when invoked; -Preview is the explicit no-contact mode. Account-context matching and broad ACE comparisons help select what to review, but a local token SID can differ from the LDAP network identity and direct/primary groups are not a complete effective token. The same boundary applies to host correlation: a listener joined to a process and an unquoted service path are observations, while usable access and escalation require separate authorization, permission and trigger checks.

The compact AD quick-use section separates current-host investigation from destination reachability and remote authorization. Its reusable LDAPSearch function is defined inline once; directory queries select candidates and do not establish effective rights. Paging and resource cleanup follow DirectorySearcher paging and FindAll lifecycle. The function uses current Windows authentication; multi-valued membership properties are not complete effective membership.

The numbered AD chapter separates 6.1 context/connectivity, 6.2 enumeration, 6.3 credentials/identity changes, 6.4 movement and 6.5 interpretation/recovery. Baselines and alternatives sit under their parent section. Read an output row as a conditional handoff: the exact clue, the remaining check and one numbered receiving subsection. A section number identifies where to investigate; it does not establish that its technique is enabled or require practical execution during concept study.

Use AD Notes when the immediate question is where to look or how to interpret output. Its Quick Reference opens one focused investigation at a time; expected behavior separates ordinary features from useful configuration or permission clues. The command baseline and complete variants remain owned by the linked operational procedures.

Section 6.6 Study aids adds a method chooser, terminology definitions, one continuous synthetic investigation and unanswered changed-condition cases. Compare the actual decisive line with the supported interpretation, missing prerequisite and exact next section. Each focused investigation labels execution context and effects, then defines when to stop and what new evidence would justify revisiting it. The worked chain includes a rejected path and re-enumeration; it is explanatory material, not practical evidence.

Interpret AD evidence through explicit boundaries: a reachable endpoint is not authenticated access; authentication is not object authorization; listing is not file reading; a writable object needs a useful consumer/trigger; a service ticket is not a recovered password. Record the exact source identity, object, operation and outcome before inferring a new capability. Empty results need collection-scope, filter, permission and freshness checks. The output-reading guide shows a synthetic worked example and links to the focused failure checks.

Track the chain as Identity -> Group -> Rights -> Host Access -> Session/Credential -> New Identity -> Higher Privilege. These are relationships to investigate, rather than a mandatory sequence for every environment.

For each useful relationship, state the prerequisite, the evidence it exists, the action it permits and the new options that follow. Distinguish local rights, domain rights, host access and network reachability. A domain identity may authenticate to LDAP yet lack share access; a local administrator may execute remotely on one host yet possess no directory privilege.

BloodHound supplies candidate relationships. Validate the relationships needed for the chosen path, including whether the controlled identity has the effective rights and whether the required host or service is reachable.

0.1.13.1 Mapping before movement

Maintain four related maps: identities and nested groups; directory/host rights; computers/services/sessions; and the route/DNS/time state from the current source. These answer different questions. Successful authentication does not establish authorization, a directory relationship does not establish network reachability, and a session observation does not establish accessible credentials.

Establish the domain DNS name, NetBIOS name, DC FQDN/IPs, AD DNS server, time/KDC state, current token and network credential context first. Kerberos binds authentication to realm, service principal name, ticket validity and clock state, so IP-based LDAP/SMB success can coexist with Kerberos failure. A remote WinRM or PowerShell session can also encounter a credential-delegation “double hop”: the identity used to enter one host may not be available for an onward DC query.

AD objects are identified by distinguished names and GUIDs, while security principals use SIDs. UPN and DOMAIN\sAMAccountName are logon forms, and a computer account ending in $ is an independent domain principal. OUs organize delegation and Group Policy scope but are not token groups. Effective access can flow through nested groups, so direct memberOf output is not a complete authorization calculation. Trusts accept authentication relationships across domains; they do not grant resource access without an applicable target permission.

RootDSE supplies the default, configuration, schema and root-domain naming contexts and can be readable when anonymous subtree enumeration is denied. An LDAP result depends on server/transport, bind identity, base DN, search scope, filter and requested attributes. Use paging for inventories; an unpaged result near the server limit is not complete. Referrals indicate another naming context, while an empty authenticated search can mean an incorrect base/filter, attribute filtering or genuinely no match.

Enumerate users, groups/nesting, computers, trusts, SPNs, OUs/GPOs, shares, sessions and ACLs using the least complex available path: native net/nltest/setspn, RSAT when installed, built-in ADSI/DirectorySearcher, raw LDAP, PowerView and targeted SMB clients. PowerView is convenient but the upstream PowerSploit repository is archived and forks/course copies can use different Get-Domain* or legacy Get-Net* names. Tool absence or API denial calls for a narrower alternative query rather than the conclusion that no relationship exists.

Treat share listing, share connection, file read and file write as distinct permissions. SYSVOL/NETLOGON and deployment shares may expose scripts, configuration, backups, connection strings or legacy Group Policy Preferences cpassword material. Retrieve relevant files selectively; a discovered value still requires credential identity, freshness and compatible-use validation. Write access becomes an attack path only when a more privileged consumer uses the controlled object.

An SPN maps a service instance to the account holding its Kerberos key. It does not establish password weakness, service reachability or account privilege. Record account, service class/host, groups, password age, delegation/encryption clues and reachable service before handing the candidate to the identity-transition block.

For an ACL, resolve trustee → allow/deny → right → object type/GUID → inheritance → target. GenericAll, GenericWrite, WriteOwner, WriteDacl, extended rights and validated writes describe possible operations, not automatic compromise. Establish the controlled trustee through nested membership, applicable target class/property, effective inheritance/deny behavior, a useful downstream state change and a restoration plan. GPO/OU control additionally needs a writable policy component, effective link/scope, affected target and refresh/trigger.

Host access is protocol-specific. SMB administrative context, RDP logon, WinRM/PowerShell remoting, WMI/DCOM and share-only rights have separate services and authorization. NetExec's (Pwn3d!) marker is an SMB administrative-context result, not a universal remote-access grant. Broad local-admin checks are candidate generators; manually test the selected host through the service a later movement method requires.

Session data is volatile and often incomplete. PowerView session functions depend on Windows APIs that modern hosts may restrict; PsLoggedOn uses loaded profile evidence plus network-session enumeration and can create its own network-session artifact while querying. Access denied or an empty result is inconclusive. A reported privileged session matters only when the host is reachable/controlled and a later credential or ticket mechanism can benefit; presence alone does not prove reusable material exists.

Current SharpHound CE without flags performs broad default directory plus local-group/session attempts. A controlled approach can begin with DCOnly, which collects directory relationships without touching workstations, and then add targeted LocalGroup or looped Session collection for candidate hosts. All is not an automatic first pass. Collector generations and Linux alternatives differ in schema and flags, so match the collector to the BloodHound deployment and inspect its help.

BloodHound supplies candidate relationships. Mark only identities or hosts actually controlled, verify collection/ingestion quality, inspect outbound control from the current identity, classify static-ish directory edges separately from host-derived and volatile session edges, and manually validate the minimum decisive relationship. The shortest graph path is not always operationally best: rank confidence, deterministic value, route/service availability, volatility, reversibility and unsupported assumptions. An unreachable graph host is a routing handoff, not evidence that credentials or the graph are wrong.

Represent each candidate as:

CONTROLLED PRINCIPAL -> EFFECTIVE RELATIONSHIP -> TARGET OBJECT/HOST
                     -> REACHABLE SERVICE -> EXPECTED TRANSITION
                     -> MINIMUM VALIDATION -> STATUS/NEXT BLOCK

Re-enumerate the relevant maps after every new identity, host, route, subnet or domain. Full operational commands and failure routing are in Domain Mapping.

0.1.13.2 Credential and ticket transitions

A useful identity transition is not “obtain a hash.” It is mapped prerequisite → permitted request or read → typed credential artifact → compatible authentication path → newly verified identity/rights → re-enumeration. Keep password, NT hash, cached verifier, Net-NTLM response, TGT, service ticket, DPAPI-protected secret and certificate distinct; they are not interchangeable.

AS-REP roasting exploits an account setting, not an exposed service password. If Kerberos preauthentication is disabled, the KDC can return an AS-REP encrypted with key material derived from that user's password before the requester proves knowledge of it. The returned krb5asrep verifier can be attacked offline. A valid username and KDC reachability are sufficient for a known account; an authenticated directory query can identify candidates. Success proves only that crackable material was obtained, not that the password is weak or the account privileged.

Kerberoasting exploits normal service-ticket behavior. Any authenticated domain principal can generally request a TGS for an SPN; part of that ticket is protected with the SPN-owning account's key. Prioritize a selected user-managed service account by privilege, password age and downstream access instead of immediately requesting every SPN. Classify the returned etype before cracking: common Hashcat modes are 13100 for TGS etype 23, 19600 for etype 17 and 19700 for etype 18. Strong managed passwords can make offline cracking infeasible even when the request succeeds.

An effective write to a user's servicePrincipalName enables targeted Kerberoasting: register a unique temporary SPN, request that user's TGS and remove the SPN immediately. This is an object-control transition, not evidence that the target was previously a service account. It changes directory state and therefore needs exact right validation, duplicate-SPN checking and cleanup.

Credential sources answer different questions. LSASS holds material for active logon sessions and normally requires local administrator/SYSTEM plus debug or dump capability; LSA protection and Credential Guard can block or isolate useful secrets. SAM plus SYSTEM yields local-account hashes. SECURITY plus SYSTEM can expose LSA secrets and cached domain logon verifiers; a DCC2 verifier is an offline password-verification target, not a reusable NT hash. Credential Manager values are often DPAPI-protected, so useful recovery also needs the correct user/machine context and DPAPI key chain. NTDS plus SYSTEM represents directory database material; remote replication is a separate DCSync path. Prefer ticket inventory or a dump-first/offline workflow before direct live parsing when the objective and lab authorization permit it.

Classify recovered material before action. Cleartext may support any permitted password authentication. An NT hash can support NTLM pass-the-hash where the protocol and policy allow it, or a key-to-ticket/overpass transition when Kerberos prerequisites are satisfied. A TGT represents one client identity in one realm during its validity and can request service tickets; a TGS is restricted to its named SPN. A cached verifier must be cracked before becoming a password. Each method still requires reachable service, accepted protocol and authorization.

Interpret a cached ticket as client identity -> ticket type -> service/SPN -> validity -> authorization. krbtgt/REALM is a TGT; cifs/HOST, ldap/HOST, host/HOST and other SERVICE/HOST values are service tickets constrained to their named service context. Kdc Called identifies the issuing KDC, so a ticket issued by a DC or naming a DC-hosted service does not itself prove administrative access to the DC. Ticket flags and encryption types describe Kerberos behavior and compatibility, not the client's privilege. A machine-account client ending in $ is a separate domain identity whose effective rights must be established rather than inferred.

Pass-the-Ticket imports a valid ticket into the correct logon/session context; it does not widen the ticket's SPN, time or authorization. A silver ticket is a forged TGS for one service, constructed with that service or machine account key, the correct realm/domain SID and exact target SPN. It avoids requesting the TGS from the KDC, but service-side authorization, naming, key currency and modern PAC validation still matter. A ticket that imports but cannot access the resource is evidence to inspect those constraints, not a reason to assume the tool failed.

0.1.13.3 Object control and replication; conditional supplements

Directory rights such as GenericAll, GenericWrite, WriteDacl, WriteOwner and extended rights describe possible modifications, not automatic compromise. Resolve effective trustee, allow/deny and inheritance, target type, exact property/right and protected-object behavior. Then connect the permission to one controlled effect:

• a password-reset right produces a new password for the target but does not disclose or preserve the old one;
• group member-property control can add a controlled principal, but a current token may require a new logon to contain the new group SID;
• SPN-property write can create the targeted-Kerberoast transition;
• WriteDacl can grant a narrower reset, membership or replication right;
• WriteOwner may permit a subsequent DACL edit after ownership changes.

Every such action changes directory state. Save the original owner, security descriptor, membership or attribute where restoration is possible; choose the least disruptive useful transition; validate the new identity or authorization; then restore and re-enumerate. A graph edge is a candidate, not permission to mutate the directory.

DCSync is a protocol/authorization transition rather than “dumping LSASS on a DC.” The controlled identity needs effective domain-root replication rights equivalent to Replicating Directory Changes and Replicating Directory Changes All, with filtered-set rights where applicable. Local administrator on a member host, LDAP access or a ticket for ldap/DC_HOST is insufficient. A successful request for one selected account is already domain-compromise evidence; broad collection adds risk without proving more.

AD CS, delegation/RBCD and broad GPO abuse remain conditional branches for this block. When target evidence makes one relevant, validate the entire chain rather than trusting a category label. AD CS needs a reachable CA, enabled/published template, enrollment rights and exact subject/SAN, EKU, approval/signature and object-permission conditions; issuance and certificate authentication are separate transitions, and a PFX is a credential. Delegation needs control of the delegating principal/key, an allowed or written delegation relationship, the requested SPN and service-side authorization. GPO control needs both effective edit capability and an applicable link/filter/target plus a trigger. These are not prerequisites to understand the active password, roast, credential-source, object-right, silver-ticket and DCSync routes.

0.1.13.4 Lateral movement is service authorization

Lateral movement is not credential reuse alone. Model it as source position → route → destination name/service → credential form → authentication protocol → service-specific authorization → execution/output mechanism → verified new state. A password can support several protocols, an NT hash needs an NTLM-capable route, a TGT can request compatible service tickets, and a TGS remains restricted to its named SPN. Net-NTLM responses and DCC2 verifiers are not reusable NT hashes.

Establish reachability from the tool's actual source. SMB/service execution normally needs 445 plus administrative share and Service Control Manager rights. WMI/DCOM begins with RPC endpoint mapper on 135 and commonly negotiates dynamic high ports; Impacket WMIExec also uses SMB for output unless run without output. WinRM uses 5985/5986 and an authorized endpoint. RDP uses 3389, NLA/security negotiation and a remote-interactive logon right. A pivot that carries TCP/445 does not automatically carry dynamic RPC or callbacks.

Separate authentication, administrative context, remote operation, command effect, output retrieval and usable session. SMB authentication can permit one share but not ADMIN$ or SCM. NetExec's (Pwn3d!) is an SMB administrative-context indicator, not a universal execution grant. A WMI ReturnValue = 0 proves process creation, while a missing stdout channel can still hide a successful effect. Session-0 processes will not create a visible GUI for an interactive user.

PsExec and SMBExec both use SCM but leave different artifacts. Impacket PsExec uploads a RemCom service binary and communicates through named pipes; SMBExec creates temporary services whose command lines redirect output. ATExec creates/deletes a scheduled task and retrieves output through ADMIN$. WMIExec creates processes through WMI/DCOM and normally retrieves output over SMB. Native CIM provides the same process-creation primitive without Impacket. DCOM MMC/Shell objects are an alternative RPC mechanism, but current Impacket DCOMExec deliberately rejects Kerberos for its supported objects; use a Kerberos-capable WMI path when the material is a ticket.

WinRM/WinRS/PowerShell remoting create remote shells or runspaces when an endpoint accepts the identity. Local Administrators or a remote-management group are common authorization sources, but endpoint SDDL and policy are decisive. Hostname/FQDN use normally supports Kerberos; an IP commonly forces different trust/authentication handling. Do not globally weaken TrustedHosts to compensate for a DNS/SPN mistake. A first WinRM hop also may not delegate the entered credential onward—the double hop is a credential-context problem, not proof the second host is unreachable or the password wrong.

RDP is an interactive-logon route, not an administrative-execution synonym. Password-based RDP needs service availability, NLA compatibility and an effective “Allow log on through Remote Desktop Services” assignment without a deny override. Restricted Admin permits hash/ticket-style network authentication only under its policy/support conditions and requires administrator access; ordinary Remote Desktop Users membership is insufficient for that mode. Ordinary RDP can place reusable credentials in the destination LSASS, whereas Restricted Admin avoids doing so but removes ordinary onward access as that user.

Pass-the-Hash presents an NT hash through NTLM without first recovering plaintext. The target service must accept NTLM, the local/domain account context must be correct and the represented identity must hold that service's right. Remote UAC commonly filters network tokens for non-built-in local administrators. Domain administrators traditionally receive full remote tokens when locally authorized, but newer Administrator Protection policies can alter this; trust the observed token and operation rather than memorized defaults.

Overpass-the-Hash/key-to-ticket uses an NT or AES long-term key to obtain a Kerberos TGT, then requests tickets through normal hostname/SPN flows. The process's local whoami can remain the original token while its outbound network credential represents another identity. Pass-the-Ticket imports a TGT or TGS into a logon/cache context; import success proves neither destination access nor execution. Validate the ticket client, realm, validity, SPN and resulting remote identity.

After movement, verify hostname, full token, addresses, routes, listeners and ticket cache. Then repeat host credential-source checks and Block 10 domain mapping from the new identity/position. Preserve the earlier state so the chain records exactly which credential, protocol, method and authorization produced each transition. Full commands and failure routing are in Check which other hosts your current identity can access.

Source route: PEN-200 Ch 22-24; current OffSec BOK; Microsoft RootDSE, DirectorySearcher and PsLoggedOn documentation; current SpecterOps SharpHound CE documentation; reviewed getSH Active Directory route, current Impacket/NetExec/OpenLDAP sources and Hexdump Active Directory modules. The live Hexdump AD module was still a TODO when checked, so its minimal legacy collector cue was not treated as current syntax authority. Procedures: Stage 06.

0.1.14 Tunnels and network reachability

Draw application source → entry listener/SOCKS/TUN route → tunnel transport → pivot exit → destination before selecting a forwarding command. For a callback, draw the reverse graph separately. Identify the initiator, bind address, destination as seen by the exit, transport, DNS-resolution point, authentication hostname and cleanup objects. “The tunnel works” is too broad: process start, listener/session creation, pivot egress, local route/proxy use, application flow, name/authentication behavior and callback return are separate claims.

Begin on the foothold by inspecting interfaces, routes, neighbors, DNS and local listeners. A second interface or route is a candidate vantage point, not proof that an internal service is reachable. Test one justified destination socket from the pivot. Prefer the smallest sufficient route: one explicit forward for one known TCP service; SOCKS for several TCP endpoints; a TUN/routed pivot for many ordinary clients; and command execution on the pivot itself when no forwarding is needed.

SSH direction is defined by where the listener is created. -L and -D create listeners on the SSH client; destination connections exit from the SSH server. -R creates a listener on the SSH server and sends connections through the client. Remote dynamic -R PORT creates a SOCKS endpoint on the server and requires OpenSSH 7.6+ on the client issuing it. ProxyJump is an SSH-specific path, while ProxyCommand lets SSH use an existing proxy transport. ExitOnForwardFailure proves requested sockets were bound, not that the final service works. Server-side AllowTcpForwarding, PermitOpen and GatewayPorts can restrict behavior.

Socat is a simple fixed relay and adds neither authentication nor encryption. sshuttle creates a transparent selected-subnet TCP/DNS-oriented route through SSH, but needs local firewall privileges and a compatible remote Python path; it is not a layer-2 or arbitrary-UDP VPN. On Windows, built-in OpenSSH retains the SSH model; Plink supports local, remote and dynamic forwards but not OpenSSH's remote-dynamic shorthand. Elevated netsh interface portproxy creates persistent TCP-only forwarding and may also need a firewall exception/IP Helper, so both rule and exception require deliberate cleanup.

SOCKS only helps clients that use it. ProxyChains interposes dynamically linked socket calls and is TCP-only; static binaries, some scripts/modules, UDP, ICMP, SYN scans and pcap discovery will not transparently work. Nmap through ProxyChains therefore uses focused -sT -Pn -n, while native proxy options are preferred. A Chisel socks/R:socks remote is TCP CONNECT only. Current Chisel adds udpsocks/R:udpsocks for SOCKS5 UDP ASSOCIATE, but that does not make ProxyChains UDP-capable and both peers/client/firewall must support the UDP path.

Chisel wraps its SSH-secured channel in HTTP/WebSocket transport and is useful when the pivot can initiate permitted HTTP-like egress. Reverse SOCKS or a reverse fixed forward places the usable listener at the server side. Server fingerprint verification, client/server compatibility, target OS/architecture and runtime libraries matter. An HTTP request reaching the server without a WebSocket upgrade points to an intermediary/transport problem rather than internal routing.

Ligolo-ng creates a userland routed path so normal clients can use selected internal subnets without ProxyChains. Current versions can create interfaces and routes in the console; manual TUN and OS routes remain a fallback. Its special 240.0.0.0/4 mapping exposes the selected agent's loopback when narrowly routed, while agent listeners can relay internal callbacks to the proxy host. A session alone is not enough: the correct agent, TUN interface, route and listener must all align. Raw-packet, ICMP and some UDP behavior can differ from direct networking.

Kerberos reveals why route and name are different variables. Numeric IP connectivity can work while authentication fails because the client needs the target FQDN/SPN, a reachable KDC, matching realm and correct time. Decide explicitly whether DNS runs locally, through ProxyChains, at a SOCKS exit or through the pivot's resolver. Preserve a service hostname and use a separate routing address when a tool provides that option.

Forward access and callback access are independent. A path that lets Kali browse an internal web service does not prove the target can reach a Kali listener. The callback may need a listener on the pivot plus SSH/Chisel/Ligolo relay. Payload delivery can need a third path. Verify each direction with a simple protocol-appropriate test before changing credentials, exploits or payloads.

DNS tunneling is a conditional last-resort path, but remains in the current official BOK. dnscat2 needs client execution plus authoritative NS delegation for a controlled domain or direct DNS-server reachability. Resolver forwarding, caching, EDNS, TCP fallback and response limits affect the channel; it is slower and more conspicuous than ordinary tunnels. A DNS query arriving proves only the resolver path, not an authenticated encrypted session. DNS tunneling is not DNS spoofing, which the current exam guide prohibits.

In a multihop route, validate outward from the first hop and use distinct routes/listeners. One upstream failure invalidates all deeper observations. Record route ownership, versions, bind addresses, name mappings and cleanup. The current exam guide explicitly prohibits Metasploit pivoting even though the course/BOK teaches the concept.

Source route: PEN-200 Ch 19 pp583–629 and Ch 20 pp630–652; current OffSec BOK and exam guide; reviewed getSH and Hexdump tunneling routes; current OpenSSH, Socat, ProxyChains, sshuttle, Plink, Microsoft Netsh, Chisel, Ligolo-ng and dnscat2 documentation. Procedure: Stage 07.

0.1.15 Integrated attack control, stagnation and recovery

An unfamiliar attack is a state machine, not a linear checklist. The reusable loop is Observe → Enumerate → Interpret → Hypothesize → Validate → Exploit → Verify → Re-enumerate → Escalate/Move → Document. The purpose of the loop is to keep conclusions tied to the source position, identity and evidence that produced them. A new credential changes the authorization view; a new route changes the reachable attack surface; a new session changes the host context; and a new privilege changes which protected objects and sessions can be enumerated. Each state change routes the investigation back to the applicable earlier block.

Maintain two queues. The coverage queue tracks each reachable host/endpoint/application and whether its required enumeration is complete in the current context. The hypothesis queue tracks observation, desired transition, prerequisites, cheapest discriminating test, decisive results and status. Coverage prevents tunnel vision; hypotheses prevent random command execution. A confirmed prerequisite with a direct objective transition outranks a popular technique supported only by a banner. Information-expanding tests can outrank exploit attempts when they may unlock several branches.

Every candidate path should state what success and failure mean before testing. Disproven requires a valid test of the actual prerequisite. A tool error, wrong source position, missing proxy support, bad syntax or unavailable dependency is an environment/tool failure. A result that does not separate plausible explanations is inconclusive. Keeping these states distinct prevents a viable path from being abandoned for the wrong reason and prevents repeated attempts against an absent prerequisite.

Warning signs include repeated tests with unchanged evidence, multiplying assumptions, increasingly exotic mechanisms without prerequisite checks, tool switching without a new hypothesis and work whose success would not advance the objective. Freeze the current host/identity/route/credential map, label the last decisive result per path, audit coverage and authenticated views, then choose a test that can change the decision. Return to a disproven path only when new evidence changes its prerequisites.

For a standalone target, integrate scope/objective → TCP and bounded UDP coverage → service/web enumeration → files/configuration/identities → credential/manual weakness/exact exploit prerequisites → bounded effect → verified session → local privilege reasoning → elevated identity → final evidence and cleanup. For assumed-breach AD, integrate starting identity → DNS/time/DC/route → hosts/services and directory objects/rights → ranked identity/host transition → compatible password/hash/ticket use → verified new session/identity → authenticated re-enumeration → movement → final domain objective. Every AD edge must keep controlled identity, effective group/right, target, protocol/route and resulting state together.

Source route: supplied PEN-200 Chapter 27 pp963–1017, especially the cyclic enumeration and wrap-up lessons at pp963–968 and 1015–1016; current BOK; reviewed getSH Home/AD flow and the live Hexdump report workflow. Procedure: Stage 08.

0.1.16 Evidence and reproducibility

Capture access and privilege transitions when they happen: time, source position, host, identity, command/request, decisive output, effect, artifact hash and reproduction steps. Keep actual screenshots, transcripts, target details and proof material in private records. Maintain separate maps of hosts, identities, credentials, routes, hypotheses and transitions so a new state triggers the right re-enumeration rather than erasing the earlier chain.

Document exploit source/version, modifications and why they were necessary. Preserve a focused diff, build/interpreter command, payload-generation command and result verification. A technically competent reader should be able to reconstruct the attack from the resulting report without relying on unexplained screenshots or a raw terminal transcript.

The report is a normalized sequence of state transitions rather than a chronological terminal dump: starting state → decisive enumeration → prerequisite validation → exact action → session/identity proof → privilege/movement transition → final objective → cleanup. Retain enough failed-path evidence to explain important decisions, but do not bury the reproducible path under every inconclusive command. Screenshots require captions and nearby interpretation; they do not replace copyable steps.

The current exam guide requires strict proof handling, report completeness and exact packaging. Proof-file contents must be read from the original location through an interactive target shell and captured with the target IP; control-panel submission is a separate action before the practical period ends. Target grading follows report order. The final report is an exactly named PDF inside an exactly named non-password-protected .7z no larger than 200 MB, with only PDF content accepted. Visually inspect every page, test/list the archive, compare the local and uploaded MD5 and complete final submission. Recheck the guide because these details can change.

Before a mock or exam, consult the current official exam guide for evidence, tool and submission requirements.

Source route: PEN-200 Ch 5 pp94–113; current official exam guide and reporting requirements; reviewed getSH Home/AD flow. OffSec's Word/LibreOffice template is the baseline. Hexdump's Markdown/Org → Pandoc/LaTeX → PDF/7z generator is a viable optional workflow only after a full local rehearsal. Procedure: Stage 08.