8.1 Complete attacks and retain reproducible evidence

Strategy map | Master Notes | Operational index | Cheatsheets

Operate the attack as changing state. Keep coverage questions separate from vulnerability hypotheses, select tests that resolve an uncertainty, re-enumerate after transitions and preserve enough evidence to reproduce each step.

Speedrun blocks: 15. Documented methods: 5.

Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.

8.1.1 First pass: tools and findings

Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.

8.1.1.1 Capture the access transition while it is reproducible

Keep commands/output, host and identity beside the transition that produced them.

hostname
id
ip addr

• If A new identity, host or route: Re-enumerate from that exact new position. → Maintain state and select the next evidence-producing test.
• If The final objective is evidenced: Build the report from the reproducible chain. → Build and validate the report and submission artifacts.
• Otherwise: A transition lacks proof: repeat its specific verification before connecting it to another method. → Integrate a standalone or assumed-breach AD attack.

8.1.1.2 When stuck, return to the last working boundary

Preserve the working session/route. Change one failed layer at a time.

LAST WORKING STATE | FIRST FAILED BOUNDARY | EXACT ERROR | CHANGED CONDITION | DISCRIMINATING TEST

• If Authentication works but an action is denied: Inspect service/object authorization under that same identity. → Match route, destination service and effective authorization.
• If A new credential or route has not been used for enumeration: Update the host/identity/route state and revisit the accessible surface. → Maintain state and select the next evidence-producing test.
• Otherwise: Several guesses added no evidence: switch to a missing enumeration check, not a more exotic payload. → Validate uncertain results and rebuild the service queue.

8.1.2 Discovery workflow

Start with assigned scope/objectives and saved observations; no complete path or report-ready evidence is assumed.

Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.

1. Record hosts, identities, material, routes and unresolved questions: Maintain state and select the next evidence-producing test.
2. Connect only methods whose receiving prerequisites have evidence: Integrate a standalone or assumed-breach AD attack.
3. Return to the last working state when tests stop producing new evidence: Recover from dead ends without repeating disproven paths.
4. Capture each transition and validate rendered report/archive artifacts: Capture state-transition, proof and exploit-adaptation evidence; Build and validate the report and submission artifacts.

Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.

8.1.3 Method families

• State, chain selection and recovery: Maintain state and select the next evidence-producing test, Integrate a standalone or assumed-breach AD attack, Recover from dead ends without repeating disproven paths.
• Transition evidence and reporting: Capture state-transition, proof and exploit-adaptation evidence, Build and validate the report and submission artifacts.

8.1.4 Choose a method

8.1.5 Maintain state and select the next evidence-producing test

Blocks: 15. Operational procedure | Operational procedure | Operational procedure | Operational procedure | Quick sheet

8.1.5.1 Purpose and result

A ranked, reproducible next-test decision with separate coverage and hypothesis queues.

8.1.5.2 Recognition clues

Several hosts, identities, routes or competing hypotheses need coordination.

8.1.5.2.1 Find the clue from your starting access

Where to investigate: Inspect the current private host/identity/route notes and compare each proposed action with a named unresolved question.

Discovery action — reference example:

Access/context: An assigned objective, scope and accumulated host/identity/route evidence

For each candidate record:
HOST | IDENTITY | ROUTE | OBSERVED CAPABILITY | MISSING CONDITION | NEXT DISCRIMINATING TEST

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Candidate A: writable object; consumer unknown
Candidate B: permitted operation; trigger verified
Coverage gap: unexamined service

Recognize this detail: The ledger distinguishes an unvalidated hypothesis from an enabled candidate and a missing coverage question.

Still missing before method selection: Verify the next test resolves a stated uncertainty and its expected outcomes change the decision.

If you do not yet have this clue: start with this topic's discovery workflow.

8.1.5.3 Prerequisites

Starting access: An assigned objective, scope and accumulated host/identity/route evidence. Required conditions: Explicit scope/objective and a record of observations, unknowns and available capabilities.

8.1.5.4 Discover and verify prerequisites

HOST | IDENTITY | CREDENTIAL TYPE | ROUTE | OBSERVATION | HYPOTHESIS | MISSING PREREQUISITE | NEXT TEST

