The OSCP+ exam tests more than exploitation skill. It also tests whether you can explain what you did, prove it, and present it in a way an assessor can follow without guessing. That is where many candidates lose time and points. A report written under pressure can become messy fast: screenshots out of order, vague findings, missing proof, or remediation advice that says almost nothing. A good reporting template fixes that. It gives you a structure to follow when your brain is tired and the clock is running. In this guide, I’ll break down how to write findings and evidence clearly during an OSCP+ engagement, what to include in each section, how to word remediation so it sounds useful instead of generic, and how to run a final quality check before you submit. If you want to sharpen your workflow before exam day, the OSCP+ practice test is a practical way to rehearse both technical work and reporting discipline.
Why a reporting template matters in OSCP+
Under exam pressure, decision quality drops. You forget small details. You assume you will remember a command later, then you do not. A template reduces that risk because it turns reporting into a checklist instead of a creative task.
The main benefit is consistency. Every finding follows the same pattern. Every screenshot has a place. Every host and privilege level is recorded the same way. That matters because assessors are not inside your head. They only see what you submit. If they cannot trace your steps from vulnerability to proof to impact, your work becomes harder to validate.
A strong template also saves time. You do not want to think, “Where should I put this shell screenshot?” or “How should I phrase local privilege escalation?” while the exam is still active. You want sections ready in advance so you can drop in notes and evidence as you go.
Think of the template as part of your attack chain. Enumeration finds attack paths. Reporting preserves them.
A simple OSCP+ report structure that works
Your report should be easy to scan. The examiner should be able to move from high-level results to technical proof without effort. A practical structure usually looks like this:
- Executive Summary
- Scope and methodology
- Attack summary or system overview
- Detailed findings by target or vulnerability
- Evidence log and screenshots
- Remediation guidance
- Appendix with commands, hashes, payloads, and notes
This order works because it matches how people read. First, they want the result. Then they want the context. Then they want the proof.
If you are using an editable report template, build the headings in advance and leave placeholders for:
- Target IP / Hostname
- Finding title
- Severity or exam relevance
- Description
- Affected service / port / path
- Proof of exploitation
- Impact
- Remediation
- Screenshots referenced
- Commands used
This keeps your format stable even if the engagement gets chaotic.
How to write the executive summary without sounding vague
The executive summary should be short, but not empty. Many candidates write summaries that say almost nothing, such as “Several vulnerabilities were found and exploited.” That is true, but useless. The summary should answer three basic questions:
- What was achieved?
- How serious was it?
- What should be fixed first?
For an OSCP+ style report, the summary does not need business jargon. It should state which targets were compromised, whether initial access and privilege escalation were achieved, and what that means in practical terms.
For example:
During the assessment, three target systems were evaluated. Initial access was obtained on two systems through a web application flaw and weak service configuration. Administrative or root-level access was achieved on both compromised targets through local misconfigurations. The issues observed would allow an attacker to execute commands, access sensitive files, and fully control affected hosts. Priority should be given to fixing the exposed application flaw, removing unsafe privilege settings, and reviewing credential and service hardening.
Why does this work? Because it is specific. It tells the reader what happened, what the attacker gained, and where attention should go. It does not overstate. It does not hide behind buzzwords.
How to write findings clearly when time is tight
Each finding should read like a small story with a beginning, middle, and end. The reader should understand:
- What the weakness was
- Where it existed
- How it was exploited
- What access or impact it created
- How to fix it
A reliable finding structure is:
- Title: Clear and direct
- Description: What the issue is and why it exists
- Affected Asset: Host, port, endpoint, account, or file
- Evidence / Reproduction: Commands, requests, outputs, screenshots
- Impact: What an attacker can do because of it
- Remediation: Specific fix steps
Here is the key point: describe the vulnerability first, then describe your exploit path. Do not merge everything into one long paragraph. Under pressure, long paragraphs become unclear and hide missing details.
For example, instead of writing:
I found a web issue on port 80 and used it to get a shell, then escalated because sudo was misconfigured.
Break it out:
- Description: The web application on port 80 accepted unsanitized input in the file parameter, allowing command execution in the application context.
- Evidence: A crafted request triggered execution of the id command and returned the web server user context. A reverse shell payload then provided interactive access.
- Impact: Remote command execution allowed initial compromise of the host.
- Follow-on Finding: The compromised account could run a privileged binary via sudo without a password, allowing root access.
This is easier to read and easier to score.
What good evidence looks like
Evidence should prove your claim with the least amount of confusion. The examiner should not have to infer what a screenshot means. If a screenshot is included, it should show something specific and relevant.
Good evidence usually includes:
- The target identifier, such as IP or hostname
- The command or request used
- The result, such as a shell, file read, user context, or hash dump
- The privilege level, if relevant
- The flag or proof file, if required by exam rules
Bad evidence is often one of these:
- A screenshot with cropped context
- A terminal shot where the command is not visible
- An image with five different actions in one scrollback window and no explanation
- Output pasted without saying which host it belongs to
If possible, pair screenshots with short text. A screenshot alone can be ambiguous. A screenshot plus one sentence is much stronger.
Example:
Figure 4 shows successful command execution via the vulnerable parameter on 10.10.10.15. The response includes the result of the whoami command, confirming code execution as the web service account.
That one sentence removes doubt.
Build a screenshot log as you go
One of the easiest ways to lose reporting quality is to save screenshots with random names and sort them out later. Do not do that. Build a screenshot log during the exam.
A simple screenshot log can track:
- Screenshot ID: SS-01, SS-02, SS-03
- Target: 192.168.x.x or hostname
- Step: Enumeration, initial access, privesc, proof
- Description: What the screenshot proves
- File Name: Match the actual image file
For example:
- SS-07 — 10.10.10.15 — Initial Access — Reverse shell established as www-data — ss-07-www-data-shell.png
- SS-08 — 10.10.10.15 — Privilege Escalation — Sudo rights on vulnerable binary — ss-08-sudo-l.png
- SS-09 — 10.10.10.15 — Proof — Root shell and proof file — ss-09-root-proof.png
This helps for two reasons. First, you can quickly insert the right evidence into the right finding. Second, you can notice gaps before it is too late. If you have a screenshot for the root shell but none for the privilege escalation step, you know what is missing.
Keep the naming consistent. Use simple, sortable names. Do not rely on image files named by timestamp alone.
How much command detail should you include?
Include enough to make the attack reproducible, but not so much that the report becomes a wall of terminal output. The goal is clarity, not a raw dump of your notes.
In most findings, include:
- The key command or request that demonstrates the issue
- The output that proves success
- Any small adjustment needed to make the step understandable
You do not need to include every failed attempt. You do not need full nmap output in the middle of every finding if one line showing the exposed service is enough. Save bulky material for an appendix if it supports your process.
A good rule is this: if removing a command would make the exploit chain harder to follow, keep it. If it adds noise without helping the reader understand what happened, cut it.
How to write remediation guidance that sounds useful
Weak remediation is a common problem. Many reports say things like “Patch the system,” “Sanitize input,” or “Use least privilege.” Those statements are not wrong, but they are too broad on their own. Good remediation explains what should change and why that change reduces risk.
Strong remediation usually has three parts:
- The immediate fix
- The hardening step
- The validation step
For example, for command injection:
Remove the ability for user input to reach shell execution functions directly. Replace shell-based calls with safe internal application logic where possible. Apply strict allow-list input validation on the affected parameter and reject unexpected characters and command separators. Review the application for similar unsafe execution patterns and test that user-controlled input can no longer trigger system commands.
Why is this better than “sanitize input”? Because it tells the defender what to remove, what to enforce, and what to check afterward.
For a sudo misconfiguration:
Remove passwordless sudo access for the affected low-privilege account unless it is operationally required. If elevated command execution is needed, restrict access to a tightly controlled wrapper script or specific safe command set. Review all sudoers entries for wildcard use, shell escape paths, and binaries that permit arbitrary file or command execution.
This is practical. It shows that the issue is not just “bad sudo.” The real problem is unsafe privilege delegation.
Common reporting mistakes in OSCP+ submissions
Most weak reports fail in predictable ways. Knowing them helps you avoid them.
- Missing link between evidence and finding
The screenshot shows a shell, but the finding never explains how the shell was obtained. - Too much assumed knowledge
You know why a GTFOBins path worked. The reader may not if you do not explain the privilege condition. - Vague impact statements
Saying “this could be dangerous” is weaker than “this allows remote execution as the web server account.” - Poor screenshot quality
Tiny fonts, cropped windows, and cluttered terminals make proof hard to verify. - No host-level organization
When multiple targets are involved, mixing all commands together creates confusion. - Generic remediation
If the fix could apply to any vulnerability on any host, it is probably too generic.
The fix for all of these is structure. A template does not just make your report look professional. It catches missing logic.
A practical writing workflow during the exam
You should not leave all reporting until the end. That creates two problems: missing proof and poor memory. Instead, use a rolling workflow.
- Step 1: Start a host section as soon as you enumerate a target.
Record open ports, likely attack paths, and host identifiers. - Step 2: Capture evidence at each meaningful milestone.
Save screenshots for exploit confirmation, shell access, user context, privilege escalation, and proof files. - Step 3: Add rough notes immediately.
A short messy note now is better than a perfect forgotten note later. - Step 4: Clean each finding after the target is complete.
Once the host is done, convert rough notes into a structured finding while details are fresh. - Step 5: Do a final formatting pass at the end.
Use the last phase for consistency, not for rebuilding the entire story.
This workflow reduces panic. It also protects you if you run out of time near the end.
Final quality-control checklist before submission
Before you submit, review the report like an examiner would. Assume nothing. Check whether every claim is supported.
- Does the executive summary state what was compromised and why it matters?
- Does each finding identify the affected host or service clearly?
- Does each finding explain the vulnerability, not just the exploit?
- Is there proof for initial access?
- Is there proof for privilege escalation, where applicable?
- Are screenshots labeled and referenced consistently?
- Do commands and outputs match the host being discussed?
- Are remediation steps specific to the actual issue?
- Have obvious typos, broken formatting, and missing image references been fixed?
- Can someone else follow the attack chain without asking questions?
One more useful check: read each finding and remove your own prior knowledge from the process. If you had not performed the attack yourself, would the section still make sense? That test catches weak explanations fast.
What an editable report template should include
If you are building or choosing an editable report template for OSCP+, look for one that supports speed and accuracy, not just appearance.
- Pre-built sections for summary, scope, findings, remediation, and appendix
- Tables or placeholders for host details and evidence IDs
- Space for short reproduction steps and proof text under each screenshot
- Consistent heading structure for every finding
- A final checklist page
The best template is one you can use half-asleep. That is the real standard. If it looks nice but slows you down, it is the wrong template.
OSCP+ reporting is not about sounding impressive. It is about being clear, complete, and believable under time pressure. A strong template gives you that structure. It helps you turn technical work into a clean record of what happened, why it worked, and what should be fixed. That matters in the exam, and it matters in real client work too. If you practice one reporting habit before test day, make it this: capture proof early, organize it as you go, and write findings so a tired stranger can still follow them. That is what good reporting looks like.
