OSCP Report Template: What to Include and How to Stand Out

---

The OSCP exam is 24 hours of hacking followed by another 24 hours to write and submit the report. Most candidates spend months preparing for the hacking portion. Far fewer prepare for the report.

That is a mistake. Offensive Security evaluates reports manually. If a reviewer cannot follow your exploitation chain, you do not get credit for the machine. Fail on enough machines this way and you fail the exam with points you actually earned sitting on the table.

This guide covers the OSCP report structure, what OffSec actually needs to see, the most common mistakes candidates make, and how to format a report that is both passing-grade and genuinely clear.

---

What OffSec requires (and what costs you points)

Before anything else: read the current OffSec exam guide for your version of OSCP. The exam structure has evolved over time. As of the current format, the exam includes three standalone machines worth 20 points each and an Active Directory set worth 40 points. Passing score is 70 points.

The report requirements that matter most:

Proof files. For each machine, you need a screenshot showing the proof.txt (or local.txt) file contents alongside the target IP address and your own hostname in the same frame. That means running hostname or ipconfig in the same terminal window as your cat proof.txt or type proof.txt output. Not two separate screenshots. Not a cropped image where the IP is cut off. One frame with all three visible: your hostname, the target IP, and the flag.

Full exploitation walkthrough. Your report needs to document the complete chain from initial access to privilege escalation for every machine you are claiming points for. OffSec reviewers need to be able to reproduce what you did. That means exact commands, exact payloads, and exact parameters -- not "I used a SQL injection" but the actual request and the payload that worked.

Lab report (optional but worth it). If you completed 30 PWK course exercises and documented 10 unique lab machines with proof screenshots, you are eligible for 10 bonus points. The lab report is submitted separately alongside the exam report. If you are close to the passing threshold, those 10 points are worth the documentation work.

---

The OSCP report structure

OffSec provides an official report template on the student portal. Use it, or use a template that matches its structure closely. The naming convention for the submitted PDF is OSCP-OS-XXXXX-Exam-Report.pdf where XXXXX is your student ID. Get this right before you submit.

Cover page

Student name, OSCP student ID, exam date, and report submission date. Administrative. Clean it up, match the required naming convention, move on.

Introduction

One short paragraph. What exam was taken, when, and what this document covers. Candidates sometimes write half a page here explaining what OSCP is. OffSec reviewers know what OSCP is.

High-level summary

A table covering which machines you compromised and at what level:

This gives reviewers an immediate picture before they read any detail, and tells them which sections need close attention.

Methodology

Half a page covering your general approach: enumeration tools used (Nmap, Gobuster, Feroxbuster, etc.), your overall testing methodology, and any relevant notes about the testing environment. This section exists for completeness, not for demonstrating expertise. Keep it brief.

Individual machine writeups

This is where the report is won or lost.

Each machine gets its own clearly labeled section. Within each section, document in order:

Initial enumeration. Show your port scan. Include the Nmap command you ran, not just the results. If you ran additional scans (Gobuster, enum4linux, Feroxbuster), show those too. Then explain what you found and what it told you about likely attack paths. Reviewers want to see your reasoning, not just the output.

Exploitation. Walk through the vulnerability and how you exploited it. Include:

• The specific vulnerability or misconfiguration
• Any public exploit used, with the CVE or ExploitDB reference
• Modifications you made to the exploit (paste the code change)
• The exact payload or command that worked
• A screenshot of the resulting shell

This section needs to be reproducible. If you used a Metasploit module, name it exactly. If you modified a Python exploit, show the diff. If you used a manual injection payload, include the full request.

Privilege escalation. Document the path from your initial shell to root or SYSTEM.

For Linux: show your enumeration output (what LinPEAS flagged, or what you found manually), the specific misconfiguration, and the exact commands that escalated your privileges.

For Windows: same structure. If you used token impersonation, a kernel exploit, credential harvesting, or a misconfigured service, document each step with the relevant commands and output.

