Integrated Attack Tracking and Evidence

← Stage index | Quick sheet | Master Notes | Strategy map | Study methods: Complete attacks and retain reproducible evidence

Goal: finish an unfamiliar scoped target by keeping the current attack state, candidate paths and required evidence synchronized. This is the integration procedure for the earlier stages; it does not replace their service- and technique-specific procedures.

Establish the operating contract

Before interacting with a target, record:

Copyscope 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:

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

Maintain a live state map

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

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

Run the attack as a state machine

CopyObserve
→ 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:

Keep two queues

The coverage queue prevents missed surfaces:

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

The hypothesis queue prevents random exploitation:

Copyobservation → 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.

Rank candidate paths

Create one card per distinct mechanism:

CopyObservation:
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.

Standalone attack workflow

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.

Assumed-breach AD workflow

Copystarting 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:

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

Capture every state transition

Linux:

Copydate -Is
hostname
id
ip addr
ip route

Windows:

Copyecho %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:

Copytime/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.

Save tool output deliberately

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

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

Hash important transferred or generated artifacts:

Copysha256sum FILE | tee FILE.sha256

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

Proof/evidence checkpoint

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:

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

Windows example layout:

Copyhostname & 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.

Public exploit evidence

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.

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

Reproduction-path template

Copy### 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.

Dead-end recovery

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:

Build the report from transitions

For every achieved objective, the report path should read:

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

Final PDF and archive validation

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:

Copy7z 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:

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

Final quality checks

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

Tooling for this section

No new attack tool is required for Block 15. The value comes from disciplined state/evidence handling around the tools already taught.

Sources

• Supplied PEN-200 Chapter 27 pp. 963–1017, especially pp. 963–968 and 1015–1016; Chapter 5 pp. 94–113.
• getSH Home and AD flow, source snapshot e1f62dd
• Current OSCP+ exam guide
• Current OSCP+ reporting requirements
• Hexdump report workflow: optional Markdown/Org → Pandoc/LaTeX → PDF/7z path; use only after local rehearsal.