8.1.5.5 Why it works

A route, credential or privilege change modifies the attack state. Coverage tests discover available behavior; hypothesis tests discriminate a proposed weakness. Mixing them hides missing prerequisites.

8.1.5.6 Execute and choose variants

Before interacting with a target, record:

scope and explicit exclusions
objective and required evidence
starting identity/credential and whether it is local, domain or application scoped
source host, interface, route and DNS context
allowed/restricted tools and the current Metasploit target decision
case directory and note/evidence locations
cleanup or restoration obligations

An interesting vulnerability is not automatically the objective. The attack is complete only when the required access or privilege is verified and the reproduction/evidence chain is retained.

Create a private case workspace using target-neutral names until the real scope is known:

mkdir -p case/{00-admin,01-scans,02-services,03-web,04-exploits,05-loot,06-sessions,07-screenshots,08-report}
touch case/00-admin/{scope.md,state.md,credentials.md,routes.md,hypotheses.md,transitions.md}

Do not put exam or private target material in a public repository.

Keep target-specific values in a private case/lab record, not this public repository.

HOSTS
- host/IP | role | reachable from | open services | evidence file

IDENTITIES
- local/domain identity | credential type | validated services | privilege | source

ROUTES
- source -> listener/tunnel -> pivot -> destination | DNS point | callback path

HYPOTHESES
- observation | hypothesis | prerequisite | next discriminating test | status

TRANSITIONS
- old state -> action -> new access/identity/route | decisive output | evidence

EVIDENCE COVERAGE
- objective | reproduction complete? | identity/IP proof? | screenshot? | panel/task state

Label each claim observed, inferred, possible, confirmed, disproven or inconclusive. Close a path only with a test that addressed its prerequisite; do not confuse a tool error with a disproven attack hypothesis.

Observe
→ Enumerate
→ Interpret
→ Hypothesize
→ Validate prerequisite
→ Exploit the confirmed primitive
→ Verify the new state
→ Re-enumerate from that state
→ Escalate, move or pivot
→ Capture evidence and cleanup

The sequence is a loop, not a one-time checklist. A state change routes work back to the relevant earlier stage:

8.1.5.6.1.1 Keep two queues

The coverage queue prevents missed surfaces:

host/source position → endpoint → confirmed application → required enumeration → state

The hypothesis queue prevents random exploitation:

observation → possible transition → prerequisite → cheapest discriminating test
→ decisive success/failure → next action

Do not spend the whole assessment deepening one hypothesis while high-value coverage remains unknown. Conversely, do not keep scanning after a confirmed path only to avoid validating it.

Create one card per distinct mechanism:

Observation:
Desired state transition:
Required prerequisites:
Already confirmed:
Still unknown:
Cheapest discriminating test:
Success means:
Failure means:
Noise/change/cleanup:
Handoff if successful:
Status/evidence:

Rank without false numerical precision:

1. Confirmed prerequisite, direct objective transition. Test first.
2. Strong observation, one cheap missing prerequisite. Validate next.
3. Useful information path. Prefer when it can unlock several branches.
4. Multiple unsupported assumptions or disruptive action. Defer.
5. Disproven prerequisite. Close until new evidence changes it.

Evidence strength overrides technique popularity. Prefer low-cost tests that split plausible explanations and create reusable information. A path that succeeds only after several unverified assumptions is not yet a high-priority path.

8.1.5.7 Worked example — hypothetical

Observation: three candidates exist but only one has a verified trigger. Test: compare required access, missing conditions, likely gain and reversibility. Illustrative output: the trigger-backed candidate is selected. Interpretation: the choice follows evidence rather than tool familiarity.

8.1.5.8 Verify the result

Every proposed action must name the uncertainty it resolves and the result that changes the decision.

8.1.5.9 Failure and fallback

An untested assumption must remain possible/inferred, not confirmed. Record disproven contexts to avoid repeating them without new evidence.

8.1.5.10 Continue from the interpreted result

8.1.6 Integrate a standalone or assumed-breach AD attack

Blocks: 15. Operational procedure | Operational procedure | Quick sheet

8.1.6.1 Purpose and result

A coherent chain of verified capability transitions.

8.1.6.2 Recognition clues

Individual techniques are understood but the full path must be selected independently.

8.1.6.2.1 Find the clue from your starting access

Where to investigate: Take the current verified capability and compare it with the receiving method's starting access and missing conditions.

Discovery action — reference example:

Access/context: An assigned objective, scope and accumulated host/identity/route evidence

CURRENT RESULT -> CANDIDATE NEXT METHOD -> REQUIRED INPUT -> MISSING PROOF

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Result: file read
Proposed next step: SSH
Missing input: usable key/password and matched user

Recognize this detail: A file read does not itself create a shell; the chain needs an actual credential/identity transition.

Still missing before method selection: Verify every produced material type, account, route and service-specific right before connecting the next step.

If you do not yet have this clue: start with Maintain state and select the next evidence-producing test.

8.1.6.3 Prerequisites

Starting access: An assigned objective, scope and accumulated host/identity/route evidence. Required conditions: An assigned objective and current host/identity/route map; each next method's enabling conditions must be produced or discovered.

8.1.6.4 Discover and verify prerequisites

OBSERVATION -> ENABLED METHOD -> VERIFIED CAPABILITY -> NEW STATE -> RE-ENUMERATION

8.1.6.5 Why it works

A chain is connected by capabilities, not chapter order. File read may produce a key, a session may expose another subnet, and a new identity returns to authenticated enumeration.

8.1.6.6 Execute and choose variants

Use the earlier procedure linked at each transition; the integration layer owns order and state:

1. Record scope, objective, source position and evidence requirements.
2. Establish TCP coverage, bounded UDP coverage and confirmed application identities.
3. Enumerate every confirmed service in its anonymous/current context; map web requests, hosts, parameters, content and roles.
4. Search files, configuration, repositories and application data for identities or prerequisites.
5. Build candidate cards for manual application weaknesses, compatible credentials and exact public-exploit prerequisites.
6. Validate one prerequisite at a time and prove the smallest useful effect.
7. Convert execution into a verified session; record host, identity, privilege, interfaces and routes.
8. Capture the initial-access transition and any required unprivileged objective before changing state.
9. Enumerate local privilege paths as controlled object → effective permission → privileged consumer → trigger → effect.
10. Verify the elevated identity, capture required evidence, re-enumerate protected context and remove exercise artifacts.
11. Reconstruct the ordered reproduction path while the commands and assumptions are still known.

Failure at a step returns to its owning block. Do not skip service enumeration because one banner suggests a CVE, and do not start privilege escalation before proving which host and identity the shell represents.

starting credential
→ local/domain identity + DNS/time/DC context
→ reachable host/service map
→ users/groups/computers/shares/SPNs/ACLs/sessions
→ ranked identity or host transition
→ compatible password/hash/ticket use
→ verified session/new identity
→ re-enumeration
→ route/movement to next host
→ higher domain privilege/objective

Keep five variables together for every edge:

controlled identity
effective group/right
target object or host
required protocol/route
resulting identity/access

BloodHound and enumerators generate candidate edges. Validate the underlying group membership, ACL, session, service right, route and authentication material before acting. After every new identity or host session, repeat authenticated enumeration rather than continuing from the old authorization view.

For multihop work, maintain a route diagram and a separate callback diagram. A route that permits an operator tool to reach a service does not prove that a payload can return to its handler.

8.1.6.7 Worked example — hypothetical

Observation: a web read yields an application credential. Test: validate its source identity, then justified SSH reuse. Illustrative output: SSH gives a Linux foothold whose sudo rule enables a root transition. Interpretation: retain separate evidence for read, authentication, session and privilege.

8.1.6.8 Verify the result

For every transition record its prerequisite evidence and independently verified effect; no step is complete because the next tool launched.

8.1.6.9 Failure and fallback

A broken route or invalid account context can halt an otherwise plausible chain. Return to the first unmet prerequisite.

8.1.6.10 Continue from the interpreted result

8.1.7 Recover from dead ends without repeating disproven paths

