The Gap Between Where the Packet Says It Came From and Where the Threat Actually Lives
In mid-2026, as P2P botnet activity continues to evolve and threat actors increasingly distribute command infrastructure across residential ISPs and cloud providers, IP geolocation remains one of the most misunderstood data points in a defender's toolkit. Security operations teams treat geolocation as fact during triage. Analysts cite country codes in incident reports. Firewall rules fire based on region tags. And yet the underlying accuracy of that geolocation data, under real operational conditions, is rarely tested against anything more rigorous than a quick sanity check on a known IP.
This article addresses the mechanics of how geolocation databases work, where they fail under adversarial conditions, and what that means for the security controls that depend on them. The goal is to give cybersecurity professionals and IT administrators a working mental model they can apply to actual alert triage, policy design, and threat investigation.
How IP Geolocation Actually Works
Most commercial and open-source geolocation databases derive their data from a combination of sources: Regional Internet Registry (RIR) allocation records, BGP routing tables, active probing, user-submitted corrections, and inference from associated infrastructure. Services like MaxMind GeoIP2, IP2Location, and ipinfo.io aggregate these signals into a database that maps IP ranges to geographic locations, typically at the country, region, city, and sometimes postal code level.
Accuracy degrades significantly as you move from country-level to city-level resolution. Country-level accuracy for most major commercial databases sits somewhere between 95% and 99% for well-documented IPv4 ranges. City-level accuracy drops to somewhere between 50% and 80% depending on the provider, the region, and how recently the data was refreshed. For IPv6 addresses, accuracy is generally lower across the board because adoption is uneven, RIR records are less complete, and many providers are still filling in gaps in their datasets.
The practical implication is that when your SIEM fires an alert tagged as originating from a specific city, that tag may be wrong in one out of every four or five cases, even with a reputable provider. That error rate compounds when attackers deliberately route traffic to influence how geolocation resolves.
What Adversaries Do to Manipulate Geolocation Signals
Threat actors with any degree of operational sophistication understand that defenders use geolocation as a quick filter. The ESET APT Activity Report covering Q4 2025 through Q1 2026 documents continued use of multi-hop infrastructure by advanced persistent threat groups, including deliberate selection of relay nodes in countries unlikely to trigger high-severity alert rules. This is not a coincidence. It reflects deliberate infrastructure choices made with defender tooling in mind.
Several manipulation patterns appear consistently across incident data:
- VPN and proxy chaining through geolocation-friendly regions: Attackers route traffic through exit nodes in countries with low threat scores in commercial reputation databases. The geolocation resolves cleanly, the reputation check passes, and the actual origin is several hops removed.
- Anycast and CDN abuse: Traffic served through or originating from anycast infrastructure can resolve to geolocation data tied to the anycast node rather than the actual client. Attackers exploiting CDN infrastructure or using anycast-aware attack tools benefit from this ambiguity.
- Recently reallocated IP space: IP address blocks that have changed hands between providers, or that were recently returned to an RIR and reallocated, frequently carry stale geolocation data. A block that spent five years assigned to a European ISP and was then reallocated to a hosting provider in Southeast Asia may still resolve to European geolocation in databases that update infrequently.
- Residential proxy networks embedded in P2P botnets: As documented in recent P2P botnet research, attackers increasingly route malicious traffic through compromised consumer devices. These devices carry residential ISP geolocation data, often resolving to the country and city of the device owner rather than the attacker. This is particularly effective against controls that trust residential IP ranges.
Each of these patterns produces geolocation data that is technically accurate for the IP address in question, but misleading about the actual threat origin. The distinction matters because defenders who act on the geolocation signal as if it reflects attacker origin will make systematically wrong decisions.
Where Geolocation Data Falls Apart in Practice
Consider a realistic scenario drawn from the kind of incident patterns that have been recurring through 2026. A phishing campaign targeting an organization's employees begins with reconnaissance traffic originating from IP addresses that geolocate to Western Europe. The organization's threat intelligence platform scores these IPs as low risk. Firewall policy allows traffic from the region without additional scrutiny. The actual attack infrastructure is a residential botnet spanning multiple continents, with the phishing kit hosted on a compromised residential connection in one country and the credential harvesting endpoint sitting behind a CDN that resolves to a third.
The geolocation data is accurate for every individual IP in the chain. But the chain itself obscures origin entirely, and no single geolocation data point reflects where the campaign operators are sitting. Defenders who use geolocation to make allow or deny decisions on that traffic will be working with data that has no meaningful connection to actual threat origin.
A second scenario involves access attempts against a corporate VPN portal. Logs show login attempts from IP addresses resolving to a country the organization considers low risk. The attempts use valid usernames paired with breached credentials from a credential stuffing list. The IPs are residential addresses in that country, assigned to legitimate ISPs, with no prior abuse history. Geolocation says the traffic is local. The traffic is actually being proxied through compromised devices in that country by an operator sitting elsewhere.
These scenarios are not edge cases. They reflect the way modern attack infrastructure is built, specifically to survive the filtering layers that most organizations have deployed.
What Geolocation Data Can and Cannot Tell You
Understanding where geolocation is actually useful requires separating what it measures from what defenders often assume it measures.
Geolocation tells you where an IP block is registered or allocated, where it appears to be routed, and sometimes where probing or inference suggests the associated infrastructure sits. It does not tell you where the person using that IP is located. It does not tell you whether the IP is being used as a relay. It does not tell you whether the registered location reflects the current use of the block.
What geolocation data is genuinely useful for:
- Flagging traffic from IP ranges with no plausible business relationship to your organization, as one signal among several.
- Supporting compliance requirements that mandate logging the apparent geographic origin of access attempts.
- Providing context during incident investigation that helps narrow down likely infrastructure regions, when combined with other data points.
- Identifying gross anomalies, such as a user account that has authenticated from one continent and then from another within a physically impossible time window (impossible travel detection).
What geolocation data should not be used for on its own:
- Making final allow or deny decisions for high-stakes access points without additional authentication or behavioral signals.
- Determining attacker origin during incident response without corroborating evidence from routing, ASN, hosting provider, and infrastructure pivot data.
- Assigning threat scores to IP addresses when the geolocation may reflect a residential proxy node rather than the actual origin of abuse.
How Database Freshness Affects Operational Accuracy
IP space is not static. Blocks are reallocated, providers merge, hosting companies expand into new regions, and mobile carriers reassign address pools continuously. Most commercial geolocation databases update on a schedule ranging from daily to monthly. Free or open-source databases may update less frequently. The gap between the current state of IP allocation and what your geolocation database reflects can be significant, particularly for cloud provider IP space, which changes rapidly.
In practice, this means that a block currently used by an attacker-friendly hosting provider in one region may still geolocate to a legitimate ISP in another region if your database is running on stale data. This creates false negatives in threat detection and false positives in allow rules, both of which benefit attackers.
The operational guidance here is straightforward. Know the update frequency of every geolocation database your security tooling depends on. For any security control that makes real-time decisions based on geolocation, use a database that updates at least daily. For threat intelligence enrichment in your SIEM or SOAR, cross-reference geolocation against current BGP routing data and current RIR allocation records, particularly when investigating IPs associated with hosting providers or cloud infrastructure.
IPv6 Geolocation Is a Special Problem
IPv6 geolocation deserves explicit attention because its accuracy problems are systematically worse than IPv4, and IPv6 adoption has reached the point where assuming all malicious traffic arrives over IPv4 is operationally incorrect.
Because IPv6 allocation is still maturing, many geolocation databases have incomplete coverage. Large blocks of IPv6 address space are either absent from geolocation databases entirely or mapped to country level only, with no city or region data. Some providers fall back to the RIR's registration address when no better data is available, which can result in traffic from an Asia-Pacific deployment of a cloud provider resolving to the United States because the provider's RIR registration address is in North America.
For security teams that are still primarily focused on IPv4 threat detection, this creates a blind spot. Attackers who route through IPv6 infrastructure benefit from weaker geolocation signals, lower representation in historical abuse databases, and detection stacks that were built and tuned against IPv4 traffic patterns. This is a concrete reason to treat IPv6 security gaps as an active operational problem rather than a future concern.
Building Controls That Account for Geolocation Uncertainty
Given the accuracy constraints above, the practical question is how to design security controls that use geolocation data productively without treating it as a reliable ground truth.
Layer Geolocation With ASN and Hosting Provider Context
Geolocation by itself is a coarse signal. Combining it with ASN data and hosting provider classification significantly improves signal quality. An IP that geolocates to Germany but is assigned to a known bulletproof hosting ASN is a different risk profile than an IP that geolocates to Germany and is assigned to a major German residential ISP. Most commercial threat intelligence platforms can provide this layered view, and building enrichment pipelines that pull ASN and hosting provider data alongside geolocation should be a baseline capability for any mature SOC.
Use Impossible Travel Detection as a More Reliable Geographic Signal
Comparing the geolocation of successive authentication events for the same account is more operationally reliable than using geolocation as a static filter. An account authenticating from Tokyo and then from London within four hours is an anomaly regardless of whether either individual geolocation is accurate. This approach uses geolocation comparatively rather than absolutely, which is more robust against the accuracy limitations described above.
Treat Geolocation-Based Firewall Rules as Noise Reduction, Not Access Control
Geolocation-based firewall rules are legitimate as a layer that reduces unwanted traffic volume. They should not be the primary mechanism for making trust decisions. For any access pathway that matters, authenticated identity, device posture, and behavioral signals should carry more weight than geolocation. This is particularly relevant for VPN portals, administrative interfaces, and API endpoints, all of which are high-value targets where geolocation-based trust has historically been exploited.
Validate Your Geolocation Provider Against Known Baselines
A practical step that most teams skip is periodically validating the accuracy of their geolocation provider against known data. Take a sample of IP addresses from your own infrastructure and from known partner organizations and check how your database resolves them. Compare against RIR records and BGP routing data. This gives you an empirical sense of the error rate you are working with, which is far more useful than the accuracy claims in the provider's marketing materials.
During Incident Response, Treat Geolocation as a Starting Point
When investigating a suspicious IP during an active incident, geolocation is the first clue, not the conclusion. From the geolocation tag, pivot to ASN data, WHOIS records, passive DNS, current hosting provider, and any available abuse reports. The ISC SANS Stormcast reporting from June 2026 continues to document incidents where defenders made incorrect attribution calls by stopping at geolocation rather than following the full pivot chain. The investigation discipline of treating every data point as a hypothesis to be tested rather than a fact to be accepted applies directly here.
Putting This Into Operational Context
The record-breaking Patch Tuesday for June 2026 is a useful reference point for why geolocation accuracy matters beyond the obvious filtering use cases. When defenders are triaging which exposed systems to prioritize patching based on observed exploitation attempts in their logs, geolocation data influences that triage. If the logs show exploitation attempts appearing to come from regions associated with lower threat actor activity, and those geolocation tags are inaccurate because the traffic is proxied through residential infrastructure, patching prioritization can be systematically skewed in the wrong direction.
Similarly, as phishing attack volume has declined but risk continues to rise, the remaining campaigns tend to be more targeted and more operationally sophisticated. These campaigns are precisely the ones most likely to use infrastructure designed to survive geolocation-based filtering. A team that has calibrated its alert thresholds around geolocation signals needs to account for the fact that the campaigns most likely to succeed are the ones that have already defeated those signals.
SMB security programs, which often rely more heavily on commercial geolocation-based blocking due to limited staffing and budget, face a specific version of this problem. Geolocation blocking is operationally accessible and provides real noise reduction, but it creates a false sense of coverage against targeted attacks that route through geolocation-friendly infrastructure. Building awareness of this limitation into how SMB security programs communicate risk to leadership is part of honest security posture management.
The Practical Summary
IP geolocation is a useful operational signal with well-documented accuracy constraints that get worse under adversarial conditions. Country-level accuracy is reasonable for well-documented IPv4 space. City-level accuracy is substantially lower. IPv6 accuracy is lower still. Attackers who understand how defenders use geolocation deliberately route through infrastructure that produces geolocation signals that bypass detection.
The controls that hold up under these conditions are the ones that use geolocation as one signal among several rather than a definitive data point. Layering ASN context, impossible travel detection, behavioral signals, and authenticated identity alongside geolocation produces a substantially more reliable picture than geolocation alone. Validating your geolocation provider's accuracy against known baselines and keeping database freshness within daily update cycles reduces the systematic error that stale data introduces.
During incident response, following the full pivot chain from geolocation to ASN to hosting provider to infrastructure context is the difference between accurate attribution and a confident wrong answer. The map tells you where the packet appeared to come from. Finding out where the threat actually originated requires the work that comes after the map.
