MITRE Attack Flow Guide: Modelling Attack Sequences

A list of ATT&CK technique IDs says what an adversary did but not how each step made the next one possible, so defenders cannot see which single control would have broken the chain. Attack Flow, from the MITRE Center for Threat-Informed Defense (CTID), is a STIX 2.1 extension and a free browser-based builder for modelling those dependencies: actions, the conditions they create, the assets they touch and the points where paths branch or merge. This guide explains the language, how to build a flow that is accurate and reusable, and how detection engineers, incident responders, threat intelligence analysts and red teams use flows in practice. It goes deeper than the short Attack Flow entry in the MITRE ATT&CK Guide for Defenders and assumes you already know ATT&CK tactics and techniques.

This is an independent guide from NHI Mgmt Group, based on MITRE CTID's public Attack Flow documentation as of November 2026. It is not sponsored or reviewed by MITRE. The project changes, so confirm details against the current documentation.

Key takeaways

Arrows mean dependency, not just order. In Attack Flow, an arrow between two actions says the second could not happen until the first succeeded, which is what lets you find choke points.
Five object types carry the model. attack-action, attack-condition, attack-operator (AND or OR), attack-asset and one attack-flow object per document, all defined as a STIX 2.1 extension with schema version 2.0.0.
Confidence is explicit. The specification maps seven terms, from Speculation (0) to Certainty (100), onto the STIX confidence property so readers can see which steps are observed and which are inferred.
Version 4.0 adds defence to the flow. Flows can now carry detection and mitigation objects, D3FEND, ATLAS and Fight Fraud Framework techniques, TLP banner markings, tags and AI-assisted generation from a report.
A flow is only as good as its source. Begin from evidence, mark gaps with conditions such as "initial access unknown", and validate every AI-generated object before you publish.

What Attack Flow is and how it differs from other models

CTID describes Attack Flow as "a language for describing how cyber adversaries combine and sequence various offensive techniques to achieve their goals". The project has four parts: the language specification, the Attack Flow Builder (a browser application that needs no installation and can also be run locally in Docker), a corpus of example flows, and a Python library with an af command line tool for validation and conversion. It is open source under the Apache 2.0 licence. The website showed version 4.0 in November 2026; version 3.2, released in May 2026, bundled ATT&CK 19.1 content.

Attack Flow does not require ATT&CK. Actions can reference other knowledge bases, custom techniques created in ATT&CK Workbench, or ad hoc behaviours with no taxonomy at all. In practice most flows use ATT&CK Enterprise, Mobile or ICS technique IDs.

Model	Unit of analysis	Answers	Machine-readable form	Best used for
Cyber Kill Chain	Seven fixed phases of an intrusion	Which stage did we stop it at?	None standard	Explaining intrusion stages to non-specialists
Diamond Model	One event: adversary, capability, infrastructure, victim	Who, with what, from where, against whom?	None standard	Pivoting and clustering activity for attribution analysis
ATT&CK matrix or Navigator layer	Individual techniques	Which behaviours were seen, and do we cover them?	STIX 2.1 data, Navigator JSON layers	Coverage mapping and prioritisation
Attack Flow	Techniques linked by dependency, with conditions, assets and logic	How did each step enable the next, and where would one control break the chain?	STIX 2.1 extension (JSON)	Incident reconstruction, choke-point analysis, emulation plans, reporting

The models are complementary. A Diamond Model event can become one action in a flow; a flow can be rolled up into a Navigator layer for coverage. For the older models see the Cyber Kill Chain and Diamond Model Guide.

The language: objects and properties

Every Attack Flow document is a STIX 2.1 bundle that declares the extension (extension-definition--fb9c968a-745b-4ade-9b25-c324172197f4) and contains exactly one attack-flow object. Because it is STIX, any standard STIX object (process, file, user-account, infrastructure, indicator, threat-actor) can be linked into a flow to add detail. For STIX itself, see the STIX and TAXII Guide.

Object	Represents	Key properties
attack-flow	The flow as a whole	scope (incident, campaign, threat-actor, malware, other), start_refs, name, description, external_references for sources
attack-action	The adversary executing one technique	technique_id, tactic_id, description, execution_start, execution_end, command_ref, asset_refs, effect_refs, confidence
attack-condition	A state of the world after earlier actions, or a decision point	description, on_true_refs, on_false_refs, pattern and pattern_type (experimental)
attack-operator	A join of parallel paths	operator (AND or OR), effect_refs; if the operator evaluates false, the flow halts
attack-asset	An object affected or used by actions, such as a host, an account or a password hash	name, description, object_ref to a STIX object

