Case Study 2: Report Anti-Patterns and the OSCP Report Model

Background

Every experienced penetration tester has encountered (or written) reports that fail to communicate effectively. These failures follow predictable patterns --- anti-patterns --- that, once identified, are easy to avoid. At the same time, one of the most effective training grounds for report writing is the OSCP certification exam, which requires candidates to submit a professional report as part of the examination. The OSCP report model has influenced industry practice and provides a useful benchmark for report quality.

This case study examines common report anti-patterns drawn from real-world experience and analyzes the OSCP report model as a training framework for professional report writing.

Part 1: Report Anti-Patterns

Anti-Pattern 1: The Data Dump

Description: The report is an unfiltered collection of tool output with minimal analysis. Nmap scans, Nessus results, Burp Suite findings, and command output are pasted directly into the document with no curation, validation, or context.

Example: A 300-page report for a 5-day engagement. Page after page of:

Nessus Plugin 10079: Anonymous FTP Enabled
Synopsis: Anonymous logins are allowed on the remote FTP server
Description: [three paragraphs of Nessus description]
Risk Factor: Medium
CVSS Base Score: 5.0
Plugin Output: It was possible to log into the remote FTP server...

Repeated for every single finding from every scanner across every host.

Why It Fails: - The client cannot distinguish critical issues from noise - No validation means the report contains false positives - No business context means findings are not prioritized - The sheer volume makes the report unusable - It demonstrates that the tester added no value beyond what the scanner provided

The Fix: Treat scanner output as raw data, not as findings. Validate each potential finding, assess its actual impact in the client's context, and write a curated finding that explains what the vulnerability means for the organization. A report with 15 validated, contextualized findings is infinitely more valuable than 300 unfiltered scanner results.

Anti-Pattern 2: The Jargon Bomb

Description: The report is written entirely in hacker jargon, assuming the reader has the same technical knowledge as the tester. Acronyms are undefined, techniques are referenced without explanation, and the executive summary reads like a technical blog post.

Example: "We leveraged a blind time-based SQLi in the UNION-compatible endpoint, extracted the pg_shadow table via OOB DNS exfil, cracked the bcrypt hashes using hashcat with rockyou, then used the creds for WinRM lateral movement to pivot through the trust boundary into the T1 domain, where we Kerberoasted three SPNs and performed a DCSync to obtain the krbtgt hash for a Golden Ticket."

Why It Fails: - The CISO reading this understands about half of it - The board member reading it understands none of it - The legal team reading it cannot assess liability - Even the technical team may not understand every reference - It makes the tester look impressive but provides no actionable guidance

The Fix: Write for your audience. The executive summary should be understandable by a non-technical business leader. Technical detail belongs in the finding write-ups, where it should still be clear and well-structured. When you must use technical terms, define them on first use. Write as if explaining to a competent professional who is not a security specialist.

Anti-Pattern 3: The Severity Inflation

Description: Every finding is rated Critical or High. The tester inflates severity to make the report look impressive or to justify the engagement cost. Alternatively, the tester applies CVSS base scores without considering the client's specific context.

Example: A report where missing HTTP security headers (a Low-risk finding in most contexts) is rated "High" because "an attacker could potentially use clickjacking to trick users." Meanwhile, an actual SQL injection in the payment system is also rated "High," making both findings appear equally urgent.

Why It Fails: - If everything is Critical, nothing is Critical --- the client cannot prioritize - It erodes trust: the client's technical team will spot inflated ratings - It misaligns resources: the client may spend effort on false urgencies - It reduces the tester's credibility for future engagements

The Fix: Use a consistent, defensible risk rating methodology. Provide the CVSS vector string so readers can verify your scoring. Contextualize risk based on the client's environment: a CVSS 7.0 vulnerability on an internal printer is different from a CVSS 7.0 vulnerability on the internet-facing payment system. Be honest about Low and Informational findings --- they still have value but should not compete for attention with genuine Critical issues.

Anti-Pattern 4: The Ghost Evidence

Description: Findings are documented without sufficient evidence to verify them. The report states that a vulnerability exists but does not provide the proof to back it up. Screenshots are missing, steps to reproduce are vague, and request/response data is absent.

Example: "The application is vulnerable to IDOR. An attacker can access other users' data by manipulating the user ID parameter."

