Collective Threat Intelligence Without Revealing Your Watchlist

Threat intelligence sharing has a trust problem that no amount of TLP markings can fix. To share, you must disclose. To disclose, you must trust every recipient. And trust doesn’t scale to hundreds of organizations across competing sectors, jurisdictions, and regulatory regimes.

ISACs try to solve this with membership agreements and governance committees. The result is sharing that’s high-trust but low-velocity — reports circulate on days-to-weeks timescales, long after the initial wave of exploitation. Bilateral sharing between SOC teams works faster but tops out at a handful of relationships before the coordination overhead becomes unsustainable.

The underlying question is simple: “Are other organizations seeing the same threat I’m seeing right now?” Answering it shouldn’t require publishing your watchlist.

Threat Pool: anonymized collective sighting

MalCloud’s Threat Pool is a collective sighting layer. Every participating organization automatically contributes anonymized sighting signals for IOCs they encounter. In return, they see aggregate intelligence: how many organizations have seen this indicator, what sectors are affected, and how fast the sighting rate is accelerating.

No organization reveals which indicators they track. No organization sees another’s watchlist. The aggregation is the product.

Here’s what a Threat Pool signal looks like for a given IOC:

IOC:        185.220.101[.]34
Sightings:  47 organizations
Sectors:    Financial (19), Healthcare (12), Technology (9), Other (7)
Velocity:   8 sightings in last 60 minutes (accelerating)
First seen: 2026-04-15T08:12:00Z (pool)
Trending:   Yes — crossed velocity threshold 14 minutes ago

Forty-seven organizations confirmed sighting this IP. Twelve of them are in healthcare. Eight sightings landed in the last hour. You didn’t need to ask anyone. Nobody needed to reply to an email. The signal materialized because the network exists.

How it works

Hash-based counters, not raw indicators

When an organization’s MalCloud instance encounters an IOC — through feed ingestion, manual lookup, extractor output, or SIEM correlation — the Threat Pool client computes a MiMC commitment hash of the indicator value and submits it to the pool. MiMC (Minimal Multiplicative Complexity) is a hash function designed for efficient arithmetic circuit representation, making it well-suited for zero-knowledge proof systems.

The pool never receives the raw indicator. It receives a commitment: a cryptographic value that binds the submitter to a specific IOC without revealing it. The pool increments a counter against that commitment. When another organization submits the same commitment, the counter increments again.

This is a one-way operation. The pool can aggregate counts against commitments but cannot reverse a commitment to recover the underlying IOC. Organizations querying the pool submit their own commitment for an IOC they already know and receive the aggregate count — they learn how many others have seen it, not who.

Sector-tagged aggregation

Each sighting carries a sector tag (financial, healthcare, government, technology, energy, etc.) derived from the organization’s self-declared profile. Sector tags enable breakdown analysis: “19 of 47 sightings are from financial services” tells you something different than “47 organizations saw this.” If you’re a bank and 40% of sightings are from other banks, that’s a targeted campaign. If sightings are spread evenly, it’s likely opportunistic scanning.

Privacy threshold: MinSectorCount=3

A sector breakdown that reads “Healthcare: 1” when only one hospital in your region participates in the pool is a de-anonymization risk. MalCloud enforces a MinSectorCount threshold: sector-level data is only visible when at least 3 organizations in that sector have reported sightings. Below that threshold, sightings roll into “Other.”

This prevents the pool from becoming an inadvertent signal about specific organizations’ defensive focus. The threshold is configurable per pool instance but defaults to 3.

Deduplication and velocity

Sightings are deduplicated per organization on a 60-second window. If your SIEM correlates the same IP 200 times in a minute during a brute-force campaign, the pool registers one sighting, not 200. This prevents high-volume organizations from skewing aggregate counts and keeps velocity metrics meaningful.

Velocity — the rate of new organization sightings per time window — is the most operationally useful signal. A dormant IOC that suddenly receives 8 sightings in 60 minutes is behaving differently than one that accumulated 47 sightings over three months. MalCloud tracks velocity as a sliding window and flags IOCs that cross configurable acceleration thresholds as trending.

