TI-2026-064A — The Same Ten Minutes: Why Coincidence Is the Weakest Evidence

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

The honeypot's entity-resolution graph holds 192,395 edges between attacking IPs. Only a handful are smoking guns — a planted backdoor key, an identical malware binary. The overwhelming majority are circumstantial: same network prefix, co-listing in a third party's threat feed, an accident of geolocation, or the subject of this dossier — two IPs that happened to attack in the same ten minutes. This series takes the circumstantial layer itself as its subject: what is weak evidence actually worth in attribution? We begin with the weakest signal of all, because it is the one most likely to fool you.

1. The Signal

The pipeline records 1,956 temporal_correlation edges. The rule is mechanical: bucket all honeypot sessions into 10-minute windows; any IPs that appear in the same bucket get linked, tagged with the time_bucket, the cluster_size, and window_minutes=10. The platform assigns this relationship an average confidence of 0.51 — barely above a coin flip, and deliberately so. It is the honest number for "these two events happened near each other in time."

Here is one bucket, 2026-07-07 03:50 UTC, cluster size 5:

Five machines, four countries, five different networks, "linked" by nothing but a shared clock reading. Taken alone, that is not a relationship. It is a queue.

2. The Tell: Busy Scanners Are Busy

The reason temporal coincidence is so weak becomes obvious the moment you look across buckets instead of within one. The same heavy hitter, 185.246.128.133 (w1n ltd, threat 97), appears in three separate buckets on two different days — each time paired with an entirely different set of IPs:

w1n is one of the most persistent SSH brute-forcers in the entire dataset. It scans constantly. So it lands in almost every ten-minute window — and the correlation engine dutifully "links" it to whoever else happened to be firing at that instant. In the 08:50 window that includes a Viettel residential handset in Vietnam; in the 03:50 window, an Amazon EC2 box. There is no world in which w1n ltd (a Swedish bulletproof scanner) and a random Vietnamese phone line are the same operator. The edge is an artifact of both being frequent, nothing more. This is the birthday-paradox of a honeypot: with enough busy attackers, any two of them will eventually share a minute.

A note on provenance: 176.53.159.196, which threads through two of these buckets, is the same IP whose direct-tcpip proxy-recruitment probe to 1.1.1.1:53 opened this honeypot's investigation queue earlier today. It is a genuinely active node — which is precisely why it keeps turning up in temporal buckets, and precisely why that co-occurrence proves nothing on its own.

3. Where the Signal Is Not Zero

Temporal correlation is weak, not worthless. It carries information in exactly one situation: when the co-firing IPs also share infrastructure. Look again at the buckets and a sub-pattern surfaces — Dutch bulletproof hosts recur: TECHOFF SRV (NL), Omegatech LTD (NL, threat 100), TechTies Inc. These are not hyperscalers with millions of tenants; they are boutique abuse-friendly ranges. Two IPs from the same small bulletproof host firing in the same window is a materially different claim than w1n-meets-Viettel — because the base rate of "random coincidence" collapses when the population is small and already curated.

That is the whole lesson of the weakest signal: coincidence only means something once something else already links the parties. Temporal correlation is a multiplier on a pre-existing hypothesis. It cannot be the hypothesis.

4. Alternative Interpretation

Steelman: "Coordinated botnets do fire simultaneously. A command-and-control server that tells 50 nodes to start scanning at 03:50 will produce exactly this signature. Dismissing temporal correlation throws away a real detection for synchronised campaigns."

Why the calibration still holds:

• Synchronised C2 is real — and it looks different. A genuine coordinated burst shows the same set of IPs recurring together across multiple buckets, ideally on shared tooling (one HASSH, one command hash). What we see instead is one persistent node recombining with a shifting cast — the signature of individual busyness, not collective command.
• The confidence number already encodes this. The platform rates temporal_correlation at 0.51, not 0.9. It is not claiming attribution; it is flagging a lead. The error is not in computing the edge — it is in reading it as more than it is.
• The correct use is scoping, not attribution. Once a strong signal (see TI-2026-064E) establishes that two IPs are the same operator, a shared time bucket becomes corroborating detail — evidence of an active, synchronised phase. Absent that anchor, it is queue noise.

What is not claimed: that any two IPs in these buckets are the same actor. Confidence: MEDIUM that temporal correlation is a genuine but low-weight signal whose value is entirely conditional on independent corroboration; HIGH that, used alone, it manufactures false links between unrelated heavy scanners.

5. Defense Response

• Never block on coincidence. A temporal-only correlation to a known-bad IP is not grounds to block the co-occurring address; you will blackhole EC2 and residential ranges that merely shared a minute.
• Use it to enrich, not to accuse. When you already have a confirmed malicious node, its same-bucket partners are worth a look — a cheap way to surface a possibly-coordinated phase — but they inherit no guilt.
• Weight by base rate. A shared bucket between two IPs on the same 256-address bulletproof block is worth attention; a shared bucket between a bulletproof scanner and a hyperscaler tenant is worth nothing. The population size is the signal.
• Watch for true synchrony. The pattern that does warrant escalation is the same IP-set recurring across many buckets with shared tooling — coordinated command. Filter for recurrence, not single coincidence.

6. Investigation Metadata

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