Oswe Exam Report Work ((new)) -

Getting through the OffSec Web Expert (OSWE) exam is a massive achievement, but many students find that the real "final boss" isn't the exploit code—it's the OSWE exam report work.

The OSWE (WEB-300) certification focuses on white-box web application assessments. Because it’s a professional-grade certification, OffSec requires a report that reflects professional-grade analysis. Here is a comprehensive guide on how to approach your report work to ensure you don't fail on a technicality after doing the hard work of exploitation. 1. The Reporting Mindset: Accuracy Over Volume

The most common mistake in OSWE exam report work is thinking that "more pages equals a better grade." In reality, OffSec graders look for reproducibility.

If a colleague followed your report, could they recreate your exploit from scratch without guessing?

Include every step: From finding the vulnerability in the source code to the final execution.

Be concise: Don't fluff the report with generic definitions of SQL injection. Focus on this specific SQL injection. 2. Structuring Your OSWE Report

While OffSec provides a formal report template, you need to populate it strategically. Your report should generally follow this flow:

Executive Summary: A high-level overview of the systems compromised.

Detailed Technical Breakdown: This is the meat of your "report work." You need a section for each machine/application.

Vulnerability Analysis: Explain the "Why." Why did the code fail? (e.g., "The application uses an unsafe eval() call on user-controlled input in functions.php at line 42.")

Exploit Path: A step-by-step narrative of how you chained vulnerabilities together.

Proof of Concept (PoC) Code: Your full, working exploit script. 3. Mastering the "Source Code to Exploit" Narrative

Since the OSWE is a white-box exam, your report work must highlight your ability to read and analyze code.

Snippet Inclusion: Copy the specific blocks of vulnerable code into your report. oswe exam report work

Highlighting: Use bolding or code comments to point out exactly where the sanitization is missing.

The "Chain": OSWE rarely involves a single-step exploit. Clearly document how you used a "low-severity" bug (like an Authentication Bypass) to reach a "high-severity" bug (like RCE). 4. Essential Screenshots and Proofs

Your OSWE exam report work is incomplete without visual evidence. For every machine, you must include:

The local.txt and proof.txt flags: These must be shown in their original location via a terminal/command prompt.

The ipconfig or ifconfig output: You must prove the flags were taken from the correct target IP.

The Payload in Action: If you used Burp Suite, include screenshots of the request/response that triggered the bug. 5. Final Checklist for Your Report Work

Before you hit "submit" on the OffSec portal, run through this checklist:

Did I include the full script? Ensure your Python/Perl/Bash scripts are included in the report and are easy to copy-paste.

Are the screenshots legible? If the text is blurry, the grader can't verify your work.

Is it in PDF format? OffSec is strict about file formats and naming conventions (e.g., OSWE-WM-XXXXX-Exam-Report.pdf).

Did I explain the remediation? Don't just show how to break it; provide a brief code snippet showing how the developer should fix the vulnerability. Conclusion

OSWE exam report work is the final hurdle in becoming an OffSec Web Expert. By treating the report as a professional deliverable rather than a school assignment, you demonstrate that you possess both the technical skill to find bugs and the communication skill to help organizations fix them.

Do you have a draft of your exploit steps or a specific section of the OffSec template you're struggling to fill out? Getting through the OffSec Web Expert (OSWE) exam

2. Scope & Methodology

  • List the application name, version, and IP.
  • Methodology: "White-box review focusing on user input flows, dangerous functions (eval, unserialize, exec), and authentication bypasses."

Proof of Exploit

Include exact flags, file paths, screenshots, and command outputs. Example items to include:

  • Flag: FLAGexample_flag_value — obtained from /root/flag.txt
  • Screenshot: HTTP response showing uploaded shell executing whoami.
  • HTTP request/response dumps for key actions (upload, token bearer requests, shell execution).

Master the OSWE Exam Report Work: A Complete Guide to Documentation That Scores

If you have attempted the OSWE (Offensive Security Web Expert) exam, you know the truth: The exploit is only half the battle. The other half—the part that makes or breaks your pass—is the "OSWE exam report work."

Unlike the OSCP, where a simple screenshot and a paragraph might suffice, the OSWE demands a fully validated, step-by-step exploitation chain. The exam is 48 hours long, but a shocking number of students fail not because they cannot hack the box, but because their documentation is incomplete, invalid, or fails to prove unique vulnerability chains.

This article is a deep dive into exactly what the OSWE exam report work entails, how to structure it, common pitfalls, and a pre-submission checklist to ensure you get the "Pass" you earned.

1. Report Structure & Requirements

  • Official template is provided (similar to OSCP). You must submit a single PDF.
  • Sections expected:
    • Executive summary
    • Methodology (brief)
    • Detailed walkthrough per exploit (must include: vulnerability description, affected code lines, proof-of-concept (PoC) requests/responses, reproduction steps, and raw HTTP requests/responses).
    • Code snippets from the source code analysis (with line numbers).
    • Screenshots of successful exploitation (e.g., id command output, file read, reverse shell).

