TI-2026-064D — Same Street, Different Houses: When Network Adjacency Is and Isn't Identity

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

The three signals so far were behavioural or accidental. This part is about the largest circumstantial category of all — structural adjacency. same_prefix (29,197 edges) is the single most common relationship in the graph; add shared_bgp_upstream (11,890), shared_rdap_org (12,222) and shared_abuse_phone (14,209) and network-adjacency signals dominate the entire dataset. They are also the most dangerous to misread, because their weight is not fixed — the same relationship means almost nothing on one network and almost everything on another. This is the signal whose value is entirely a function of context.

1. The Signal

Adjacency links are cheap and abundant because they are structural: two IPs in the same /24 are same_prefix; two announced through the same transit AS are shared_bgp_upstream; two registered to the same org or abuse phone number are shared_rdap_org / shared_abuse_phone. No behaviour required — geography of the address space does all the work. That is why they are the biggest buckets in the graph, and why they carry no fixed confidence: an adjacency edge is only as meaningful as the network it sits on.

The governing question is always the same: how many innocent tenants share this container?

2. The Base-Rate Fork

The same same_prefix edge splits into near-worthless and near-conclusive depending entirely on the block it describes.

Near-worthless — the hyperscaler case. Two attacking IPs both in a Google Cloud or AWS /24 share a prefix with tens of thousands of unrelated customers cycling through ephemeral VMs. same_prefix on AS396982 or AS16509 is a coincidence of the rental market, not a relationship. (Part C's eleven GCP IPs are "same region"; that is weaker still than "same operator," for exactly this reason.)

Near-conclusive — the boutique bulletproof case. The Dutch bulletproof hosts that surfaced in Part A's temporal buckets — TECHOFF SRV, Omegatech LTD (threat 100), TechTies Inc. — are a different universe. When a /24 is entirely malicious, rented in bulk by one operator to run one campaign, then two attacking IPs in that block are not "neighbours who happen to share a street." They are two windows of the same house. same_prefix there approaches identity, and shared_abuse_phone / shared_rdap_org push it further: a single abuse contact behind multiple ranges is a strong operator-level tie, because legitimate multi-tenant networks do not concentrate that way.

The relationship type is identical. The population it partitions is everything.

3. Why Adjacency Is Seductive — and Where It Fails

Structural signals are seductive precisely because they are so plentiful. Any two busy IPs, run through the graph, will almost always share some adjacency — a transit provider, a registrar, a RIR block. That abundance is a liability, not an asset: a signal you can find between any two nodes cannot, by itself, distinguish a real pair from a random one. This is the mechanism behind the confirmation-bias failure this whole series builds toward (Part E) — start with a suspicion, and the adjacency layer will always hand you an edge to "confirm" it.

The discipline is to price each adjacency by its container before trusting it:

The same column headers, opposite verdicts. Adjacency without base-rate context is not evidence — it is the appearance of evidence, which is worse.

4. Alternative Interpretation

Steelman: "Infrastructure adjacency is the backbone of real attribution — threat intel teams cluster by ASN and netblock every day, and it works. Calling it 'context-dependent' understates how reliably bulletproof-host clustering identifies operators."

Why the framing holds:

• It agrees where the steelman is right. On curated bulletproof blocks, adjacency is strong — the table above says exactly that. The claim is not that adjacency is weak; it is that its weight is conditional, and the condition is the base rate of the container.
• The failures are concrete, not hypothetical. Treating same_prefix on GCP/AWS as a relationship would merge thousands of unrelated tenants — a routine, real mistake in naïve graph clustering. The safeguard is pricing by population, not discarding the signal.
• It is the connective tissue, not the proof. Adjacency is what turns isolated strong signals into a mapped operator once you know the block is theirs. It scales an anchor; it does not create one. Same rule as every part of this series.

What is not claimed: that adjacency is uniformly weak (it is not) or uniformly strong (it is not) — only that its value cannot be read off the edge without knowing the network. Confidence: MEDIUM overall, resolving to HIGH at both extremes: high that same-prefix on hyperscalers is near-noise, and high that same-prefix on a wholly-malicious bulletproof block is near-identity.

5. Defense Response

• Price every adjacency by its container first. Before clustering on same_prefix, ask how many legitimate tenants share that block. On a /24 that is 100% malicious, cluster freely; on a hyperscaler range, don't.
• Prefer the concentrating signals. shared_abuse_phone and shared_rdap_org across multiple distinct ranges are the strongest adjacency ties — legitimate networks rarely concentrate abuse contacts across blocks; shell operators do.
• Block at the right granularity. For a curated bulletproof block, escalate from IP to prefix — the whole range is likely hostile. For a hyperscaler, never blocklist the prefix; you will break innocent tenants.
• Use adjacency to expand, anchored on strength. Once a strong signal confirms one node, walk its adjacency to map the operator's footprint. Do not walk adjacency to find the operator — that is how you invent one.

6. Investigation Metadata

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