offensive-reporting
# ClaudeWave Editor Entry **offensive-reporting** is a penetration testing and red team reporting methodology that covers executive summary structuring for non-technical audiences, technical finding formatting with severity scoring (CVSS v3.1/v4.0 and OWASP risk rating), evidence hygiene including credential redaction and artifact management, and deliverable formats across multiple platforms. Use this skill at the end of an engagement when authoring the final client report, restructuring a draft for executive readability, or establishing a reusable reporting template for a consulting practice.
git clone --depth 1 https://github.com/SnailSploit/Claude-Red /tmp/offensive-reporting && cp -r /tmp/offensive-reporting/Skills/utility/offensive-reporting ~/.claude/skills/offensive-reportingSKILL.md
# 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 detActive Directory attack methodology for internal network red team engagements. Covers reconnaissance (BloodHound, PowerView, ADExplorer), credential abuse (Kerberoasting, ASREProasting, NTLM relay, LLMNR/NBT-NS poisoning), privilege escalation (ACL abuse, GPO abuse, unconstrained/constrained delegation), lateral movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, WMI/WinRM/PsExec), persistence (Golden/Silver/Diamond Tickets, DCSync, DCShadow, AdminSDHolder, Skeleton Key), forest trust attacks, ADCS abuse (ESC1-ESC15), and modern MDI/Defender for Identity evasion. Use when assessing on-prem AD, hybrid AD/Entra ID environments, or ADCS deployments.
Comprehensive red team operations methodology covering full engagement lifecycle from planning through reporting. Addresses engagement scoping and rules of engagement negotiation, multi-tier C2 infrastructure design with redirectors and domain fronting, malleable traffic profiles and beacon tradecraft, OPSEC discipline including attribution avoidance and indicator management, EDR and AMSI evasion techniques using direct syscalls and unhooking, data collection with chain-of-custody controls, and structured reporting with purple team debrief workflows. Covers assumed-breach, external-to-internal, insider threat, and hybrid physical-cyber engagement scenarios with MITRE ATT&CK mapping throughout. Targets operators planning or executing adversary simulation engagements against mature defenders.
Anti-forensics and evidence destruction techniques for red team operators conducting authorized engagements. Covers log clearing on Windows (wevtutil, Clear-EventLog, ETW provider patching) and Linux (journal truncation, utmp/wtmp binary editing, syslog manipulation), timestamp manipulation via Timestomp and SetMACE to defeat timeline analysis, filesystem-level anti-forensics including NTFS Alternate Data Streams for payload hiding and secure deletion with sdelete/shred, memory artifact removal to counter live forensics, disk artifact manipulation targeting MFT entries and USN journal records, network forensics evasion through encrypted C2 channels and DNS-over-HTTPS tunneling, and anti-VM/sandbox detection to avoid dynamic analysis environments. Tools: Timestomp, wevtutil, sdelete, shred, MimiPenguin, Invoke-Phant0m. Aligns to MITRE ATT&CK T1070 (Indicator Removal), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion). Each technique includes the forensic artifact it targets, the destruction or manipulation method, and the defender perspective so operators understand detection gaps they must account for.
Advanced API exploitation methodology focused on business logic abuse and sophisticated attack patterns that bypass traditional security controls. Covers business logic bypass through API call chaining and workflow manipulation. Addresses GraphQL-specific attacks including batching for credential brute-force, query depth exploitation, and introspection abuse. Includes pagination exploitation for data exfiltration, webhook hijacking for SSRF and data interception, and resource exhaustion through algorithmic complexity attacks. Covers race conditions in API transactions using parallel request techniques. Provides comprehensive JWT manipulation including algorithm confusion, kid injection, jku/x5u abuse, and claim tampering. Details API key leakage detection across source repositories, client-side code, and error messages. Covers undocumented endpoint discovery through predictable naming, debug routes, and source map analysis. Tooling includes Arjun, ParamSpider, jwt_tool, and GraphQL Voyager. Designed for authorized penetration testers targeting business logic layers that automated scanners miss.
Comprehensive API security testing methodology covering REST, gRPC, and WebSocket attack surfaces. Addresses the full OWASP API Security Top 10 2023 including BOLA/IDOR, broken authentication, excessive data exposure, rate limiting bypass, BFLA, mass assignment, SSRF, and security misconfiguration. Includes REST-specific attacks such as HTTP verb tampering, content-type switching, and parameter pollution. Covers gRPC exploitation through protobuf interception, reflection API enumeration, and metadata injection. Addresses WebSocket vulnerabilities including origin bypass, message injection, and cross-site WebSocket hijacking. Provides tooling guidance for Burp Suite, Postman, grpcurl, websocat, and mitmproxy. Each technique includes detection signatures and defensive indicators so you understand what artifacts your testing leaves behind. Designed for authorized penetration testing engagements against API-driven architectures.
Bluetooth Low Energy (BLE) attack methodology — GATT enumeration, characteristic read/write without auth, pairing downgrade (Just Works forced), LE Secure Connections bypass, MITM via active relay, sniffing with Sniffle (TI CC1352) / Ubertooth / Frontline, encryption key extraction (LE Legacy Pairing crackable, LE Secure Connections strong), proximity authentication abuse (cars, locks), and companion-app trust analysis. Use for IoT BLE devices, smart locks, fitness trackers, medical devices, BLE beacons, or any device pairing over BLE.