Vulnerability #1: [Name, e.g., SQL Injection in login parameter]

  • Affected Component: /login.php?user=
  • Severity: Critical
  • CWE: CWE-89
  • Description: [1-2 sentences]
  • Proof of Concept (Code): 
    # Paste your exploit here

  • Proof of Concept (Execution Output): [Screenshot of terminal]
  • Remediation: [Use parameterized queries]

Chain of Vulnerabilities: SQL Injection to RCE

Application Context
The target application, InvoiceManager v2.4, exposes a REST API endpoint at /api/invoice/preview. The endpoint accepts a template_id parameter, which is used to fetch a Jinja2 template from the database.

Vulnerability 1: Boolean-Based Blind SQL Injection

  • Location: api.php lines 112–124 
    $template_id = $_GET['template_id'];
$query = "SELECT template_content FROM templates WHERE id = $template_id";
$result = $db->query($query);
  • Impact: Direct concatenation of user input into SQL query → blind SQL injection.
  • Proof:
    Request:
    /api/invoice/preview?template_id=1 AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a'
    Response timing diff: ~2s delay confirms boolean extraction.

Vulnerability 2: Server-Side Template Injection (SSTO) via Retrieved Content

  • Location: TemplateRenderer.php line 89 
    return $twig->render($template_content, $context);
  • Trigger: The template_content fetched via SQLi is passed directly to Twig.
  • Bypass attempt: Twig’s sandbox blocks __construct, _self, etc. However, map, filter, and reduce allow calling arbitrary functions if a function name can be controlled.

Exploit Chain

  1. Use SQLi to extract admin password hash – not directly useful for RCE.
  2. Notice templates table has template_content and is_system_template column.
  3. Use SQLi UPDATE (if DB user has write perms) to inject a malicious Twig template: 
    UPDATE templates SET template_content = ' _self.env.registerUndefinedFilterCallback("system")  _self.env.getFilter("id") ' WHERE id = 1
  4. Trigger the template via GET request:
    /api/invoice/preview?template_id=1 → system("id") executes → returns command output in HTTP response.

Result
Full remote code execution as www-data. From here, read /root/flag.txt.

The OffSec Web Expert (OSWE) exam report is a critical technical document that must be submitted within 24 hours after the 47-hour-45-minute practical exam. It serves as formal proof of your technical findings and is graded on both correctness and completeness; failing to provide sufficient documentation can result in zero points for a finding, even if you successfully exploited the target. Key Reporting Requirements

Target Replication: Documentation must be detailed enough for a technically competent reader to replicate your attacks step-by-step.

Flag Verification: You must include screenshots showing the contents of local.txt and proof.txt on the target machines to receive credit. List the application name, version, and IP

Exploit Automation: The report must contain the full source code for a single, non-interactive script that automates the entire exploit chain for each target.

Submission Format: Reports must be submitted as a PDF archived within a .7z file. Recommended Report Structure

OffSec provides official templates in Word and OpenOffice formats to ensure candidates include all mandatory sections:

Methodology Walkthrough: A high-level overview of your discovery and exploitation process.

Vulnerability Breakdown: For each target, detail the research performed, the specific code analyzed, and how the vulnerability was identified.

Proof of Concept (PoC): The final automated script used to gain access.

Screenshots: Visual evidence of successful exploitation and flag retrieval. Critical Tips from Reviews Advanced Web Attacks and Exploitation OSWE Exam Guide

1. The Vulnerability Walkthrough (Step-by-Step)

This is the heart of your OSWE report work. OffSec examiners do not want to guess. They want to replicate your attack exactly on their internal exam instance.

You must include:

  • The HTTP Request: The exact raw request used to trigger the bug.
  • The Source Code Snippet: Copy the vulnerable lines of code from the exam application. Highlight or annotate the vulnerable line.
  • The Input Trace: Show the flow of data. "User input → GET parameter 'file' → $_GET['file'] → include() function."

Example Structure:

Step 1: The application accepts a lang parameter in index.php?lang=en. Step 2: In core.php line 42, the code reads $language = $_GET['lang']; Step 3: At line 45, it executes include($language . '.php'); without validation. Step 4: By sending index.php?lang=../../../../etc/passwd%00, we achieve LFI.

The 4-Hour Report Work Sprint

Many candidates finish exploiting the exam in 20 hours, but fail because they leave only 30 minutes for the report. Do not do this.

Here is the recommended timeline:

  • Hour 1-40: Hacking & note-taking (use Obsidian, Notion, or a simple text file).
  • Hour 41-44: Write rough draft of technical report while the exploit is fresh in your mind.
  • Hour 45-46: Test your Python exploit scripts against the exam box again. Re-run them. Screenshoot everything fresh.
  • Hour 47-48: Finalize PDF. Check for typos, missing screenshots, and broken code formatting.