TI-2026-064C — The Cartographer's Error: Attribution From a Map That Disagrees With Itself

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

Parts A and B dealt with signals an attacker emits — when they fire, who else reports them. This part is about a signal the attacker never chose and cannot control: the fact that different geolocation databases disagree about where their IP is, and that the shape of that disagreement is itself a fingerprint. shared_geo_pattern is the lowest-confidence relationship the platform computes — 0.35 — and yet it exposes something the attacker cannot hide: which corner of which cloud they spun their machine up in.

1. The Signal

Every IP in the graph is geolocated by several independent sources: Team Cymru's BGP prefix origin, ipinfo's commercial geolocation, the RIR registration country. Usually they agree. When they disagree, the pipeline records the exact disagreement as a pattern and links any two IPs whose maps break the same way. There are 4,531 such shared_geo_pattern edges, at confidence 0.35 — the platform's frank admission that a shared cartographic error is thin evidence of anything.

The canonical example, an 11-IP cluster, all carrying the identical discrepancy {cymru: US, ipinfo: BE, derived: US}:

BGP says United States. ipinfo says Brussels. Both are "right."

2. What the Disagreement Actually Is

The contradiction resolves the moment you know how the two sources work. Team Cymru reports the country where the ASN is registered — and Google's AS396982 is registered to Mountain View, California, so every Google Cloud IP worldwide reads "US" by BGP origin. ipinfo, by contrast, geolocates the physical region the address actually serves. Ten of these eleven IPs (the 34.x / 35.x / 104.199.x blocks) are GCP europe-west1 — Google's data centre in St. Ghislain, Belgium, which fronts as Brussels.

So the "error" is not an error at all. It is a precise fingerprint: these machines were provisioned in Google Cloud's Belgian region. The attacker chose a region from a dropdown; the map's self-contradiction quietly recorded that choice. It is an accidental signal — nothing the operator emitted, nothing they can scrub, a byproduct of infrastructure geography leaking through the disagreement of two databases.

And note the eleventh member: 207.175.30.65 is not a Google IP, yet it carries the same US/BE pattern. That is the signal's built-in warning — a purely mechanical pattern-match will always sweep in a false friend that happens to break the map the same way for unrelated reasons. The pattern reveals co-location; it does not prove common control.

3. Why It Is Weak, and Why It Still Matters

At 0.35, shared_geo_pattern is barely evidence of identity. Thousands of unrelated tenants share GCP europe-west1; sharing a region is like sharing a postal code in a city of millions. As an attribution claim between two arbitrary IPs, it is close to nothing — correctly priced.

Its value is orthogonal to identity. It answers a different question — not "are these the same operator?" but "where does this operator like to build?" That is durable tradecraft intelligence. An actor who repeatedly surfaces in GCP europe-west1 (or, elsewhere in the data, in a specific bulletproof region) has a provisioning habit, and habits are trackable across campaigns even when keys and tooling rotate. The cartographer's error is useless for the verdict and genuinely useful for the profile.

4. Alternative Interpretation

Steelman: "This is over-reading noise. Geolocation databases are wrong constantly and for boring reasons — stale WHOIS, anycast, VPN egress. Turning database disagreement into a 'fingerprint' dresses up data-quality problems as intelligence."

Why the calibration is right:

• The platform already agrees it is weak. 0.35 is the lowest confidence in the graph. Nobody is asked to convict on it. The claim is narrow: the shape of a disagreement is reproducible and therefore is data, even if it is weak data.
• Reproducibility is the test. A one-off geolocation glitch is noise. Eleven IPs breaking the map in the identical way (cymru:US / ipinfo:BE) is a structural fact about a shared deployment surface, not a random error — because random errors do not line up.
• It profiles, it does not accuse. Used as intended — a hint about provisioning geography, cross-checked against real signals — it adds a dimension. Used as identity, it fails, and the presence of the non-Google 207.175.30.65 in the cluster is the honest proof that it must never stand alone.

What is not claimed: that the 11 IPs share an operator (they share a cloud region, which is far weaker), or that geo-discrepancy is anything but the lowest-weight signal available. Confidence: MEDIUM that the disagreement encodes a real deployment fingerprint useful for actor profiling; HIGH that it is worthless as standalone attribution and will always catch false friends.

5. Defense Response

• Mine it for tradecraft, not verdicts. When you have a confirmed actor, check the geo-pattern of their nodes — a consistent cloud region is a durable behavioural marker that survives key and tool rotation.
• Never deduplicate on it. Two IPs sharing a geo-discrepancy are not one host; folding them together will merge unrelated tenants of the same data centre.
• Cross-check the pattern's meaning. Decode why the databases disagree (ASN-registration vs physical region vs anycast) before trusting the pattern. A US/BE split on Google is a region fingerprint; a US/NL split on an anycast CDN is meaningless.
• Feed provisioning geography into hunting. If an actor favours GCP europe-west1, new hostile IPs in that region+ASN are worth pre-emptive scrutiny — a cheap prior, not a conviction.

6. Investigation Metadata

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