Files
antifragile/antifragile-consulting/playbooks/kill-chain-assessment-app.md
T

8.7 KiB

Kill Chain Assessment App

"We say it in every engagement: find the kill chain first. But how do you find it in territory you've never seen? You don't start with the chain — you start with the questions that surface the edges, and you let the graph tell you where the shortest path to the end of the company actually runs."

This document specifies the Kill Chain Assessment app — a single-file, offline browser tool a consultant runs during the diagnostic to turn an unknown estate into a mapped attack graph, compute the shortest existential path (the kill chain), and size every node on it into a remediation quantum.

The tool: tools/kill-chain-assessment.html — open it in any browser. No install, no network, no data leaves the machine. State persists locally and exports to .json (to resume) and .md (to drop straight into the report or the Findings Backlog).


Why this needed to be built

The handbook and the Move Fast and Fix Things posture both rest on a single instruction: fix the kill chain first. The assessment team guide tells you what to run (BloodHound, Purple Knight, Elysium, Entra checks); the sample engagement shows a finished kill chain drawn as an ASCII path. But between "run the tools" and "here is the finished chain" there is a synthesis step that has always lived only in the consultant's head: taking a pile of findings about an unfamiliar estate and working out which sequence of them actually ends the company.

In unknown territory that synthesis is hard, inconsistent between consultants, and easy to get wrong — the obvious 9.8 grabs attention while the cheap two-hop path to the backups goes unseen. The app makes the synthesis explicit and repeatable: capture what you find as nodes and attacker moves, and let a shortest-path computation surface the chain you'd otherwise have to spot by eye. It is the missing instrument for the first and most important act of every engagement.


The model

Nodes

A node is any asset, foothold, identity, or system. Each carries the attributes that determine its position in the chain:

Attribute Meaning Drives
Layer entry / identity / privilege / device / data / infra-OT / recovery Orientation, report grouping
Tier T0 / T1 / T2 (T0 Asset Framework) Blast-radius weighting
Entry point Internet-reachable or unauth foothold Source of the chain
Crown jewel Existential — the org cannot operate without it End of the chain
Reachable? Can the adversary actually get to it (yes/no/unknown) Quantum sizing
Exploit available? Working path/exploit in the wild (yes/no/unknown) Quantum sizing
Compensating control EDR / WAF / segmentation already in front Quantum sizing (the ~90% subtraction)

The "unknown" values are first-class, not placeholders: a node you cannot characterise is a dark quantum, and capturing it honestly is the point.

Moves (edges)

A move is one directed attacker step — "from here, an attacker can reach there" — with a mechanism (how: DCSync, NTLM relay, password spray, reused credential, OAuth consent) and an effort weight from 1 (trivial) to 5 (very hard). Effort is the consultant's judgement of how hard that single hop is for the adversary.

The computation

The app runs a multi-source Dijkstra from every entry point across the move graph, and finds the lowest-total-effort path to any crown jewel. That path is the kill chain — the cheapest route from foothold to existential impact. The tool then classifies every node:

  • P0 — on the shortest chain. Break any one link and the existential path is severed.
  • P1 — on some path from an entry to a jewel (reachable-from-entry ∧ can-reach-a-jewel), but not on the cheapest one.
  • P2 / off-chain — not on any path to a crown jewel. Real, but not existential — housekeeping, not kill chain.

This is the Move Fast doctrine made computable: kill-chain position sets priority, not CVSS.

Quantum sizing

Each node on a chain is sized into a quantum by the same logic the framework defines:

Quantum Condition Budget / action
Critical On shortest chain, reachable yes, exploit yes, not compensated Hours — sever reachability / compensating control now
Severe On a chain, reachable or exploit = yes Days — one change window, verify enforcement
Standard On a chain, neither reachable nor exploitable yet Sprint — batch; patch velocity fits here
Dark On a chain but reachability or exploit = unknown Unsized — route to discovery; characterise first

How to run it in an engagement

  1. Open the tool and clear the sample (or keep it as a worked reference). Switch to the Discovery tab — it lists, per layer, the questions and commands that surface edges (external scan for entries, the Connect sync account for the cloud↔on-prem bridge, BloodHound shortestPath for privilege, "what stops the business operating?" for jewels, flat-network checks for blast radius). This is the unknown-territory protocol.
  2. Capture as you go. Every finding from the assessment team guide becomes a node; every "an attacker could move from X to Y" becomes a move. Mark entries and jewels. Leave reachability/exploit as unknown when you genuinely don't know — that flags the dark quanta to chase.
  3. Read the chain. The centre panel draws the attack graph and highlights the shortest existential path in red. The right panel sizes the quanta. If no path is found, either the estate is genuinely segmented there (note it as a win) or you haven't mapped the connecting moves yet — in unknown territory, assume the latter until proven.
  4. Export. Export report .md produces a kill-chain section, quantum-bucketed remediation, and a priority table ready to paste into the diagnostic deliverable. Save .json lets you resume or hand off.
  5. Close the loop. After remediation, reload the .json and ask the antifragile question the framework demands: did the chain get shorter? A severed link or a collapsed privilege should visibly lengthen the shortest path or remove it entirely.

What it is and is not

It is a synthesis and prioritisation instrument — it makes the consultant's kill-chain judgement explicit, repeatable, and exportable, and it removes the human error of eyeballing the cheapest path. It is deliberately offline and dependency-free (Pillar 4, Sovereign Intelligence: the attack graph of a client estate must never leave the consultant's machine for a vendor cloud).

It is not a scanner and not an autonomous agent. It does not discover assets for you — it structures what you discover. The discovery still comes from the tools in the assessment team guide and the zero-budget discovery playbooks; the autonomous hours-lane execution lives in AI-Assisted TVM. This tool is the bridge between them: it turns raw discovery into a sized, prioritised chain that the rest of the programme acts on.


Roadmap (build-later)

The current tool is a self-contained synthesis instrument. Natural extensions, in priority order:

  1. Import from BloodHound / Purple Knight — ingest exported attack paths directly as nodes and moves, rather than hand-entry.
  2. PULSAR / ASTRAL signal overlay — pull live reachability and config-drift signal so "reachable?" is answered by observation, not assertion (Book I: validate by observation).
  3. Chain-shortening tracker — store successive .json snapshots and chart kill-chain length over time, making the antifragile feedback loop a number on a dashboard.
  4. Multi-chain view — surface the top-N existential paths, not just the cheapest, so secondary chains (the sample engagement on-prem path) aren't hidden behind the primary.

Specified for Book VII — Vulnerability Management and the Quantum Vulnerability Management framework. The tool: tools/kill-chain-assessment.html.