CtrlK
BlogDocsLog inGet started
Tessl Logo

cleanup-template

Cleanup & restoration plan generator — artifact inventory, persistence removal commands, pre-engagement baseline, post-engagement verification.

64

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./packages/decepticon/decepticon/skills/standard/soundwave/cleanup-template/SKILL.md
SKILL.md
Quality
Evals
Security

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 PhaseLikely artifact_types
recontool (installed scanners), network-rule (firewall whitelist)
initial-accessaccount (test users), file (uploaded payloads), tool (web shells)
post-exploitpersistence-mechanism (scheduled-task / service / registry-run), account (created backdoor users), file (dropped binaries)
c2beacon (C2 implants), network-rule (egress allow), tool (sliver / cobalt-strike payloads)
exfiltrationfile (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.

Repository
PurpleAILAB/Decepticon
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.