Blocks: 15. Operational procedure | Quick sheet

8.1.7.1 Purpose and result

A targeted recovery test or a justified switch to another candidate.

8.1.7.2 Recognition clues

Repeated attempts add no new evidence or several layers have been changed at once.

8.1.7.2.1 Find the clue from your starting access

Where to investigate: Compare recent attempts with the last saved working state and classify the first newly introduced boundary.

Discovery action — reference example:

Access/context: An assigned objective, scope and accumulated host/identity/route evidence

LAST VERIFIED STATE | FIRST NEW FAILURE | EXACT ERROR | CHANGED CONDITION | NEXT CONTROL

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Last working: target command identity proof
New failure: artifact download has no server request
Recent changes: several payload variants

Recognize this detail: Repeated payload changes are not testing the first missing transfer/route condition.

Still missing before method selection: Reproduce the last proof and isolate one new condition at a time; preserve rejected paths and return conditions.

If you do not yet have this clue: start with Maintain state and select the next evidence-producing test.

8.1.7.3 Prerequisites

Starting access: An assigned objective, scope and accumulated host/identity/route evidence. Required conditions: A saved last-known-working state, recorded errors and a bounded next uncertainty.

8.1.7.4 Discover and verify prerequisites

LAST WORKING STATE | FIRST FAILED BOUNDARY | EXACT ERROR | CHANGED CONDITION | DISCRIMINATING TEST

8.1.7.5 Why it works

Tool/environment failure and target evidence must be separated. Re-enumeration after a new credential/route is often more valuable than repeating a disproven exploit under unchanged conditions.

8.1.7.6 Execute and choose variants

Treat stagnation as a state problem, not an instruction to try more commands. Warning signs include unchanged evidence, repeated disproven tests, increasingly exotic mechanisms, tool switching without a new hypothesis, and work whose success would not advance the objective.

When progress stalls:

1. Freeze the current host/identity/route/credential map.
2. Mark each path with the last decisive result.
3. Recheck scan/service/application coverage and authenticated views.
4. Separate environment/tool failure from a disproven prerequisite.
5. Choose the cheapest test that can change the decision.
6. Switch paths when the expected information gain is higher.
7. Return only when new evidence changes an assumption.

Use this failure router:

8.1.7.7 Worked example — hypothetical

Observation: successive payload changes have no effect. Test: return to the last working command proof and verify the first new boundary. Illustrative output: the download route is absent. Interpretation: repair transfer connectivity instead of swapping exploit families.

8.1.7.8 Verify the result

The recovery action should create new evidence and preserve the reason an old path was rejected.

8.1.7.9 Failure and fallback

If the same prerequisite remains absent, switch to an enabled path and retain a clear return condition.

8.1.7.10 Continue from the interpreted result

8.1.8 Capture state-transition, proof and exploit-adaptation evidence

Blocks: 15. Operational procedure | Operational procedure | Operational procedure | Operational procedure | Operational procedure | Quick sheet

8.1.8.1 Purpose and result

A private reproducible transition record with commands, output, identity and effect.

8.1.8.2 Recognition clues

Access, privilege, identity or route changes, or a report will need reproduction.

8.1.8.2.1 Find the clue from your starting access

Where to investigate: At every observed access/identity/privilege change inspect whether saved output ties the effect to the correct host, token and command/request.

Discovery action — reference example:

Access/context: An assigned objective, scope and accumulated host/identity/route evidence

hostname
id
ip addr

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Saved record: command and output present
Host/identity: recorded
Route and reproduction parameters: missing

Recognize this detail: A success screenshot or identity line can be real while the reproduction path is incomplete.

Still missing before method selection: Capture the exact source/destination, method, material context, transition, relevant proof and adaptation steps privately.

If you do not yet have this clue: start with Maintain state and select the next evidence-producing test.

8.1.8.3 Prerequisites

Starting access: An assigned objective, scope and accumulated host/identity/route evidence. Required conditions: Known destination/identity, observable effect and a private evidence destination; actual exam proof requirements must be read from current official guidance.

8.1.8.4 Discover and verify prerequisites

hostname
id
ip addr

8.1.8.5 Why it works

