pentest-report

name	pentest-report
description	Professional penetration testing report writing — executive summary, findings format, CVSS severity, risk matrix, attack chains, and remediation roadmaps

Penetration Testing Report Methodology

Report Structure

A professional pentest report has two audiences: executives who need to understand risk and make budget decisions, and technical staff who need to reproduce findings and implement fixes. The report must serve both.

Full Report Outline

1. Cover Page
2. Executive Summary
3. Scope and Methodology
4. Risk Summary (heat map / dashboard)
5. Findings (detailed, sorted by severity)
6. Attack Chain Documentation
7. Remediation Roadmap
8. Appendices (raw data, tool output, screenshots)

1. Executive Summary

Audience: C-suite, board members, non-technical stakeholders Length: 1 page maximum Tone: business risk, not technical jargon

Template

EXECUTIVE SUMMARY

[Organization] engaged [Firm] to conduct a [type] penetration test of [scope]
from [start date] to [end date]. The assessment focused on [objective].

Overall Risk Rating: [CRITICAL / HIGH / MODERATE / LOW]

Key Findings:
- [N] Critical findings requiring immediate remediation
- [N] High findings requiring remediation within 30 days
- [N] Medium findings requiring remediation within 90 days
- [N] Low/Informational findings for awareness

The most significant finding was [brief description of worst finding and its
business impact in plain language]. An attacker exploiting this vulnerability
could [business consequence: access customer data, control physical systems,
disrupt operations, etc.].

[One sentence on overall security posture — strengths observed and primary
areas of concern.]

Recommended immediate actions:
1. [Most urgent remediation — one sentence]
2. [Second priority — one sentence]
3. [Third priority — one sentence]

Executive Summary Rules

• NO CVE numbers, protocol names, or tool output
• Frame everything as business risk ("an attacker could access customer records" not "SQLi in /api/users endpoint")
• Include positive findings ("Multi-factor authentication was properly enforced on VPN access")
• Use analogies for technical concepts if needed
• End with clear, actionable recommendations

2. Scope and Methodology

Scope Documentation

SCOPE

Test Type: [Black box / Gray box / White box]
Engagement Period: [Start] to [End]
Testing Window: [Business hours / After hours / 24x7]
Authorization: [Reference to signed Rules of Engagement document]

In-Scope Assets:
- [IP ranges, domains, device types, physical locations]
- [Specific systems, applications, wireless networks]

Out-of-Scope:
- [Explicitly excluded systems]
- [Denied attack types: DoS, social engineering, etc.]

Credentials Provided: [None / Standard user / Admin (specify)]

Methodology Section

Reference established frameworks:

• OWASP Testing Guide — for web applications
• PTES (Penetration Testing Execution Standard) — general methodology
• NIST SP 800-115 — technical guide to information security testing
• OSSTMM — Open Source Security Testing Methodology Manual

Document the phases executed:

1. Reconnaissance and information gathering
2. Service enumeration and vulnerability scanning
3. Exploitation and credential testing
4. Post-exploitation and lateral movement
5. Reporting and evidence documentation

List tools used (with versions) — this enables reproducibility.

3. Findings Format

Individual Finding Template

FINDING: [F-001] [Descriptive Title]

Severity: [Critical / High / Medium / Low / Informational]
CVSS v3.1 Score: [0.0-10.0]
CVSS Vector: [e.g., AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H]

Affected Asset(s): [IP, hostname, device, application]

Description:
[2-3 sentences explaining the vulnerability in clear technical language.
What is the vulnerability, where does it exist, and why is it a problem.]

Evidence:
[Screenshots, command output, captured data — redacted as appropriate.
Enough detail for the client to reproduce the finding.]

Impact:
[What can an attacker do with this vulnerability? Be specific:
- Access to X records of customer data
- Ability to unlock physical door Y
- Control of device Z motor/actuator
- Lateral movement to internal network]

Remediation:
[Specific, actionable fix. Not "improve security" but "change the default
password on device X to a unique 16+ character password and disable the
default admin account."]

References:
[CVE numbers, vendor advisories, OWASP references, CWE IDs]

CVSS v3.1 Scoring Guide

Attack Vector (AV):

• Network (N) = 0.85 — remotely exploitable
• Adjacent (A) = 0.62 — requires same network segment (BLE, WiFi, LAN)
• Local (L) = 0.55 — requires local access
• Physical (P) = 0.20 — requires physical device access

Attack Complexity (AC):

• Low (L) = 0.77 — no special conditions needed
• High (H) = 0.44 — requires specific configuration, race condition, MITM

Privileges Required (PR):

• None (N) = 0.85 — no authentication needed
• Low (L) = 0.62/0.68 — standard user privileges
• High (H) = 0.27/0.50 — admin privileges needed

User Interaction (UI):

• None (N) = 0.85 — no user action needed
• Required (R) = 0.62 — victim must click/interact

Scope (S):

• Unchanged (U) — impact limited to vulnerable component
• Changed (C) — impact extends beyond vulnerable component

CIA Impact (each rated):

• High (H) = 0.56 — total loss of confidentiality/integrity/availability
• Low (L) = 0.22 — partial loss
• None (N) = 0.00 — no impact

Severity Mapping for Cyber-Physical Findings

Finding	Typical CVSS	Severity
Unauthenticated BLE write unlocks smart lock	8.1 (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)	HIGH
Default credentials on IoT device (network)	9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)	CRITICAL
WiFi deauth causes device denial of service	6.5 (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)	MEDIUM
Static Sub-GHz code replay opens garage door	6.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N)	MEDIUM
Unencrypted BLE leaks sensor data	6.5 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)	MEDIUM
Hardcoded BLE pairing PIN	7.4 (AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N)	HIGH
IR replay controls critical device	4.6 (AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N)	MEDIUM

