OSCP Exam Report Template: Document Evidence to Pass

You rooted the box at 3:00 AM but your OSCP exam report template has no screenshot to prove it. That machine doesn’t count.

Technical success without documentation is zero in this exam. Graders can’t award credit for a step they can’t see in the submitted PDF. OffSec’s grading policy is consistent on this: if an exploitation step isn’t documented with clear evidence, it’s treated as not performed, no matter what flag you submitted.

That makes your reporting workflow as much a technical constraint as your enumeration methodology during the 24-hour window. Treat the report template as part of the exploit chain, not paperwork you do afterward. Every command you run should generate evidence you can drop into the report before you move to the next target.

Why Your OSCP Exam Report Template Determines Pass or Fail

Graders score against a rubric where partial credit depends on visible proof of work, not the final flag value. Run a flawless kernel exploit, and if the terminal output is truncated or the IP is cropped out of frame, that machine effectively doesn’t exist in your results. The grading team works through hundreds of reports a week. They will not reconstruct missing context or assume competence because you got the right hash.

Documentation gaps are the main reason candidates fail despite getting root on enough machines to pass. This isn’t a pitch for automated report generators, black-box tooling tends to produce submissions that don’t match current formatting standards, and you won’t understand your own report well enough to defend it if something’s flagged. You own every line and every image in the submission. Build the template to capture evidence at the moment of exploitation, not hours later when you’re tired and trying to remember what you did.

Mandatory Sections in the Current OSCP Exam Report Template

PEN-200’s current guidelines enforce a structure that separates high-level findings from step-by-step technical reproduction. Deviating from it risks confusing the grader, or worse, an automatic non-compliance failure. Check your section headers against the official course PDF before you write a word.

Executive Summary vs Technical Narrative

The executive summary has to read for non-technical stakeholders. The technical narrative carries the exhaustive reproduction steps a security engineer would need. Blur the two together and you create ambiguity about whether you understand business impact versus technical mechanism, and that’s a specific line item graders check. Keep risk ratings and compromised-asset counts in the summary. Save command syntax and vulnerability analysis for the technical body, where graders actually validate your methodology.

Required Evidence Artifacts per Machine

Every compromised machine needs three artifacts: a screenshot of the initial foothold showing the target IP, a screenshot of the privilege escalation step, and the contents of both local.txt and proof.txt. Miss one and the whole machine is invalid, regardless of the flag hash you submitted through the portal. Capture these as you go. Sessions die, environments reset, and reconstructing evidence after the fact often just doesn’t work.

Documenting Exploitation Chains Without Losing Points

Complex attacks need deliberate visual pacing so the grader can follow your logic without guessing how you chained separate vulnerabilities together. A wall of text buries the methodology. Too much whitespace burns page count you don’t have. Balance the narrative with clearly labeled evidence blocks that map to each step of the attack path.

Screenshot Standards and Readability

Terminal captures need the full prompt visible, username and hostname both, to prove execution context on the target. Blurry images or dark themes with low contrast are a recurring failure point, because graders can’t verify the flags or file paths you’re referencing in the text next to them. Use light backgrounds with high-contrast text, and keep the timestamp or session identifier visible across captures so continuity is obvious.

Handling Multi-Step Pivots and Tunnels

Lateral movement needs the network topology change shown at each hop, not just a shell on the final box with no explanation of how you got there. Skip the tunnel configuration or pivot technique and graders read it as a gap in understanding, not a shortcut. Sketch simple ASCII diagrams or annotated network maps labeling each interface, port forward, and credential used in the pivot sequence, so the reviewer isn’t reconstructing your path in their head.

Formatting Commands and Tool Output

Raw terminal dumps bury the commands that actually matter in noise. Curate the output down to the lines that show successful exploitation or key discovery. Stabilize your reverse shells before you start capturing evidence, an unstable PTY produces garbled output, and that reads as sloppy operational discipline as much as it reads as unreadable. Format commands in monospaced code blocks with language tags. Never inline a multi-flag command into a paragraph where it’s hard to parse or copy.

