Pivoting Examples

The point of a pre-joined graph is the chain — walking from one layer to the next in a single query. This page collects the pivots you will reach for most, each with the traversal it encodes and a runnable query. These are examples, not the complete set: any two connected labels can be joined, and the Connection Types page is the full menu of edges you can compose your own chains from.

Every pivot below starts from an anchored {name: "..."} lookup, and on URL the name is the kit path itself. That is what turns a chain into an instant traversal instead of a scan — see Best Practices for why.

Domain → network owner

Who hosts this domain, and on whose network? Resolve the host to an IP, follow the IP to its announced prefix, and follow the prefix to the AS that routes it.

This four-hop chain — HOSTNAME → RESOLVES_TO → IPV4 → ANNOUNCED_BY → ANNOUNCED_PREFIX → ROUTES → ASN → HAS_NAME → ASN_NAME — is the workhorse of the graph. It needs an API key; sign in to run it — there is no card to enter.

IP → jurisdiction

Geolocate an address by chaining its GeoIP city to the city's country.

Anycast and large-CDN IPs often lack a city. When LOCATED_IN returns nothing, read the owning ASN's country instead: (:ASN)-[:HAS_COUNTRY]->(:COUNTRY).

ASN → physical footprint

Where does a network actually sit? A network is present in facilities directly, and reaches more facilities through the exchanges it joins.

The direct form is (:ASN)-[:AS_PRESENT_AT]->(:FACILITY). A large network can be present in hundreds of facilities, so anchor the ASN.

ASN → registry entity and BGP neighbours

Who is the network registered to, and who does it exchange routes with? RDAP registration entities hang off prefixes and ASNs over REGISTERED_TO_ENTITY, and BGP adjacency is BGP_NEIGHBOR.

BGP_NEIGHBOR is the adjacency edge to write; PEERS_WITH is its deprecated alias. It works inside a variable-length pattern too. On a multi-hop peering walk, filter WHERE n <> a so the mesh does not return you to the origin AS. The AS paths a network appears on are BGP_PATH_OBSERVATION nodes reached over BGP_PATH, and each observation's name is the hyphen-joined path, origin last:

Submarine cable → landing → facility

Trace a subsea cable from the sea to the building it terminates in.

Domain → mail servers

NAMESERVER_FOR and MAIL_FOR point server → domain, so traverse them backwards to answer "what serves this domain".

Domain → WHOIS

Who registered this domain? Three registration edges fan out from the hostname: HAS_REGISTRAR to the registrar, HAS_EMAIL to the WHOIS contact email, and REGISTERED_BY to the registrant organization.

These edges point domain → record — the opposite of MAIL_FOR above — so pivoting from a WHOIS email to every domain it registered traverses HAS_EMAIL backwards: (:EMAIL)<-[:HAS_EMAIL]-(:HOSTNAME). A shared contact can sit behind many domains, so bound it with WITH e LIMIT 3 before expanding. WHOIS contacts are sparse and current records are often redacted, so expect gaps.

Reach an organization through an edge, then fold it.

ORGANIZATION names are raw registrant strings — github hostmaster, github, and GitHub, Inc. are three separate nodes for one company, so a display string copied out of a WHOIS record may match a different variant, or none at all. Anchor on the hostname or ASN, traverse REGISTERED_BY, then follow SAME_ORG_AS to the canonical company record and use that name for further pivots.

Read coverage before band. Only known-clean — coverage: known-clean. In coverage, no malicious evidence. licenses the word "clean"; no-data — coverage: no-data. Not in coverage. This is not a verdict — nothing was looked at. means unknown, which is a different thing again; malicious-evidenced — coverage: malicious-evidenced. In coverage, with positive evidence of malice. and ambiguous — coverage: ambiguous. In coverage, and the evidence points both ways. mean there is evidence, whatever the band says. Full contract: Coverage — what we looked at.

IP → threat feeds → categories

Enrich an indicator: which feeds flagged it, and what categories those feeds belong to.

Bound the feed list with WITH f LIMIT 10 before expanding to categories. Filter feeds and categories on their stable slug, exposed as both id and name ({name: "c2"}); displayName is the human label. The full catalog and taxonomy are on the Threat Feeds & Categories page. For a scored verdict with per-feed evidence in one call, prefer explain() over walking these edges by hand.

Phishing-kit path → hosts

