Autonomous Systems (AS) form the backbone of internet routing — each one representing a distinct network under unified control with its own routing policies. Whether you’re tracking threat infrastructure, performing attribution, or analyzing global traffic flows, understanding how ASNs work is essential.

This guide walks you through the key concepts and techniques for exploring Autonomous Systems. You’ll start by learning what ASNs are, who controls them, and how they’re categorized. Then, we examine the main data sources — WHOIS, RDAP, BGP collectors, and contextual platforms — that power ASN analysis. Finally, you’ll apply this knowledge through practical investigation methods using both command-line tools and web-based interfaces.

By the end, you’ll be equipped with a solid foundation in ASN lookups and discovery techniques to support cybersecurity research, OSINT workflows, and network intelligence.

What Is an Autonomous System (AS) and What Is an ASN?

Before we dive deeper, let’s clarify a few basic concepts:

Autonomous System (AS)

A group of IP networks and routers operated by a single organization that follows a unified routing policy and appears as a single entity in global routing.

Autonomous System Number (ASN)

A globally unique identifier used to distinguish one AS from another, assigned by Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIR).

IANA and the RIRs work together to coordinate the global distribution of IP address space and ASNs used for routing internet traffic.

Each autonomous system manages one or more blocks of IP addresses, known as prefixes.

Prefix

A block of IP addresses, written in CIDR notation, that shows which part of the IP space an Autonomous System manages and announces to the internet.

For example, 192.0.2.0/24 represents 256 IP addresses from 192.0.2.0 to 192.0.2.255.

Autonomous Systems announce their prefixes to the global internet using the Border Gateway Protocol (BGP). The ASN serves as a label indicating which AS is originating or forwarding a particular prefix. This connection between ASNs and prefixes forms the basis for global routing — it tells other networks where to send traffic for a given destination.

In practice, a single ASN might announce multiple prefixes, each covering different parts of its infrastructure or customer networks.

Who Runs an Autonomous System?

An autonomous system is typically created by organizations that need full control over how their internet traffic is routed. This includes internet service providers, large corporations, universities, and financial institutions that operate their own networks and connect to multiple upstream providers.

To register an autonomous system, the organization must apply for an ASN through the Regional Internet Registry responsible for their geographic area.

The applicant must demonstrate a valid technical reason, such as multihoming (connecting to two or more providers) or having a unique routing policy. Once approved, the ASN allows the organization to announce its own IP prefixes, establish BGP sessions with other networks, and participate in global internet routing as an independent entity.

Types of Autonomous Systems

Autonomous Systems can be categorized into four basic types based on how they connect and operate within the larger internet infrastructure:

• Stub (Simple) AS: A basic type of autonomous system that connects to only one other network. It does not carry traffic for others — just its own. The majority of autonomous systems are configured this way.
• Multihomed (Redundant) AS: Connects to multiple providers for resilience but does not carry traffic between them. Offers redundancy, not transit.
• Transit AS: Allows traffic from other autonomus systems to pass through. These are service providers or backbone networks that facilitate global internet routing.
• Internet Exchange Point (IXP): A physical facility where multiple systems (e.g., ISPs, CDNs) connect and exchange traffic directly. While not an autonomus system itself, it’s vital for efficient, low-latency routing between networks.

Transit systems and IXPs are especially critical — they influence how traffic flows, how resilient a network is, and how disruptions might ripple across regions. In security investigations, recognizing whether an IP belongs to a stub network, a transit provider, or an IXP can provide context about its purpose, reliability, and potential risk level.

Evolution of ASN Formats

Autonomous system numbers were originally structured as 16-bit values, allowing for a maximum of 65,536 unique identifiers. Of these, a range from 64512 to 65534 was reserved for private use — similar in concept to private IPv4 address ranges.

However, by the early 2000s, the rapid growth of the internet raised concerns that the 16-bit space would soon be exhausted. To address this, a 32-bit ASN format was introduced in RFC 4893 (May 2007), and further refined in RFC 6793 (December 2012). This upgrade expanded the total number of possible ASNs to over 4 billion. Within the new 32-bit space, a block from 4200000000 to 4294967294 is reserved for private use.

