{"id":"offensive-reporting","name":"offensive-reporting","summary":"ペネトレーションテストとレッドチームレポート作成の方法論。","body":"# Penetration Test Reporting — Professional Methodology\n\nA 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.\n\n## Quick Workflow\n\n1. Capture evidence as you exploit — never reconstruct after the fact\n2. Draft each finding immediately while context is fresh; one finding = one numbered file\n3. Build the executive summary last, after all findings are scored\n4. Two-pass review: technical accuracy first, then read-as-CISO for narrative\n5. Hand off with a retest plan and a JSON/CSV index for the client's tracking system\n\n---\n\n## Report Structure (Standard)\n\n```\n1. Executive Summary             ← Last to write, first read\n2. Engagement Overview\n   2.1 Scope\n   2.2 Methodology\n   2.3 Limitations / Assumptions\n   2.4 Timeline\n   2.5 Team\n3. Risk Summary                  ← Heatmap, finding count by severity\n4. Technical Findings            ← One per finding, sorted by severity\n5. Attack Narratives / Chains    ← Critical chains called out separately\n6. Strategic Recommendations     ← Programmatic, not finding-by-finding\n7. Appendices\n   A. Tools Used\n   B. Indicators of Compromise (for blue team)\n   C. Raw Evidence Pointers\n   D. Glossary\n```\n\n---\n\n## Executive Summary — The 90-Second Read\n\nThe executive summary is for the CISO, the GRC officer, and the board member. They read this and nothing else.\n\n**Structure (one page max):**\n\n1. **Engagement context** — what was tested, when, by whom (1 sentence)\n2. **Headline finding** — the worst thing you found, in business terms (2–3 sentences)\n3. **Risk verdict** — overall posture in plain language (1 paragraph)\n4. **Counts** — number of findings by severity, in a small table\n5. **Top 3 strategic recommendations** — programmatic fixes, not \"patch CVE-X\"\n\n**Words to avoid in the executive summary:**\n`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.\")\n\n**Words to include:**\nBusiness impact (`customer data`, `regulatory exposure`, `operational disruption`, `financial loss`). Anchor every finding to a business consequence.\n\n---\n\n## Technical Finding Template\n\n```markdown\n## Finding ID — Short Descriptive Title\n\n**Severity:** Critical (CVSS 9.8 — vector below)\n**Affected Scope:** <hosts/URLs/components, with version where relevant>\n**Status:** Open / Fixed in retest / Accepted Risk\n**CWE:** CWE-89 (SQL Injection)\n**OWASP:** A03:2021 — Injection\n\n### Summary\nOne paragraph. What is the finding, why does it matter, what's the worst case.\n\n### Background\nWhat technology is involved and why this class of bug exists. Two paragraphs max.\nSkip if obvious (e.g. don't explain XSS to an XSS shop).\n\n### Description\nDetailed walkthrough of the issue. The root cause, not just the symptom.\n\n### Reproduction Steps\n1. Numbered, copy-paste ready.\n2. Include the exact request/response, redacted.\n3. A reader with no engagement context should reproduce in <15 minutes.\n\n### Evidence\n- `screenshots/finding-007/01-payload.png`\n- `requests/finding-007/initial-poc.http`\n- `evidence-log.csv` line 142 (timestamp 2025-04-12 14:33:07Z)\n\n### Impact\nConcrete. Quantified where possible.\n- \"Read access to the entire customer table (~2.3M records)\"\n- \"Authenticate as any user; verified for sample ID 1, 2, 999, 1000000\"\n- \"Cross-tenant access — verified by reading data from acquired-tenant ABC\"\n\n### Remediation\nSpecific, actionable, ordered by precedence:\n1. **Fix the bug** — exact code change or config flag\n2. **Defense in depth** — secondary control (WAF rule, input validation)\n3. **Detection** — log line / SIEM rule that would have caught the exploit\n\n### References\n- CWE / OWASP / CAPEC\n- Vendor advisory if known CVE\n- Blog posts only if directly relevant\n\n### Notes for Retest\nWhat you'd do to verify the fix. Specific request, specific expected response.\n```\n\n---\n\n## Severity Scoring\n\n### CVSS v3.1 Discipline\n\nCVSS is a tool, not a verdict. Score it, then sanity-check against business impact.\n\n```\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical\n```\n\nFor every metric, justify the choice in one sentence:\n- `AV:N` — exposed to internet (port 443)\n- `AC:L` — no special preconditions\n- `PR:N` — no authentication needed\n- `UI:N` — no user interaction\n- `S:U` — does not cross security scope\n- `C:H` `I:H` `A:H` — full read/write/availability impact on the database\n\nIf two reasonable people would score it differently, document why you chose what you chose.\n\n### When CVSS Lies\n\nCVSS 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.\n\nIn those cases, score CVSS honestly and then **add a \"Business Impact Adjustment\"** paragraph that argues for higher reporting severity. Don't lie with CVSS.\n\n### CVSS v4.0 (where required)\n\nCVSS 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.\n\n### OWASP Risk Rating (alternative)\n\nFor web-app-only engagements where CVSS feels stretched, OWASP's risk rating (likelihood × impact across multiple factors) often communicates better.\n\n---\n\n## Evidence Discipline\n\n### What to Capture\n\nFor every finding, every action:\n\n1. **Timestamp** (UTC, ISO 8601)\n2. **Source IP** (yours, including any pivot)\n3. **Target** (host, URL, RPC interface)\n4. **Action** (what request was sent)\n5. **Result** (response, what you got)\n6. **Hash** of any data extracted (so you can prove what you saw)\n\n```csv\ntimestamp,operator,src_ip,target,action,result_hash,notes\n2025-04-12T14:33:07Z,KA,10.10.10.5,app.client.com,SQLi probe ' OR 1=1--,sha256:abc...,initial detection\n```\n\nThis is the audit trail. Clients with mature security teams will ask for it.\n\n### Redaction Rules\n\nBefore any artifact leaves your secure environment:\n\n- **Replace credentials** with placeholders: `<REDACTED-PASSWORD>`, `<TOKEN-A1>`\n- **Hash extracted PII** — never include real names, emails, SSNs in screenshots\n- **Crop screenshots** to the relevant area; check for browser tab leaks (other tabs visible)\n- **Strip EXIF** from images; auto-redact via `exiftool -all= *.png`\n- **Remove debug toolbars** from screenshots that reveal client infrastructure paths\n- **Verify URLs in screenshots** don't include session tokens\n\n### Storage & Chain of Custody\n\n- Encrypted volume during the engagement (LUKS, FileVault, BitLocker)\n- Per-engagement key, not a master operator key\n- Wipe to client-spec at end of engagement (typically 30–90 days post-delivery)\n- Retain only the report and a hash manifest of evidence, deletable on request\n\n---\n\n## Scope, Limitations, and Assumptions\n\nThese three sections protect both you and the client. Be explicit.\n\n### Scope\n- IPs / domains / repos / accounts in scope, with start/end of engagement window\n- Excluded: third-party SaaS used by the client (they don't own it)\n- Out of scope by request: physical, social engineering against staff, DoS\n\n### Limitations\n- \"Testing was conducted from the internet only; no internal network access provided\"\n- \"Source code review was not in scope\"\n- \"Production database mutations were avoided per ROE\"\n- \"No coordinated downtime — testing windows were 22:00–06:00 UTC\"\n\n### Assumptions\n- \"We assumed the staging environment mirrors production\"\n- \"We assumed the WAF in front of app.client.com is the same as production\"\n- \"Service accounts with admin rights were assumed pre-existing\"\n\n---\n\n## Risk Summary & Heatmap\n\nShow, don't tell. A visual summary every executive can read in 5 seconds:\n\n```\nSeverity   Count   Top Example\nCritical     3     RCE via deserialization (Finding #2)\nHigh         7     ADCS ESC1 → Domain Admin (Finding #11)\nMedium      14     Stored XSS in customer support panel (Finding #4)\nLow         22     TLS 1.0 still enabled on api.client.com (Finding #29)\nInfo        11     —\n```\n\nA simple bar chart or stoplight grid converts this to a one-glance summary. Put it on page 2 (after exec summary).\n\n---\n\n## Attack Chains / Narratives\n\nCritical findings rarely matter in isolation. The chain is the story:\n\n```\n1. Phishing email → user runs HTA payload (Finding #1, Medium)\n2. Local UAC bypass via Token Manipulation (Finding #5, Low)\n3. Kerberoast service account (Finding #11, High)\n4. Crack TGS offline → service account password (Finding #11)\n5. ACL abuse: service account has WriteDacl on Domain Users (Finding #14, High)\n6. Grant DCSync, dump krbtgt → Golden Ticket → Domain Admin (Finding #15, Critical)\n\nTotal time: 4 hours. Detection points missed: 3 (see Appendix B).\n```\n\nHighlight chains separately because the *combination* often warrants higher severity than any individual finding.\n\n---\n\n## Strategic Recommendations\n\nBelow the per-finding remediations, write 3–5 programmatic recommendations:\n\n- \"Adopt SAST in CI for Java services\" (addresses 12 findings)\n- \"Roll out tier-0 admin model for AD\" (addresses entire AD attack chain)\n- \"Centralize secrets in HashiCorp Vault; rotate hardcoded creds\" (addresses 9 findings)\n\nThis is what the CISO presents to the board. Make it memorable.\n\n---\n\n## Deliverable Formats\n\n| Format | Use |\n|--------|-----|\n| **PDF** | Executive read, formal record, contractual deliverable |\n| **DOCX** | If the client wants to redact or extend |\n| **HTML** | Internal portal upload, searchable via grep |\n| **JSON** | SIEM / GRC tool ingestion (DefectDojo, Faraday, ServiceNow) |\n| **CSV** | Quick import into Jira / Asana for tracking |\n| **Markdown source** | The single source of truth that generates all the above |\n\nBuild all formats from one Markdown source via Pandoc / a static site generator. Never maintain parallel formats by hand.\n\n```bash\n# Markdown → polished PDF via Pandoc + LaTeX template\npandoc report.md -o report.pdf \\\n  --template=client-template.tex \\\n  --pdf-engine=xelatex \\\n  --metadata=title:\"Penetration Test Report — Client Co.\" \\\n  --toc --number-sections\n```\n\n---\n\n## Common Report Mistakes\n\n| Mistake | Fix |\n|---------|-----|\n| CVSS 9.0 on every finding (\"over-CVSSing\") | Score honestly; clients lose trust if everything is critical |\n| Marketing language (\"revolutionary attack\") | Plain professional tone |\n| Tool output dumped as evidence | Curate; show the relevant 5 lines |\n| Generic remediation (\"validate input\") | Specific code/config changes |\n| Missing reproduction steps | If they can't reproduce, they can't fix |\n| Untimed evidence | Every action gets a UTC timestamp |\n| Confusing identical findings | Group by class, list affected items in a table |\n| Forgotten retest plan | Each finding includes how you'll verify the fix |\n| Failure to separate scope from limitations | Scope = what we tested; Limitations = what blocked us |\n| Treating informational findings as filler | Either drop them or write them well |\n\n---\n\n## Reporting for Bug Bounty (Different Audience)\n\nBug bounty triagers are time-pressured and skeptical. Adjust:\n\n- **Title**: include the bug class + endpoint + impact in 80 chars\n- **Reproduction**: a single curl command if possible, plus the expected vs actual response\n- **Impact**: anchor to the program's threat model (read PII? auth bypass? cross-account?)\n- **Avoid**: walls of text, screenshots without a request log, claims without reproduction\n\nA good bounty report is read in 2 minutes and reproduced in 5. A bad one bounces with \"more info.\"\n\n---\n\n## Retest & Closeout\n\n```markdown\n### Retest Summary\n\n| Finding | Original Severity | Retest Status | Verification Date |\n|---------|-------------------|---------------|-------------------|\n| #1 | Critical | ✓ Fixed (verified) | 2025-05-10 |\n| #2 | High | ✓ Fixed | 2025-05-10 |\n| #5 | Medium | ⚠ Partially fixed — see notes | 2025-05-10 |\n| #11 | High | ✗ Not fixed — finding stands | 2025-05-10 |\n| #14 | Low | • Accepted Risk (client decision) | 2025-05-10 |\n```\n\nFor each finding, include the exact verification request/response showing the fix. Without proof, \"fixed\" is hearsay.\n\n---\n\n## Sample CVSS Vectors (Reference)\n\n| Class | Typical Vector | Score |\n|-------|---------------|-------|\n| Unauth RCE | `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` | 9.8 |\n| Authed RCE | `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` | 8.8 |\n| Stored XSS | `AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N` | 5.4 |\n| IDOR (PII read) | `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` | 6.5 |\n| SSRF (cloud meta) | `AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N` | 9.0 |\n| Open Redirect | `AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N` | 4.3 |\n\nUse these as starting points; adjust per environment.\n\n---\n\n## Tooling\n\n| Tool | Use |\n|------|-----|\n| Pandoc + LaTeX | Markdown → polished PDF |\n| Sphinx / mkdocs | Markdown → HTML portal |\n| DefectDojo | Finding tracking, JSON export |\n| Faraday | Multi-engagement aggregation |\n| Dradis | Collaborative report drafting |\n| serpico (legacy but still used) | Pentest report templates |\n| Plextrac | Commercial reporting platform |\n\n---\n\n## Key References\n\n- NIST SP 800-115 (technical security testing reporting)\n- PTES — Penetration Testing Execution Standard, reporting section\n- OWASP Testing Guide — reporting chapter\n- FIRST CVSS v3.1 / v4.0 specifications\n- CREST Cyber Security Incident Response and Penetration Testing reporting standards\n- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/reporting.md","author":"@SnailSploit","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/SnailSploit/Claude-Red/tree/main/Skills/utility/offensive-reporting","license":"MIT","category":"writing","lang":"en","tokens":3465,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}