Threat Investigation

The alert

The question

What this cannot answer

What do we know

Why

1. 01Capability preflight. db.relationshipTypes()/db.labels() are cheap schema-introspection calls; the flags they yield gate the §9 aggregate pass so a layer absent on this server degrades to a coverage note instead of erroring — the same instructions enrich automatically as layers ship.
2. 02Threat-engine reading. explain() auto-detects the indicator type and returns the graph's own score, level, factors and cited sources — the first-hand observation everything else is read alongside.
3. 03Suspicion assessment. whisper.assess returns a label + band with an explicit coverage qualifier, so a clean read is reported as "known-clean" vs "no-data" rather than silently implying safety.
4. 04Threat-feed listings. Names the LISTED_IN feeds and their categories, EXCLUDING popularity/trust lists (Tranco, Cloudflare Radar — a legitimacy signal, not a threat) and ad/tracking blocklists, so the threat-feed count is real.
5. 05Popularity / trust context. Tranco / Cloudflare Radar top-1M membership is a popularity/legitimacy signal, and ad/tracking blocklists merely flag ad-serving domains — neither is a security threat, so they are reported as CONTEXT, never as a threat hit. (Popularity VDP — returns nothing until the layer ships to prod, then activates automatically.)
6. 06What this is. The indicator is routed into the right typed frontier (hostname / IP / ASN / prefix) so round one expands it by the correct rules.
7. 07De-CDN origins. whisper.origins peels back CDN/proxy fronting to the likely origin IP(s) and network; those origin IPs are seeded into the IP frontier so the fan-out expands the infrastructure that actually serves the content — not the CDN front-end (whose co-tenants are suppressed).
8. 08Subdomain family. Derives the registrable apex with the Public Suffix List and enumerates its subdomain family, each threat-checked. ANCHORED ON THE HOSTNAME LABEL: fed a bare IP, whisper.psl.tldPlusOne happily returns '101.33' as the 'apex' of 185.220.101.33, which then poisons the profile card and the subdomain table. Matching (h:HOSTNAME) first makes the step a clean no-op for an address, network or prefix seed.
9. 09Infrastructure classification. Reads vendor delegation, the prefix anycast flag (ip.isAnycast is null — read it from the prefix), co-tenant degree and the node's own egress/abuse flags to tag the infra class (§15.7). A threat/egress flag on a SHARED address (CDN vendor / anycast / high-degree) is a bad co-tenant, not the seed's own infra, so it does NOT flip a fronted domain to BULLETPROOF/TOR — shared seeds suppress co-tenant fan-out and lean on de-CDN origins; only a DEDICATED abuse address expands HARDER.
10. 10Round 1: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
11. 11Round 1: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
12. 12Round 1: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
13. 13Round 1: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
14. 14Round 2: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
15. 15Round 2: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
16. 16Round 2: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
17. 17Round 2: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
18. 18Round 3: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
19. 19Round 3: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
20. 20Round 3: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
21. 21Round 3: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
22. 22Round 4: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
23. 23Round 4: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
24. 24Round 4: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
25. 25Round 4: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
26. 26Round 5: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
27. 27Round 5: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
28. 28Round 5: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
29. 29Round 5: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
30. 30Round 6: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
31. 31Round 6: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
32. 32Round 6: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
33. 33Round 6: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
34. 34Round 7: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
35. 35Round 7: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
36. 36Round 7: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
37. 37Round 7: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
38. 38Round 8: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
39. 39Round 8: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
40. 40Round 8: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
41. 41Round 8: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
42. 42Round 9: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
43. 43Round 9: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
44. 44Round 9: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
45. 45Round 9: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
46. 46Round 10: hostnames → IPs & subdomains. Each hostname fans out to the IP(s) it resolves to (its hosting), the subdomains beneath it, its parent domain (up to the apex, never the TLD), and the hostnames it links out to — all become nodes the next round expands.
47. 47Round 10: IPs → hosts & prefix. Each IP fans out to the hostnames it serves and the prefix that announces it. CDN/cloud-delegated addresses host millions of unrelated tenants, so their co-tenant promotion is suppressed (DELEGATED_TO a VENDOR) — the de-CDN origins pivot carries the meaningful neighbours instead.
48. 48Round 10: ASNs → prefixes. Each owning network fans out to the prefixes it announces — the address space that depends on it, and the next nodes to expand to their IPs.
49. 49Round 10: prefixes → IPs & ASN. Each prefix fans out to the IPs it contains and the ASN that routes it — but a prefix on a large provider network (anycast / many-prefix ASN / CDN vendor) holds hundreds of unrelated tenants, so its IP expansion is suppressed (the toxic-neighbourhood poison pivot); a small dedicated prefix still reaches its sibling hosts.
50. 50Threat sweep across the fan-out. Every hostname, IP, prefix and ASN reached is read for its own threat listing & level, LISTED_IN feeds, HAS_SIGNAL threat signals and per-node flags — so a compromised node anywhere in the neighbourhood surfaces, not just the indicator itself.
51. 51Fan-out recap. A count of everything reached — hostnames, IPs, prefixes and networks — the strategy expands each branch as far as its signal warrants.
52. 52MOAS route conflicts (with RPKI status). MOAS is USUALLY LEGITIMATE — multihoming, anycast, DDoS scrubbing, aggregation and mergers all look identical to a hijack, and >90% of MOAS prefixes are plain multihoming. So the row that matters is not "is it MOAS" but the per-(prefix, origin) RPKI status: a ROA that covers the prefix but does NOT authorize this origin ('not-authorized') is the only aggravating case, and it is the only one the highlight rules will promote. 'not-found' means no ROA covers the prefix at all — unverifiable, not invalid (only ~45% of routable prefixes carry one). ROAs are typed to PREFIX while routing produces ANNOUNCED_PREFIX, so the join is by NAME — and it must be the UNWIND value `n`, never the bound `ap.name`: anchoring the PREFIX lookup on a bound node property both misses the index (13s — 65x slower than the indexed form) AND silently returns 0 ROAs, which would have reported every MOAS conflict as 'not-found'. Live-validated on 216.168.228.0/24: 180ms, two VeriSign origins, both 'not-authorized'.
53. 53RPKI origin authorization. ROAs are typed to PREFIX and routing produces ANNOUNCED_PREFIX, so bridge through the ASN. roa_n = 0 is a CANDIDATE unverified origin (labelled "unverified", not "invalid") — corroborate per (prefix, origin).
54. 54Shared-IP clusters. Hosts sharing one IP are a co-hosting cluster (size ≥ 2, ≤ 200 — a mapping to hundreds is shared hosting, not a cluster).
55. 55Shared-nameserver clusters. Domains behind one nameserver (NAMESERVER_FOR goes ns→domain) form a shared-NS cluster — a bulk-registration pivot (a boutique NS, not a mega-managed-DNS one with 137k siblings).
56. 56Shared-registrant clusters. Domains registered by one email are a campaign cluster — the highest-value shared-infra pivot (exclude privacy-proxy contacts that map to countless domains).
57. 57Threat density by network. A raw count of threat-listed addresses says nothing without a denominator: 200 listed IPs in a hyperscaler is background noise, 4 in a 30-address block is a toxic neighbourhood. The sampled percentage is what makes the finding promotable (the highlight rules require BOTH a floor on the count and a floor on the density), and capping the sample at 300 addresses keeps the query bounded on a large network.
58. 58Egress / anonymizer concentration. A concentration of egress/anonymizer nodes in one class is a stronger signal than any single hit (per-node flags; no assess round-trip needed).
59. 59Clean-in-toxic contradictions. A clean IP inside a prefix that also carries threat-listed IPs is not "safe" — no-data at the IP granularity inside a hostile neighbourhood is a contradiction worth surfacing (WHOIS/GeoIP mismatch is computed in the handler from whois + origins).
60. 60Abuse-infra neighbours. Co-tenants of a bulletproof/abuse address are likely related bad actors (the opposite of CDN noise) — the highest-value branch to expand, bounded to threat-flagged neighbours in the same prefix. Fires on the aggregate pass or whenever the seed classified as bulletproof/abuse.
61. 61WHOIS ownership. Registrar, registrant org and contact email are the ownership anchors that link this domain to siblings and to known actors.
62. 62WHOIS history. Registration age and the history of registrar/registrant/nameserver changes separate stable assets from freshly-registered, disposable ones.
63. 63Vendor / host identity. whisper.identify maps the host to a canonical vendor, category and role set (CDN, mail receiver, DNS operator…), so known-good infrastructure is recognised rather than re-investigated.
64. 64Listing vector — feeds, weights & recency. Breaks the base score into its direct-listing evidence: every feed that listed the indicator, the weight it contributed, and when it was first and last seen — the sourced, dated rows that justify the verdict to an analyst or auditor.
65. 65Threat-class vector — phishing / malware / C2 / spam / anon. Decomposes the indicator's own verdict into named abuse types — phishing, malware, C2, spam, botnet, DGA, brute-force, scanner, anonymizer/Tor — so the score reads as a class breakdown rather than one opaque number.
66. 66Network-neighborhood vector — toxic density on the hosting prefix. The guilt-by-hosting signal: how many threat-listed IPs share the announced prefix behind the indicator. An IP anchors directly on its prefix; a domain resolves to its serving IPs first, so a clean indicator sitting in a bad block still surfaces the neighbourhood risk.
67. 67ASN composite vector — threatDensity / graphMetrics / historical / prefixAge. Exposes the engine's structured reputation breakdown for the owning network — threat-density, graph-metrics, historical-behaviour and prefix-age sub-scores. Scores the ASN directly when the indicator is one, otherwise resolves the owning ASN behind an IP or domain.
68. 68DNS records. The seed hostname’s resolved v4/v6 addresses, its nameservers and mail servers, any CNAME aliases, and the count of sites it links to and that link to it — the DNS + web-graph facts an analyst reads first.
69. 69Nameservers & providers. Each nameserver (NAMESERVER_FOR goes NS→domain) with the vendor its own address is delegated to — the managed-DNS / hosting provider behind the zone.
70. 70Mail servers & providers. Each mail server (MAIL_FOR goes MX→domain) with the vendor its address is delegated to — who actually receives the domain’s mail.
71. 71SPF authorization chain. The domain’s SPF record expanded one and two levels deep — which hosts, mail exchangers and IP ranges it authorizes to send mail as it — rendered as a tree.
72. 72Network & hosting attribution. For the indicator’s own address(es): the announcing prefix and ASN (with its name), the registered-prefix owner org, the GeoIP city/country, and the CDN/cloud vendor or cloud region — the hosting story as one coherent table instead of five.
73. 73Physical footprint. The data-center facilities (AS_PRESENT_AT) and internet exchanges (IX_MEMBER) the owning ASN is present at — the physical-layer footprint behind the address. Sparse for small networks (PeeringDB coverage).
74. 74Address tenancy. The most load-bearing number in the report: it decides whether co-hosting is evidence at all. On an address with 4,000 tenants, "a flagged domain shares this IP" says nothing — threat actors and enterprises sit on the same shared platforms. On an address with 3, it says a great deal. Every neighbourhood highlight is gated on this class (shared ≥20 / low-density / dedicated ≤2); the count is a capped sample, because the only question ever asked of it is which tenancy band it falls into.
75. 75Structural context (whisper.walk). A novel host is not a clean host. whisper.walk answers the question a feed lookup cannot: does the graph hold ANY structural record of this thing? `no_atlas_match` means it matched nothing we know — which is a coverage statement, not a verdict, and is exactly the case where a not-listed reading is least trustworthy.
76. 76Network reputation. The graph pre-computes a per-ASN reputation (max/avg threat score, overall level, whether it announces threatening prefixes). Running it over the networks the FAN-OUT reached — not just an ASN input — means a domain or IP investigation also gets its hosting network's posture, which is the difference between a boutique bulletproof AS and a Fortune-500 cloud.
77. 77Unflagged registrant siblings. The forward-TI arm: the domains registered by the same contact that NOTHING has flagged yet. If the seed is bad, these are the not-yet-burned infrastructure — the most actionable rows in the whole report, and by definition invisible to every feed lookup.
78. 78Abuse signals. The typed abuse signals (THREAT_SIGNAL_TYPE) are a first-class layer, distinct from the boolean flags and the feed listings — an entity can carry a signal with no feed listing at all. Gated on the PREFLIGHT capability probe, so a server without the layer degrades to a coverage note instead of an error.
79. 79Tor exit relays on the resolved addresses. Anonymised traffic changes how every other piece of evidence is weighed — an exit address is the source of other people's traffic, not necessarily its operator's. Anchoring on the seed AND its resolved addresses (OPERATES_EXIT_NODE runs IPV4 → TOR_RELAY) means a DOMAIN pointing at an exit is caught too, not just a bare IP. Running an exit relay is legal and common for nonprofits and universities: this is context, never a verdict.
80. 80Tor relay record. Only runs once the graph traversal has already found an exit relay, and is bound to THAT address — so the procedure is always handed an IP (it takes a scalar), never a hostname. It adds the provenance the edge alone cannot: which consensus/source recorded it, and when.
81. 81Tor exit presence across the network. The network-scale view: how much of this ASN is Tor egress, and where. Deliberately gated — it only runs when the seed IS a network, or when the seed itself already touched an exit relay, because walking every prefix of an arbitrary hosting ASN is expensive and, for an ordinary domain, pointless. Capped at the first 5 in-scope networks.

The pivot the score did not suggest

Falsify it

The conclusion

What this cost

81 named steps across the threat-intel, DNS, BGP, WHOIS, historical layers. The runner reports what each step returned, row by row, so the evidence and what it took to get it arrive together rather than as one number at the end.