Network effects

Threat Pool’s value is a function of participation. This isn’t a marketing claim — it’s the mathematical reality of aggregate signals.

With 10 participating organizations, sighting counts provide directional confirmation. “3 of 10 orgs saw this” tells you it’s not isolated to your environment. Useful, but the sample is too small for reliable sector breakdowns or velocity detection.

With 100 organizations, the signal becomes actionable. Sector breakdowns are statistically meaningful. Velocity detection catches campaigns in their first hour. Trending indicators surface threats that haven’t hit public feeds yet. An IOC that 30 financial institutions reported in the last 90 minutes is a high-confidence signal that no single-organization telemetry can replicate.

With 1,000+ organizations, the pool becomes a real-time threat barometer. Sector-specific attack campaigns are visible as they unfold. The collective detection speed exceeds any individual organization’s capability, including large vendors with global telemetry, because the pool aggregates across organizational boundaries that vendors can’t cross.

This creates a defensible network effect. Each new participant increases the value for every existing participant. An organization that leaves the pool loses access to signals they can’t replicate internally. This isn’t vendor lock-in through data formats or API incompatibility — it’s lock-in through collective intelligence that only exists because the network exists.

What you see (and what it costs)

Threat Pool data is tiered:

Signal	Free	Pro+
Sighting count (total orgs)	Yes	Yes
Sector breakdown	—	Yes
Velocity (sightings/time)	—	Yes
Trending indicators	—	Yes
Historical velocity	—	Yes

Free-tier organizations contribute sightings and see aggregate counts. That alone answers the most basic question: “Am I the only one seeing this?” Pro+ unlocks the analytical layer — sector context, velocity, and trending — that converts raw counts into operational intelligence.

Every participating organization contributes regardless of tier. The pool’s value depends on broad participation, so gating contribution behind a paywall would be self-defeating.

Technical implementation

Event-driven pipeline

Threat Pool runs on the same NATS event bus that powers the rest of MalCloud. When an IOC is sighted:

1. MalCloud emits a sighting.new event on NATS
2. The Threat Pool client computes the MiMC commitment hash
3. The commitment + sector tag + timestamp are submitted to the pool endpoint
4. The pool updates Redis-cached counters (sighting count, sector buckets, velocity window)
5. If a velocity threshold is crossed, a trending.new event propagates back to subscribers

End-to-end latency from sighting to updated pool signal: under 200ms. Query latency for pool signals against cached counters: under 5ms. Redis handles the hot path; PostgreSQL backs the durable store for historical analysis.

What the pool cannot do

The pool cannot determine which organizations contributed specific sightings. It cannot reverse commitment hashes to recover IOC values. It cannot correlate sightings across IOCs to infer an organization’s watchlist composition. The sector tag reveals that some organization in a given sector saw something, but only when the MinSectorCount threshold is met, and never in combination with organizational identity.

These aren’t policy controls. They’re structural properties of the commitment scheme. An operator running the pool infrastructure has no more visibility into participant watchlists than an external observer.

The gap this fills

Public threat feeds (abuse.ch, OTX, VirusTotal) provide indicator data but no collective sighting context. You know an IP appeared on a blocklist. You don’t know if anyone in your sector encountered it this week.

ISACs provide sector context but on timescales measured in days. By the time an ISAC advisory circulates, the campaign has either concluded or mutated.

Commercial threat intelligence vendors (Recorded Future, Mandiant, CrowdStrike) aggregate telemetry from their customer base but keep the aggregate signals proprietary. You’re paying for access to intelligence derived partly from your own data, filtered through a vendor’s analytical lens, with no visibility into the underlying signal.

Threat Pool sits in the gap: real-time, sector-aware, privacy-preserving collective sighting data. It won’t replace your ISAC membership or your Recorded Future subscription. It fills the space between “I see this IOC” and “the industry sees this IOC” with a latency measured in seconds instead of days.

If you’re running MalCloud, Threat Pool is available now. Enable it in settings, configure your sector tag, and start contributing. The more organizations participate, the sharper the signal gets for everyone.

Request access or request a walkthrough.