ASN Hijacking: Why IP Geolocation Data Lags
ASN hijacking, more precisely BGP route hijacking, happens when a network announces IP prefixes it is not authorized to originate, or announces them in a way that makes other networks send traffic toward it. Because IP geolocation and ASN datasets are built on periodic snapshots, they generally do not show a hijack while it is happening.
How a BGP hijack works
Every network on the internet is identified by an Autonomous System Number (ASN) and uses the Border Gateway Protocol (BGP) to tell its neighbours which prefixes it can reach. BGP was designed around trust: by default, a neighbour that receives an announcement has no built-in way to check that the announcing network really owns the prefix. Routers then pick the best path using rules such as shortest AS path and, above all, longest prefix match.
That last rule is what attackers and misconfigurations exploit. If a legitimate network announces a /22, and someone else announces a more specific /24 inside it, routers that accept the /24 will prefer it, because the more specific route wins. Traffic for those 256 addresses flows to the wrong network. Variants include originating someone else's prefix outright, forging part of the AS path, and leaking routes that should have stayed internal. Many real incidents are accidents, such as a customer leaking a full table to an upstream, but the effect on traffic is the same.
What happens to the traffic
An attacker who attracts traffic can drop it (a blackhole), inspect it, or relay it onward to the real destination so users notice nothing but a slight delay. Encryption limits the damage for content protected by TLS, though hijacks have also been used to obtain certificates by intercepting domain validation traffic, and to intercept DNS. Duration varies from minutes to hours, which is exactly why detection speed matters.
Why geolocation and ASN datasets lag
Geolocation and ASN-to-prefix datasets are compiled from registry data, routing snapshots and other sources, then published as versions. They answer "who normally holds this range" rather than "who is announcing it this minute". On ipto, the IP and ASN datasets refresh daily and the threat feeds every 6 hours, so a hijack lasting an hour will usually have started and ended between refreshes. During the incident, a lookup of an affected address will most likely still show the legitimate owner, which is the correct answer to the question the dataset is designed for.
Two further effects add to the lag. Registry records change slowly, so an address block does not move organizations because of a routing event. And a geolocation database inferring a city from a prefix does not re-infer it every time the route changes. If anything, the stable data is useful as a baseline: it tells you who should be originating a prefix, which is the thing you compare against live routing data.
How to check for suspicious routing
- Know the expected origin. The ASN lookup shows the registered owner, organization, country and number of ranges for an AS number, and the IP range directory lets you browse which networks hold a given /8 or /16 block.
- Check the registration. The IP whois lookup returns the registry record via RDAP, including the abuse contact you would notify.
- Validate route origin. The RPKI lookup checks live, through RIPEstat, whether the route currently announced for an IP is covered by a valid Route Origin Authorization. A result of valid, invalid or not covered is reported.
Interpret the RPKI result carefully. An "invalid" result means the origin AS or prefix length does not match what the owner authorized, which deserves investigation. "Not covered" only means no ROA exists, which is common and not proof of a hijack. RPKI also does not protect against every attack, such as forged AS paths that keep the correct origin. Operators who publish ROAs and filter on them reduce exposure, and monitoring services that alert on unexpected origins for your prefixes give faster notice than any dataset refresh.
What this means for applications
If your application uses ASN or geolocation data for decisions such as fraud scoring or region rules, treat it as slowly changing context and not as proof of where a connection physically terminates. The ipto IP lookup returns asn and org fields, and you can read the response format in the API documentation. A sudden change in the network a known customer connects from is a useful signal, but a hijack is one of many possible explanations, and most such changes are mundane: a new ISP, a mobile handover or a VPN.