Proof screenshot. The screenshot showing local.txt or proof.txt contents alongside the target IP and your hostname, all in the same frame. Put it at the end of each machine section. Reviewers should be able to find it immediately without searching the document.

Active Directory section

The AD set requires different documentation because it is a chained attack across multiple machines. Document the entire chain in sequence: initial foothold, lateral movement to each intermediate host, and final escalation to domain admin.

For each step in the chain, show the commands, explain why they worked, and include evidence. BloodHound graphs are genuinely useful here if you captured them during the exam -- they make the attack path clear at a glance. The required proof is the proof.txt from the domain controller, with the same hostname and IP requirements as the standalone machines.

---

Formatting choices that affect readability

Screenshots need surrounding context. A terminal screenshot without the command that produced the output does not tell reviewers much. Scroll up, or add a note explaining what the screenshot shows. If the output spans multiple screens, show the command and the relevant portion.

Include command output as text, not only screenshots. Paste critical Nmap output, tool results, and payloads as formatted code blocks in addition to screenshots. Text is searchable and can be read in a diff if a reviewer is comparing your report against another. An image of output cannot be copy-pasted for reproduction.

Number your steps. In exploitation and privilege escalation sections, numbered steps make the sequence unambiguous. "Step 1: I ran X. Step 2: I observed Y. Step 3: I ran Z." is clearer than prose that buries the order.

One section per machine, no exceptions. Reviewers read many reports. They are looking for a specific machine's documentation. If two machines are merged into one section, or if sections are out of order, you create friction that works against you.

---

Common OSCP report mistakes

Missing the hostname in proof screenshots. This is the single most common way candidates lose points they earned. You got root. You have the flag. You did not include the hostname in the same frame. Points gone. Retake the screenshot before the exam window closes.

Gaps in the exploitation chain. You describe finding a vulnerability on page 4, then show a root shell on page 7 with nothing in between. Reviewers cannot give full credit for a chain they cannot follow. Document every step even when it feels obvious.

Explaining what tools are instead of what you did with them. A paragraph about what Gobuster does, or a definition of privilege escalation, adds nothing. Reviewers know what the tools are. Get directly to the specific commands, specific findings, and specific exploitation steps.

Writing the report entirely from memory after the exam. The candidates who produce the strongest reports document as they go -- screenshots captured in real time, notes written immediately after each phase while the detail is fresh. Writing from memory the following morning means you will reconstruct payloads, forget exact parameters, and miss steps you took at 3am. Build documentation into your exam methodology, not after it.

---

Report quality versus professional pentest reports

OSCP is pass/fail. The report does not need to be polished -- it needs to be clear, complete, and reproducible. There is no need for an executive summary, no need for business impact framing, and no need for the kind of client-facing formatting that professional reports require.

That said, the core habits that make an OSCP report pass -- specific reproduction steps, evidence that matches the narrative, consistent structure across findings -- carry directly into professional work. The OSCP report is a good place to build those habits under time pressure.

For pentesters moving from certification into professional engagements, the reporting demands increase substantially. Professional clients expect executive summaries, risk framing, and polished output formatted for non-technical readers. That is where the documentation burden becomes a real time problem, and where tools like Pentellect change the equation: scanner imports, AI-drafted finding descriptions, and consistent output templates handle the repetitive structural work so you can focus on the analysis. But that is a different problem. For OSCP, clear documentation and valid proof screenshots are what the report needs to accomplish.

---

The short version

A passing OSCP report documents every compromise with enough detail to reproduce it and includes valid proof screenshots for every machine you are claiming credit for. Every point lost on report evaluation is a point you earned during the 24-hour exam and then gave back.

Prepare your template before the exam starts. Capture screenshots while you work. Document the chain, not just the outcome. And make sure the proof screenshot includes your hostname, the target IP address, and the flag contents -- all in the same frame, every time.