Threat Feeds & Categories

WhisperGraph aggregates 164 intelligence feeds grouped into 33 categories, of which 140 carry isThreat. The rest are VPN, proxy, Tor, ad-tracking, reputation and popularity lists — useful signal, but not abuse reports, so filter on f.isThreat when you mean threat data only. The feeds are part of the graph itself: each feed is a FEED_SOURCE node, each category is a CATEGORY node, and every indicator that appears on a feed carries a LISTED_IN edge to it. On top of the raw listings, a reconciled verdict is written onto the indicator node, so a single anchored read tells you how bad an IP or hostname is with no extra hops.

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.

This page covers how feed data enters the graph, the full catalog and its refresh cadence, the category taxonomy, and the queries to work with both. For a scored verdict with an inspectable evidence chain, use explain().

How feeds enter the graph

Feeds are collected by a companion collection service that pulls from public and commercial sources on each feed's own refresh schedule. Inside the graph, the threat-intelligence layer surfaces three ways:

• LISTED_IN edges. An IPV4, IPV6, or HOSTNAME node connects to each FEED_SOURCE that lists it. The edge itself carries no queryable properties, so do not project r.weight or r.firstSeen off it. Per-feed weights and first/last-seen timestamps come from CALL explain(indicator), which returns them in sources[]; the feed's static weight is on the node as f.weight.
• BELONGS_TO edges. A FEED_SOURCE connects to its CATEGORY (there is no IN_CATEGORY edge), so you can turn feed names into threat categories in one hop.
• Verdict properties on nodes. Listed indicators carry raw threat properties (threatScore, threatLevel from NONE to CRITICAL, threatSources — a count of feeds, not their names — threatFirstSeen, threatLastSeen) plus a reconciled verdict: verdictScore, verdictLevel, verdictBlocking, and on IP nodes verdictAdvisory. Prefer the reconciled verdict* properties for triage decisions; they are the authoritative signal. A node can carry a threat listing and a whitelist marker at the same time: read the verdict as the verdict and treat the whitelist marker as context, not as an override.

Listed nodes also carry boolean posture flags derived from the categories of the feeds that list them: isThreat, isAnonymizer, isC2, isMalware, isPhishing, isSpam, isBruteforce, isScanner, isBlacklist, isTor, isProxy, isVpn, isWhitelist, isReputation, isBotnet, isDga, isStateActor, isExfilDestination, isOfacSanctioned, isScam and isEgressRisk, with egressClasses naming the kind of egress (tor-exit, for example). Flags like isTor and isAnonymizer matter for triage even when the score is moderate: a login from a Tor exit reads very differently than the same login from a residential IP.

Two mechanics to know before querying:

• LISTED_IN and the feed-to-category BELONGS_TO step are computed at query time. Label or anchor one endpoint of each, and bound the feed list with WITH f LIMIT 10 before expanding to categories. See Best Practices.
• Curated allowlists clamp the verdict surfaces (threatLevel, isThreat, verdictLevel) to INFO/false for well-known public DNS resolvers such as 1.1.1.1 and 8.8.8.8, which appear on aggressive blocklists for reasons that rarely matter to a defender. Such a node carries allowlisted: true. The raw threatScore is not clamped, so it keeps the feed evidence.

Click to expand

Feed catalog

The live catalog holds 164 feeds.

This table is generated — every row, every column, straight from the FEED_SOURCE nodes, so it is the catalog rather than a copy of it. The Feed column is the human label (f.displayName). Anchor on the Query key column: it is the feed's stable slug, exposed as both f.id and f.name, so MATCH (f:FEED_SOURCE {id: "abuse-ch-feodo-tracker"}) and the name form both match, while the display name matches nothing. Each feed node also carries isThreat, isPopularity and category (the slug of its category), so you can filter the catalog without a hop. Weight is the feed's static score contribution (f.weight): one listing on a 0.5 feed is a lead, one on a 2.0 feed is a finding.

Rows measured live from MATCH (f:FEED_SOURCE) RETURN f, 2026-11-08.

The feed set evolves as sources are added or rebalanced. The first query on this page returns the current list, and GET /api/query/stats reports the live feedSourceCount and categoryCount (see the API Reference).

Refresh cadence

• Per-feed refresh. Each source is re-fetched on its own schedule, from hourly to daily, depending on how often its publisher updates it.
• Incremental sync into the graph. A new listing typically becomes queryable through its LISTED_IN edge within about an hour of the source publishing it. A hot C2 IP added to ThreatFox is usually reachable inside that window.

Listings carry first-seen and last-seen timestamps in explain()'s sources[], so you can tell a fresh listing from a stale one. Treat scores and listings as a live read rather than a fixed record, and re-read an indicator before you act on a verdict you fetched earlier.

Category taxonomy

Every feed belongs to one of 33 categories, and the categories fall into three groups. Threat categories mark confirmed or suspected badness. Anonymizer categories mark infrastructure that hides origin without being malicious in itself. Reference categories carry context data, including trust lists: a Tranco or Cloudflare Radar listing is a popularity signal, so a LISTED_IN edge alone does not mean an indicator is malicious. Check the category, or read the reconciled verdict, before escalating.

Two of the Reference categories are allow-lists — known-good and hash-allowlist. A LISTED_IN edge into either says the opposite of an accusation, and a pipeline that counts edges without reading the category will escalate on them.

The Query key column is the anchor here too. It is the category's stable slug, exposed as both c.id and c.name: MATCH (c:CATEGORY {id: "blacklists"}) matches, and {name: "General Blacklists"} matches nothing because that string is c.displayName. Not every category has a feed attached today; a category with no feeds still exists as a node, so MATCH (c:CATEGORY) lists more categories than a walk from FEED_SOURCE over BELONGS_TO reaches. The Group column is generated from the category's own isThreat / isAnonymizer flags, so it says what the engine says rather than what a writer remembered.

Rows measured live from MATCH (c:CATEGORY) RETURN c, 2026-11-08.

Use the category to scope a hunt: filter to C2 Servers plus Malware Distribution for confirmed-bad, or exclude the Reference group when counting threat evidence.

Querying feeds and verdicts

FEED_SOURCE and CATEGORY are small reference labels, so they are safe to scan without an anchor:

// List the live feed catalog with its human label, category slug and weight
MATCH (f:FEED_SOURCE)
RETURN f.id AS feed, f.displayName AS label, f.category AS category, f.weight AS weight
ORDER BY f.id
LIMIT 50

For an indicator, read the listings and the reconciled verdict together in one anchored query:

// Feeds listing this IP, plus its reconciled verdict and posture flags
MATCH (ip:IPV4 {name: "185.220.101.1"})
OPTIONAL MATCH (ip)-[:LISTED_IN]->(f:FEED_SOURCE)
RETURN ip.name AS ip, ip.verdictScore AS score, ip.verdictLevel AS level,
       ip.verdictBlocking AS blocking, ip.isTor AS isTor,
       collect(DISTINCT f.name) AS feeds
LIMIT 1

Several feeds naming the same indicator is a stronger signal than one. To turn the feed names into categories, pivot each feed through BELONGS_TO, bounding the feed list with WITH f LIMIT 10 between the two hops. The full recipe, along with batch enrichment patterns, is in Indicator Triage. For the scored reasoning behind a verdict, with the exact feeds, weights, and first/last-seen timestamps, call explain(). Labels, edges, and properties for the whole threat layer are in the Graph Schema.