Does a tag mean this indicator is attributed to a named actor?

No. A tag is a lead, not an actor claim — this graph has no live tag-to-actor edge. The only actor claim this workflow makes is a direct ATTRIBUTED_TO edge, always labelled "direct".

Why does the same actor sometimes show two rows with different descriptions?

A known graph quirk: some actor names exist as two separate nodes (whisper-dbj-ng#1487). Both are queried and shown, each with its own description, so you can tell the twins apart rather than have one silently picked.

Why does an actor have tactics but no direct tactic edge?

This graph links an actor to its techniques, and separately links each technique to its tactic — there is no actor-to-tactic edge to read directly, so the tactic set shown is derived from the actor’s own techniques.

Is an actor’s infrastructure list limited to their known malware families?

No — it is every indicator this graph directly attributes to the actor, bounded to 200. A malware-family-based pivot was considered and dropped for this first cut; see the open engine finding this issue’s evidence points at.

Only in WhisperThreat intelligence

Who is behind this indicator and what do they do?

From an indicator to a named actor, or from an actor name to their techniques and infrastructure — direct graph attribution, never a tag-derived guess.

Try:

Try this in Console

No credit card needed.

What it solves

A SOC analyst who gets a malicious verdict from an indicator workflow cannot ask "who, and what do they do" without writing Cypher by hand, and an intel analyst starting from an actor name has no graph-native way in at all — the retired actor-ttp workflow left this pivot with no direct equivalent.

From an indicator, it reads threat tags and any direct actor attribution, then the attributed actor’s techniques and (derived from those techniques) tactics, plus other indicators sharing a tag, threat-checked. From an actor name, it resolves the exact name, then a known alias, then offers similarly-named candidates; once resolved, it reads the actor’s techniques/tactics and every indicator this graph directly attributes to them, bounded to 200 and threat-checked, plus which networks concentrate their IP infrastructure. Duplicate actor-name nodes (a known graph quirk) are queried together and shown side by side, each with its own description, rather than silently collapsed into one.

The old way3 tools / tabs

Pivoting from a malicious indicator to a named actor, or from an actor name to their known infrastructure, otherwise means writing the graph query by hand and separately checking each actor-name variant.

a MITRE ATT&CK Navigator lookup
a hand-written Cypher ATTRIBUTED_TO/TAGGED_AS query
a manual alias/spelling guess

What this means

Give it a domain, IP, prefix, or a threat-actor name (or alias) and it reads the threat-attribution layer straight off the graph: threat tags, direct actor attribution, the actor’s MITRE ATT&CK techniques and tactics, and — starting from an actor name — every indicator this graph directly attributes to them.
Every actor claim cites the graph’s own ATTRIBUTED_TO edge; a tag is shown as a lead, never resolved to a named actor this graph does not actually name.

Dig deeper

Read the how-to

What this workflow does and how it uses the graph, plus the copy-paste recipes it's built from.

Open the documentation

Related flows

All use cases

Faster in Whisper

Threat Investigation

The deep-dive you run when something looks bad and you need the full story. Give it one indicator and it works outward across its whole footprint — the related domains, the real servers behind any CDN, the neighbouring infrastructure — and checks each piece for known abuse. You get one coherent read on how dangerous it is and why, with safe next steps to pivot on. Reach for it when a quick check says 'look closer.'

SOC, DFIR & IRDocs