Which hosts serve a known phishing-kit path? URL nodes are kit URL paths, not web pages, and LINKS_TO joins a path to every host it has been seen on. Anchor the path by {name: …}, which holds the path and is indexed, or bound it with WITH u LIMIT n, before following the edge; {path: …} and {id: …} scan the whole label.

segmentRarity, hostnameCount and apexCount on the URL node say how distinctive the path is and how widely it has been seen. The hostname-to-hostname form of LINKS_TO is a small sample of hyperlinks, not a web-scale link graph; do not plan a link-graph question on it.

Actor → technique → tactic

Map a threat actor to the MITRE ATT&CK techniques it uses, and roll each technique up to its tactic.

WhisperGraph carries the MITRE ATT&CK knowledge base as graph structure — 9,630 USES_TECHNIQUE edges from ACTOR to ATTACK_PATTERN and 881 USES_TACTIC edges, across 1,987 actors and 721 techniques. This is a curated reference layer, not Whisper's own attribution. It reflects what public reporting has mapped, not what Whisper observed. The edge that joins it to live infrastructure is sparse: ATTRIBUTED_TO, a published attribution from an indicator to a named group, holds 345 edges. These queries return technique and tactic rollups. They do not attribute anything.

ACTOR names are case-sensitive, and the vendor names for the same group live in ACTOR.aliases. A technique can also be anchored by its T-number, {name: "T1003"}, which the name index resolves, or filtered with {kind: "technique"}. Group a technique under its tactic with (:ATTACK_PATTERN)-[:USES_TACTIC]->(:ATTACK_PATTERN) — a rollup of the same curated mapping, with the same caveat above it. Convergence between two actors is a lead about the reporting, not proof about the infrastructure, and an absent mapping is no-data — coverage: no-data. Not in coverage. This is not a verdict — nothing was looked at., never evidence of absence.

RPKI authorization

Check what a route-origin authorization covers — which AS it authorizes, for which prefix, down to which length, and which trust anchor signed it.

MATCH (a:ASN {name: "AS13335"})<-[:ROA_AUTHORIZES_ORIGIN]-(roa:ROA)-[:ROA_AUTHORIZES_PREFIX]->(p:PREFIX)
WHERE roa.authSource = "rpki-roa"
RETURN a.name AS authorized_asn, p.name AS authorized_prefix,
       roa.maxLength AS max_length, roa.trustAnchor AS trust_anchor
LIMIT 10

A specific result may differ from this capture (captured 2026-10-06: AS13335 against 102.219.82.0/24 at maxLength 24, trust anchor afrinic). The query shape is what stays useful.

A ROA carries no name. Read it through asn, prefix, maxLength, trustAnchor and validUntil, and keep to authSource = "rpki-roa": the label also holds route objects from the internet routing registries, which are registry declarations rather than signed authorizations. The announced prefix itself carries the outcome as rpkiStatus, with roaAsn and roaMaxLength beside it.

Prefix → cloud region

Place a prefix inside the cloud region that operates it.

Cloud-region coverage is partial, so swap the seed and this usually returns nothing. The seed above is an AWS range, chosen because it answers. A zero-row result means Whisper has not mapped that prefix to a tracked region — never that the prefix is not in a cloud.

Prefix → MOAS conflict

A prefix announced by more than one origin AS is the fingerprint of a hijack or route leak.

MATCH (ap:ANNOUNCED_PREFIX {name: "196.8.213.0/24"})-[:CONFLICTS_WITH]->(a:ASN)
RETURN ap.name AS prefix, ap.isMoas AS is_moas, a.name AS conflicting_asn
LIMIT 15

Multi-origin state shifts as routes change, so any specific example prefix may settle (captured 2026-09-03: 196.8.213.0/24 against AS33763 and AS10798). The query shape is what stays useful. When you expand outward from an announced prefix, type the edge (-[:CONFLICTS_WITH]->, -[:ROUTES]->) rather than writing a bare -[r]->.

Compose your own

These chains are building blocks. Because the layers are pre-joined, you can splice them — resolve a domain to an IP, geolocate the IP, and pull its threat feeds in one query; or pivot from a WHOIS email to every domain it registered to their shared ASNs. A longer chain needs a key. Anchor the start, label or anchor at least one endpoint of every computed edge, and bound the range of any variable-length pattern. Walk from an IP to its network with ANNOUNCED_BY then ROUTES, and over a routing chain de-duplicate on the client or use an aggregate instead of RETURN DISTINCT. The Connection Types reference lists every edge you can chain, and Best Practices covers the rules that keep a deep traversal fast.