4. Risk Matrix

Likelihood x Impact Grid

                    IMPACT
                Low    Medium    High    Critical
           ┌─────────┬─────────┬─────────┬─────────┐
  High     │ MEDIUM  │  HIGH   │ CRITICAL│ CRITICAL│
           ├─────────┼─────────┼─────────┼─────────┤
LIKELIHOOD │         │         │         │         │
  Medium   │  LOW    │ MEDIUM  │  HIGH   │ CRITICAL│
           ├─────────┼─────────┼─────────┼─────────┤
  Low      │  LOW    │  LOW    │ MEDIUM  │  HIGH   │
           └─────────┴─────────┴─────────┴─────────┘

Likelihood factors:

• Skill level required (script kiddie → nation state)
• Access required (internet → physical proximity → inside building)
• Tools required (free/common → custom/expensive)
• Whether exploit is public / Metasploit module exists

Impact factors:

• Data sensitivity (public → PII → financial → health → classified)
• Physical safety implications (none → property → personal safety)
• Business disruption potential (minutes → hours → days)
• Regulatory implications (none → fines → license revocation)

5. Attack Chain Documentation

Purpose

Show how individual findings chain together to demonstrate real-world attack scenarios. Individual medium findings may combine into a critical attack path.

Format

ATTACK CHAIN: [AC-001] [Descriptive Name]

Overall Severity: [Highest severity in the chain, potentially elevated]

Step 1: [F-003] WiFi reconnaissance identified corporate SSID
  → Discovered "CorpWiFi" WPA2-Personal network

Step 2: [F-007] Deauth attack captured WPA2 handshake
  → 4-way handshake captured for offline cracking

Step 3: [F-008] Weak WiFi password cracked in 4 hours
  → Password "Company2024" recovered via hashcat

Step 4: [F-012] Internal network access revealed IoT devices
  → 14 smart locks discovered on 192.168.10.0/24

Step 5: [F-013] Default credentials on smart lock management server
  → admin:admin granted full lock control

Result: Complete physical access to all electronically-locked doors
  from a position outside the building perimeter.

Chain Severity Elevation

• If a chain of Medium findings results in Critical impact, the chain is rated Critical
• Individual findings retain their original severity
• The chain demonstrates why "medium" findings still require remediation

6. Remediation Roadmap

Priority Tiers

Immediate (0-7 days):

• Critical severity findings
• Findings actively exploitable from the internet
• Default credentials on any network-accessible service
• Anything with safety implications

Short-term (8-30 days):

• High severity findings
• Findings exploitable from adjacent network
• Credential issues requiring password policy changes
• Encryption gaps

Medium-term (31-90 days):

• Medium severity findings
• Architecture improvements (network segmentation, monitoring)
• Process changes (patch management, credential rotation)

Long-term (91-180 days):

• Low severity findings
• Strategic improvements (replace legacy protocols, deploy WIDS)
• Training and awareness programs

Remediation Entry Format

Priority: [Immediate / Short-term / Medium-term / Long-term]
Finding Reference: [F-001, F-003, F-007]
Remediation Action: [Specific technical action]
Estimated Effort: [Hours / person-days]
Responsible Team: [IT, Security, Facilities, Development]
Verification: [How to confirm the fix worked]

Writing Quality Standards

• Be specific — "Change password on Hikvision DVR at 192.168.1.50 from admin:12345" not "improve password policy"
• Be reproducible — another tester should be able to reproduce every finding from your evidence
• Be objective — report facts, not opinions; let the evidence speak
• Be consistent — same severity criteria applied to every finding
• Redact appropriately — blur sensitive data in screenshots, mask full credentials in body (show in secure appendix)
• Proofread — the report represents your professionalism; typos and formatting errors undermine credibility
• Version control — draft → internal review → client review → final
• Timestamps — every finding should note when it was discovered and verified

Operational Notes

• Generate the report structure as you test — do not leave all documentation to the end
• Take screenshots at every step of exploitation — you cannot go back after remediation
• Keep a testing log with timestamps — this is your evidence chain
• Separate the report from raw data — report is the deliverable, raw data is the appendix
• Provide the report in both PDF (for distribution) and editable format (for client to track remediation)
• Include a findings tracker spreadsheet for the client to mark remediation status