asnmap: from an organization name to a list of CIDR ranges

Four ways in: ASN, IP address, domain or organization

asnmap takes a target that identifies a network operator and returns the address space that operator holds. What is unusual is the range of ways you can name that operator. The feature list names four lookups: ASN to CIDR, ORG to CIDR, DNS to CIDR and IP to CIDR, and the input flags cover the same ground with short and long forms.

The organization lookup is the one that catches people out, because it is a name match rather than a number. The example in the project documentation is a bare uppercase organization name, and the tool resolves it to every range that belongs to it. The four documented input shapes look like this:

asnmap -a AS45596 -silent
asnmap -i 100.19.12.21 -silent
asnmap -d hackerone.com -silent
asnmap -org GOOGLE -silent

A domain lookup is the case most people will use, and it works the same way in reverse. The tool resolves the name, finds the autonomous system behind the address it lands on, and hands back the ranges registered to that system. That is a different answer from a reverse DNS lookup, and a much bigger one. A single address can sit inside a range that covers thousands of hosts, which is the entire reason the tool exists.

Input also arrives on standard input, and the usage section is explicit that standard input accepts every supported format. Single values, comma separated lists and a file of targets are all accepted by the same options, so the tool fits either a one line command or a bulk list without changing shape.

The default output is a bare list of CIDR ranges

Run without a format flag, asnmap prints the CIDR ranges it found, one per line, with nothing else on the line. This is the shape you want if the next thing in the pipeline consumes address ranges, because it is the shape that pipes cleanly. The documented run for an organization prints a set of blocks like these:

8.8.4.0/24
8.8.8.0/24
8.35.200.0/21
34.3.3.0/24
34.4.4.0/24
34.96.0.0/20
34.96.32.0/19
34.96.64.0/18
34.98.64.0/18
34.98.136.0/21
34.98.144.0/21

Before the results, the tool prints a banner with the project name and a caution line saying that you are responsible for your actions and that the developers assume no liability for misuse or damage. The banner carries a version string, which in that sample reads v0.0.1 even though the newest published release is v1.1.1 from 2024-06-27, so do not read the banner number as the release you have installed.

One detail catches new users. IPv6 ranges are not part of the default command line output. A separate -v6 flag exists to display IPv6 CIDR ranges in the CLI output, and the JSON format shows them as their own entries. If your workflow covers IPv6, you need that flag or the machine readable output.

JSON output names the autonomous system, the country and the ranges

The JSON format is where the real information sits, and the usage section is clear that all of the information is always available in it. The -json flag is the convenient option for automation and post processing, and the output can be piped straight into a JSON formatter:

echo hackerone.com | ./asnmap -json -silent | jq

Each record carries a timestamp, the input that produced it, the AS number, the AS name, the AS country and the range list. In the documented example, the domain hackerone.com resolves to AS13335 with the name CLOUDFLARENET in the US, and the ranges are a set of /14, /16 and /17 blocks, with the IPv6 range arriving as a separate record rather than being folded into the same list.

{
  "timestamp": "2022-09-19 12:14:33.267339314 +0530 IST",
  "input": "hackerone.com",
  "as_number": "AS13335",
  "as_name": "CLOUDFLARENET",
  "as_country": "US",
  "as_range": [
    "104.16.0.0/14",
    "104.20.0.0/16",
    "104.21.0.0/17"
  ]
}

The CSV format carries the same fields with a header row, and the ranges are packed into one comma separated cell:

timestamp|input|as_number|as_name|as_country|as_range
2022-09-19 12:15:04.906664007 +0530 IST|hackerone.com|AS13335|CLOUDFLARENET|US|104.16.0.0/14,104.20.0.0/16,104.21.0.0/17
2022-09-19 12:15:05.201328136 +0530 IST|hackerone.com|AS13335|CLOUDFLARENET|US|2606:4700:9760::/44

The separator is a pipe rather than a comma, which is what lets the range cell keep its commas. A script that assumes a comma separated file will get it wrong, so read the header before writing a parser.

A cloud API key now sits between you and the answer

The CLI is built on top of the ASNMap API, and that API requires an API token from the ProjectDiscovery Cloud Platform. The token can be supplied as an environment variable:

export PDCP_API_KEY=*************

or entered interactively with the -auth option, which prints the banner and then prompts for the key:

asnmap -auth

Once a key is present the tool logs in and reports the account it logged in as. There is also an -up flag to update asnmap to the latest version and a -duc flag to disable the automatic update check, which matters in scheduled jobs where a network call to a version endpoint is noise.

This is the sharpest change for anyone who used the tool earlier. A lookup that used to be a local table lookup is now a request to a hosted API, and the key becomes a runtime dependency of the tool rather than an optional convenience. The documentation does not describe a local fallback or an offline mode, so a machine that cannot reach the service, or a key that has expired or hit a quota, produces no ranges at all. There is also a -config flag for a path to an asnmap configuration file, and a -r flag to set the resolvers to use, which is the one knob for the resolution step itself.

Installing it means one go install line and a Go version mismatch

The installation section is short. asnmap requires Go 1.21 to install successfully, and the tool is installed with the standard Go install command for the command package:

go install github.com/projectdiscovery/asnmap/cmd/asnmap@latest

The documentation also points to the release page for pre-compiled binaries, which is the faster route when you only need the CLI and not the library.

There is a version mismatch here worth catching before you start. The go.mod file in the repository declares go 1.24.0, while the installation section names Go 1.21 and the Dockerfile builds on the golang:1.21.4-alpine base image. The module declaration is the one the Go toolchain enforces, so a machine with Go 1.21 installed may refuse to build the current source even though the installation section says that version is enough. The Dockerfile also installs build tooling and build-base in the builder stage, compiles ./cmd/asnmap, and copies the binary into an alpine:3.18.0 runtime image with bind-tools and ca-certificates added, with the entrypoint set to the binary itself.

The repository root holds a Makefile with three targets: cli, which builds ./cmd/asnmap/ with the flags stripped of debug information, test, which runs the Go test runner over the whole module, and tidy. The test target calls a variable that is not defined among the Makefile variables shown, so that part of the target expands to nothing and the cache flag is passed straight to the test command. If you plan to run the tests, check that line first.

The output is designed to be the input of the next command

The usage section is explicit that asnmap output can be piped directly into other projects whose workflow accepts standard input, and it lists the combinations:

echo AS54115 | asnmap | tlsx
echo AS54115 | asnmap | dnsx -ptr
echo AS54115 | asnmap | naabu -p 443
echo AS54115 | asnmap | naabu -p 443 | httpx
echo AS54115 | asnmap | naabu -p 443 | httpx | nuclei -id tech-detect

Each of those steps changes the size of the target set. asnmap turns one organization or ASN into a set of network ranges, naabu turns ranges into reachable hosts on a port, httpx turns those hosts into responses, and nuclei applies checks to the responses. The first step is the one that multiplies the search space, which is why a range level tool has a place in the chain even though a domain level tool gives a smaller, more precise answer.

The alternative to asnmap is not another tool, it is a different question. If you need the addresses of one host, resolve it and read the answer. If you need every range an operator has registered, the realistic options are an IP geolocation or ASN database you query yourself, or the routing registry data, and in both cases you write the lookup and the merge yourself. asnmap is the option where someone has already written that code, added four input shapes, and made the result a single line of text that the rest of your pipeline can read.

The project is MIT licensed, so the code carries no copyleft obligation if you embed it, and the last push to the repository was on 2026-10-08, with the newest tagged release being v1.1.1 from 2024-06-27.

Editorial conclusion

asnmap fits a reconnaissance pipeline that needs whole network ranges rather than single hosts, especially when the next stage is another command that reads CIDRs from standard input. It is the wrong tool for a one off lookup of one address, and a poor base for anything that must work without a network service, because the CLI is built on the ASNMap API and asks for a PDCP API key before it will answer. If you take it on, check two things first: that your Go toolchain matches the go directive in go.mod rather than the version named in the install section, and that the API key you hold covers the lookups your workflow makes, since a search that works on a laptop can fail inside a scheduled job.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. projectdiscovery/asnmap on GitHub
4. README
5. Releases