Adversary Emulation Playbook Catalog

This is a planning routing skill for Soundwave. Each leaf playbook below converts a named threat actor into a concrete, RoE-bounded kill chain: a ThreatProfile seed, an ordered CONOPS kill_chain, and a phase→technique→skill map that the orchestrator turns into OPPLAN objectives.

These playbooks reference operational skills (/skills/standard/ad/..., /skills/standard/cloud/..., etc.) that the EXECUTING agents load — not Soundwave. Soundwave is a planning agent; its load_skill allowlist is /skills/standard/soundwave/. The skill paths in each playbook tell the orchestrator which agent + skill each objective maps to. Soundwave only reads them to author plan/threat-profile.json and the conops.json kill chain.

Playbooks

Use the loaded actor playbook and current evidence for attribution and TTP details. Skillogy does not expose sibling reference files; do not assume those cards were read.

Adapting a playbook

1. Pick the actor from the operator's intake answer and current evidence. One dominant actor per engagement.
2. Load the leaf: load_skill("/skills/standard/soundwave/threat-profile/emulation/<actor>/SKILL.md").
3. Copy the ThreatProfile seed into plan/threat-profile.json, then prune any key_ttps / initial_access techniques the RoE forbids (Step 3 of the threat-profile skill). A pruned technique whose whole phase is now empty drops that kill-chain row.
4. Lift the kill chain into conops.json → kill_chain (one KillChainPhase per surviving phase), and embed the one-entry threat_actors summary.
5. Carry the safety gates from the playbook's RoE / safety gates section into abort.json (destructive / ICS / identity-takeover actors need at least one EMERGENCY trigger) and the deconfliction identifiers into deconfliction.json. These mappings are planning inputs, not an execution handoff. An operational runtime may later build OPPLAN and load the mapped skills after the operator selects execution. Soundwave does not create objectives or dispatch the mapped actions.

Playbook anatomy (every leaf has these)

• ThreatProfile seed — a valid decepticon.core.schemas.ThreatProfile JSON (drop your engagement_name).
• Kill-chain emulation table — # | phase | MITRE | emulated action | executing agent → skill.
• CONOPS kill_chain — the phase order to copy into conops.json.
• OPSEC & signature fidelity — what to mirror so the emulation reads like the actor.
• RoE / safety gates — actor-specific authorizations and abort triggers.
• Deconfliction — identifiers so blue team can separate the exercise from a real intrusion.
• Fidelity notes (deviations) — where the emulation intentionally diverges (e.g. canary data instead of real destruction) and why.

Discipline

• Emulate behavior, not malware. Decepticon reproduces an actor's TTPs and sequencing with its own tooling (Sliver, NetExec, certipy, etc.) — it does not run the actor's real implants. Fidelity comes from technique order + OPSEC posture, not from sample reuse.
• RoE wins every tie. If the actor's signature move (spearphishing, deauth, ICS write, encryption-for-impact) isn't authorized, drop it — never "emulate harder" past scope.
• One actor per profile. Multi-actor scenarios pick the dominant emulation target; note the secondary in recent_cti_delta.