From claude-bughunter
Generates client-facing red-team reports in a canonized Subject/Observations/Description/Impact/Recommendation/PoC structure for external enterprise engagements with DOCX/PDF output.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claude-bughunter:redteam-report-templateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill for **client-deliverable** reports:
Use this skill for client-deliverable reports:
Do NOT use for:
report-writing / bugcrowd-reporting instead)This is the canonical structure each finding follows:
## Finding F##: <descriptive title>
**Severity:** Critical / High / Medium / Low / Informational
**Status:** Confirmed / Patched mid-engagement / Suspected (1 signal)
**CVSS 3.1:** <score> (<vector>)
**Affected Asset:** <URL / IP / app name>
### 1. Subject
<One-line statement of the issue. Plain English, no jargon.>
### 2. Observations
<Bulleted list of what was observed during testing. Concrete facts only — no interpretation yet.>
- <Observation 1>
- <Observation 2>
- ...
### 3. Description
<Technical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>
### 4. Impact
<What an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business — money, data, reputation, regulatory exposure.>
### 5. Recommendation
<Specific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid "implement security best practices" — say what specifically.>
### 6. Proof of Concept (PoC)
<Steps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>
**Step 1:** <action>
```http
<full HTTP request or curl one-liner>
Step 2:
<response excerpt>
Screenshot:

---
## Severity & status disciplines
### Severity table (client-facing — different from CVSS-only)
| Severity | Business definition | CVSS rough range |
|---|---|---|
| Critical | Direct revenue/data loss without prerequisites | 9.0-10.0 |
| High | Full account/system takeover with limited prerequisites | 7.0-8.9 |
| Medium | Significant data exposure or partial compromise | 4.0-6.9 |
| Low | Information disclosure with limited exploitation path | 0.1-3.9 |
| Informational | Hygiene finding, no immediate exploit | N/A |
### Status field (red-team-specific)
This is the field that distinguishes red-team deliverables from bug-bounty reports. Use one of:
- **Confirmed** — reproduced multiple times, with full PoC
- **Confirmed; patched mid-engagement** — was reproducible, client patched during the test window (still ship the finding — see `mid-engagement-ir-detection`)
- **Confirmed; partially reproducible** — works but needs specific conditions
- **Suspected (1 signal)** — single indicator, not confirmed (rare — usually drop)
- **Out-of-band** — finding from passive recon, not actively tested
---
## Mistakes to avoid (from authorized-engagement)
### 1. Don't retract findings that stopped reproducing
If a finding was confirmed and then stopped working, that is almost always a CLIENT PATCH, not a finding-was-false. The correct response is "Confirmed; patched mid-engagement" with timestamps showing when it broke. See `mid-engagement-ir-detection`.
### 2. Don't hedge in the Impact section
Bad: "An attacker could potentially be able to access user data, which may lead to..."
Good: "An attacker reads any user's profile data. Demonstrated on test user `[email protected]` at 14:22 IST."
### 3. Don't generic-CIA the impact
Bad: "Loss of confidentiality and integrity of customer data"
Good: "Read access to 247,000 customer records including PAN cards, addresses, GST numbers. India DPDPA Section 33 mandates 72-hour breach disclosure to DPB."
### 4. Don't list every recon finding as a finding
Recon notes (subdomains found, ports open, technologies fingerprinted) belong in a separate **Recon / Attack Surface** appendix, not the findings list. A finding must have an attacker-attainable outcome.
### 5. Don't bury the PoC
Each finding MUST have reproducible steps. The PoC section is what proves the finding to a skeptical reader. If you can't write the PoC clearly, the finding probably isn't ready to ship.
---
## Document-level structure
Executive Summary (1 page, non-technical)
Engagement Details
Risk Summary Table
| F# | Title | Severity | Status |
|---|---|---|---|
| F01 | ... | Critical | Confirmed |
| ... |
Findings (one per ## section, in severity order — Critical first)
Attack Surface / Recon Appendix
Indicators of Compromise (IoCs)
Cleanup Statement
Appendices (raw output, screenshots index, full target list)
---
## DOCX generation pipeline (markdown → docx with embedded images)
```bash
# Prerequisite: pandoc installed
brew install pandoc
# Convert
pandoc REPORT_FINAL.md \
-o REPORT_FINAL.docx \
--resource-path=engagement_log/poc \
--reference-doc=~/.claude/skills/redteam-report-template/templates/reference.docx \
--toc \
--toc-depth=2 \
--highlight-style=tango
# Verify image count
python3 -c "
from docx import Document
d = Document('REPORT_FINAL.docx')
imgs = [r for r in d.part.rels.values() if 'image' in r.target_ref]
print(f'Embedded images: {len(imgs)}')
print(f'Paragraphs: {len(d.paragraphs)}')
print(f'Headings: {sum(1 for p in d.paragraphs if p.style.name.startswith(\"Heading\"))}')
"
screenshots/F<NN>_<descriptive>.png
Examples:
F01_locked_accounts.png
F02a_saml_landing.png
F02b_saml_ca_block_page.png
F03_sqli_timing_chart.png
F15_saml_metadata.png
Variants get letter suffixes (F02a, F02b). Always zero-pad finding number.
| Section | Tone |
|---|---|
| Subject | Plain English, jargon-free, 1 line |
| Observations | Bulleted facts, past tense ("observed that...") |
| Description | Technical but accessible; assume CISO reader |
| Impact | Business-translated; tie to revenue/regulation |
| Recommendation | Imperative, specific, actionable |
| PoC | Operator-level technical; copy-pasteable |
Always:
Never:
Example: hardcoded JWT in APK
| Section | Technical framing | CISO framing | Board framing |
|---|---|---|---|
| Impact | "JWT signing key extracted from APK enables forging admin tokens" | "Anyone with the customer-facing mobile app can read any customer's invoice" | "A leaked secret in our mobile app lets attackers impersonate users" |
The same finding's Impact paragraph should cover both ends — start with the business outcome, then drop into technical detail.
Red-team deliverables should include — not just bug-bounty payable bugs:
Bug bounty would reject most of these. Red-team deliverables embrace them — the client paid for the assessment to know.
Beyond findings themselves, the deliverable should include:
Each gives the client context about their real-world detection capability, which often matters more than the findings themselves.
Maintain reusable boilerplate in:
~/.claude/skills/redteam-report-template/templates/
executive_summary.md # Reusable exec summary skeleton
methodology.md # Standard methodology section
cleanup_statement.md # Standard cleanup language
reference.docx # Pandoc style template (fonts, headings, colors)
cover.docx # Cover page template
Don't write these from scratch each engagement; clone and customize.
Pre-delivery checklist:
report-writing — bug-bounty platform reports (different format, different audience)redteam-mindset — informs what counts as a finding worth shippingmid-engagement-ir-detection — informs the "patched mid-engagement" status patternevidence-hygiene — informs screenshot redaction disciplinem365-entra-attack, enterprise-vpn-attack, etc. — each provides finding-templates specific to its attack surfaceFor calibration:
These numbers are typical for a 1-week external red-team engagement on a mid-size enterprise. Scale down for short tests, up for full purple-team exercises.
triage-validation — This template ingests findings that have ALREADY passed the 7-Question Gate. Engagement flow: every finding through triage-validation first → only validated findings → redteam-report-template packaging. Skipping triage produces a deliverable padded with informational noise that erodes client trust.evidence-hygiene — The DOCX with 16 embedded screenshots only works if evidence was captured systematically throughout the engagement. Engagement flow: evidence-hygiene discipline at session start → timestamped, organized screenshot folder → redteam-report-template consumes that folder to populate Evidence blocks.redteam-mindset — The Subject / Observations / Description / Impact / Recommendation / PoC structure assumes the operator already thinks like a red-teamer (impact-first, blast-radius framing). Engagement flow: redteam-mindset loaded at engagement start → findings collected with red-team framing baked in → redteam-report-template produces deliverable without rewriting every Impact section.mid-engagement-ir-detection — Defensive-action findings (SOC patches mid-test, new IPS rules deployed, account lockouts triggered by external attacker) are first-class findings in red-team deliverables. Engagement flow: mid-engagement-ir-detection captures behavior-change events → each becomes its own Subject in the deliverable, framed as "client capability observation" not as "bug we missed."report-writing + bugcrowd-reporting — Bug-bounty platform reports use DIFFERENT structure (one finding per submission, platform-specific severity scoring, OOS-clause counters). Engagement flow: if engagement mode is bug-bounty per project memory → use report-writing / bugcrowd-reporting instead. This template is ONLY for external red-team / enterprise client deliverables.npx claudepluginhub elementalsouls/claude-bughunterPenetration test and red team report writing methodology covering executive summaries, technical finding format, CVSS/OWASP scoring, evidence hygiene, and deliverable formats.
Provides CVSS 3.1 vector examples, executive summary template, technical finding template, and remediation language for pentest reports. Useful for drafting security assessments.
Guides writing impact-first bug bounty reports for HackerOne, Bugcrowd, Intigriti, and Immunefi with templates, CVSS 3.1 scoring, title formulas, and downgrade counters.