From around 2007, many systems supported a dual-format approach using the so-called ASDOT+ notation¹. Eventually, as of January 1, 2010, IANA and RIRs began assigning 32-bit ASNs by default.

Book Your Netlas Demo

Chat with our team to explore how the Netlas platform can support your security research and threat analysis.

ASN Data Sources

To analyze, monitor, or investigate ASN-related infrastructure, analysts rely on a range of data sources — from registration records to routing behavior and contextual metadata.

This chapter explores the most important protocols, platforms, and registries used to gather insights about ASNs.

WHOIS Protocol

The WHOIS protocol is one of the oldest and most widely used sources for retrieving information about autonomous systems. It provides registry-based data — that is, information recorded and maintained by Regional Internet Registries such as RIPE NCC, ARIN, APNIC, and others.

When you perform a WHOIS lookup for an ASN, you typically receive:

• The organization name that owns or operates the Autonomous System
• Administrative and technical contact information (email, phone, person or role object)
• Timestamps for when the ASN was registered or last updated

You should see a response like this (truncated for clarity):

% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

as-block:     13312-15359
organisation: Assigned by ARIN

ASNumber:   15169  
ASName:     GOOGLE  
RegDate:    2000-03-30  
Updated:    2012-02-24  
Ref:        https://rdap.arin.net/registry/autnum/15169  

OrgName:    Google LLC  
Address:    1600 Amphitheatre Parkway, Mountain View, CA, 94043, US  
Abuse Email: [email protected]  
Tech Email:  [email protected]  

This output comes from ARIN and shows that ASN 15169 is assigned to Google LLC. It includes the registration date, company name, and a link to the full RDAP record.

This data is useful for attribution, compliance checks, and basic ownership verification.

However, WHOIS has several limitations:

• Formats vary across RIRs, making automation or comparison difficult without additional parsing logic.
• The data is manually maintained, so it’s often outdated or incomplete.
• It does not provide routing visibility — you won’t see what prefixes an ASN is announcing or who its peers are.

Despite its shortcomings, WHOIS remains a foundational source for understanding the administrative side of ASN ownership. It’s often the first step when investigating an unfamiliar network on the internet.

RDAP: The Modern WHOIS Alternative

The Registration Data Access Protocol (RDAP) is the modern successor to the WHOIS protocol. It was designed to solve several of WHOIS’s long-standing limitations — including inconsistent formats, lack of structure, and limited support for internationalization or authentication.

Unlike WHOIS, which returns raw, free-form text, RDAP delivers structured JSON responses, making it easier for applications to parse, display, and automate lookups across different regional internet registries.

curl https://rdap.arin.net/registry/autnum/15169

RDAP returns a structured response like this (truncated for clarity):

{
  "handle": "AS15169",
  "name": "GOOGLE",
  "startAutnum": 15169,
  "endAutnum": 15169,
  "entities": [
    {
      "handle": "GOGL",
      "vcardArray": [
        "vcard",
        [
          ["fn", {}, "text", "Google LLC"],
          ["adr", {}, "text", ["", "", "1600 Amphitheatre Parkway", "Mountain View", "CA", "94043", "US"]],
          ["tel", {}, "text", "+1-650-253-0000"],
          ["email", {}, "text", "[email protected]"]
        ]
      ]
    }
  ]
}

While RDAP is more powerful and structured than WHOIS, many casual users still rely on WHOIS tools for quick checks. But if you’re building tools or performing large-scale analysis, RDAP is the better choice. RDAP is now the default lookup mechanism for many RIRs, including ARIN, RIPE, and APNIC.

For an up-to-date list of RDAP base URLs for various registries, you can refer to the IANA Registrar IDs registry.

Public BGP Collectors and Monitoring Tools

The Border Gateway Protocol (BGP)

