OWASP Amass for Attack Surface Mapping

How OWASP Amass works, where it fits your recon pipeline, how it stacks up against Subfinder and SpiderFoot, and a reproducible 10-minute hands-on recipe.

OWASP Amass for Attack Surface Mapping

Most external penetration tests fail to find the interesting stuff not because the tester lacks skill but because the asset inventory was incomplete before they started. Amass exists to close that gap. Hosted under the OWASP umbrella with over 14,800 GitHub stars, it has grown from a subdomain enumeration script into a full external asset discovery platform with a persistent graph database at its core.

This post covers what Amass does under the hood, where it belongs in a recon pipeline, how it compares to the tools you’re probably already using, and a reproducible workflow you can run in under ten minutes.

What Amass Actually Does

Amass performs attack surface mapping and asset discovery by combining multiple data-collection techniques into a single configurable pipeline. Per the owasp-amass/amass GitHub repository, the tool exposes three primary modes:

• amass intel – Collects organizational intelligence: ASN numbers, WHOIS data, and seed domains tied to a target company name or IP range.
• amass enum – Enumerates subdomains and network assets using passive sources, active DNS probing, and graph-based analysis.
• amass db – Manages and queries the local graph database that persists results across sessions.

The design distinction that matters most: Amass builds a graph-oriented data model where discovered assets—domains, IPs, CIDRs, ASNs—are nodes connected by relationship edges. That means findings from multiple sessions accumulate into a queryable knowledge graph rather than flat text files you merge by hand. For continuous monitoring programs, this is the feature that makes Amass worth the setup overhead.

The passive collection layer pulls from certificate transparency logs (Censys, crt.sh), DNS aggregators (SecurityTrails, Robtex), threat intel feeds (AlienVault OTX), web archives, and search engine APIs—all without touching the target’s infrastructure. Active mode adds DNS brute-forcing, zone transfer attempts, and ASN route lookups. Those do generate traffic the target can log, so authorization requirements are not optional.

Where Amass Fits in Your Toolchain

Recon is a funnel. Amass lives at the wide top: it surfaces assets you didn’t know existed, not ports or vulnerabilities. A standard workflow:

1. Scope definition → amass intel to discover ASNs and seed domains from a company name or known IP range.
2. Asset enumeration → amass enum to build the full subdomain graph using passive and, if authorized, active techniques.
3. Live host confirmation → Pipe Amass output into httpx or massdns to filter for responding hosts.
4. Port and service scanning → Pass live hosts to Nmap or Naabu for service fingerprinting.
5. Vulnerability analysis → Feed scanner inputs—Nuclei, manual frameworks—from the confirmed live inventory.

Amass does not try to replace steps three through five, and it shouldn’t. It’s the discovery engine that makes those steps more complete. Skip thorough asset discovery and every downstream activity runs on an incomplete picture—the “unknown unknowns” problem that produces scope gaps in external tests and blind spots in EASM programs.

For blue-team and threat-intel work, Amass fits a different role: scheduled monitoring. Because results persist in the graph database, recurring enumerations let you diff output over time and catch new subdomains, dangling DNS records, or newly provisioned infrastructure before an adversary does.

Amass vs. Alternatives

No tool wins every scenario. Here’s where the tradeoffs actually land.

Subfinder (ProjectDiscovery)

Subfinder is lighter, faster, and drops cleanly into automated pipelines via JSON output. For a CI/CD check that flags new subdomains on every deployment, Subfinder is the right call—Amass is overkill. Where Amass pulls ahead is the depth of its graph model, the intel mode for organizational scope discovery, and active enumeration capability. Subfinder does not build persistent session graphs or do ASN-level intelligence gathering. Per the Subfinder documentation, it’s explicitly scoped to passive subdomain discovery.

TheHarvester

TheHarvester overlaps on email and subdomain gathering from public sources. It’s useful for quick, targeted lookups in early recon or for email harvesting specifically, but it has no graph database and narrower scope than Amass.

