I sat at my desk the night before the OSWE, the apartment silent except for the hum of my laptop and the soft tap of rain against the window. For months I'd built exploits and templates, learned how memory and web logic braided together, and practiced turning fragmented leads into full, reproducible chains. Still, the exam felt like a door I'd never opened.
Hour one: reconnaissance. The target web app looked ordinary—forms, endpoints, a few JavaScript libraries. My notes became a map: parameters, cookies, user roles. I moved carefully, fingerprinting frameworks and tracing hidden inputs. A misconfigured template engine glinted like a seam in concrete. I smiled; that seam was a promise.
Hour three: exploit development. I crafted payloads slowly, watching responses for the faintest change in whitespace, an extra header, anything. One payload returned a JSON with an odd key. I chased it into a file upload handler that accepted more than it should. The upload stored user data in a predictable path—perfect for the next step.
Hour five: pivot. The upload allowed me to write a template that the server would render. I needed to get code execution without breaking the app or tripping filters. I built a tiny, brittle gadget: a template that called an innocuous-seeming function but passed it a crafted string that forced the interpreter to evaluate something deeper. When the server rendered it, a single line of output confirmed my foothold: a banner string displayed only to admins.
Adrenaline pushed me to move logically, not recklessly. From that foothold I chained a local file read to discover configuration secrets. One value—an API key—opened an internal endpoint that exposed a debug interface. The debug console let me run code in a restricted context; I used a timing side-channel to exfiltrate a small secret that unlocked remote command execution. The moment the server executed my command, I felt equal parts elated and exhausted.
I documented every step as I went: the exact requests, the payloads, the timing, and why one approach failed while another succeeded. The exam wasn't a race to the first shell; it was a careful record of reasoning. I took screenshots, saved raw responses, and wrote clear remediation notes—how input validation could be tightened, how templates should be sandboxed, and which configuration flags to change.
The final hour was spent polishing the report. I wrote an executive summary that explained impact in plain language, then a technical section with reproducible steps. Each finding had a risk rating, reproduction steps, code snippets, and suggested fixes. I cross-checked hashes and timestamps, then uploaded the report.
When it finished submitting, I sat back and let the relief wash over me. The rain had stopped. I didn't know the score, but I knew I had followed the methodology: observe, hypothesize, test, and document. Passing or failing would be a single line in someone else's system, but the real reward was the clarity of the narrative I left behind—the trail of logic that turned curiosity into a usable report.
OffSec Web Expert (OSWE) exam requires a professional-grade penetration test report submitted within 24 hours of completing the 48-hour practical exam. This report is the final deliverable and is graded on both technical correctness and the fullness of documentation. FlashGenius Core Reporting Requirements
OffSec enforces strict documentation standards; failure to meet them can result in a failing mark even if all flags were obtained. Detailed Methodology
: You must provide a walkthrough of every step taken during the exploitation process. Vulnerability Identification : For each finding, explain exactly why the code is vulnerable (root cause analysis). Reproducibility
: Documentation must be clear enough for a technically competent reader to replicate the attacks step-by-step. Full Exploitation Chain
: The report must document how you chained multiple logic flaws to achieve the final objective. Mandatory Report Sections Based on the official OSWE Exam Report Template , your document should include: High-Level Summary : An overview of the assessment and total points earned. Target Information : Flag contents for for each machine. Vulnerability Analysis Method and Code : Identify the specific vulnerable source code. Screenshots
: Visual proof of every major step in the exploitation process. Custom Exploit Code
: You must include the source code for your fully automated, non-interactive exploit scripts. Remediation oswe exam report
: Recommended fixes for each vulnerability, such as using parameterized queries or input sanitization. Critical Grading Criteria Automation
: You must provide a single script that executes the entire exploit chain (e.g., Auth Bypass to RCE) with zero user interaction. Points Threshold : You need a minimum of to pass. Points are typically awarded as follows: for each successful Authentication Bypass. for each successful Remote Code Execution (RCE).
: Once submitted, the report is final. You cannot add missing screenshots or code after the deadline.
The OSWE exam is unique among OffSec certifications because it focuses on white-box web application security (source code review). Unlike OSCP, you have access to the application’s source code. The exam requires full compromise of two separate web applications (or a multi-app environment) within 48 hours, followed by a 24-hour submission window for the report.
Key grading criteria:
This is the most important section. You must document every step required to exploit the vulnerability. Treat this as a tutorial for the grader.
For each vulnerability found, use the following structure:
A passing OSWE report must contain the following (based on OffSec’s official template):
| Section | Required Content |
|--------|------------------|
| Objective | Brief summary of the test, targets, and overall outcome (e.g., “Achieved root/administrative access on both machines”) |
| Methodology | High-level approach – source code review, attack surface mapping, vulnerability discovery, exploit development |
| Vulnerabilities & Exploits | One detailed section per unique vulnerability chain. Include:
- Vulnerability type (e.g., SSTI, SQLi, deserialization)
- Affected code snippet (with line numbers)
- Proof of concept (PoC) – working exploit script
- Step-by-step reproduction |
| Flags / Proofs | Screenshots of proof.txt (or equivalent) and sensitive data (e.g., /etc/shadow, database contents) |
| Remediation | Brief fix for each vulnerability (optional for passing, but good practice) |
| Appendix | Full exploit code, curl commands, logs, or additional notes |
OSWE examiners love debugging output. In your exploit script, include print() statements that show the vulnerable function call.
Example Python output to include in report:
[+] Sending payload to index.php?page=../../../../etc/passwd%00
[+] Server response includes 'root:x:0:0:...' -> LFI confirmed.
[+] Now reading /var/www/secret.php for API key...
This proves you understand the mechanism, not just the result.
The OSWE report is a code‑grounded exploit narrative. You are not just a pentester – you are a security researcher proving that reading the source code leads to a reliable, chainable attack. Focus on clarity, reproducibility, and precise code references. A well‑written report can save you even if your exploit is slightly unstable – the examiner must understand your reasoning.
Good luck with your OSWE exam!
Creating an OffSec Web Expert (OSWE) exam report requires strict adherence to professional documentation standards to ensure every step of your exploitation process is reproducible. After finishing your 48-hour practical exam, you have exactly 24 hours to submit your final report in PDF format. Core Report Requirements
Official Templates: You must use the provided OffSec OSWE Exam Report Templates (available in .docx and .odt).
Detailed Methodology: Document every step, command, and console output. A technically competent reader should be able to replicate your attack exactly.
Screenshots: Include clear screenshots of your local.txt and proof.txt flags, as well as the commands used to retrieve them.
Custom Exploit Code: You must include the full source code for the custom, non-interactive exploit scripts used to automate your attacks. Recommended Report Structure
Based on successful community guides, organize your machine write-ups as follows:
High-Level Summary: A brief overview of the vulnerabilities found and the results achieved. Vulnerability Discovery (White-Box):
Vulnerable Code Snippet: Provide screenshots of the specific lines of source code.
Analysis: Explain why the code is vulnerable (e.g., lack of sanitization, logic flaw). Exploitation Walkthrough:
Step-by-Step Instructions: Detail the stages of the attack (e.g., Auth Bypass to RCE).
Script Explanation: Provide your exploit code with a line-by-line breakdown of its functionality.
Proof of Concept (PoC): Screenshots showing the script running successfully and capturing the final flag. Pro Tips for Reporting Advanced Web Attacks and Exploitation OSWE Exam Guide
To create a professional OSWE (OffSec Web Expert) exam report, you must prioritize reproducibility and strictly follow the OffSec Exam Guide. OffSec provides an official OSWE report template that you should use as your base. 1. Mandatory Technical Requirements
Submission Format: You must submit your report as a PDF file, archived into a .7z file (no password). OSWE exam report — short story I sat
Naming Convention: Both the PDF and the archive must be named OSWE-OS-XXXXX-Exam-Report, where OS-XXXXX is your OSID.
Complete Exploits: Include the full, automated exploit source code for each target directly within the PDF as text.
Screenshots: You must include screenshots of local.txt and proof.txt contents, clearly showing the IP address and the command used to read them (e.g., type or cat). 2. Core Report Structure
A "proper" paper follows a narrative that a technically competent reader can replicate step-by-step:
Executive Summary: High-level overview of the targets and whether they were fully compromised.
Methodology Walkthrough: A detailed outline of your discovery process.
Individual Finding Sections: For each vulnerability (Auth Bypass, RCE, etc.), provide:
Vulnerable Code: A screenshot of the specific code snippet with a clear explanation of why it is vulnerable.
Exploitation Steps: A walkthrough of how you manipulated the code flaw to gain access.
PoC Code: The specific script or manual steps used for that particular finding.
Screenshots: Visual proof for every critical stage (e.g., showing a successful login or a shell). 3. Tips for a Passing Report OSWE-Exam-Report.docx - OffSec
Based on the nature of the OSWE (Offensive Security Web Expert) exam, which focuses on white-box testing (source code analysis) and developing custom exploits, the most relevant "feature" to develop is an automated script to chain vulnerabilities for RCE.
OSWE exam reports typically require you to demonstrate that you can not only find the bugs manually but also automate the exploitation process.
Here is a proposed feature design for an OSWE exam report scenario. Full exploitation of all required targets (no partial