is the core routing protocol of the internet — it’s how Autonomous Systems exchange information about which IP address ranges (prefixes) they can reach.

While WHOIS and RDAP provide ownership data, BGP tells us how networks are connected and how traffic flows between them.

What BGP Data Reveals:

• Which prefixes an ASN is announcing
• Which AS are directly connected (BGP peers)
• How routes are propagated (AS path)
• Hijacks or route leaks, such as an ASN suddenly announcing someone else’s IP range

This kind of visibility is crucial for network engineers, threat hunters, and researchers trying to understand how a given ASN interacts with the global internet.

Let’s take ASN 15169 (Google). A BGP collector might show:

Origin ASN: 15169
Prefix: 8.8.8.0/24
AS Path: 6939 15169
Peer AS: 6939 (Hurricane Electric)

This means AS15169 is announcing the 8.8.8.0/24 block, and it’s being passed to the world by AS6939 (a transit provider).

Public BGP collectors and monitoring tools for ASN data exploration are listed in the table below:

Limitations of BGP ASN Data:

• BGP is observational — what you see depends on where the monitor is located
• Private peering relationships may be hidden
• It doesn’t show ownership — that’s still the job of WHOIS/RDAP

Still, BGP data is invaluable for detecting anomalies, tracking infrastructure changes, and understanding how autonomous systems interconnect in practice.

Routing Policy Repositories

In addition to observing actual BGP routes, it’s sometimes useful to know what network operators intend to announce. This is where Internet Routing Registries come in.

Internet Routing Registries (IRRs)

are public databases where Autonomous System (AS) operators can declare their routing policies in advance.

These declarations are voluntary and typically include how the AS imports and exports traffic from peers and providers. They are written in a structured format using fields like:

• import – how the AS accepts routes from other networks
• export – how it advertises routes to others
• mp-import / mp-export – for multi-protocol (IPv6, VPN) routing rules

Network engineers and transit providers use this information to validate configurations, manage routing filters, and automate parts of BGP peering.

Here is an example request:

whois -h whois.radb.net AS15169

The response should looks like this:

aut-num:        AS15169
as-name:        Google
descr:          Google, Inc
import:         from AS-ANY   accept ANY AND NOT {0.0.0.0/0}
export:         to AS-ANY   announce AS-GOOGLE AND NOT {0.0.0.0/0}
import:         from AS1273   accept ANY
import:         from AS3356   accept ANY
import:         from AS6453   accept ANY
admin-c:        Google Network Engineering
tech-c:         Google Network Engineering
notify:         [email protected]
mnt-by:         MAINT-AS15169
changed:        [email protected] 20190626
source:         RADB
last-modified:  2023-11-13T15:56:40Z

What it means:

• AS15169 is accepting routes from major upstream providers like AS3356 (Lumen), AS6453 (Tata), and AS1273 (Vodafone).
• The import and export lines define how Google receives and advertises routes — for example, it announces AS-GOOGLE but filters out the default route (0.0.0.0/0).
• This record is published in the RADB IRR and is used by other networks to build filtering and routing policies.

Enrichment and Contextual Platforms

Beyond WHOIS, RDAP, and BGP data, there are several platforms that enrich ASN information with additional context — such as geolocation, hosting providers, DNS metadata, peering presence, or related infrastructure. These tools help analysts better understand what a network does, where it operates, and who runs it.

Common Use Cases:

• IP geolocation and ASN ownership lookup
• Linking ASNs to hosting/cloud providers
• Finding related domains, certificates, and IP ranges
• Understanding network role (CDN, ISP, university, etc.)

Popular enrichment platforms are listed in the table below:

These platforms are often used alongside traditional ASN sources to complete the picture — for example, identifying whether an IP range is hosted in the cloud, tied to a threat actor’s infrastructure, or part of a CDN.

Some of them offer bulk exports, APIs, or integrations with security tools and automation platforms.

Practical Guide to ASN Investigations

Let’s walk through practical techniques — using both CLI tools and web platforms — to identify ASN ownership, explore IP block metadata, and uncover related infrastructure.

