When the Map Is Wrong: A Case That Went Sideways
A mid-sized financial institution's SOC team flagged a login attempt originating from a North Korean IP block. The analysts escalated immediately, blocking the address range and initiating a full incident response procedure. Sixteen hours later, after pulling in two senior engineers and drafting regulatory notifications, they discovered the traffic was coming from a Cloudflare edge node in Seoul that happened to share a subnet with DPRK-associated ranges in an outdated geolocation database. The actual attacker — whose tradecraft closely resembled North Korea's Lazarus Group, which has been increasingly targeting non-Windows environments including macOS users via techniques like ClickFix — was still active, pivoting through an entirely different IP block that the team had dismissed as domestic traffic.
This is not a hypothetical edge case. It is the kind of operational failure that happens weekly inside enterprise security teams that treat IP geolocation as ground truth rather than probabilistic signal. Understanding why geolocation fails — and exactly how far to trust it — is one of the most underappreciated skills in practical threat analysis.
How IP Geolocation Actually Works (And Where the Cracks Form)
Most geolocation services derive location data from a combination of sources: Regional Internet Registry (RIR) records like ARIN, RIPE, APNIC, LACNIC, and AFRINIC; BGP routing table announcements; active probing and latency triangulation; user-submitted corrections; and commercial data licensing agreements. Each source introduces its own error surface.
RIR Data Is Often Stale
When an organization acquires an IP block, they register it with an RIR. But organizations move, merge, sell IP space, or use addresses in geographically distant locations from their registration address. A block registered by a European multinational's Dutch headquarters might be actively routing traffic from data centers in Singapore and São Paulo. RIR data reflects administrative ownership, not physical routing location. Updates to registry records can lag real-world changes by months or years.
CDN and Cloud Provider Sprawl
Cloudflare, Akamai, Fastly, AWS CloudFront, and similar providers have edge nodes in dozens of countries, all potentially announcing the same IP ranges from multiple locations depending on anycast routing. A single Cloudflare IP might appear to be in Germany from one vantage point and in Singapore from another, depending on which BGP path your geolocation vendor is sampling. The growth of cloud infrastructure has made anycast routing the norm rather than the exception for significant portions of internet traffic.
VPN and Proxy Infrastructure
Commercial VPN providers, SOCKS proxies, and residential proxy networks actively obscure geolocation. A recent DFIR investigation into the SystemBC malware framework — documented in threat intelligence as a tool used by sophisticated ransomware operators — highlighted how modern proxy-as-a-service infrastructure allows attackers to exit traffic through residential IP addresses in virtually any country on demand. Residential proxies are particularly dangerous because their IPs are registered to real home users in real locations, meaning geolocation databases show accurate residential location data for an address being actively weaponized.
Database Freshness and Commercial Incentives
Geolocation database vendors update their records at different cadences — some daily, some weekly, some on quarterly commercial release cycles. MaxMind's GeoIP2, one of the most widely used databases, acknowledges city-level accuracy rates of roughly 80% for the US and significantly lower for many developing regions. Country-level accuracy is higher, typically in the 95–99% range for major vendors, but that remaining 1–5% at scale represents millions of incorrectly attributed connections per day across a large network.
The Accuracy Numbers You Should Actually Internalize
Before building any decision logic around geolocation, security teams should understand what the data can and cannot support statistically:
- Country-level accuracy: 95–99% for major commercial databases on non-proxied traffic. Sounds high until you realize that at 100 million daily authentications, a 2% error rate means 2 million misattributed sessions.
- Region/state-level accuracy: Typically 55–80%, highly variable by country. Western Europe and North America perform better. Southeast Asia, Africa, and Central Asia perform significantly worse.
- City-level accuracy: 50–75% in best cases, often far lower. Rural areas and small countries are especially unreliable. Treating city-level data as actionable for blocking or attribution is operationally risky.
- ISP/ASN attribution: Generally the most reliable layer — autonomous system number data tends to be accurate because BGP routing tables are a near-real-time source. ASN-level data is more trustworthy than geographic data for many threat intelligence use cases.
Where Geolocation Errors Actually Hurt Security Operations
Impossible Travel Detection
One of the most common uses of geolocation in identity security is impossible travel detection — flagging logins that appear to originate from two geographically distant locations within a timeframe that makes physical travel impossible. This is a genuinely useful signal, but geolocation errors create two failure modes: false positives that lock out legitimate users on VPNs or using split-tunnel configurations, and false negatives where attackers using proxies in the same country as the victim appear to be co-located.
The 0ktapus threat group, which compromised over 130 organizations through sophisticated phishing and session hijacking, frequently used US-based infrastructure to attack US-based targets. Impossible travel detection would have been useless against them — their infrastructure geolocated identically to their victims. Teams relying solely on geographic anomaly detection for session hijacking missed the attack entirely until credential abuse became visible through other behavioral signals.
Geofencing as a Security Control
Many organizations implement country-level IP blocking, allowing only traffic from specific countries to reach sensitive applications. This approach has merit for dramatically reducing attack surface, but its effectiveness is undermined by proxy infrastructure. Ransomware operators targeting enterprises rarely attack directly from their home country's IP space. Groups associated with nation-state operations routinely stage attacks through neutral third countries — the DFIR Report's analysis of SystemBC-based intrusions showed attackers regularly pivoting through Eastern European and Southeast Asian exit nodes regardless of their actual geographic origin.
Geofencing also creates operational challenges for organizations with globally distributed staff, legitimate business in sanctioned or high-risk regions, and for security researchers who need to access assets from multiple locations. Blocking at the country level requires rigorous exceptions management, and those exceptions frequently become the path of least resistance for attackers who spend time understanding an organization's access patterns.
Threat Intelligence Enrichment and Attribution
When an IP address appears in a threat feed or shows up in logs during an investigation, geolocation is often the first enrichment applied. But attribution errors compound quickly. An analyst who sees a malicious IP attributed to China might immediately frame their investigation around Chinese threat actor TTPs, potentially missing indicators that suggest a completely different actor profile. During the current period of heightened concern around critical minerals and cyber operations — where nation-state actors from multiple countries are targeting resource sector organizations — misattributing attack origin can lead analysts to pursue the wrong kill chain entirely.
Building a Geolocation-Aware Security Architecture
Treat Geolocation as One Signal Among Many
The most dangerous operational pattern is geolocation as a binary decision input. Geographic data should always be combined with other signals before triggering high-confidence actions like blocking or escalation. Useful corroborating signals include:
- ASN reputation and hosting provider classification (datacenter vs. residential vs. mobile)
- Time-of-day patterns relative to claimed location's business hours
- User agent and TLS fingerprint consistency
- Behavioral baseline deviation (typing cadence, click patterns, navigation sequences)
- Whether the IP is a known VPN exit, Tor exit, or proxy (separate detection problem, but correlated)
- Historical access patterns for the specific user or account
Use Multiple Geolocation Sources and Compare
No single geolocation database is authoritative. In high-stakes investigations, cross-referencing MaxMind against IP2Location, ipinfo.io, and BGP-based tools like Team Cymru's IP-to-ASN mapping gives you a confidence interval rather than a single data point. When multiple sources disagree on country or region, treat the location as unknown rather than defaulting to any single vendor's answer.
For real-time decisions like adaptive authentication, conflicting geolocation data should itself be treated as a risk signal — an IP that different databases place in different countries is almost certainly behind some form of proxy or load-balancing infrastructure.
Maintain Your Own Geolocation Overlay
Organizations with significant security maturity should consider maintaining internal geolocation enrichment that supplements commercial databases with organizationally specific knowledge:
- Known corporate VPN exit node IPs and their actual user base locations
- Office and branch network ranges with accurate physical location metadata
- Cloud workload IP ranges annotated with their deployment region
- Known good partner and vendor IP ranges with verified locations
This internal overlay, applied before or after commercial geolocation lookups, dramatically reduces false positive rates for the traffic patterns most relevant to your specific environment.
Differentiate Use Cases by Required Accuracy
Not all geolocation use cases require the same accuracy level. A practical framework:
- Country-level blocking for high-risk regions: Acceptable use of geolocation, but combine with ASN reputation data and accept that sophisticated attackers will bypass it. Use as a friction layer, not a security boundary.
- Impossible travel for session anomaly detection: Require significant geographic distance (cross-continental) before triggering high-confidence alerts. Single-country discrepancies should generate low-confidence signals only.
- City-level attribution in investigations: Treat as directional hypothesis only. Never present city-level geolocation as evidentiary in incident reports without corroborating technical data.
- ISP/ASN classification for risk scoring: Most reliable use case. Classifying traffic as datacenter-hosted, residential, or mobile ISP origin is significantly more accurate than geographic classification and provides more operationally meaningful risk context.
Geolocation in Specific Threat Scenarios
Ransomware Pre-Deployment Reconnaissance
Ransomware attack volumes continue to climb in 2026, and initial access brokers are a central part of the ecosystem. Access brokers — some of whom are reportedly selling access to compromised Chinese surveillance camera networks, which provide both reconnaissance capability and proxy infrastructure — specifically select exit infrastructure in countries that are unlikely to trigger geographic alert rules for their target organizations. A US company that blocks logins from Russia and China might still see initial access come through a Canadian residential proxy. Geolocation-based controls need to be understood as deterrents that change attacker tool selection, not as walls that stop attacks.
Romance Scam and Fraud Operations
Romance scammers and fraud operators running pig butchering operations invest heavily in appearing geographically local to their targets. Residential proxy providers sell location-specific exit nodes precisely because they defeat geolocation-based fraud controls. When investigating romance scam infrastructure — which increasingly requires a proactive approach to victim identification and outreach — analysts frequently discover that the operational IP addresses used for victim contact geolocate to the victim's own city or region, while the actual command infrastructure is located thousands of miles away.
Supply Chain and Third-Party Access
When a vendor or partner's access credentials are compromised, attackers often use infrastructure that geolocates near the vendor's headquarters to avoid triggering impossible travel alerts. Understanding that geolocation can be deliberately spoofed through proxy selection is essential for building third-party access monitoring programs that don't over-rely on geographic consistency as a legitimacy signal.
Practical Implementation Recommendations
For teams looking to recalibrate how geolocation data flows through their security controls, the following changes provide immediate operational benefit:
- Audit your SIEM correlation rules for any rule that uses geolocation as a sole trigger condition. Every such rule should have at least one additional corroborating condition before triggering high-priority alerts.
- Implement ASN classification alongside geographic lookup. A login from a datacenter ASN in Germany is a different risk profile than a login from a residential ISP in Germany, even if both geolocate identically. Most commercial threat intelligence platforms support ASN classification natively.
- Build geolocation uncertainty into your risk scoring model. Instead of binary location match/mismatch, assign a confidence weight to geographic signals based on whether the IP is datacenter-hosted, known proxy infrastructure, or appears in multiple databases with conflicting location data.
- Test your geolocation logic regularly. Use red team exercises or purple team simulations that include proxy infrastructure from multiple countries. Validate that your geographic controls behave as expected and document where they fail.
- Document geolocation confidence levels in incident reports. When geographic attribution is part of a post-incident report or regulatory notification, explicitly note the data source, its known accuracy rates, and whether attribution was corroborated by non-geographic signals.
The Honest Operational Conclusion
IP geolocation is useful. It is not reliable enough to be trusted alone, and its limitations are systematic rather than random — meaning the errors cluster in exactly the scenarios where attackers are most likely to be active. Nation-state-linked groups, ransomware operators, fraud networks, and access brokers all invest specifically in defeating geographic controls because those controls are so widely deployed.
The appropriate posture is to use geolocation as a friction-generating, hypothesis-generating signal that feeds into multi-factor risk scoring, while building the rest of your detection architecture on behavioral, protocol, and reputation signals that are harder to spoof than an exit node location. The teams that successfully caught early indicators of campaigns like 0ktapus or Lazarus Group intrusions were not primarily using geolocation — they were watching authentication patterns, credential reuse signals, and post-authentication behavior. Geography was context, not evidence.
Understanding what your geolocation data actually tells you — and what it doesn't — is not a limitation to work around. It is foundational knowledge for building security controls that hold up against adversaries who have already mapped your detection logic and planned their infrastructure accordingly.
