offsec-debrief

name	offsec-debrief
description	Post-challenge debrief — generates writeup with structured failure analysis. Outputs to writeup/ directory and updates MEMORY.md with key lessons.
user-invocable	true

Offsec Debrief & Writeup

Generate a structured writeup documenting the full challenge including both the successful attack path and every failure with structured analysis. Update MEMORY.md with generalized lessons.

---

Phase 1: Generate the Writeup

When to Use

• After completing a CTF challenge (HackTheBox, CTF competitions, etc.)
• When documenting penetration testing exercises
• For educational walkthroughs of security challenges

Data Collection (First Step)

Before writing anything, reconstruct the attack history from conversation context, workspace files, and any saved notes.

Writeup Structure

1. Header

# [Platform] - [Box Name] Writeup

**Difficulty:** [Easy/Medium/Hard]
**OS:** [Linux/Windows/Other]
**Category:** [Web/PWN/Wireless/Network/etc.]
**Target IP:** [IP Address]

2. Overview

• Brief challenge description
• High-level attack path summary
• Key vulnerabilities exploited
• Network architecture (if applicable)

3. Flags

| Flag | Value |
|------|-------|
| User | `[hash]` |
| Root | `[hash]` |

4. Attack Chain Summary

Visual representation of the successful path:

1. Initial Access Method → Result
2. Exploitation Step → Outcome
3. Privilege Escalation → Final Goal

5. Failure Track (REQUIRED — The Most Important Section)

This section is where learning happens. Every failed strategy must be documented with enough structure to extract patterns from.

Review all failed approaches from conversation context and workspace notes. For each failure, document:

## Failure Track

### F1: [Short description of what was attempted]
- **Strategy:** What technique/tool/CVE was tried
- **Target component:** What service/port/endpoint was targeted
- **Trigger signal:** What observation led you to try this (version number, error message, open port, etc.)
- **Result:** What actually happened (error messages, no output, wrong response, etc.)
- **Root cause:** Why it failed (wrong CVE for this config, network isolation, wrong layer, etc.)
- **Time spent:** How long before pivoting
- **Stop signal missed?** Was there an early indicator this wouldn't work that was ignored?
- **Rabbit hole type:** [Wrong CVE | Wrong exploitation method | Wrong layer | String filter | Session limitation | Other]
- **Rule for next time:** One-sentence decision rule to avoid this in the future

### F2: [Next failure...]

Rabbit hole types:

• Wrong CVE, Right Service — CVE exists but vulnerable component/module isn't present
• Correct Vuln, Wrong Method — vulnerability is real but exploitation blocked by environment
• Wrong Layer — attacking app layer when it's infra, or vice versa
• String Filter Bypass — filter blocks direct approach, needs encoding/traversal
• Session Limitation — tool/technique doesn't work in current session type
• Premature Complexity — tried advanced technique when simple one existed
• Unverified Assumption — proceeded based on something assumed but not confirmed

Why this structure matters:

• "Stop signal missed" teaches us to recognize early exits faster
• "Rabbit hole type" helps classify failure patterns
• "Rule for next time" becomes a candidate for MEMORY.md lessons
• "Trigger signal" helps us understand what false signals look like

6. Success Path (Phase-by-Phase Walkthrough)

For each phase of the successful attack:

• Clear phase title (e.g., "Phase 1: Initial Access — SNMP Enumeration")
• Step-by-step technical details
• All commands used (in code blocks with syntax highlighting)
• Command output (formatted)
• Explanation of what each step accomplishes
• What signal triggered this approach (version number, error output, config leak, etc.)

# Include comments explaining purpose
command --flags argument

Clearly formatted command output

7. Key Takeaways

Numbered list of lessons learned:

## Key Takeaways

1. **Vulnerability Type** — Brief explanation of the security issue
2. **Attack Technique** — How it was exploited
3. **Detection/Prevention** — How to defend against it

8. Tools Used

## Tools Used

- `tool-name` — Purpose/usage
- `another-tool` — Purpose/usage

9. Additional Sections (as needed)

• Vulnerabilities Exploited — CVE details, CVSS scores, affected versions
• Timeline — Timestamps showing progression
• References — Links to CVE databases, advisories, documentation

Output

Save to writeup/[BoxName].md.

Writing Style

• Include exact commands used
• Show actual output
• Use GitHub-flavored Markdown with syntax highlighting
• Technical but accessible — explain acronyms on first use
• Focus on methodology and reasoning, not just outcomes

Completeness Checklist

Before finalizing, ensure the writeup includes:

• Title with difficulty, OS, category, target IP
• Overview paragraph
• Both flags clearly displayed
• Attack chain summary
• Failure track with full structure (trigger, root cause, stop signal, rabbit hole type, rule)
• Complete phase-by-phase walkthrough of the successful path
• All commands with proper formatting
• Key takeaways section
• Tools used section

---

Phase 2: Update MEMORY.md

After the writeup is saved, extract generalized lessons and update MEMORY.md.

What to capture

From failures:

• New rabbit hole patterns worth remembering
• Decision rules that would have saved time
• False signal patterns (what looked promising but wasn't)

From successes:

• New attack patterns or technique combinations
• Recon methods that proved critical
• Tool usage insights

How to generalize

• BAD: "On Browsed, Flask on :5000 was the path from git → larry"
• GOOD: "Localhost-only web services are frequently the bridge between a service account and a real user"
• BAD: "Soulmate had Erlang SSH on 127.0.0.1:2222"
• GOOD: "Non-standard SSH variants on localhost ports are common privesc paths"

Rules

• Keep MEMORY.md under 200 lines — consolidate older entries or move details to topic-specific files if approaching the limit
• Machine-specific details ARE allowed in MEMORY.md (it's a personal journal, not a playbook)
• Don't add generic advice ("always be thorough") — only specific, actionable rules
• If unsure whether a pattern is generalizable, record it and wait for confirmation from a second challenge

---

Workflow Summary

When this skill is invoked:

1. Pull attack history
   └─ Review conversation history and workspace files

2. Write the report
   ├─ Header, overview, flags, attack chain
   ├─ FAILURE TRACK (every failed strategy with full analysis)
   ├─ Success path (phase-by-phase)
   └─ Save to writeup/[BoxName].md

3. Update MEMORY.md
   ├─ Extract generalized lessons from failures and successes
   ├─ Add new decision rules and patterns
   └─ Keep under 200 lines

---

Common Patterns by Category

Web Exploitation

• Recon (port scan, directory enumeration)
• Application fingerprinting
• Vulnerability identification (SQLi, XSS, LFI, etc.)
• Exploitation and initial access
• Credential extraction
• Privilege escalation

Wireless Security

• Interface setup and monitor mode
• Network discovery
• Traffic capture
• Credential interception
• Hash cracking
• Network access
• Lateral movement

PWN/Binary

• Binary analysis
• Vulnerability discovery
• Exploit development
• Payload crafting
• Privilege escalation

Network/Infrastructure

• Service enumeration
• Version fingerprinting
• Credential attacks
• Lateral movement
• Persistence

Quality Standards

A complete writeup should:

• Be reproducible by following the steps
• Explain not just what was done, but why
• Include defensive considerations
• Serve as both documentation and learning resource
• Maintain professional technical writing standards
• Credit tools, researchers, and references appropriately