A regional SOC opened a ticket after threat intel flagged unusual referral spam and credential-harvesting pages riding compromised Brazilian government domains. The first enrichment step looked routine: resolve every source IP, pull country and city, and build a map of who was hitting the landing pages. Half the addresses came back as São Paulo and Brasília. Another cluster mapped to Guangzhou and Shenzhen. A third sat inside European cloud regions. Leadership asked for an attribution brief by end of day. The brief leaned hard on those geo labels, and the brief was wrong.
The operators behind the SEO weaponization spoke Chinese and used Brazilian public-sector sites as disposable ranking engines. The IPs that looked "local" were compromised or rented infrastructure, not a Brazilian crime crew. The Chinese-looking hits included residential proxy exits and shared hosting customers whose databases had not been refreshed after ASN reassignments. The European cloud hits were staging boxes. Geolocation told the team where packets exited the public internet. It never told them who controlled the campaign.
What "accuracy" actually means in a security pipeline
Vendors publish accuracy rates that look reassuring: country matches above 95 percent, city matches often advertised in the 70 to 85 percent range. Those figures come from controlled tests against known ground truth. Production traffic in a SOC looks nothing like that sample.
Country-level data is usually strong enough to support coarse risk scoring, travel-rule checks, and first-pass triage. City and postal claims degrade quickly once you leave residential broadband. Accuracy also depends on which database you query, how often you refresh it, and whether the IP sits behind carrier-grade NAT, a mobile core, an anycast CDN edge, or a cloud provider with elastic address pools.
Treat every geo field as a probabilistic enrichment, not a forensic fact. Store the provider name, database version, and lookup timestamp beside the country and city values. When two tools disagree, keep both answers. Disagreement is a signal.
Failure modes that show up in real tickets
Cloud exits and elastic address space
Public cloud providers reassign prefixes constantly. A /24 that lived in Ashburn last quarter may now serve workloads in Frankfurt or Singapore. If your MaxMind, IP2Location, or commercial TI feed still carries the old region, every alert that depends on "impossible travel" or "foreign admin login" will fire on legitimate automation. Mirage Kitten-style campaigns that target aviation and FinTech across the Middle East and Africa often stage C2 and loaders in mainstream cloud regions. A geo hit that says "Dubai" or "Lagos" can be a VPN exit, a CDN node, or a stale registry row rather than an operator sitting in that city.
Carrier NAT and mobile cores
Millions of subscribers share a small set of public IPs. Your fraud system sees one address in Johannesburg and concludes a single actor is spraying accounts. The truth is a mobile gateway covering a wide metro area. City-level precision collapses here. Country may still be usable; neighborhood claims are theater.
Residential proxies and "clean" home ISNs
Malware droppers and adware loaders, including families marketed like ValleyRAT, routinely exit through residential proxy networks. Those exits inherit consumer ISP geolocation. Reputation and geo both look benign. If your playbook auto-trusts "residential + local country," you are grading the proxy vendor's footprint, not the attacker.
Compromised legitimate sites as launchpads
The Brazilian government SEO case is the cleanest recent reminder: infrastructure geography and operator geography diverge. Investigators who ranked leads by geo proximity to the victim environment chased the wrong continent for days. The same pattern appears whenever attackers hijack local trust to poison search results, host payloads, or relay phishing.
A concrete remediation path with tradeoffs
1. Demote city data in automated decisions
Keep city and coordinates for analyst context and map views. Remove them from auto-block, auto-lockout, and step-up auth triggers unless you have a second independent signal. Country and ASN remain usable inputs for risk scores when combined with device, session, and behavior features.
Tradeoff: You will miss some low-volume fraud that only looks anomalous at city granularity. You will also stop locking out traveling employees and partners whose phones hop through distant PGWs.
2. Require dual-source enrichment before high-impact actions
For containment decisions, query two independent geo providers plus WHOIS/RDAP and ASN ownership. Act only when country agrees across sources, or when disagreement is explained by known anycast or CDN behavior. Log the full enrichment bundle into the case.
Tradeoff: Extra latency and licensing cost. Worth it for privilege escalation, account freezes, and law-enforcement packages. Skip the dual lookup for routine dashboard widgets.
3. Age out and version-pin your databases
Stale MMDB files are a silent outage. Automate weekly or daily refreshes, alert when the build date is older than your SLA, and record the build ID on every lookup. After major cloud or ISP renumbering news, force an immediate refresh rather than waiting for the next cron.
Caveat: Fresh data still mislabels proxy and CGNAT space. Freshness reduces one error class; it does not create ground truth.
4. Rewrite "impossible travel" to "impossible session continuity"
Classic impossible-travel rules compare consecutive login cities and assume physical movement. Replace that with checks that combine geo with TLS fingerprint, device posture, IP type (residential, mobile, hosting, education), and auth method. A jump from Riyadh to Amsterdam in twelve minutes through a hosting ASN is interesting. The same jump through a corporate SASE egress is expected.
5. Build investigation checklists that start with infrastructure class
Before writing "actor located in X," classify the IP:
- Hosting or cloud provider
- Residential ISP
- Mobile carrier NAT
- VPN or proxy ASN
- University or enterprise egress
- CDN or anycast
Only after that classification should analysts weigh geo. For hosting and proxy classes, treat country as the location of the provider footprint. For mobile CGNAT, treat city as unreliable. For compromised public-sector or brand sites used in SEO and malware delivery, treat geo as a property of the victim infrastructure, not the operator.
How this changes day-to-day operations
SOC triage: Display country, ASN org, IP type, and geo confidence side by side. Hide city by default behind an "expand" control so junior analysts stop anchoring on a single misleading field.
Fraud and IAM: Score "hosting ASN from unexpected country" higher than "city mismatch on residential IP." Require step-up auth on proxy and hosting classes regardless of a matching home country.
Incident response and legal: When packaging evidence for counsel or law enforcement, state geolocation as "database X, version Y, country Z at time T" and explicitly note uncertainty for city-level claims. Overconfident geo language in affidavits and customer notices creates avoidable liability.
Threat intel consumption: Reports on regional campaigns such as Mirage Kitten activity across Middle East and Africa aviation and FinTech targets are useful for prioritization. They are weak grounds for assuming every related IP will geolocate inside those regions. Expect cloud, VPS, and proxy dilution.
A short validation exercise you can run this week
- Pull 500 recent auth or WAF events where your stack stored a city.
- Re-query the same IPs against a second provider and against current RDAP.
- Measure country agreement, city agreement, and disagreement by IP type.
- Sample twenty hosting and twenty mobile addresses and manually verify against provider documentation.
- Disable any automated control that fires solely on city mismatch if city agreement in your sample sits below your risk tolerance.
Most teams discover that country agreement stays high while city agreement collapses on mobile and cloud. That single measurement usually funds the policy change.
Actionable takeaways
- Use country and ASN as supporting signals. Keep city for humans, not for break-glass automation.
- Version and timestamp every geo lookup so stale data is visible in postmortems.
- Classify infrastructure before you interpret location, especially during campaigns that abuse local legitimate sites or residential proxies.
- Dual-source geolocation before account freezes, network blocks that affect customers, or external attribution statements.
- Rewrite travel and geo-anomaly detections around session and IP-type context so cloud staging and SASE egress stop generating false containment.
Geolocation remains valuable enrichment when you treat it as a map of network exits under active churn. The Brazilian SEO abuse case, regional targeting by groups such as Mirage Kitten, and proxy-backed malware distribution all reward teams that separate "where the packet left the internet" from "who ran the operation." Build your playbooks around that separation and geolocation stops steering investigations toward the wrong continent.
