/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 → l