Shodan / Censys

These are data sources as much as tools. Amass actually queries both—with valid API keys configured—and enriches its graph with their output. Analysts who need real-time banner data or device-level fingerprinting will still hit these platforms directly, but Amass abstracts and correlates their outputs alongside dozens of other sources automatically.

SpiderFoot

SpiderFoot covers a broader OSINT surface—people, companies, threat correlation—making it a general-purpose automation platform. For pure network asset discovery, Amass produces more thorough DNS and network topology results. If your scope extends to personnel or corporate structure, SpiderFoot is the better fit.

Decision table:

10-Minute Hands-On Recipe

The following assumes Go 1.21+ on Linux or macOS, using the install method from the official Amass repository. Only run active enumeration against targets you are explicitly authorized to test.

Step 1: Install Amass

go install -v github.com/owasp-amass/amass/v4/...@master

Verify:

amass -version

Or pull the Docker image:

docker pull caffix/amass

Step 2: Passive Subdomain Enumeration

amass enum -passive -d example.com -o passive_results.txt

This queries configured passive sources without sending traffic to the target. Results write to passive_results.txt and simultaneously land in the local graph database.

Step 3: Configure API Keys

Amass reads a YAML config. Create ~/.config/amass/config.yaml:

resolvers:
  - 8.8.8.8
  - 1.1.1.1

datasources:
  - name: Censys
    creds:
      key: YOUR_CENSYS_API_ID
      secret: YOUR_CENSYS_API_SECRET
  - name: SecurityTrails
    creds:
      key: YOUR_SECURITYTRAILS_KEY

Even a free-tier Censys or SecurityTrails key meaningfully expands coverage. The official docs list all supported source names and their required credential fields.

Step 4: Re-run with Configuration

amass enum -passive -d example.com -config ~/.config/amass/config.yaml -o passive_enriched.txt

Step 5: Organizational Intelligence

If you’re starting from a company name rather than a known domain:

amass intel -org "Example Corporation" -o org_seeds.txt

This queries WHOIS, ASN registries, and related sources to surface domains and IP ranges associated with the organization. This is the right starting point when scope isn’t yet defined—it’s where Amass separates from tools that assume you already know the seed domain.

Step 6: Query the Graph Database

amass db -names -d example.com

Retrieves all discovered subdomain names from the persistent graph, including findings from previous sessions. No need to re-run a full enumeration to access prior results.

Step 7: Visualize the Graph (Optional)

amass viz -d3 -d example.com -o graph.html

Opens as an interactive D3.js-rendered view of discovered asset relationships. Useful for scoping conversations with clients who need visual context rather than a flat subdomain list.

Production Considerations

API quota burn: With many sources configured, passive enumeration against large targets will exhaust free-tier quotas fast. Stagger enumeration schedules on continuous monitoring programs and track usage per source.

Result noise: Amass casts a wide net. Output will include wildcard DNS entries, CDN-fronted hosts, and infrastructure outside the target’s direct control. Always confirm live hosts before treating every discovered subdomain as in-scope—I’ve seen triage time double on engagements where teams skipped this step.

Storage growth: The graph database grows with every session. For long-running engagements or ongoing monitoring, set a retention policy and archive or prune older graph data on a schedule.

Active mode detection: Brute-forcing and zone transfer attempts generate traffic targets can log. Per the OWASP Attack Surface Analysis Cheat Sheet, scope boundaries matter here—active modes require a signed statement of work or explicit written authorization, not just a verbal green light.

Takeaway

Amass is the most capable open-source tool available for graph-backed, multi-session external attack surface mapping. The intel mode for organizational scope discovery combined with persistent graph storage is what separates it from faster but shallower tools. On external engagements, run it before anything else. In monitoring programs, run it on a schedule and diff the output—new subdomains appearing between runs are your early warning.

Start with the passive workflow above, add API keys in the order of whatever free tiers you already have access to (Censys first, SecurityTrails second), and build from there.