The Gap Between Where an IP Says It Is and Where the Threat Actually Lives
On July 20th, a fresh threat intelligence report circulated among security operations teams highlighting a pattern that seasoned analysts recognized immediately: attackers coordinating watering hole campaigns, including those pushing keyloggers like ScanBox, were using infrastructure that geolocation databases consistently placed in the wrong country. In some cases, the discrepancy was several thousand miles. In others, the misattribution placed attacker infrastructure inside trusted geographic regions, allowing traffic to pass filters that should have caught it at the perimeter.
IP address geolocation is one of the most frequently cited tools in a security team's analytical toolkit. It appears in SIEM dashboards, threat intelligence platforms, fraud detection workflows, and access control policies. Yet the accuracy of that data varies significantly depending on the database vendor, the age of the data, the type of IP address involved, and whether the address belongs to infrastructure that was designed to obscure its real location. Understanding precisely where geolocation data is reliable, where it degrades, and how to compensate for its limitations is a practical necessity for any cybersecurity professional making decisions based on it.
How IP Geolocation Data Gets Built and Why That Process Creates Accuracy Ceilings
Geolocation databases are assembled from multiple sources: Regional Internet Registry (RIR) allocation records from ARIN, RIPE, APNIC, LACNIC, and AFRINIC; BGP routing table announcements; active network probing; user-submitted corrections; and commercial data licensing agreements. No single source covers the full address space with equal precision, and the quality of data degrades at different rates depending on the region and the type of address block.
RIR allocation records are the most authoritative starting point. When an organization registers an IP block, the registration includes a country of the registrant. This is the country field that most databases use as a baseline. The problem is that registration country and operational country frequently diverge. A multinational corporation headquartered in Germany might register address blocks through its US subsidiary. A cloud provider might hold allocations registered in one country while serving customers on physical infrastructure spread across dozens of countries. A content delivery network might announce the same prefix from multiple geographic locations simultaneously.
BGP routing data adds another layer. Analysts can identify which Autonomous System announces a given prefix and roughly where the AS peering points are. But BGP routing is designed for reachability, not location precision. A single AS can span continents, and the country listed in the AS registration may have little relationship to where a specific IP is actively being used at any given moment.
Active probing, where vendors send packets toward IP ranges and measure latency triangulation, improves city-level accuracy for some address blocks. But this method is expensive to run at scale, creates its own privacy considerations, and produces results that go stale quickly as providers reassign address space.
Accuracy Benchmarks Worth Understanding Before You Build Policy Around Them
Independent accuracy studies on commercial geolocation databases consistently show that country-level accuracy sits somewhere between 92 and 98 percent depending on the vendor and the region of the world. That sounds reassuring until you work through what it means operationally. If your organization processes a million connection attempts per day and your geolocation database has a 4 percent country-level error rate, you are looking at approximately 40,000 misclassified connections daily. Some of those errors will block legitimate traffic. Others will pass traffic that should have been flagged.
City-level accuracy drops considerably, typically falling to somewhere between 50 and 75 percent depending on the vendor and whether you are measuring within dense urban networks or more rural infrastructure. For use cases where city-level precision matters, such as fraud detection workflows that use location consistency to assess whether a login is plausible given a user's established patterns, this level of error is significant and needs to be factored into confidence thresholds explicitly.
Accuracy also varies substantially by region. Networks in Western Europe and North America tend to have better geolocation coverage because they have more granular RIR records, more active probing coverage, and more historical data. Networks across parts of Africa, Southeast Asia, and the Middle East have systematically lower accuracy because the data ecosystem is thinner and routing architectures sometimes reflect historical infrastructure patterns rather than current usage.
Infrastructure Categories Where Geolocation Accuracy Collapses
Several categories of IP infrastructure produce geolocation data that is structurally unreliable regardless of which database vendor you use.
Cloud Provider Address Space
Cloud providers reassign IP addresses constantly. An address that hosted a legitimate customer workload in Virginia yesterday might be assigned to a different customer in a different region today. Geolocation databases struggle to keep pace with this reassignment velocity. More importantly, cloud providers like AWS, Azure, and Google Cloud operate global networks where traffic originating in one geographic region frequently exits through infrastructure in another. An attacker running tools from a cloud instance in Singapore may appear to be located wherever that provider's egress infrastructure happens to be, which may not be Singapore at all.
When security teams see cloud provider IP ranges in their logs, the geolocation data is one signal among several rather than a definitive attribution point. The AS number and the provider identity often carry more actionable information than the country label in this context.
VPN and Proxy Infrastructure
Commercial VPN providers maintain servers in dozens of countries. An attacker connecting through a VPN endpoint in the Netherlands appears to originate from the Netherlands regardless of where they are physically located. Residential proxy networks are more sophisticated still. These networks route attacker traffic through legitimate residential internet connections, meaning the geolocation database correctly identifies the exit IP as a residential address in whatever country that subscriber lives in. The geolocation is accurate. The inference that the traffic is therefore legitimate is the failure point.
This is directly relevant to campaigns like the ScanBox watering hole activity documented in recent threat intelligence reporting. Attackers running these campaigns often route their infrastructure management and payload delivery through geographic regions that appear low-risk to defenders, specifically to avoid triggering geo-based filters.
Mobile Carrier Address Space
Mobile carriers use centralized network gateways that serve subscribers across wide geographic areas. A mobile user physically located in Edinburgh may connect through a gateway infrastructure that geolocates to London or Manchester. Carriers also use CGNAT (Carrier-Grade Network Address Translation) extensively, meaning thousands of subscribers share a single IP address. Any geolocation assigned to that address reflects the carrier's infrastructure location rather than any individual user's physical location.
Satellite and Emerging Connectivity
Low-Earth orbit satellite internet services introduce a new accuracy problem. The IP addresses assigned by providers like Starlink may geolocate to data center infrastructure rather than to the physical location of the ground terminal. As satellite connectivity expands into regions that previously had limited coverage, security teams will encounter more traffic where the geolocation is technically accurate for the service infrastructure but meaningless for understanding where the connection actually originates.
Operationalizing Geolocation Data Without Overfitting to It
Security teams that treat geolocation as binary, either trusting or blocking based on country labels alone, consistently generate both false positives and false negatives that weaken their defensive posture. The more defensible approach is to use geolocation as one weighted input within a broader risk scoring model.
Layering Geolocation with AS and Provider Context
The Autonomous System Number associated with an IP address often provides more stable and useful context than the country label. An AS registered to a residential broadband provider in Brazil behaves differently than an AS registered to a known hosting provider or VPN service, even if both geolocate to the same country. Security information and event management platforms should normalize AS data alongside geolocation data so analysts can distinguish between traffic that genuinely originates in a given region and traffic that merely exits through infrastructure registered there.
For practical implementation, this means maintaining enrichment pipelines that pull AS organization names, AS categories where available from commercial providers, and historical abuse data associated with specific AS numbers. This combination gives you a more accurate picture than country-level geolocation alone.
Consistency Checks Against Historical Patterns
For authenticated services, particularly those with established user populations, behavioral consistency is a stronger signal than raw geolocation accuracy. If a user account has authenticated exclusively from UK-registered ISP addresses for 18 months and suddenly authenticates from a Kazakhstani hosting provider, the geolocation discrepancy is meaningful in context. Without that historical baseline, the same IP might produce no useful signal at all.
Building user-level and device-level geolocation baselines requires storing enriched authentication telemetry over time. Many organizations store authentication events without preserving the enriched location and AS data, which means the baseline is never built. The practical fix is enriching authentication logs at ingest time and retaining that enriched data for at least 90 days to establish a meaningful behavioral window.
Confidence Intervals in Access Control Decisions
Access control policies that enforce hard geo-blocks introduce operational friction when the geolocation data is wrong. A more resilient approach assigns a geolocation confidence score rather than a binary location label and uses that score to determine the level of additional verification required rather than the access decision itself. A connection from a country that geolocates as high-risk but where your database has known accuracy limitations might trigger step-up authentication rather than a block. A connection from a known VPN exit node might require hardware token verification regardless of what country the exit node geolocates to.
This approach requires coordination between security and identity teams, but it reduces the rate at which legitimate users are incorrectly blocked while maintaining meaningful friction for suspicious sessions.
Threat Intelligence Integration and the Freshness Problem
Threat intelligence feeds that include IP-to-location mappings carry their own freshness constraints. An IP address identified as malicious and located in a specific country three months ago may have been reassigned to a different operator in a different region today. Dynamic IP address reassignment is common in consumer broadband and cloud environments. Teams consuming threat intelligence with embedded geolocation data need to verify that the location data is being refreshed at a cadence that matches the reassignment velocity of the infrastructure type involved.
For cloud provider IP ranges, location data can go stale within days. For allocated but less frequently reassigned enterprise blocks, the data might remain accurate for months. Building a threat intelligence workflow that applies different staleness thresholds by infrastructure type produces more accurate results than applying a single expiration window to all ingested IP data.
The WSzero DDoS family, now in its fourth version and reportedly using 21 different vulnerabilities for propagation, illustrates this challenge concretely. Botnet infrastructure of this sophistication changes IP addresses and providers frequently, specifically to defeat reputation-based blocking. Geolocation data that was accurate when the botnet first established a C2 node may be pointing to decommissioned infrastructure by the time that data reaches a defender's SIEM.
Where SMBs Face a Different Set of Constraints
Guidance focused on cyber readiness for smaller organizations consistently highlights that SMBs use geolocation data differently than enterprise teams, often because they have fewer resources to layer multiple intelligence sources together. An SMB using a firewall or cloud security service that enforces geo-blocks is typically relying on the vendor's geolocation database without visibility into that database's accuracy characteristics or update frequency.
For these environments, the practical recommendation is to request from vendors a clear statement of their geolocation database source, update frequency, and known accuracy characteristics by region. Vendors that cannot or will not provide this information are offering geolocation-based controls that are difficult to evaluate. Additionally, SMBs should understand that geo-blocking inbound traffic does not address threats that originate within the allowed geographic regions, which includes most credential stuffing, phishing infrastructure hosted in US and EU cloud providers, and a substantial portion of financially motivated attack traffic.
Forensic Use Cases and the Retrospective Accuracy Problem
Incident response workflows frequently involve retrospective geolocation of IP addresses observed during an attack. The challenge is that geolocation databases reflect the current state of IP allocation and routing, which may differ from the state at the time of the incident. An IP address that hosted attacker infrastructure six months ago may now be assigned to a completely different organization and geolocate differently than it did during the event.
For forensic accuracy, incident responders should use geolocation data sources that provide historical allocation records rather than only current state. Some commercial providers offer historical data products specifically for this use case. When these products are unavailable, cross-referencing current geolocation against archived BGP routing data from sources like RouteViews or RIPE RIS can help reconstruct where an address was being routed at the time of an incident.
RIR WHOIS history, where available, provides similar retrospective context for registration records. Documenting the geolocation data used in an investigation and the date it was queried is good practice regardless of the tools available, because it preserves the investigative basis for conclusions drawn at the time rather than allowing later data changes to retroactively alter the record.
Calibrating Geolocation Into Your Detection Stack
The most effective use of geolocation data in security operations comes from treating it as a probabilistic input with explicit confidence bounds rather than a definitive attribute. This means documenting the accuracy characteristics of the databases you use, building enrichment pipelines that layer geolocation with AS data, provider type, and abuse history, and constructing detection logic that weights geolocation according to its reliability for the infrastructure category involved.
For authentication and access control, supplement geolocation with behavioral consistency checks. For threat hunting and incident response, use geolocation as a starting hypothesis to be validated against routing and registration data rather than a conclusion. For policy-based geo-blocking, apply additional verification steps rather than hard blocks where database accuracy is lower, and maintain a process for users to escalate when blocks are triggered incorrectly.
Geolocation data will continue to be a useful signal in security operations as long as teams understand its precision limits and build workflows that compensate for them. The operational failure mode is not using geolocation data. It is using it without knowing how accurate it actually is for the specific traffic categories and geographic regions your environment encounters most frequently.