Effects and dependency: an action's effect_refs point to the actions, conditions or operators it enables. CTID stresses that this is not the same as saying one action happened before another: it models how one behaviour creates the preconditions for the next.
Conditions with true and false branches: a condition can show what the adversary does when a step fails, for example falling back from spearphishing to password spraying when no credential was captured. on_false_refs with no targets means the flow stops there.
Parallel paths: at incident scope, branches mean the adversary used several techniques; at campaign scope they mean different behaviours seen across incidents. Say which scope you are using, because it changes how a reader interprets every branch.
Ambiguous joins: two arrows pointing at one node without an operator are allowed but ambiguous. Use an AND or OR operator unless the source intelligence is itself ambiguous, and say so in the description.

The confidence scale

Term	Value	Range	Meaning in the specification
Speculation	0	0	Purely hypothetical, a what-if
Very Doubtful	10	1 to 20	All available evidence is against it, or reporting may be biased
Doubtful	30	21 to 40	Most evidence is against it
Even Odds	50	41 to 60	Evidence equally weighted
Probable	70	61 to 80	Most evidence supports it
Very Probable	90	81 to 99	All available evidence supports it
Certainty	100	100	Unquestionably true

Align this scale with the confidence language your intelligence team already uses, as described in the Writing Threat Intelligence Reports Guide, so a flow and the report it accompanies never disagree.

What version 4.0 adds for defenders

Detections and mitigations: free-text detection and mitigation objects attach to actions, with suggestions drawn from ATT&CK detection strategies, ATT&CK mitigations and ATLAS mitigations. They can hold pseudocode, analytic references or the actual query, which turns a flow into a coverage record.
More frameworks: a flow can be set to use ATT&CK Enterprise, Mobile and ICS, MITRE ATLAS, MITRE D3FEND and the MITRE Fight Fraud Framework (F3), and the Builder keeps technique choices aligned with the selected set.
Technique suggestions: drawing a line into blank space opens a suggestion pane that uses CTID's Technique Inference Engine (TIE) to propose the five most likely next techniques. Treat these as hunting hypotheses, not as evidence.
Handling markings: banner options include TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN, TLP:CLEAR, UNCLASSIFIED and CUI, stored in the flow's metadata. See the Traffic Light Protocol Guide.
Tags: colour-coded tags on any object, for example "detected", "not detected", "remediation open", with a filter that highlights every object carrying a tag.
Views: presentation, treemap, tactic table, timeline, matrix and IOC table views, plus export to PNG.
AI generation: the Builder can draft a flow from a PDF, URL or plain-text report. You supply your own LLM endpoint and token; CTID states the Builder does not store the token. Its documentation recommends validating every object and updating its confidence before use.

Building a flow: a step-by-step method

Fix the scope and the source: choose incident, campaign, threat-actor or malware scope and list every source in external_references. One flow per scope; do not mix a single incident with campaign-wide behaviour.
Extract the behaviours: read the report or case notes and list each adversary action with its technique, timestamp if known, and the evidence for it. For incidents, logs map more directly than prose, because they are already sequential.
Start at the beginning: CTID's best practice is to begin with a Reconnaissance, Resource Development or Initial Access technique. If initial access is unknown, start with a condition that says so; if there are several candidates, join them with an OR operator.
Link by dependency: for each action ask "what did this make possible?" and draw effect arrows only where the dependency is real. Add a condition where the link would not be obvious to the reader, and skip it where it is.
Add assets and STIX objects: attach the accounts, hosts, tokens or data stores that actions affect or use. Identity assets matter most for choke-point analysis, because one credential often enables several later steps.
End at impact: finish with an Impact technique, or a condition stating that impact is unknown.
Write useful descriptions: describe what the adversary did in this case, not a rephrasing of the technique name. "Exploits remote services" adds nothing; the specific service, vulnerability class and outcome do.
Set confidence and validate: set confidence on each action and link, then run the Builder's validation (or af validate on the published JSON) before saving.
Save in two forms: the Builder does not autosave. Save the editable .afb file and use Publish Attack Flow to produce the .json STIX bundle for sharing and tooling.

Worked example: an identity-led intrusion

A simplified incident flow shows how dependency reveals choke points:

Two initial paths joined by OR: Password Spraying (T1110.003) against a cloud identity provider, and Phishing (T1566) for credentials.
Condition: "valid password for a user account obtained", with a false branch that ends the flow.
Next action: Multi-Factor Authentication Request Generation (T1621), leading to the condition "session established as the user".
Then: Cloud Accounts (T1078.004) used for access, followed by Additional Cloud Credentials (T1098.001) on an application registration, an asset that persists after the user's password is reset.
Finally: Remote Email Collection (T1114.002) through the application's permissions, the impact for this case.

