10.14 Integrated Attack and Reporting Cheatsheet

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

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:

10.14.14.1.2.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.

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

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

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

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.

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

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

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

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.

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

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

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

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.

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

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