offensive-reporting

# Penetration Test Reporting — Professional Methodology

A great finding lost in a bad report is a wasted finding. Reports are the artifact the client pays for, the auditor reads, and the developer fixes from. Treat the report with the same rigor as the exploit.

## Quick Workflow

1. Capture evidence as you exploit — never reconstruct after the fact
2. Draft each finding immediately while context is fresh; one finding = one numbered file
3. Build the executive summary last, after all findings are scored
4. Two-pass review: technical accuracy first, then read-as-CISO for narrative
5. Hand off with a retest plan and a JSON/CSV index for the client's tracking system

---

## Report Structure (Standard)

```
1. Executive Summary             ← Last to write, first read
2. Engagement Overview
   2.1 Scope
   2.2 Methodology
   2.3 Limitations / Assumptions
   2.4 Timeline
   2.5 Team
3. Risk Summary                  ← Heatmap, finding count by severity
4. Technical Findings            ← One per finding, sorted by severity
5. Attack Narratives / Chains    ← Critical chains called out separately
6. Strategic Recommendations     ← Programmatic, not finding-by-finding
7. Appendices
   A. Tools Used
   B. Indicators of Compromise (for blue team)
   C. Raw Evidence Pointers
   D. Glossary
```

---

## Executive Summary — The 90-Second Read

The executive summary is for the CISO, the GRC officer, and the board member. They read this and nothing else.

**Structure (one page max):**

1. **Engagement context** — what was tested, when, by whom (1 sentence)
2. **Headline finding** — the worst thing you found, in business terms (2–3 sentences)
3. **Risk verdict** — overall posture in plain language (1 paragraph)
4. **Counts** — number of findings by severity, in a small table
5. **Top 3 strategic recommendations** — programmatic fixes, not "patch CVE-X"

**Words to avoid in the executive summary:**
`payload`, `RCE`, `XSS`, `LDAP`, `SMB`, `kerberos`, `injection`. Translate every one. ("An attacker could run arbitrary commands on the server" not "RCE via deserialization gadget chain.")

**Words to include:**
Business impact (`customer data`, `regulatory exposure`, `operational disruption`, `financial loss`). Anchor every finding to a business consequence.

---

## Technical Finding Template

```markdown
## Finding ID — Short Descriptive Title

**Severity:** Critical (CVSS 9.8 — vector below)
**Affected Scope:** <hosts/URLs/components, with version where relevant>
**Status:** Open / Fixed in retest / Accepted Risk
**CWE:** CWE-89 (SQL Injection)
**OWASP:** A03:2021 — Injection

### Summary
One paragraph. What is the finding, why does it matter, what's the worst case.

### Background
What technology is involved and why this class of bug exists. Two paragraphs max.
Skip if obvious (e.g. don't explain XSS to an XSS shop).

### Description
Detailed walkthrough of the issue. The root cause, not just the symptom.

### Reproduction Steps
1. Numbered, copy-paste ready.
2. Include the exact request/response, redacted.
3. A reader with no engagement context should reproduce in <15 minutes.

### Evidence
- `screenshots/finding-007/01-payload.png`
- `requests/finding-007/initial-poc.http`
- `evidence-log.csv` line 142 (timestamp 2025-04-12 14:33:07Z)

### Impact
Concrete. Quantified where possible.
- "Read access to the entire customer table (~2.3M records)"
- "Authenticate as any user; verified for sample ID 1, 2, 999, 1000000"
- "Cross-tenant access — verified by reading data from acquired-tenant ABC"

### Remediation
Specific, actionable, ordered by precedence:
1. **Fix the bug** — exact code change or config flag
2. **Defense in depth** — secondary control (WAF rule, input validation)
3. **Detection** — log line / SIEM rule that would have caught the exploit

### References
- CWE / OWASP / CAPEC
- Vendor advisory if known CVE
- Blog posts only if directly relevant

### Notes for Retest
What you'd do to verify the fix. Specific request, specific expected response.
```

---

## Severity Scoring

### CVSS v3.1 Discipline

CVSS is a tool, not a verdict. Score it, then sanity-check against business impact.

```
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical
```

For every metric, justify the choice in one sentence:
- `AV:N` — exposed to internet (port 443)
- `AC:L` — no special preconditions
- `PR:N` — no authentication needed
- `UI:N` — no user interaction
- `S:U` — does not cross security scope
- `C:H` `I:H` `A:H` — full read/write/availability impact on the database

If two reasonable people would score it differently, document why you chose what you chose.

### When CVSS Lies

CVSS doesn't capture business context. A "Medium" CVSS XSS in the customer support chat panel that authenticated agents use to handle PII is more dangerous than an unauthenticated "High" SSRF on a metadata-less internal service. Use CVSS as the floor, not the ceiling.

In those cases, score CVSS honestly and then **add a "Business Impact Adjustment"** paragraph that argues for higher reporting severity. Don't lie with CVSS.

### CVSS v4.0 (where required)

CVSS v4.0 adds environmental and threat metrics that better capture real-world risk. Use it when the client mandates it (PCI DSS 4.0 trends this way) — otherwise v3.1 stays the lingua franca.

### OWASP Risk Rating (alternative)

For web-app-only engagements where CVSS feels stretched, OWASP's risk rating (likelihood × impact across multiple factors) often communicates better.

---

## Evidence Discipline

### What to Capture

For every finding, every action:

1. **Timestamp** (UTC, ISO 8601)
2. **Source IP** (yours, including any pivot)
3. **Target** (host, URL, RPC interface)
4. **Action** (what request was sent)
5. **Result** (response, what you got)
6. **Hash** of any data extracted (so you can prove what you saw)

```csv
timestamp,operator,src_ip,target,action,result_hash,notes
2025-04-12T14:33:07Z,KA,10.10.10.5,app.client.com,SQLi probe ' OR 1=1--,sha256:abc...,initial det