offensive-reporting

Name: offensive-reporting
Author: SnailSploit

2.8kstars447forks

How to install offensive-reporting?

snailsploit/claude-red/offensive-reporting

$npx -y skills add SnailSploit/Claude-Red --skill offensive-reporting

Installs into the current project.

Summary

Penetration test and red team report writing methodology. Covers executive summary structuring (risk-led narrative for non-technical readers), technical finding format (title, severity, affected scope, narrative, reproduction steps, impact, remediation, references), CVSS v3.1 / v

Files · 1

View on GitHub

SKILL.md

1	# Penetration Test Reporting — Professional Methodology
2
3	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.
4
5	## Quick Workflow
6
7	1. Capture evidence as you exploit — never reconstruct after the fact
8	2. Draft each finding immediately while context is fresh; one finding = one numbered file
9	3. Build the executive summary last, after all findings are scored
10	4. Two-pass review: technical accuracy first, then read-as-CISO for narrative
11	5. Hand off with a retest plan and a JSON/CSV index for the client's tracking system
12
13	---
14
15	## Report Structure (Standard)
16
17	```
18	1. Executive Summary ← Last to write, first read
19	2. Engagement Overview
20	2.1 Scope
21	2.2 Methodology
22	2.3 Limitations / Assumptions
23	2.4 Timeline
24	2.5 Team
25	3. Risk Summary ← Heatmap, finding count by severity
26	4. Technical Findings ← One per finding, sorted by severity
27	5. Attack Narratives / Chains ← Critical chains called out separately
28	6. Strategic Recommendations ← Programmatic, not finding-by-finding
29	7. Appendices
30	A. Tools Used
31	B. Indicators of Compromise (for blue team)
32	C. Raw Evidence Pointers
33	D. Glossary
34	```
35
36	---
37
38	## Executive Summary — The 90-Second Read
39
40	The executive summary is for the CISO, the GRC officer, and the board member. They read this and nothing else.
41
42	Structure (one page max):
43
44	1. Engagement context — what was tested, when, by whom (1 sentence)
45	2. Headline finding — the worst thing you found, in business terms (2–3 sentences)
46	3. Risk verdict — overall posture in plain language (1 paragraph)
47	4. Counts — number of findings by severity, in a small table
48	5. Top 3 strategic recommendations — programmatic fixes, not "patch CVE-X"
49
50	Words to avoid in the executive summary:
51	`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.")
52
53	Words to include:
54	Business impact (`customer data`, `regulatory exposure`, `operational disruption`, `financial loss`). Anchor every finding to a business consequence.
55
56	---
57
58	## Technical Finding Template
59
60	```markdown
61	## Finding ID — Short Descriptive Title
62
63	Severity: Critical (CVSS 9.8 — vector below)
64	Affected Scope: <hosts/URLs/components, with version where relevant>
65	Status: Open / Fixed in retest / Accepted Risk
66	CWE: CWE-89 (SQL Injection)
67	OWASP: A03:2021 — Injection
68
69	### Summary
70	One paragraph. What is the finding, why does it matter, what's the worst case.
71
72	### Background
73	What technology is involved and why this class of bug exists. Two paragraphs max.
74	Skip if obvious (e.g. don't explain XSS to an XSS shop).
75
76	### Description
77	Detailed walkthrough of the issue. The root cause, not just the symptom.
78
79	### Reproduction Steps
80	1. Numbered, copy-paste ready.
81	2. Include the exact request/response, redacted.
82	3. A reader with no engagement context should reproduce in <15 minutes.
83
84	### Evidence
85	- `screenshots/finding-007/01-payload.png`
86	- `requests/finding-007/initial-poc.http`
87	- `evidence-log.csv` line 142 (timestamp 2025-04-12 14:33:07Z)
88
89	### Impact
90	Concrete. Quantified where possible.
91	- "Read access to the entire customer table (~2.3M records)"
92	- "Authenticate as any user; verified for sample ID 1, 2, 999, 1000000"
93	- "Cross-tenant access — verified by reading data from acquired-tenant ABC"
94
95	### Remediation
96	Specific, actionable, ordered by precedence:
97	1. Fix the bug — exact code change or config flag
98	2. Defense in depth — secondary control (WAF rule, input validation)
99	3. Detection — log line / SIEM rule that would have caught the exploit
100
101	### References
102	- CWE / OWASP / CAPEC
103	- Vendor advisory if known CVE
104	- Blog posts only if directly relevant
105
106	### Notes for Retest
107	What you'd do to verify the fix. Specific request, s

People who liked this also viewed

6 picks

Type

offensive-reporting

2.8kstars447forks

View on GitHub

How to install offensive-reporting?

snailsploit/claude-red/offensive-reporting

$npx -y skills add SnailSploit/Claude-Red --skill offensive-reporting

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Penetration Test Reporting — Professional Methodology
2
3	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.
4
5	## Quick Workflow
6
7	1. Capture evidence as you exploit — never reconstruct after the fact
8	2. Draft each finding immediately while context is fresh; one finding = one numbered file
9	3. Build the executive summary last, after all findings are scored
10	4. Two-pass review: technical accuracy first, then read-as-CISO for narrative
11	5. Hand off with a retest plan and a JSON/CSV index for the client's tracking system
12
13	---
14
15	## Report Structure (Standard)
16
17	```
18	1. Executive Summary ← Last to write, first read
19	2. Engagement Overview
20	2.1 Scope
21	2.2 Methodology
22	2.3 Limitations / Assumptions
23	2.4 Timeline
24	2.5 Team
25	3. Risk Summary ← Heatmap, finding count by severity
26	4. Technical Findings ← One per finding, sorted by severity
27	5. Attack Narratives / Chains ← Critical chains called out separately
28	6. Strategic Recommendations ← Programmatic, not finding-by-finding
29	7. Appendices
30	A. Tools Used
31	B. Indicators of Compromise (for blue team)
32	C. Raw Evidence Pointers
33	D. Glossary
34	```
35
36	---
37
38	## Executive Summary — The 90-Second Read
39
40	The executive summary is for the CISO, the GRC officer, and the board member. They read this and nothing else.
41
42	Structure (one page max):
43
44	1. Engagement context — what was tested, when, by whom (1 sentence)
45	2. Headline finding — the worst thing you found, in business terms (2–3 sentences)
46	3. Risk verdict — overall posture in plain language (1 paragraph)
47	4. Counts — number of findings by severity, in a small table
48	5. Top 3 strategic recommendations — programmatic fixes, not "patch CVE-X"
49
50	Words to avoid in the executive summary:
51	`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.")
52
53	Words to include:
54	Business impact (`customer data`, `regulatory exposure`, `operational disruption`, `financial loss`). Anchor every finding to a business consequence.
55
56	---
57
58	## Technical Finding Template
59
60	```markdown
61	## Finding ID — Short Descriptive Title
62
63	Severity: Critical (CVSS 9.8 — vector below)
64	Affected Scope: <hosts/URLs/components, with version where relevant>
65	Status: Open / Fixed in retest / Accepted Risk
66	CWE: CWE-89 (SQL Injection)
67	OWASP: A03:2021 — Injection
68
69	### Summary
70	One paragraph. What is the finding, why does it matter, what's the worst case.
71
72	### Background
73	What technology is involved and why this class of bug exists. Two paragraphs max.
74	Skip if obvious (e.g. don't explain XSS to an XSS shop).
75
76	### Description
77	Detailed walkthrough of the issue. The root cause, not just the symptom.
78
79	### Reproduction Steps
80	1. Numbered, copy-paste ready.
81	2. Include the exact request/response, redacted.
82	3. A reader with no engagement context should reproduce in <15 minutes.
83
84	### Evidence
85	- `screenshots/finding-007/01-payload.png`
86	- `requests/finding-007/initial-poc.http`
87	- `evidence-log.csv` line 142 (timestamp 2025-04-12 14:33:07Z)
88
89	### Impact
90	Concrete. Quantified where possible.
91	- "Read access to the entire customer table (~2.3M records)"
92	- "Authenticate as any user; verified for sample ID 1, 2, 999, 1000000"
93	- "Cross-tenant access — verified by reading data from acquired-tenant ABC"
94
95	### Remediation
96	Specific, actionable, ordered by precedence:
97	1. Fix the bug — exact code change or config flag
98	2. Defense in depth — secondary control (WAF rule, input validation)
99	3. Detection — log line / SIEM rule that would have caught the exploit
100
101	### References
102	- CWE / OWASP / CAPEC
103	- Vendor advisory if known CVE
104	- Blog posts only if directly relevant
105
106	### Notes for Retest
107	What you'd do to verify the fix. Specific request, s

People who liked this also viewed

6 picks

Type