Still Confused by Amass or Can’t Understand Its Results, This Is for You

Discovering the attack surface of a target is arguably the most critical phase of any penetration test or bug bounty hunt. If you don't know an asset exists, you can't test it for vulnerabilities. For years, OWASP Amass has been celebrated as the gold standard for asset discovery and subdomain enumeration.

Yet, for many researchers, running Amass for the first time feels like staring directly into the Matrix. You execute a command, and your terminal floods with lines of arrow-separated networks, cryptographic-looking strings, and DNS jargon.

If you have struggled to run Amass effectively, or if you look at its output and think, "What am I even looking at?" — you are not alone. This guide is your definitive blueprint to mastering Amass, breaking down its output, and leveraging that data like a pro.

1. Demystifying the Output: What Amass Is Actually Telling You

When you run a passive scan, Amass doesn't just spit out a flat list of subdomains. Instead, it builds an infrastructure dependency graph. It maps how a domain connects to an IP, how that IP sits inside a network block, and who owns that network.

Let's look at a realistic sample output and break it down line-by-line:

Plaintext

google.com (FQDN) --> mx_record --> smtp.google.com (FQDN)
accelerator.google.com (FQDN) --> a_record --> 142.251.216.46 (IPAddress)
datafusion.cloud.google.com (FQDN) --> cname_record --> www3.l.google.com (FQDN)
142.250.0.0/15 (Netblock) --> contains --> 142.251.216.46 (IPAddress)
15169 (ASN) --> announces --> 142.250.0.0/15 (Netblock)

google.com (FQDN) --> mx_record --> smtp.google.com (FQDN)
accelerator.google.com (FQDN) --> a_record --> 142.251.216.46 (IPAddress)
datafusion.cloud.google.com (FQDN) --> cname_record --> www3.l.google.com (FQDN)
142.250.0.0/15 (Netblock) --> contains --> 142.251.216.46 (IPAddress)
15169 (ASN) --> announces --> 142.250.0.0/15 (Netblock)

We can categorize these relationships into three core layers:

The DNS Layer

FQDN (Fully Qualified Domain Name): This is simply a specific subdomain or host address.
a_record (IPv4) & aaaa_record (IPv6): This maps a subdomain to its actual host server's IP address.
Example: accelerator.google.com resolves directly to the server at 142.251.216.46.
cname_record (Canonical Name): Think of this as an alias or redirect. It means one subdomain points to another backend domain for load balancing or third-party hosting.
mx_record (Mail Exchange): Points to the servers handling email traffic for that domain.

The Routing & Infrastructure Layer

Netblock (CIDR Notation): Servers rarely sit alone; they belong to groups of IP ranges called netblocks (e.g., 142.250.0.0/15). Amass tells you exactly which "neighborhood" a server IP resides in.
ASN (Autonomous System Number): This is a collection of IP networks controlled by a single giant entity (like an ISP or a tech giant). ASN 15169 belongs entirely to Google LLC.

Why this matters:

Amass maps the entire logical pipeline:

$$\text{Subdomain} \longrightarrow \text{IP Address} \longrightarrow \text{Netblock Range} \longrightarrow \text{ASN Owner}$$

2. From Data to Bugs: The Pro Researcher's Action Plan

Amass has given you raw data. What does a top-tier security researcher do next? They run it through a systematic pipeline to turn strings of text into high-impact vulnerabilities.

[ Amass Output ] ──> [ httpx Probing ] ──> [ Filtering Dev/Stage ] ──> [ Directory Brute-Force ]

[ Amass Output ] ──> [ httpx Probing ] ──> [ Filtering Dev/Stage ] ──> [ Directory Brute-Force ]

Step 1: Probe for Live Targets (`httpx`)

Amass pulls historical data passively, meaning some subdomains it finds might be dead or offline. Do not scan blindly. Use a tool like httpx to verify which subdomains are actively listening on web ports.

Bash

cat subdomains.txt | httpx -title -tech-detect -status-code -o live_subs.txt

cat subdomains.txt | httpx -title -tech-detect -status-code -o live_subs.txt

The Goal: Isolate hostnames returning 200 OK, 403 Forbidden, or 401 Unauthorized statuses.

Step 2: Target Dev, Staging, and Pre-production Environments

Look closely at the names Amass uncovers. Subdomains containing words like dev, stage, alpha, test, or corp are absolute goldmines. Developers frequently disable strict authentication or leave debugging modes active on these endpoints.

What to look for: Look for exposed internal management consoles, unauthenticated setups, or default credentials (e.g., admin:admin).

Step 3: Check for Dangling CNAMEs (Subdomain Takeover)

Pay strict attention to cname_record entries pointing to third-party services like AWS S3, GitHub Pages, Zendesk, or Shopify.

The Bug: If a company points help.target.com to a Zendesk instance via a CNAME, but later deletes that Zendesk instance without removing the DNS record, you can sign up on Zendesk, claim that space, and completely control help.target.com.

Step 4: Network Infrastructure Mapping (Port Scanning)

When Amass gives you a tight Netblock owned directly by the target, don't just focus on standard web traffic. Run focused port scans across those specific IPs.

What to look for: Look for database instances exposed directly to the internet (e.g., MySQL on port 3306 or PostgreSQL on 5432), unauthenticated Redis clusters, or vulnerable legacy versions of SSH/FTP.

Conclusion

OWASP Amass is not just a subdomain scraper; it is an architectural cartographer. By understanding its output format, recognizing how DNS records tie into ASN routing networks, and systematically funneling its findings into active verification tools, you transition from running simple commands to orchestrating professional security assessments.

Stop looking at the data as random text. Treat it as a map of an enterprise's digital footprint, and follow the trails to find your next critical vulnerability.

Contents