Building an attack scenario
When it applies
You have an authorized scope and an objective, and the target exposes several possible surfaces.
Before running anything, you need a plan that sequences the right skills toward the objective and
adapts as evidence comes in. This is the layer above individual techniques.
Why it works
Real engagements are graphs, not checklists: each result changes what's worth trying next. Planning
the scenario explicitly — objective, hypotheses, ordered leads, decision points — is what turns a
pile of 127 techniques into a coherent path, and it's exactly what the sploit watch Attack Map
renders (lead, status, rationale).
Method
- State the objective in impact terms: "read another tenant's data", "code exec on the app
host", "domain admin". Everything is prioritised by what moves you toward it.
- Enumerate surfaces from recon (
recon-*): web, API, cloud, AD, network, people. Each surface
is a branch.
- Generate leads per surface and score each by impact × likelihood × cost/noise. A likely
high-impact, low-noise lead goes first.
- Order into a scenario: recon → highest-value lead → the pivots each success unlocks. Write it
to
plan.md as an ordered, checkbox strategy; tag each lead with a slug for the activity log.
- Define decision points: for each lead, note "if confirmed → pivot to X; if blocked → why, and
the fallback". This is the branching that makes it adaptive (see
tradecraft-pivot-decisions).
- Re-plan on evidence: every confirmed finding or dead end updates scores and can reorder what's
next. The plan is living, not a one-shot.
Gotchas
- Don't breadth-scan everything — depth on the highest-value lead beats shallow coverage.
- Objective drift: if a lead doesn't advance the stated objective, park it, don't chase it.
- Keep it inside scope; an attractive lead outside
scope.txt is not a lead (load tradecraft-scope-roe).
Verify success
There is a written plan.md with an objective, ordered leads carrying rationale, and explicit
"if/then" pivots — and the agent is working the top lead, not wandering.
References
MITRE ATT&CK (tactic ordering); PTES; the exploit-chaining and tradecraft-pivot-decisions skills.
1---2name: tradecraft-attack-scenarios3description: Turn a goal + a scope into a concrete, ordered attack scenario across multiple skills — not one technique in isolation. Load at the START of an engagement, on "where do I even begin", when a target has many surfaces, or to plan an objective-driven path (e.g. "reach domain admin", "prove data exfil"). This is how an agent decides what to try, in what order, and why.4---56# Building an attack scenario78## When it applies9You have an authorized scope and an objective, and the target exposes several possible surfaces.10Before running anything, you need a plan that sequences the right skills toward the objective and11adapts as evidence comes in. This is the layer above individual techniques.1213## Why it works14Real engagements are graphs, not checklists: each result changes what's worth trying next. Planning15the scenario explicitly — objective, hypotheses, ordered leads, decision points — is what turns a16pile of 127 techniques into a coherent path, and it's exactly what the `sploit watch` Attack Map17renders (`lead`, `status`, `rationale`).1819## Method201. **State the objective in impact terms**: "read another tenant's data", "code exec on the app21 host", "domain admin". Everything is prioritised by what moves you toward it.222. **Enumerate surfaces from recon** (`recon-*`): web, API, cloud, AD, network, people. Each surface23 is a branch.243. **Generate leads per surface** and score each by *impact × likelihood × cost/noise*. A likely25 high-impact, low-noise lead goes first.264. **Order into a scenario**: recon → highest-value lead → the pivots each success unlocks. Write it27 to `plan.md` as an ordered, checkbox strategy; tag each lead with a slug for the activity log.285. **Define decision points**: for each lead, note "if confirmed → pivot to X; if blocked → why, and29 the fallback". This is the branching that makes it adaptive (see `tradecraft-pivot-decisions`).306. **Re-plan on evidence**: every confirmed finding or dead end updates scores and can reorder what's31 next. The plan is living, not a one-shot.3233## Gotchas34- Don't breadth-scan everything — depth on the highest-value lead beats shallow coverage.35- Objective drift: if a lead doesn't advance the stated objective, park it, don't chase it.36- Keep it inside scope; an attractive lead outside `scope.txt` is not a lead (load `tradecraft-scope-roe`).3738## Verify success39There is a written `plan.md` with an objective, ordered leads carrying rationale, and explicit40"if/then" pivots — and the agent is working the top lead, not wandering.4142## References43MITRE ATT&CK (tactic ordering); PTES; the `exploit-chaining` and `tradecraft-pivot-decisions` skills.
NoorQureshi