A proof screenshot establishes a narrow state; reproduction also needs the preceding request/command, parameters, exploit changes and route. Evidence captured during the transition is more reliable than later reconstruction.

8.1.8.6 Execute and choose variants

Linux:

date -Is
hostname
id
ip addr
ip route

Windows:

echo %DATE% %TIME%
hostname
whoami /all
ipconfig /all
route print

For each access or escalation, retain:

1. the observation that selected the path;
2. the exact command/request with secrets redacted in the reusable copy;
3. relevant output or response;
4. host and identity verification;
5. the effect/new capability;
6. cleanup/restoration; and
7. the next re-enumeration result.

Use a compact transition packet:

time/timezone | source host/interface | target host/service | starting identity
observation | prerequisite | exact action | decisive output
new identity/access/route | evidence files | cleanup | next re-enumeration

Capture the transition when it happens. Reconstructing it later risks losing a required token, request, route, working directory, listener or source identity.

mkdir -p evidence/nmap evidence/web evidence/loot evidence/screenshots
nmap -Pn -sV -sC -p PORTS TARGET -oA evidence/nmap/TARGET-services
script -q -f evidence/session.txt

Run exit when finished so the transcript closes and flushes. Do not record unrelated secrets in a broad transcript.

Start-Transcript -Path .\evidence\powershell-session.txt
# commands
Stop-Transcript

Hash important transferred or generated artifacts:

sha256sum FILE | tee FILE.sha256

Never publish credentials, flags, target IPs, full private transcripts or copyrighted course text to this repository.

Current official exam guidance requires proof-file content to be displayed from its original location in an interactive target shell and included in a screenshot with the target IP. The control-panel submission is separate and must occur before the exam ends. Recheck the guide immediately before an exam because these rules can change.

Linux example layout:

hostname; id; ip addr
cat /root/proof.txt

Windows example layout:

hostname & whoami & ipconfig
type C:\Users\Administrator\Desktop\proof.txt

Use the actual objective-provided path and required identity. Do not use AI on actual exam targets, proofs or reports; the current guide prohibits AI chatbots during the exam.

For an unmodified exploit, retain its source URL rather than pasting pages of code. For a modified exploit, retain:

• original URL and version/commit;
• local modified copy;
• a focused diff/highlight of changes;
• why each change was necessary;
• build/interpreter command and dependencies;
• payload-generation command, if any; and
• exact execution and result verification.

git diff --no-index original.py modified.py > exploit-changes.diff
sha256sum original.py modified.py

### Objective / result

**Starting state:** source host, network position and identity.

1. Observation and evidence.
2. Enumeration command/request and decisive output.
3. Vulnerability/prerequisite validation.
4. Exploitation command/request, including required listener/route.
5. Session verification: host, identity and privilege.
6. Escalation evidence and final verification.
7. Cleanup/restoration.

**Artifacts:** screenshots, saved output, hashes and exploit source/diff.

Write steps in execution order. Explain why a command was needed and what the output established; a transcript alone is not a report.

8.1.8.7 Worked example — hypothetical

Observation: a higher-privilege session appears. Test: capture host, identity, relevant interface and the objective evidence immediately. Illustrative output: the transition can be replayed from retained commands and saved output. Interpretation: report it as the verified effect only.

8.1.8.8 Verify the result

Tie evidence to the correct target and transition, with no invented success or missing reproduction step.

8.1.8.9 Failure and fallback

A screenshot without identity/target context or an exploit success string without effect is incomplete. Keep real targets, credentials and proofs private.

8.1.8.10 Continue from the interpreted result

8.1.9 Build and validate the report and submission artifacts

Blocks: 15. Operational procedure | Operational procedure | Operational procedure | Quick sheet

8.1.9.1 Purpose and result

A readable, reproducible report and a validated local submission artifact.

8.1.9.2 Recognition clues

Verified findings and private transition evidence are ready for reporting.

8.1.9.2.1 Find the clue from your starting access

Where to investigate: Inspect the report rendered from retained transitions and the actual archive contents; export success is only one part of readiness.

Discovery action — reference example:

