Don't write "Login bypass." Write: "Authentication Bypass via PHP Type Juggling (CWE-843)." Use the exact OWASP/CWE terminology. Examiners love this.
Every vulnerability needs three forms of proof:
If you have all three, the vulnerability is confirmed.
Provide reproducible exploit steps for each critical finding. Include exact commands, HTTP requests, and outputs or screenshots.
| Pitfall | Consequence |
|--------|--------------|
| Missing raw HTTP requests/responses (only showing screenshots of browser) | Points deducted or failure |
| Vague code references – “Line 42 in auth.php” without showing the vulnerable snippet | Report considered incomplete |
| Assuming the reader knows the app logic – Not explaining the chain of calls from user input to sink | Points lost |
| No proof of successful exploitation – E.g., only showing a reverse shell listener, not the actual command output | Invalid proof |
| Incorrect or missing steps for full chain – OSWE requires chaining vulnerabilities (e.g., SQLi to RCE). Missing intermediate steps breaks reproducibility | Failure even if you had shell in exam |
The OSWE (Offensive Security Web Expert) exam report is the final, critical step to earning the certification. Unlike many technical exams, the OSWE requires you to not only find vulnerabilities but to provide a "professional-level" penetration testing report that documents your methodology and provides functional exploit code. The Reporting Timeline 48-Hour Exam
: You have 48 hours to complete the practical portion, which involves identifying vulnerabilities and achieving Remote Code Execution (RCE) on two separate targets. 24-Hour Documentation
: Once your lab access ends, a separate 24-hour window begins specifically for writing and submitting your report. You cannot access the exam environment during this time. Core Report Requirements
OffSec is strict about the report's structure. Missing a required section or failing to provide a working exploit can result in a failure, even if you found all vulnerabilities. Executive Summary
: A high-level overview of the findings and the overall risk to the organization, written for a non-technical audience. Step-by-Step Methodology
: You must document the entire path from initial discovery to final exploitation. This includes: Vulnerability Identification : Where in the source code the bug exists. Vulnerability Analysis : Why the code is insecure. Proof of Concept (PoC) : Screenshots showing the vulnerability being triggered. Functional Exploit Code
: The "work" in the report heavily relies on providing a single, multi-stage Python script for each target. This script should automate the entire chain (e.g., Auth Bypass → File Upload → RCE) and result in a reverse shell. Remediation Recommendations
: For every vulnerability found, you must provide specific, actionable advice on how the developers should fix the code. The "Work" Involved in Documentation oswe exam report work
Writing the OSWE report is often described by students as an "additional marathon." Code Snippets
: You must include the exact lines of vulnerable source code from the target application to prove you performed white-box analysis. Screenshots : Clear visual evidence of
flags, along with the IP addresses of the machines, is mandatory. Clarity & Reproducibility
: The report must be detailed enough that another technical person could follow your steps and achieve the same results without additional help. Common Pitfalls Incomplete Exploits
: If your Python script requires manual intervention halfway through, it may not meet the "complete automation" expectation. Formatting Errors
: Failing to follow the specific naming convention for the PDF (e.g., OSWE-WM-XXXXX-Exam-Report.pdf
) or the archive file can lead to immediate disqualification. Missing Flags : Forgetting to include a screenshot of a flag or the output is a common reason for point deductions. For those preparing, OffSec provides an official Exam Report Template
that serves as the gold standard for what the final "work" should look like.
The Offensive Security Wireless Professional (OSWP) and Offensive Security Wireless Experienced (OSWE) certifications are among the most respected in the cybersecurity industry. However, unlike traditional multiple-choice exams, OffSec certifications require a rigorous, professional-grade documentation process.
If you are currently staring at a blank document after your 48-hour exam window, here is how to tackle your OSWE exam report work to ensure your hard-earned exploits actually result in a "Pass." 1. The Mindset: Technical Accuracy Meets Executive Clarity
The OSWE is a web application security exam focused on White Box analysis. Your report isn’t just a proof of hack; it is a proof of process. OffSec graders are looking for your ability to walk a reader through the source code, identify the vulnerability, and explain how you chained it into a full-system compromise. 2. The Essential Structure of an OSWE Report
A winning report generally follows the OffSec provided template, but the "work" happens in the execution of these sections: A. The Executive Summary Don't write "Login bypass
Write this for a CISO or a non-technical manager. Briefly state that the applications were audited, vulnerabilities were discovered, and provide a high-level "risk score." Avoid jargon here; focus on the business impact of the flaws you found. B. Methodology and Vulnerability Identification
This is the "White Box" heart of the report. For every vulnerability found:
The Code Snippet: Point to the exact file and line number in the provided source code.
The Logic Flaw: Explain why the code is insecure. Is it a lack of input sanitization? A logic error in authentication?
The Remediation: Provide a code-level fix. Don’t just say "sanitize input"—provide a snippet showing how a developer should rewrite that specific function. C. The Exploit Chain (The "Money" Shot)
OSWE is rarely about a single bug. It’s about Advanced Web Attacks and Exploitation (AWAE).
Document how you chained a Cross-Site Scripting (XSS) into a Session Hijack, or a File Upload into a Remote Code Execution (RCE).
Screenshots: Every step must be documented with a screenshot. These must include the URL bar and the output of your commands (like whoami or ifconfig). 3. Automating the "Work" with Python
The OSWE requires you to submit a functional exploit script. Your "report work" should include a well-commented Python script that executes the full exploit chain from start to finish. Requirements: Use the requests library.
Clarity: Use print statements in your script (e.g., [+] Bypassing Authentication..., [+] Triggering RCE...) so the grader can follow the logic in real-time. 4. Common Pitfalls to Avoid
Missing Local.txt or Proof.txt: If you don't include the screenshots of these flags in the final shell, you will likely fail, regardless of how good your code analysis is.
Vague Steps: If a colleague couldn't recreate your exploit by reading your report alone, it is incomplete. If you have all three, the vulnerability is confirmed
Poor Formatting: Use a clean Markdown or LaTeX template. Code blocks should be syntax-highlighted for readability. 5. Post-Exam "Report Work" Workflow
The 24-Hour Rule: You have 24 hours after the exam ends to submit. Use the first 4 hours for a "sanity check" of your screenshots.
The Double-Check: Re-read the official OffSec submission instructions. Check the file name (e.g., OSWE-ID-Report.pdf) and ensure the archive isn't password-protected in a way they can't open.
The PDF Conversion: Always check your final PDF for formatting errors. Sometimes code blocks get cut off at the page margin. Final Thought
The "work" of the OSWE exam report is just as important as the "work" of the exploit. It proves you aren't just a "script kiddie" who got lucky, but a professional security researcher who understands the fundamental flaws in application logic.
Are you using a specific Markdown template or the official OffSec Word document for your current report draft?
The OSWE exam often requires chaining multiple minor bugs (e.g., SQLi -> Admin Login -> File Upload -> RCE). Your report must prove the entire chain is reliable and repeatable from zero knowledge to root shell.
For each step in the chain, you need:
If your chain breaks at step 2 because you "got lucky" in the exam, you will fail. Your report must work every time the examiner runs it.
One of the cruelest aspects of the OSWE exam report work is the Local File Inclusion (LFI) to Remote Code Execution (RCE) distinction.
If your exploit relies on log poisoning (LFI -> accessing /var/log/apache/access.log), your report must include the exact log entry you injected and the subsequent request that executes it.
Bad report work: "LFI to log poisoning works."
Good report work: "Step A: Sent User-Agent: <?php system($_GET['cmd']); ?> (Screenshot of log file showing the PHP code). Step B: Accessed index.php?page=../../../../var/log/apache/access.log&cmd=id (Screenshot of 'uid=33(www-data)' output)."
Commands used for enumeration and escalation: linpeas.sh, sudo -l, grep -R "password" /etc -n.