Geolocation and ASN Analysis: What an IP Address Really Tells You

The Most Overinterpreted Artifact in Security

Every alert has an IP in it, and every analyst is tempted to read a story into it. "Login from Russia." "Traffic to a server in the Netherlands." Both statements sound like intelligence. Neither one is, on its own.

An IP address tells you two reliable things: which network operator announced it, and roughly where that operator says it lives. Everything else, who is behind it, what they intend, whether the country label means anything at all, requires more work. This post covers what that work looks like.

Who Owns the Address: ASN Basics

The internet is a federation of roughly 100,000 autonomous systems (AS), each identified by an ASN and each announcing blocks of IP space via BGP. When you look up an IP, the ASN answers the question that matters most in triage: what kind of network is this?

$ whois -h whois.cymru.com " -v 203.0.113.7"
AS      | IP        | BGP Prefix     | CC | Registry | AS Name
64500   | 203.0.113.7 | 203.0.113.0/24 | NL | ripencc  | EXAMPLE-HOSTING, NL

That one line reframes the alert. An SSH brute-force source inside a consumer ISP's range is probably an infected home machine in a botnet. The same activity from a VPS provider's range is someone's rented attack box. Same behavior, different actor model, different response.

Network categories that matter

A login from a hosting ASN is one of the strongest cheap signals in account-compromise triage. Legitimate users sign in from residential, mobile, and corporate networks. They do not usually sign in from a freshly provisioned VPS.

ASN reputation and bulletproof hosting

ASNs accumulate reputations the way neighborhoods do. Most hosting providers process abuse reports and terminate offenders, so malicious tenancy is a passing condition. A small set of providers, so-called bulletproof hosters, sell abuse tolerance as the product: they ignore complaints, shuffle customers between prefixes, and re-register under new corporate shells when pressure mounts. Sanctions and takedowns have hit several such operations over the years, and the pattern that emerges from those cases is consistent: a small number of networks host a wildly disproportionate share of C2 servers, phishing kits, and malware distribution.

For triage, the practical takeaway is asymmetric. Traffic involving a known-dirty ASN deserves elevated suspicion. But the inverse is not safe: attackers happily operate from the biggest, cleanest clouds precisely because nobody wants to block them.

Where the Dot on the Map Comes From

Geolocation databases are built from registry allocation records, ISP-published data, latency measurements, and inference. Nobody triangulates your packet. Accuracy falls off a cliff as you zoom in:

• Country level: usually reliable, with real exceptions (addresses reassigned between regions, satellite and anycast ranges, stale registry data).
• City level: often wrong by tens or hundreds of kilometers. Mobile IPs may geolocate to the carrier's gateway in another region entirely.
• Street level: does not exist. The precise-looking coordinates many databases return are often just a country or city centroid. This has produced real-world harassment of people who happened to live at a default map pin, which is why default centroids were eventually moved to lakes.

Then there is deliberate distortion. VPNs, residential proxy networks, and Tor mean the geolocation answer describes the last hop, not the origin. A "login from France" through a residential proxy is an attacker renting a French home connection specifically so your geo-based rules stay quiet.

None of this makes geolocation useless. Country-level data drives sanctions compliance, impossible-travel detection, and coarse anomaly scoring perfectly well. It makes geolocation a network attribute, not a human location. Phrase your conclusions accordingly: "egress point in Germany," not "attacker in Germany."

Using IP Context in Triage

A repeatable enrichment pass for any IP that shows up in an alert:

1. Resolve the ASN and network type first. Hosting, residential, mobile, VPN, or Tor changes the meaning of everything else. This single field should gate your alert logic more than the country flag does.
2. Check anonymization explicitly. Tor exit lists are public. Commercial VPN ranges are well cataloged. If the IP is an anonymizer, stop interpreting its geography.
3. Look at the neighborhood. What else is on the same /24 or the same ASN? Fifty freshly registered domains on adjacent IPs tells a very different story than one flagged address inside a major cloud region.
4. Check shared-use before blocking. CDN edges, cloud load balancers, and CGNAT pools serve thousands of unrelated parties. Blocking them converts one alert into a week of connectivity tickets.
5. Add time. Passive DNS and hosting history reveal whether the address has been stable malicious infrastructure for months or was recycled from a legitimate tenant last Tuesday.

Doing this manually across five tabs gets old fast. Pasting the IP into mlab.sh returns the ASN, hosting classification, geolocation, and passive DNS in one view, and the same enrichment is available over the API if you want it applied at alert ingestion instead of during triage.

A worked example

An impossible-travel alert fires: a user authenticated from their usual city at 09:12 and from Singapore at 09:31. Naive read: compromised account, block the IP, reset the password.

Enriched read: the Singapore IP belongs to a major VPN provider's ASN, and the user's endpoint shows a corporate VPN client. The "travel" was the user toggling their VPN. Twenty seconds of ASN context saved a lockout, a reset, and an incident ticket.

Reverse case: a single successful OWA login from an IP in the user's home country, so no geo rule fires. The ASN is a VPS provider, the address was first seen hosting anything three days ago, and two lookalike domains of your company resolve to a neighbor in the same /24. The geography said "normal." The network context said "incident." The network context was right.

Geolocation tells you where a packet surfaced. ASN analysis tells you what kind of machine sent it. Triage on the second, decorate with the first.