IP-to-ASN Lookup Commands

To determine the ASN associated with a specific IP address, you can use a standard WHOIS query:

whois 23.192.228.80 | grep -i origin

This might return:

If your investigation starts with a domain, use dig to resolve it to IP addresses, then pass those to WHOIS:

whois $(dig +short example.com) | grep -i origin

That should work in theory — but in practice, my output looked like this:

OriginAS:
OriginAS:
OriginAS:
OriginAS:
OriginAS:
OriginAS:

This happens because ARIN, which handles IP registrations for North America, does not consistently populate the OriginAS field in WHOIS responses. It’s an optional field, and many network operators leave it blank.

Workaround #1: Team Cymru WHOIS Service

Team Cymru offers a purpose-built WHOIS service that reliably maps IP addresses to their originating ASNs:

whois -h whois.cymru.com 23.215.0.138

AS      | IP               | AS Name
20940   | 23.215.0.138     | AKAMAI-ASN1, NL

This method is fast, accurate, and works consistently even when standard WHOIS fails.

Workaround #2: Netlas CLI Tool

You can also use the Netlas CLI tool to retrieve detailed ASN data:

netlas host 23.215.0.138 --include whois.asn

ip: 23.215.0.138
source:
- availability: default
  id: 7106
  type: whois_ip
type: ip
whois:
  asn:
    cidr: 23.214.224.0/19
    country: US
    name: AKAMAI-AS
    number:
    - '16625'
    registry: arin
    updated: '2013-07-12'

The host command returns a rich YAML document by default (use -f json for JSON). The whois.asn section includes the announced IP block, ASN number(s), registry, country, and last update date — making it ideal for automation and enrichment pipelines.

ASN Owner Lookup Commands

Identifying who owns and operates a particular ASN is often the first step in network investigations. Whether you’re tracking a suspicious IP or mapping the infrastructure behind an online service, discovering the responsible organization provides essential context.

Once you’ve resolved an IP address to its ASN, the next step is to look up details about that ASN’s ownership: the organization name, contact points, registration data, and sometimes routing policies.

You can use RDAP to look up ownership records. For example:

curl "https://rdap.arin.net/registry/autnum/20940"

This returns structured JSON data, which includes:

• Organization name (e.g., Akamai Technologies)
• Contact info (admin and abuse contacts)
• ASN registration and update dates
• Linked entities and vCard details (phone, email, address)

Alternatively, traditional WHOIS still works with some RIRs:

aut-num:        AS20940
as-name:        AKAMAI-ASN1
org:            ORG-AT1-RIPE
import:         from AS9126 accept ANY
import:         from AS6805 accept AS-MWAYS
import:         from AS12755 accept ANY
...
export:         to AS9126 announce AS-AKAMAI
export:         to AS12755 announce AS-AKAMAI
...
admin-c:        NARA1-RIPE
tech-c:         CDAK23-RIPE
abuse-mailbox:  [email protected]
mnt-by:         AKAM1-RIPE-MNT
source:         RIPE

organisation:   ORG-AT1-RIPE
org-name:       Akamai International B.V.
country:        NL
address:        145 Broadway, Cambridge, MA 02142, US
phone:          +1-617-4443000

The same — and even more — information can be retrieved from the Netlas database. Let’s explore what’s available in the .whois field using the Netlas CLI:

netlas host 23.215.0.138 --include whois

You’ll get rich, structured data like:

ip: 23.215.0.138
organization: Akamai Technologies, Inc. (AKAMAI)
source:
- availability: default
  id: 7106
  type: whois_ip
type: ip
whois:
  abuse: [email protected]
  asn:
    cidr: 23.214.224.0/19
    country: US
    name: AKAMAI-AS
    number:
    - '16625'
    registry: arin
    updated: '2013-07-12'
  ip:
    gte: 23.214.224.0
    lte: 23.215.8.255
  net:
    address: 145 Broadway
    cidr:
    - 23.192.0.0/11
    city: Cambridge
    contacts:
      emails:
      - [email protected]
      - [email protected]
      phones:
      - +1-617-444-2535
      - +1-617-274-7134
      - +1-617-444-0017
    country: US
    created: '2013-07-12'
    description: Akamai Technologies, Inc.
    end_ip: 23.223.255.255
    handle: NET-23-192-0-0-1
    name: AKAMAI
    net_size: 2097151
    organization: Akamai Technologies, Inc. (AKAMAI)
    postal_code: '02142'
    range: 23.192.0.0 - 23.223.255.255
    start_ip: 23.192.0.0
    state: MA
    updated: '2013-08-09'
  related_nets: []

This data is far more than just ASN lookup — it includes:

• The full IP allocation range and associated network block
• Organization name, address, and abuse contacts
• All known contact emails and phone numbers
• Registry and allocation timestamps
• ASN metadata and CIDR alignment

This level of detail makes Netlas ideal for infrastructure attribution, alert triage, and enriching threat intelligence pipelines.

Web ASN Lookup Tools

If you prefer browser-based tools over command-line utilities, several platforms offer intuitive interfaces for ASN lookups, network ownership research, and IP block exploration.

Below are the most useful free tools for practical ASN investigations.

Netlas

https://netlas.io

Netlas allows users to query ASN-related data by IP address, ASN number, or organization name. The platform provides a structured output that includes:

• ASN number and name
• IP block (CIDR), country, and registry
• WHOIS contact information, including abuse contacts
• Related domains, certificates, and services hosted within the ASN

In addition to raw data, Netlas also shows historical records and connected infrastructure, enabling quick pivoting across multiple data points.

IPinfo.io

https://ipinfo.io

IPinfo.io offers quick lookup functionality for IP and ASN information, showing:

• ASN number, owner organization, country
• IP geolocation (city, region, latitude/longitude)
• Provider and hostname details
• Abuse and technical contact emails (with API plan)

It’s especially useful for geolocation context or integrating ASN data into larger threat intelligence workflows.

Hurricane Electric BGP Toolkit

https://bgp.he.net

A popular tool for viewing BGP routes, ASN details, and peering relationships. Users can:

• Search by IP or ASN to reveal prefix advertisements, route paths, and peers
• Explore IPv4 and IPv6 data, upstream/downstream ASNs, and historical BGP activity
• Browse reverse DNS, IRR records, and Internet Exchange Points (IXPs)

It is particularly useful for understanding an ASN’s routing policy and reachability.

BGPView

https://bgpview.io

BGPView offers a well-organized view into ASN and IP allocation data, including:

• ASN descriptions, prefix lists, and registry metadata
• Country, allocation date, total allocated IPs
• Peer relationships, traffic estimates, and IX presence
• JSON-formatted API for programmatic use

Each IP or ASN query yields a clear breakdown of how resources are distributed and advertised.

Team Cymru IP to ASN Mapper

https://v4.whois.cymru.com

Team Cymru provides both command-line and web-based IP-to-ASN mapping tools. The web version lets users:

• Enter a single IP or prefix to retrieve the associated ASN
• View origin ASN, allocation country, and registry data
• Use for cross-checking when WHOIS data lacks ASN details

Team Cymru’s database is updated frequently and is known for high accuracy.

Conclusion

Autonomous System investigation is a core part of understanding and mapping any organization’s internet-facing infrastructure. This guide has walked through key techniques for ASN resolution, ownership discovery, and infrastructure attribution — all of which are foundational steps in a broader attack surface management workflow.

Whether you’re tracing a suspicious IP, uncovering cloud or CDN infrastructure, or enriching threat intelligence pipelines, ASN metadata reveals how networks are structured and who controls them. By combining structured data with historical records and registry metadata, you gain a much richer understanding of how assets are distributed across the internet.

For those looking to go further, we recommend the Complete Guide on Attack Surface Discovery. It provides a holistic framework for identifying and mapping your full digital footprint, helping you uncover vulnerabilities, assess risk, and implement effective defenses.