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

For the one-card quick reference (attribution, targets, full TTP table) on any actor, see ../references/apt-groups.md. For tier archetypes when no named actor fits, see ../references/adversary-archetypes.md.

How to use a playbook (Soundwave Phase 2)

1. Pick the actor from the operator's intake answer (or from the industry → actor map in ../references/apt-groups.md). 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.
6. Hand off. The orchestrator's OPPLAN-builder reads threat-profile.json + conops.json and emits add_objective calls; each objective's executing agent loads the skill named in that kill-chain row.

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.