TI-2026-064B — Seen From Outside: When the Rest of the World's Sensors Agree

Classification: MEDIUM–HIGH · Forensic threat intelligence · Methodology · Published 2026-07-07 · Series: ⚖️ Circumstantial

Part A showed why coincidence in time is the weakest circumstantial signal — one sensor, one clock, easily fooled. This part climbs one rung. shared_otx_pulse links two of our attacking IPs when independent sensors elsewhere in the world reported them in the same threat-intelligence pulse. That independence is what makes it stronger: it is no longer our honeypot talking to itself, it is our capture corroborated by strangers who never coordinated with us. With 26,411 such edges, it is the second-largest relationship in the entire graph — and it carries its own, subtler, base-rate trap.

1. The Signal

AlienVault OTX (Open Threat Exchange) is a public feed where thousands of sensors — corporate SOCs, national CERTs, hobby honeypots — publish "pulses": named lists of IPs they observed doing something bad. The pipeline pulls, for each of our honeypot IPs, the pulses it appears in, and links any two of our IPs that co-occur in one or more of the same pulses. The edge carries a shared_pulses count and an average confidence of 0.60 — higher than temporal correlation (0.51), because the corroboration comes from outside our own instrument.

A worked example. The GCP honeypot node 104.199.19.244 sits in two OTX pulses:

• "Rimba Siber (Malaysia) SSH Attacker Hosts for 2026-06-08"
• "TSEC Honeypot: Malware Delivery — Week of 2026-06-08"

A Malaysian threat-sharing project and a separate honeypot operator both caught the same IP the same week we did. Three sensors, no coordination, one conclusion: this address was broadly, actively hostile. That is real corroboration — the kind a single sensor can never produce for itself.

2. The Strength: Independence

The value of shared_otx_pulse is that it defeats the central weakness of Part A. Temporal correlation is one sensor's clock; it can be gamed or coincidental. A shared OTX pulse is N sensors independently arriving at the same target list. When two of our IPs co-appear across many pulses, the odds that both are benign collapse — because being repeatedly, independently reported by unrelated observers is exactly what a genuinely malicious host does and a false positive does not.

The clearest pair in the current graph:

Two Gigahost (Norway) addresses co-listed in ten of the same OTX pulses. Same hoster, same behaviour, independently reported together ten times over. That is a strong circumstantial tie — well beyond anything a clock could give you.

3. The Trap: Promiscuous IPs Are Reported by Everyone

The subtler danger in shared_otx_pulse is the opposite of Part A's. There, the problem was frequency in time; here, it is promiscuity in reporting. Consider this mesh from the same query:

Every one of these is a Tor exit node (192.42.116.0/24 is a well-known exit range). Tor exits get reported by everyone, constantly, because all of Tor's abusive traffic egresses through them. So they share pulses with each other — and with half the internet — not because a single operator runs them as a campaign, but because "reported for SSH abuse" is the ambient condition of being a Tor exit. A high shared_pulses count here means "these are both heavily-reported infrastructure," which is true but says nothing about common control.

The discriminator is the specificity of the pulse, not just the count. Co-occurrence in "Emotet C2 servers, 2026-06-14" (a targeted, curated pulse) is worth far more than co-occurrence in "Daily SSH bruteforce IPs" (an automated dump that scoops up every noisy address on the internet). The signal's weight lives in what the shared pulse is about.

4. Alternative Interpretation

Steelman: "OTX is crowd-sourced and noisy — anyone can publish a pulse, quality is uneven, and stale IPs linger for months. Building attribution on third-party feeds imports their errors into your graph."

Why it still earns its rung:

• Independence survives noise. Even granting uneven quality, multiple unrelated sensors converging on the same IP is Bayesian evidence no single instrument can fabricate. Noise weakens the signal; it does not invert it.
• The count and the specificity are both available. The edge records shared_pulses; the pulse names are retrievable. A disciplined reader down-weights generic dumps and Tor ranges and up-weights curated, campaign-specific pulses. The trap is avoidable by reading, not just counting.
• It is corroboration, not origination — same rule as Part A. A shared pulse strengthens a hypothesis; between two otherwise-unconnected IPs it is a lead, not a verdict. The rung is higher than temporal correlation, but it is still a rung, not the roof.

What is not claimed: that co-listed IPs share an operator (the Gigahost pair plausibly share a hoster, which is weaker than a controller), or that OTX pulses are ground truth. Confidence: MEDIUM–HIGH that shared, specific, independent external reporting is materially stronger corroboration than intra-sensor coincidence; HIGH that promiscuous infrastructure (Tor exits, generic dumps) inflates the count without adding attribution.

5. Defense Response

• Treat multi-sensor agreement as a threat-score input, not a block rule. Repeated independent reporting is a good reason to raise reputation weight; it is a poor reason to link two of your own alerts as one actor without more.
• Read the pulse, don't just count it. Filter for specific, campaign-named, recently-curated pulses; discount daily automated dumps and known-infrastructure ranges (Tor exits, VPN egress, hyperscaler NAT).
• Exploit the independence. The one thing this signal gives you that your own logs cannot: outside confirmation. When your sensor and three others all hold an IP, you can act with confidence that it is not a local fluke.
• Cross the streams. A pair that shares OTX pulses and shares tooling or a key (Part E) is far past coincidence. Use external corroboration to promote internal leads, never as the sole thread.

6. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence