Pentest Reporting & Documentation

The pentest report is the DELIVERABLE — the reason the client hired you.
A perfect exploit is worthless if you can't communicate the risk clearly.

Audience:
- Executive team: non-technical, care about business risk
- IT/Security team: technical, need to reproduce and fix
- Management: budget allocation, compliance

Goal: enable the client to improve their security posture

Standard Pentest Report Structure:

1. Cover Page
   - Company name, report title, date, classification (CONFIDENTIAL)
   - Tester names, methodology standard (PTES, OWASP)

2. Executive Summary (1-2 pages, non-technical)
   - Engagement overview: what was tested, when, by whom
   - Key findings: highest-risk vulnerabilities (plain English)
   - Overall risk rating: Critical / High / Medium / Low
   - Top 3 recommendations (most impactful)
   - "If you read nothing else, read this"

3. Scope and Methodology
   - In-scope systems, IPs, domains, timeframe
   - Out-of-scope (explicitly excluded)
   - Testing approach: black box / grey box / white box
   - Tools used (Nmap, Metasploit, Burp Suite, etc.)
   - OWASP Testing Guide / PTES methodology

4. Findings (one section per finding)
   - Title, severity, CVSS score
   - Description (what is it?)
   - Impact (what could an attacker do?)
   - Evidence (screenshots, output)
   - Steps to reproduce (numbered, exact commands)
   - Remediation (specific, actionable steps)
   - References (CVE, OWASP, vendor advisory)

5. Appendices
   - Full scan output
   - All credentials discovered (encrypted appendix)
   - Tool versions used

CVSS (Common Vulnerability Scoring System) v3:
Standard for communicating vulnerability severity

Metric Groups:
1. Base Score (inherent characteristics):
   - Attack Vector (AV): Network/Adjacent/Local/Physical
   - Attack Complexity (AC): Low/High
   - Privileges Required (PR): None/Low/High
   - User Interaction (UI): None/Required
   - Scope (S): Unchanged/Changed
   - Confidentiality Impact (C): None/Low/High
   - Integrity Impact (I): None/Low/High
   - Availability Impact (A): None/Low/High

Score Ranges:
0.0       None
0.1-3.9   Low
4.0-6.9   Medium
7.0-8.9   High
9.0-10.0  Critical

Examples:
SQL Injection (auth bypass): AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical
Stored XSS (admin panel): AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N = 8.9 High
Information disclosure: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3 Medium

### Finding 1: Remote Code Execution via SQL Injection

**Severity**: Critical (CVSS v3: 9.8 - AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**Affected System**: https://app.target.com/api/users

**Description**:
The `/api/users` endpoint is vulnerable to SQL injection via the `id` parameter.
The parameter is passed directly to the SQL query without sanitization,
allowing an attacker to manipulate the database query.

**Impact**:
A remote unauthenticated attacker can:
- Extract all database contents including user credentials and PII
- Bypass authentication and access any account
- Write arbitrary files to the web server via INTO OUTFILE
- Execute OS commands via xp_cmdshell (if enabled on MSSQL)

**Evidence**:

[Screenshot: database dump showing 1,247 user records]

**Steps to Reproduce**:
1. Navigate to: https://app.target.com/api/users?id=1
2. Modify the `id` parameter to: 1 UNION SELECT 1,username,password,4 FROM users--
3. Observe database credentials returned in the JSON response
4. Automated extraction: sqlmap -u "https://app.target.com/api/users?id=1" --dump

**Remediation**:
1. Immediately: Use parameterized queries (prepared statements)
   - Python: cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
   - Java: PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?")
2. Short-term: Input validation — reject non-integer id values
3. Long-term: Web Application Firewall, database privilege minimization
4. Rotate all database credentials immediately

**References**:
- CWE-89: SQL Injection
- OWASP Top 10 A03:2021 – Injection
- https://owasp.org/www-community/attacks/SQL_Injection

Executive Summary Template:

Between [DATE] and [DATE], [COMPANY] performed a [TYPE] penetration test
of [SCOPE]. The testing identified [N] vulnerabilities across [SYSTEMS]:
- [N] Critical, [N] High, [N] Medium, [N] Low

The most significant finding was [BRIEF DESCRIPTION] which could allow
a remote attacker to [BUSINESS IMPACT IN PLAIN ENGLISH].

Key Recommendations:
1. [Most urgent action] — estimated effort: [hours/days]
2. [Second priority] — estimated effort: [hours/days]
3. [Strategic improvement] — estimated effort: [weeks/months]

Overall Security Posture: [POOR/FAIR/ADEQUATE/GOOD/EXCELLENT]
[1-2 sentence rationale]

Note on Positives:
[Acknowledge what was done well — MFA deployed, patching policy, etc.]

Responsible Disclosure (RD) / Coordinated Vulnerability Disclosure (CVD):
- Reporting security vulnerabilities to the vendor before public disclosure
- Gives vendor time to patch (typically 90 days)
- Ethical obligation when finding bugs outside authorized engagements

Process:
1. Report to vendor's security team: security@vendor.com
2. Wait for acknowledgment (typically 7 days)
3. Coordinate patch timeline (90 days standard — Google Project Zero)
4. Public disclosure after patch is released
5. If vendor is unresponsive: disclose after 90 days

Bug Bounty Platforms:
- HackerOne: https://hackerone.com/
- Bugcrowd: https://bugcrowd.com/
- Intigriti: https://www.intigriti.com/
- Synack: invite-only, paid researchers

CVE Assignment:
- CVE Numbering Authority (CNA) assigns CVE IDs
- MITRE: cve.mitre.org — request CVE for novel vulnerabilities

Full Disclosure vs Responsible Disclosure:
Full: publish immediately without notifying vendor (controversial)
CVD: notify vendor first, coordinate — industry standard