Read as a list, these are five techniques to cover. Read as a flow, every path passes through two nodes: the valid-password condition and the MFA step. Phishing-resistant MFA (D3FEND Multi-factor Authentication, D3-MFA) at the MFA step removes both entry paths at once, while monitoring new credentials on application registrations catches the persistence step if the earlier controls fail. That is the analysis a flow exists to produce. For identity-specific paths, see the Identity Attack Paths Guide.

Using flows across security teams

Team	Use	What to put in the flow
Detection engineering and SOC	Find choke points and gaps; prioritise analytics on nodes many paths share	Detection objects with the analytic name, log source and event IDs; tags for detected or not detected
Incident response	Reconstruct the incident and run the after-action review	Timestamps, lateral movement paths, compromised credentials as assets; where defences worked as well as where they failed
Threat intelligence	Behaviour-based reporting that outlives indicators	Scope, sources, confidence, TLP marking; remove sensitive internal detail before external sharing
Red and purple teams	Emulation plans built on realistic technique sequences	Steps that were not detected, so tests target real gaps; blue team annotations after the exercise
Leadership and risk	Explain an incident or scenario and justify investment	Presentation view; critical assets and business impact; few technique IDs

Coverage overlay: take a threat-actor-scope flow from your intelligence team, tag each action with your current detection status, and report the percentage of paths that cross at least one detected node, not just the percentage of techniques covered. See the MITRE ATT&CK Coverage Mapping Guide.
Hunting from sequences: a flow gives an order to hunt in. If you find one action, the flow tells you which preceding conditions and following actions to look for. See the Identity Threat Hunting Guide.
Exercises: a flow with conditions and false branches makes a tabletop scenario with real decision points. See the Purple Teaming Guide.
Corpus: the project repository holds more than 40 example flows, many built from government advisories and public incident reports. They are a starting point for scenario selection and a reference for style.

Measuring whether flows help

Flows per significant incident: share of post-incident reviews that produce a validated flow. Aim for every major incident.
Choke-point actions: number of controls or detections added because a flow showed a node shared by several paths, tracked per quarter.
Path coverage: share of paths in priority threat-actor flows that cross at least one detected or prevented node.
Confidence profile: share of actions at Probable or above in published flows; a falling share signals weak sources.
Reuse: number of emulation plans, hunts or exercises built from existing flows.

Framework mapping

Framework	Reference	Where Attack Flow supports it
NIST CSF 2.0	ID.RA-03, DE.AE-02, RS.AN-03, ID.IM-01	Recording threats; analysing adverse events; establishing what happened and root cause; improvements from evaluations
NIST SP 800-53 Rev 5	PM-16, RA-3, IR-4, CA-8	Threat awareness; risk assessment with realistic scenarios; incident handling; scenario-based testing
ISO/IEC 27001:2022 Annex A	A.5.7	Threat intelligence that is relevant and actionable
MITRE ATT&CK and D3FEND	Technique IDs on actions; D3FEND as a selectable framework in 4.0	Common vocabulary for actions and defensive techniques

Common failure patterns

Timeline drawn as a flow: every action linked to the next in time order, with no thought about dependency. The result looks like a flow but hides choke points. Use the timeline view for time; use arrows for enablement.
Unvalidated AI drafts: a generated flow is shared as finished, carrying misread techniques or invented links. Review every object against the source and set confidence by hand.
Technique-name descriptions: actions described only by their ATT&CK name, so the flow cannot be used for hunting or emulation.
Mixed scope: campaign-wide behaviours added to an incident flow, so branches look like things that happened in this incident.
Sensitive detail leaking out: internal hostnames, account names and missed detections shared externally because no marking was set. Set the banner marking and strip internal assets before release.
No owner after creation: flows are made once for a report and never updated with detection status, so they stop reflecting the environment.

Practitioner checklist

Pick one scope per flow and cite every source in the flow's references.
Start from initial access or an explicit "initial access unknown" condition, and end at impact or "impact unknown".
Draw arrows only for real dependencies and use AND or OR operators for joins.
Set confidence on every action and link using the specification's seven-term scale.
Attach accounts, credentials and tokens as assets, then look for nodes most paths pass through.
Record detection status with tags or detection objects and review it after each test or incident.
Validate before publishing, save both .afb and .json, and set a TLP or other banner marking.
Store flows with the incident record and reuse them for hunts, exercises and emulation plans.

MITRE Attack Flow Guide: Modelling Attack Sequences for Detection and Reporting