Red Team Report

Use this skill for client-deliverable reports:

• External red-team engagements with a signed SOW
• Pentest reports going to a CISO / IT-Sec team (not a triager)
• Findings that will be reviewed by both technical and non-technical stakeholders
• Reports that need DOCX/PDF output (not just markdown / platform UI)

• Bug-bounty platform submissions (use report-writing / bugcrowd-reporting instead)
• Quick proof-of-concept memos
• Internal team writeups

This is the canonical structure each finding follows:

```markdown

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

2. Observations

• <Observation 1>
• <Observation 2>
• ...

3. Description

4. Impact

5. Recommendation

6. Proof of Concept (PoC)

Step 1: <action>

<full HTTP request or curl one-liner>

Step 2: <action>

<response excerpt>

Screenshot:  ```

Severity table (client-facing — different from CVSS-only)

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

1. Don't retract findings that stopped reproducing

2. Don't hedge in the Impact section

3. Don't generic-CIA the impact

4. Don't list every recon finding as a finding

5. Don't bury the PoC

# 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\"))}') "

Image filename convention

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.

• Use past tense for observations ("The endpoint returned a 200 status code")
• Use present tense for descriptions of the flaw ("The application does not validate...")
• Use imperative for recommendations ("Apply patch ... by ...")
• Number reproduction steps; never "first... then... also..."

• "Could potentially" — prove it or drop it
• "It might be possible" — same
• "We recommend implementing security best practices" — say which one specifically
• "The application is vulnerable to..." without saying what specifically

Example: hardcoded JWT in APK

Red-team deliverables should include — not just bug-bounty payable bugs:

• Information disclosure that helps attack mapping (CodeIgniter debug toolbar leaking routes, version banners on appliances) — Medium
• User enumeration (Microsoft OneDrive 302 vs 404 differential) — Medium
• Pre-existing security state observations (247 accounts already locked by external attacker; weak password policies) — Informational with stakeholder relevance
• Defensive observations (SOC patched our SQLi within 30 min — evidence of working detection) — Informational/positive
• Sister-app pattern issues (same code template across 7 apps) — Medium (multiplied blast radius)

Beyond findings themselves, the deliverable should include:

• Detected SOC responses (timestamps when defenses kicked in)
• Concurrent external attacker activity (if any was observed)
• Findings the client patched during the engagement (with PoC pre-patch as evidence)
• Tooling failures (e.g., MCP timeout, CAPTCHA not solvable) — these affect what was/wasn't testable

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:

• [ ] Every finding has all 6 sections populated (no "TBD")
• [ ] Every finding has at least one screenshot or HTTP-level evidence
• [ ] Every PoC includes redactions for client PII (mask emails, phone numbers, IDs)
• [ ] Every screenshot is referenced in the MD with a relative path that resolves
• [ ] DOCX render check — image count matches MD reference count
• [ ] Severity ordering: Critical findings first, then High, etc.
• [ ] Executive summary is updated to match final findings (count, themes)
• [ ] Cleanup statement explicitly says what was created and what was removed
• [ ] IoC section enables the SOC to reconstruct what they saw
• [ ] Spell-check (especially client company name, product names)
• [ ] All tool versions noted in methodology
• [ ] Status field set correctly on every finding (especially patched-mid-engagement)

• report-writing — bug-bounty platform reports (different format, different audience)
• redteam-mindset — informs what counts as a finding worth shipping
• mid-engagement-ir-detection — informs the "patched mid-engagement" status pattern
• evidence-hygiene — informs screenshot redaction discipline
• m365-entra-attack, enterprise-vpn-attack, etc. — each provides finding-templates specific to its attack surface

• DO NOT write a 50-page report for 3 findings — pad-by-page erodes credibility
• DO NOT use the same severity for everything — calibrate
• DO NOT copy-paste OWASP top-10 boilerplate into Description sections
• DO NOT include findings without PoCs — they read as speculative
• DO NOT skip the Recommendation section's specificity — "patch and review" doesn't help
• DO NOT mix bug-bounty CVSS scoring with red-team severity unthinkingly — context differs (e.g., a Medium on a CVSS basis can be Critical for the client if it touches a regulated dataset)

For calibration:

• 14 findings shipped (2 Critical, 4 High, 5 Medium, 3 Low/Info)
• 18 screenshots embedded
• 52,737 bytes markdown / 2,262,484 bytes DOCX
• 414 paragraphs, 123 headings in DOCX
• 16 inline images (2 were inline in MD-only edge cases)
• Time-to-deliverable: ~6 hours after engagement close for first draft

• 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.