Access/context: An assigned objective, scope and accumulated host/identity/route evidence

pdfinfo REPORT.pdf
7z l REPORT.7z
md5sum REPORT.7z

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

PDF: opens; page count available
Archive: contains REPORT.pdf
Rendered review: a command is clipped

Recognize this detail: The container is valid while a reproduction instruction is unreadable; inspect rendered content as well as file structure.

Still missing before method selection: Verify complete reproduction, legible pages, current required names/content and upload/local checksum when applicable.

If you do not yet have this clue: start with Maintain state and select the next evidence-producing test.

8.1.9.3 Prerequisites

Starting access: An assigned objective, scope and accumulated host/identity/route evidence. Required conditions: Complete reproduction path, required screenshots/proofs, suitable document tooling and the current submission naming/archive rules.

8.1.9.4 Discover and verify prerequisites

pdfinfo REPORT.pdf
7z l REPORT.7z
md5sum REPORT.7z

8.1.9.5 Why it works

Report generation and rendered correctness differ. A valid archive can contain an unreadable or incomplete PDF; inspect rendered pages, file names, archive contents and checksums separately.

8.1.9.6 Execute and choose variants

For every achieved objective, the report path should read:

starting state and scope
→ decisive enumeration
→ prerequisite/vulnerability validation
→ exact exploitation action
→ session/identity verification
→ privilege or movement transition
→ final objective evidence
→ cleanup/restoration

Include only enough non-decisive enumeration to make the selection understandable. Screenshots need captions and nearby interpretation; they do not replace commands or prose. Raw transcripts are supporting artifacts, not the final narrative.

Current official exam grading follows the target order used in the report. Keep target/objective labels aligned with the control panel and place each target's complete chain together.

Recheck the current guide immediately before a mock or exam. The current baseline is one PDF inside a non-password-protected .7z, exact case-sensitive filenames and an archive no larger than 200 MB:

7z a OSCP-OS-XXXXX-Exam-Report.7z OSCP-OS-XXXXX-Exam-Report.pdf
7z l OSCP-OS-XXXXX-Exam-Report.7z
7z t OSCP-OS-XXXXX-Exam-Report.7z
md5sum OSCP-OS-XXXXX-Exam-Report.7z

Windows hash fallback for a local rehearsal:

Get-FileHash -Algorithm MD5 -LiteralPath '.\OSCP-OS-XXXXX-Exam-Report.7z'

Inspect every exported PDF page before archiving. Confirm that code is not clipped, screenshots remain readable, captions match the correct target and the archive contains only the required PDF. Required scripts and PoCs belong as text inside that PDF, not as extra archive members. The current guide recommends creating/uploading from Kali and warns of a Windows 11 archive compatibility issue. Compare the local MD5 with the upload site's value, click the final submission control and retain the acknowledgement.

The official Word or LibreOffice template is the reliable baseline. A Markdown/Pandoc pipeline, including Hexdump's report/ generator, is a viable alternative only after a complete dummy export/archive rehearsal; do not install or debug a new report stack during an assessment.

• Commands are copyable and placeholders/secrets are resolved in the private report.
• Screenshots are legible and show required identity/IP/proof context.
• Every claim is supported by nearby evidence.
• Target order and objective labels match the control panel.
• Exploit modifications and payload-generation steps are documented.
• The final PDF is visually reviewed after export.
• Archive name/format/size and upload hash match current official requirements.

8.1.9.7 Worked example — hypothetical

Observation: the PDF export succeeds. Test: inspect every rendered page and archive contents. Illustrative output: one command is clipped despite a valid PDF. Interpretation: correct layout and regenerate before the final artifact checks.

8.1.9.8 Verify the result

Verify reproduction, legible pages, correct required names/content and matching local/upload checksum when applicable.

8.1.9.9 Failure and fallback

Do not infer acceptance from successful compression. Actual exam and report-writing phases prohibit AI assistance; use the prepared general notes independently.

8.1.9.10 Continue from the interpreted result

8.1.10 Sources and shared concepts

Supplied PEN-200 Ch 5 pp94–113 and Ch 27 pp963–1017. Official reporting requirements, exam guide.

Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.