cleanup-template

name	cleanup-template
description	Cleanup & restoration plan generator — artifact inventory, persistence removal commands, pre-engagement baseline, post-engagement verification.
allowed-tools	Read Write Edit
metadata	{"subdomain":"planning","when_to_use":"create cleanup plan, artifact inventory, persistence removal, post-engagement teardown, restoration plan","tags":"cleanup, restoration, persistence, post-engagement, hygiene","mitre_attack":[]}

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 atlas.core.schemas.CleanupPlan.