8.1 Finding Documentation

What you're building: A repeatable finding template that works for every vulnerability type — one that gives the technical reader enough to reproduce the issue and the developer enough to fix it, without requiring a back-and-forth. Good finding documentation is the foundation every other deliverable is built on.

Document individual findings with enough detail for both a technical reader and a developer to independently understand, reproduce, and remediate the issue.

Tactic: Evidence Capture & Risk Communication

Technique: Finding Anatomy — structure every finding the same way so the reader always knows exactly where to look for what they need.

Work through these phases for every finding before writing it up.

Phase 1 — Evidence Capture (During the Engagement)

# Web: capture raw HTTP requests and responses in Burp Suite
# Right-click → Copy to file → save .txt with finding ID in filename
# FINDING-01_sqli_login.txt

# Command-line: capture terminal output to a timestamped log
script -a /tmp/finding-01-$(date +%Y%m%d-%H%M%S).log
# Everything in the terminal is now logged until you type 'exit'

# Screenshots: annotate and crop immediately while context is fresh
# Mark the vulnerable element with a red box or arrow — reviewers shouldn't have to guess what to look at

# Network: save Wireshark captures for covert channels or unusual protocols
tshark -w /tmp/capture-c2-callback.pcap -i eth0 -f "host 10.10.10.5"

Phase 2 — Finding Triage & Severity Rating

# CVSS Quick Scoring Guide

| Severity | CVSS Range | Attack Vector | Complexity | Privileges | Interaction |
|---|---|---|---|---|---|
| Critical | 9.0–10.0 | Network | Low | None | None |
| High | 7.0–8.9 | Network | Low | Low/None | None |
| Medium | 4.0–6.9 | Network/Local | Low/High | Low | Required |
| Low | 0.1–3.9 | Local | High | Low | Required |

# Common Scoring Examples
# Unauthenticated RCE: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 (Critical)
# Kerberoasting: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H → 8.8 (High)
# LLMNR Poisoning: AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H → 8.0 (High)
# SMB Signing Disabled: AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H → 6.8 (Medium)

Phase 3 — Finding Write-Up Template

## Finding: [Descriptive Title — System + Vulnerability Type]
**Severity:** Critical
**CVSS 3.1:** 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**CWE:** CWE-89 (SQL Injection)
**Affected System:** app.contoso.com (10.10.10.5)
**MITRE ATT&CK:** T1190 — Exploit Public-Facing Application

### Description
[2-3 sentences: what the vulnerability is, where it lives, and how it works.]

### Evidence
```
[Raw HTTP request/response, or command + output. Include timestamp.]
```

### Impact
[Business impact language: "An unauthenticated attacker can exfiltrate the full customer
database (PII for ~500,000 users) or modify financial records."]

### Remediation
[Specific, actionable fix: "Upgrade login.php line 47 to use parameterized queries.
Reference: OWASP SQL Injection Prevention Cheat Sheet."]

### References
- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- OWASP: https://owasp.org/www-community/attacks/SQL_Injection

Why: The raw HTTP request in the evidence section lets a developer reproduce the issue in 60 seconds without asking any questions. Missing it means a back-and-forth with the developer before they can even start fixing it — and a finding that doesn't get fixed is a finding that wasn't worth writing.

NOTE: Always include the raw HTTP request and response for web vulnerabilities. For AD findings, include the BloodHound attack path screenshot alongside the command output.

Part of Pillar 8: Reporting & Portfolio Development.