No screenshot. No request/response. No specific endpoint. No demonstration of what data is accessible.

Why It Fails: - The development team cannot reproduce the issue - The finding cannot be verified during retest - It creates disputes: the client may challenge unsubstantiated claims - QSAs and auditors cannot accept it as compliance evidence - It suggests the tester may not have actually validated the finding

The Fix: Every finding must include sufficient evidence to be independently verified. This means: the specific endpoint or system, the exact steps to reproduce, screenshots showing the vulnerability and its exploitation, and request/response data for web application findings. If you cannot provide evidence, either the finding is not validated (and should be marked as such) or your evidence collection process needs improvement.

Anti-Pattern 5: The Copy-Paste Report

Description: The report is a template where only the client name, IP addresses, and finding list change between engagements. Methodology sections describe testing that was not actually performed, and remediation recommendations are generic regardless of the client's technology stack.

Example: A report for a Node.js/PostgreSQL application recommends "use stored procedures to prevent SQL injection" (a recommendation more suited to Microsoft SQL Server) and includes a methodology section describing "physical security assessment" even though no physical testing was conducted.

Why It Fails: - Inaccurate recommendations waste development effort - Template artifacts reveal lazy practice - Methodology sections that do not match actual testing reduce credibility - The client gets a generic product instead of a custom analysis - It demonstrates that the tester does not understand the client's environment

The Fix: Customize every report for the specific client and engagement. Remediation recommendations should reference the client's actual technology stack. The methodology section should describe what was actually tested, not what your template says you test. Remove any sections that do not apply. A shorter, accurate report is always better than a longer, inaccurate one.

Anti-Pattern 6: The Fear Monger

Description: The report uses alarming language designed to frighten the client rather than inform them. Findings are described in worst-case-scenario terms without nuance, and the overall tone suggests that a catastrophic breach is imminent unless the tester's recommendations are followed immediately.

Example: "CRITICAL: The organization's network is COMPLETELY COMPROMISED. Patient data for 500,000 individuals is IMMEDIATELY ACCESSIBLE to any attacker on the internet. CATASTROPHIC breach is IMMINENT. Failure to act IMMEDIATELY will result in regulatory penalties, lawsuits, and irreparable reputational damage."

Why It Fails: - Alarmist language undermines credibility - It suggests bias: the tester appears to have an agenda - Decision-makers may dismiss the report as sensationalized - It does not provide the measured, professional assessment that enables good decisions - It can create unnecessary panic and poor decision-making

The Fix: State the facts. Provide the evidence. Explain the impact in business terms. Let the severity rating and business impact analysis communicate the urgency. Professional, measured language is always more persuasive than hyperbole. If the situation is genuinely critical, the evidence will speak for itself.

Part 2: The OSCP Report Model

Why OSCP Reports Matter

The OSCP certification exam requires candidates to submit a penetration testing report documenting their exam performance. This report is evaluated alongside the technical exam results, and candidates can fail the exam with insufficient technical scores if their report is inadequate. The OSCP report model has become an informal industry standard for several reasons:

1. Structured format: OffSec provides report templates that establish a clear, consistent structure
2. Reproducibility requirement: Reports must contain sufficient detail for someone else to reproduce the findings
3. Evidence standards: Screenshots and command output must clearly demonstrate vulnerability exploitation
4. Professional presentation: Reports must be clean, organized, and professionally formatted

OSCP Report Structure

The standard OSCP report template includes:

1. Introduction - Objective of the assessment - Scope (exam machines and/or lab machines) - Methodology overview

2. High-Level Summary - Overview of testing activities - Key findings summary - Recommendations

3. Individual Machine Write-Ups For each machine compromised: - Service Enumeration: Port scan results and service identification - Initial Access: The vulnerability exploited and the exploitation process - Privilege Escalation: How the tester escalated from initial access to root/SYSTEM - Proof of Exploitation: Screenshots showing the flag files with hostname/IP visible

4. Appendices - Tool output - Additional evidence

What Makes OSCP Reports Effective

Step-by-Step Reproducibility: Every exploitation path must be documented with enough detail that a reader could reproduce it independently. This trains testers to think about documentation as they work, not after the fact.

Example of good OSCP documentation:

