Actor Attribution & ATT&CK
Copy-paste Cypher for the actor layer: techniques by actor, tactic rollups, shared-tradecraft pivots, and rarity-weighted attribution.
Actor Attribution & ATT&CK Documentation
You hold one half of an attribution case: a named actor from a vendor report, or a set of ATT&CK techniques observed during an incident. You need the other half — what else that actor does, who else uses the same tradecraft, and how strongly the observed behavior points at one adversary. In most stacks the actor-to-technique mapping lives in a threat-intel platform, separate from the infrastructure data, so those questions never sit in the same query.
WhisperGraph loads MITRE ATT&CK into the graph itself: ACTOR nodes link to ATTACK_PATTERN nodes through USES_TECHNIQUE edges. Every recipe below fits the anonymous 2-hop tier, so you can paste it straight against the Cypher API at https://graph.whisper.security/api/query with no key. Two things to know before you start: actor names are case-sensitive (APT28, not apt28), and USES_TECHNIQUE is a virtual edge, so always anchor the pattern on a labeled ACTOR or ATTACK_PATTERN — a bare MATCH ()-[:USES_TECHNIQUE]->() scan returns nothing.
Run it live: Map a named actor to its ATT&CK techniques · Actor → shared TTPs → other actors · Narrow actor attribution by rare-technique convergence · Chain a phishing domain to actor TTPs — each is the guided version of a recipe on this page, runnable on your own actor or technique set.
Key concepts: MITRE ATT&CK · TTP · Attack pattern · C2 infrastructure.
Map a named actor to its ATT&CK techniques
Why it's hard with flat tools: the actor profile lives in one product, the technique matrix in another, and neither joins to your infrastructure data.
What the graph does: one anchored hop from the actor to its full technique set, ready to drop into a report.
Tip: if a name returns nothing, the casing is the usual culprit. Probe for the exact form on the graph first:
MATCH (a:ACTOR) WHERE a.name STARTS WITH "APT" RETURN a.name LIMIT 25.
Roll techniques up by ATT&CK tactic
Why it's hard with flat tools: a flat technique list hides the shape of an actor's tradecraft — you want to know which kill-chain stages it covers, and how densely.
What the graph does: each technique carries its ATT&CK tactic list, so one query turns the technique set into a tactic coverage table.
MATCH (a:ACTOR {name: "APT28"})-[:USES_TECHNIQUE]->(t:ATTACK_PATTERN)
WITH t, t.tactics AS tactic_list
UNWIND tactic_list AS tactic
RETURN tactic, count(DISTINCT t.name) AS technique_count
ORDER BY technique_count DESC
LIMIT 50
Tip: read the distribution, and treat the totals as a floor. Heavy coverage of credential-access and lateral-movement tactics reads very differently from a persistence-only profile, and a tactic with zero rows means no mapped techniques in ATT&CK — which is different from the actor never operating at that stage.
Find actors that share a technique
Why it's hard with flat tools: "who else uses this technique" means re-reading every actor profile by hand.
What the graph does: the technique is a shared node. Pivot through it to every actor that reuses the same TTP — useful when behavioral overlap is your only lead.
MATCH (seed:ACTOR {name: "APT28"})-[:USES_TECHNIQUE]->(t:ATTACK_PATTERN)
WITH t LIMIT 25
MATCH (t)<-[:USES_TECHNIQUE]-(other:ACTOR)
WHERE other.name <> "APT28"
RETURN t.name AS technique, collect(DISTINCT other.name)[..10] AS also_used_by
LIMIT 25
Tip: a shared technique is weak attribution on its own — common TTPs like spearphishing and valid accounts are used by hundreds of actors. Weight the overlaps by how rare each technique is (two recipes down) before treating one as a link.
Rank candidate actors by tradecraft overlap
Why it's hard with flat tools: comparing one actor's technique set against every other actor's is an N-way join no lookup tool offers.
What the graph does: pivot out through the seed actor's techniques and back in, counting how many each candidate shares.
MATCH (seed:ACTOR {name: "APT28"})-[:USES_TECHNIQUE]->(t:ATTACK_PATTERN)
WITH t LIMIT 50
MATCH (t)<-[:USES_TECHNIQUE]-(other:ACTOR)
WHERE other.name <> "APT28"
RETURN other.name AS actor, count(DISTINCT t) AS shared_techniques
ORDER BY shared_techniques DESC
LIMIT 25
Tip: raw overlap counts over-reward commodity tradecraft — an actor that shares five common techniques looks closer than one that shares two rare ones, and usually isn't. The Actor → shared TTPs → other actors workflow runs this pivot as a guided flow; the next recipe corrects the ranking for rarity.
Weight shared techniques by rarity
Why it's hard with flat tools: given a set of observed techniques, most tooling can only count matches per actor. Attribution needs the opposite emphasis: one rare shared technique outweighs many commodity ones.
What the graph does: for each observed technique, count how many distinct actors use it. Few users means discriminative; techniques shared by 60 or more actors (PowerShell, Spearphishing Attachment, Ingress Tool Transfer) are commodity and should be excluded from the match.
UNWIND ["OS Credential Dumping", "Rootkit", "Junk Data"] AS tname
MATCH (t:ATTACK_PATTERN {name: tname})
MATCH (a:ACTOR)-[:USES_TECHNIQUE]->(t)
WITH tname, count(DISTINCT a.name) AS actor_count
RETURN tname AS technique, actor_count,
CASE WHEN actor_count < 60 THEN "discriminative" ELSE "commodity" END AS class
ORDER BY actor_count ASC
LIMIT 50
Tip: convergence is a lead, not proof — ATT&CK mappings are curated reports of observed behavior, and absence of a mapping is no-data, never evidence of absence. The rare-technique convergence workflow runs the full version: it scores every candidate actor by rarity-weighted overlap with your observed set and reports which fingerprint techniques drove each match.
Chain infrastructure to actor TTPs
The graph draws no edge from an ACTOR to live hostnames or IPs. Attributing infrastructure to a named actor is an analyst call; what the graph gives you is both halves of that call from one endpoint. The Chain a phishing domain to actor TTPs workflow strings them together in a single run: lookalike variants of a brand domain, the co-hosted cluster behind them, and the technique set of the actor you name.
For the infrastructure pivots themselves — co-tenancy, shared WHOIS registrants, nameserver siblings, TLS fingerprints — work through Campaign Pivoting. For lookalike generation and takedown evidence, see Lookalike Hunting. Those chains run three or more hops, so they want a free key.
Where to go next
- Threat Actors & TTPs — the domain landing, with all four runnable workflows.
- Campaign Pivoting — the infrastructure half of an attribution case.
- Graph Schema — the
ACTORandATTACK_PATTERNlabels, edge directions, and the virtual-edge anchoring rule. - explain() — Threat Verdicts — score the infrastructure a candidate cluster sits on, with the evidence chain behind each verdict.
- Cypher Best Practices — the anchoring and bounding rules every query on this page follows.