cleanup-template

# Cleanup & Restoration Plan Generator The cleanup plan is the **anti-foothold roster** — every artifact the kill chain will create must have a concrete removal command and a verifier, or dummy accounts / scheduled tasks / beacons routinely outlive the engagement. ## When to Use - After CONOPS is written (the kill chain phases dictate what artifacts will exist) - User says "create cleanup plan", "list what we'll leave behind", "post-engagement teardown" ## Workflow ### Step 1: Map Kill Chain Phases → Expected Artifact Types For every phase in CONOPS.kill_chain, infer which `CleanupArtifact.artifact_type` entries will be produced: | Kill Chain Phase | Likely artifact_types | |---|---| | recon | `tool` (installed scanners), `network-rule` (firewall whitelist) | | initial-access | `account` (test users), `file` (uploaded payloads), `tool` (web shells) | | post-exploit | `persistence-mechanism` (scheduled-task / service / registry-run), `account` (created backdoor users), `file` (dropped binaries) | | c2 | `beacon` (C2 implants), `network-rule` (egress allow), `tool` (sliver / cobalt-strike payloads) | | exfiltration | `file` (staged exfil archives), `network-rule` (DNS tunneling) | ### Step 2: Seed CleanupArtifact entries For each expected artifact, set: - `artifact_type` — category above - `host` — placeholder (e.g. ``"<initial-access target>"``) — operations agents replace at run time - `path` — likely filesystem / registry / account-name location - `persistence_mech` — concrete mechanism if applicable - `removal_command` — idempotent shell or API call to remove - `verifier_command` — zero-exit on success - `created_by_objective` — left blank; operations agents fill on creation - `removed=False`, `removed_at=""` ### Step 3: Pre-engagement Baseline Set `pre_engagement_baseline` to whatever snapshot reference the operator gives during the interview (volume ID, AWS AMI, hypervisor snapshot, manual filesystem hash list). If no baseline is available, record that explicitly — it's a critical risk signal for the engagement owner. ### Step 4: Completion Criteria Default schema text covers most engagements. Override only when the engagement specifies different completion semantics (e.g. "leave honeyfile FILE_X in place for blue team training" — note as a cancellation_reason on that artifact later). ## Validation Checklist Before writing `plan/cleanup.json`: - [ ] Every CONOPS phase that creates persistence has a matching artifact entry - [ ] Every artifact has a non-empty `removal_command` - [ ] No artifact's `path` references an out-of-scope host - [ ] `pre_engagement_baseline` is either set or explicitly marked "no baseline available" ## Anti-patterns - Leaving `removal_command` empty — operations agents will skip the artifact entirely - Putting absolute paths from the operator's machine (engagement workspace is `/workspace/<eng>` inside the sandbox; cleanup runs on TARGETS not the workspace) - Forgetting C2 beacons — the kill chain's c2 phase is the most common omission ## Output Write to `plan/cleanup.json` validating against `decepticon.core.schemas.CleanupPlan`.