# Example of properly formatted evidence block
whoami && hostname && ipconfig | findstr IPv4
nt authoritysystem
DC01
IPv4 Address. . . . . . . . . . . : 192.168.50.70

Active Directory Attack Documentation Requirements

The AD set carries disproportionate weight in scoring and needs more rigorous evidence than a standalone machine, because the attack chain itself is more complex. Community exam-experience reports consistently mention the same mistake: candidates submit the final Domain Admin hash and nothing else, with no record of the Kerberoasting or DCSync commands that got them there. That reads as incomplete mastery of the chain, even when the compromise itself was clean.

Proving Domain Admin Access

Domain compromise needs the full path shown, from initial domain user to full administrative control, not just the destination credentials. Document every permission abuse, group membership change, or delegation attack that moved you up the chain. The grader needs to see you understood the mechanism, not that you stumbled into admin rights. Screenshot the BloodHound queries, the LDAP enumeration commands, and any custom scripts that identified the attack vector, alongside the final exploitation proof.

Capturing BloodHound and Kerberos Evidence

Annotate BloodHound graphs with your specific attack path highlighted. A raw, unprocessed data dump doesn’t show your reasoning, it just shows the tool ran. Kerberos attacks like AS-REP roasting or ticket forging need both the request command and the resulting ticket or hash shown, so it’s clear you ran the attack yourself rather than pasting a precomputed value. Give your template dedicated subsections for AD-specific artifacts. Cramming them into the generic machine template creates structural confusion, and that costs points on its own.

Common Reporting Mistakes That Trigger Retakes

Administrative errors cause more retakes than skill gaps do, because candidates spend all their attention on exploitation and none on submission hygiene until the deadline is on top of them. Unreadable terminal text, a missing local.txt, a wrong file name, none of that has anything to do with hacking ability. It’s attention to detail under pressure, and it’s entirely preventable.

A corrupted PDF or a forgotten archive password burns the whole attempt regardless of how well you actually hacked. There’s no fixing this after the fact: OffSec requires the exam report submitted within 24 hours of the exam end time, and there are no extensions for formatting corrections or missing evidence. Build validation checks into the template itself, so structural compliance happens while you draft, not during a panicked review in the last hour.

Adapting Legacy Templates for 2026 Exam Changes

Templates shared in previous years often skip sections for newer exam components, like the updated Active Directory set or evidence requirements that changed in recent course updates. An outdated structure signals to the grader that you didn’t engage with current materials, and that costs you credibility even when your exploitation skills are solid. Check any downloaded template against the official PEN-200 course PDF before you use it, and read the changelog notes for anything about documentation requirements that shifted between versions.

Legacy templates can also reference deprecated tools or retired lab machines that no longer show up in the current environment, which just leaves dead sections wasting space and confusing reviewers. Cross-reference your template’s placeholder content against current OSCP study resources instead of trusting a community repo that hasn’t been touched since the last exam revision. An obsolete template costs you a failed attempt and a retake fee. Thirty minutes checking your structure against the source is cheap by comparison.

Post-Exam Report Submission and Validation Checklist

Do your final review before you encrypt the archive, you can’t touch it after it’s sealed, so this is the last chance to catch a fatal error. Run a checklist: file naming, screenshot legibility, consistent command formatting, and every required artifact present for every compromised machine. Then decrypt the archive on a clean system to confirm the password works and the PDF renders without corruption or missing pages.

Check your submission timestamp against the timezone difference between your clock and the OffSec portal server. An accidental late submission voids the attempt over nothing. Match every flag hash in the report against what you submitted through the portal, exactly, a transcription error between the two creates a discrepancy that triggers manual review delays, or rejection outright. This pass takes twenty minutes. It beats weeks waiting on a retake slot because of an oversight the template should have caught for you.