1. Initial Nmap scan reveals port 80 open with Apache 2.4.49
2. Apache 2.4.49 is vulnerable to path traversal (CVE-2021-41773)
3. Verified with: curl http://target/cgi-bin/.%2e/%2e%2e/etc/passwd
4. Response contains /etc/passwd contents (screenshot: Figure 3.1)
5. Escalated to RCE: curl -d 'echo Content-Type: text/plain; echo;
   id' http://target/cgi-bin/.%2e/%2e%2e/bin/sh
6. Response shows uid=33(www-data) (screenshot: Figure 3.2)

Clear Evidence Chain: Each step must be supported by evidence. The chain from initial access to proof of exploitation must be unbroken. If there is a gap, the report is insufficient.

Conciseness: The exam time limit forces candidates to write efficiently. There is no room for filler, scanner dumps, or irrelevant information. Every sentence must contribute to the narrative.

OSCP Report Limitations

While the OSCP report model is excellent for documenting exploitation paths, it has limitations when applied to professional engagements:

No Executive Summary: The OSCP report does not require an executive summary because the audience is the OffSec grading team, not business leadership. Professional reports must include executive-level communication.

No Business Impact: OSCP findings describe technical exploitation without connecting to business risk. In professional practice, every finding must include business impact analysis.

No Remediation Depth: OSCP reports may include brief remediation suggestions, but they do not require the layered, technology-specific remediation recommendations that professional reports demand.

Single-Audience Focus: The OSCP report serves one audience (technical evaluators). Professional reports must serve multiple audiences simultaneously.

Adapting the OSCP Model for Professional Practice

The best professional reports take the OSCP model's strengths --- reproducibility, evidence quality, and step-by-step documentation --- and add what it lacks:

The PNPT Report Model: Evolution of OSCP

TCM Security's PNPT certification evolved the report model by making the written report a graded component of the exam. Unlike OSCP, where the report supplements the technical exam, the PNPT report is graded independently:

• Executive summary required and graded: Candidates must demonstrate they can communicate with non-technical stakeholders
• Business impact analysis graded: Each finding must include business context
• Remediation quality graded: Recommendations must be specific and actionable
• Professional presentation graded: Format, grammar, and overall report quality are evaluated

The PNPT report model represents the industry's recognition that report writing is as important as technical exploitation and should be formally assessed.

Combining Lessons: The Professional Report Checklist

Based on the anti-patterns and report models analyzed in this case study, here is a professional report quality checklist:

Executive Summary: - [ ] Written for non-technical leadership - [ ] Includes overall risk assessment - [ ] Connects findings to business impact and financial risk - [ ] Provides prioritized strategic recommendations - [ ] Includes comparison to previous assessments (if applicable) - [ ] Two pages or less

Individual Findings: - [ ] Consistent template for all findings - [ ] Specific affected systems (not just IP addresses) - [ ] CVSS score with full vector string - [ ] Business impact in non-technical language - [ ] Step-by-step reproduction instructions - [ ] Clear, annotated screenshots - [ ] Request/response data for web findings - [ ] Technology-specific remediation guidance - [ ] References (CVE, CWE, OWASP)

Overall Report: - [ ] No unfiltered scanner output - [ ] All findings validated (no false positives) - [ ] Consistent severity ratings - [ ] Professional, objective tone - [ ] Clean formatting and consistent style - [ ] Table of contents with page numbers - [ ] Confidentiality classification - [ ] Version control and distribution list

Discussion Questions

1. You are reviewing a colleague's report draft and notice several of the anti-patterns described above (data dump, jargon bomb, and ghost evidence). How would you provide constructive feedback without damaging the professional relationship?

2. Should penetration testing firms require all testers to pass OSCP or PNPT (which grade reports) before allowing them to write client reports? What are the pros and cons?

3. A client's legal team requests changes to the report that would minimize the apparent severity of findings. They argue that the report could be used against the company in litigation if it acknowledges serious vulnerabilities. How should you respond?

4. How do you handle findings that you believe are significant but that have no CVE, no CVSS score, and no OWASP reference (e.g., a business logic flaw unique to the client's application)?

5. Some penetration testing firms use AI tools to assist with report writing (grammar checking, finding template generation, remediation research). What are the ethical boundaries of AI assistance in professional report writing?