Amass
OWASP attack surface mapping tool for discovering internet-facing assets through DNS enumeration, certificate transparency, and 70+ data source integrations.
Continue your mission
OWASP attack surface mapping tool for discovering internet-facing assets through DNS enumeration, certificate transparency, and 70+ data source integrations.
# Amass
Amass is an open-source attack surface discovery and external reconnaissance tool maintained under the OWASP Foundation. It exists because organizations routinely accumulate internet-facing assets, such as subdomains, IP ranges, and cloud endpoints, faster than their security teams can track them. Forgotten staging servers, acquired company domains, and developer-created cloud buckets create exposure that defenders cannot address if they cannot see it. Amass solves the visibility problem by systematically mapping everything an organization exposes to the public internet, combining passive intelligence gathering from dozens of external data sources with active DNS interrogation techniques. The result is a structured, queryable graph of an organization's external attack surface that security teams can use for ongoing monitoring, penetration testing scoping, and vulnerability management prioritization.
---
Amass is a command-line reconnaissance tool written in Go, designed to perform comprehensive external asset discovery through DNS enumeration, autonomous system number (ASN) mapping, certificate transparency log analysis, and integration with more than 70 third-party intelligence APIs. It is maintained by the OWASP Foundation and classified under the OWASP Attack Surface Management category.
Amass is specifically an external reconnaissance tool. It operates from the perspective of an unauthenticated external observer and discovers assets that are publicly resolvable or publicly indexed. This distinguishes it from internal network scanners such as Nmap (which operates post-access on internal segments) and from vulnerability scanners such as Nessus or Tenable.io (which probe discovered hosts for known weaknesses). Amass finds assets; it does not assess the security posture of those assets.
Amass is not a port scanner, a web application vulnerability scanner, or a password auditing tool. It does not authenticate to systems, exploit vulnerabilities, or modify configurations. Its output feeds into the next stage of a security workflow, whether that is penetration testing, attack surface management (ASM), or continuous monitoring.
The tool operates in three primary subcommand modes. The enum subcommand performs active and passive subdomain enumeration. The intel subcommand maps organizational intelligence such as WHOIS records, ASN ranges, and reverse DNS lookups to discover the full scope of a target organization's registered infrastructure. The track subcommand compares outputs across multiple enumeration runs to identify changes in exposed assets over time. Amass also supports a viz subcommand that exports graph data into formats compatible with tools like Maltego and Gephi for visual relationship mapping. This combination of modes makes Amass suitable for both point-in-time penetration test scoping and continuous attack surface monitoring programs.
---
Amass performs asset discovery through two parallel tracks: passive reconnaissance and active enumeration. Both tracks feed results into a local graph database, where Amass builds a relational model of discovered assets and their connections.
Passive Reconnaissance
Passive techniques gather publicly available information without sending packets directly to the target organization's infrastructure. Amass queries certificate transparency logs (including crt.sh and the Google Certificate Transparency API) to find all SSL/TLS certificates issued for domains and subdomains associated with the target. Certificate transparency is particularly valuable because organizations frequently issue certificates for internal development environments, staging systems, and partner portals that never appear in marketing materials or public documentation.
Amass queries threat intelligence and OSINT APIs including VirusTotal, Shodan, Censys, SecurityTrails, PassiveTotal, AlienVault OTX, and BinaryEdge, among others. Each API contributes a different angle. Shodan provides passive scan data for IP-to-hostname mappings. Censys provides certificate and banner data. VirusTotal provides historical DNS resolution records. API keys for each service are configured in Amass's YAML configuration file, and Amass rate-limits its queries to comply with API terms of service.
Amass also scrapes web archives (such as the Wayback Machine) and search engine indices for references to subdomains embedded in historical page content, JavaScript files, and sitemaps. This catches subdomains that were once publicly referenced but no longer appear in current DNS records.
Active Enumeration
Active techniques send DNS queries and, in some configurations, HTTP requests directly toward the target's infrastructure. Amass performs DNS brute-force enumeration using wordlists, systematically testing whether common subdomain names (such as api., dev., vpn., mail., staging.) resolve to valid IP addresses. It supports custom wordlists, and practitioners typically combine default lists with organization-specific terms discovered during passive reconnaissance.
Amass attempts DNS zone transfers against authoritative name servers. Zone transfers (AXFR requests) are a legacy DNS administrative feature that, when misconfigured, return the complete list of DNS records in a zone. Most modern DNS servers block unauthorized zone transfers, but Amass tests for this condition because misconfigured DNS remains a recurring finding on external assessments.
For DNSSEC-enabled zones, Amass performs NSEC (Next Secure) record walking, a technique that iterates through authenticated denial-of-existence records to enumerate all labels in a signed zone without brute-forcing.
Graph Database and Relationship Mapping
All discovered assets are stored in a local graph database (using Cayley or a custom Amass backend). The graph maps relationships between discovered data points: a subdomain resolves to an IP address, that IP address belongs to a CIDR block, that CIDR block is registered to an ASN, and that ASN is associated with an organization name. This relational structure allows practitioners to pivot from a single discovered subdomain into a broader map of an organization's cloud and hosting footprint.
Practical Scenario
Consider a penetration test engagement scoping exercise for a mid-size financial services firm. The target organization has a primary domain of example-bank.com. Running amass enum -passive -d example-bank.com with API keys configured returns 47 subdomains from passive sources alone, including legacy-api.example-bank.com, dev-portal.example-bank.com, and acquired-brand.com (a domain from a company acquired two years prior). Running amass intel -org "Example Bank" returns two additional ASN ranges not listed on the organization's official network documentation. The penetration testing team now scopes its engagement against 47 subdomains and two previously unknown IP ranges rather than the six subdomains the client's IT team believed were their only external exposure. This scope expansion directly changes the risk picture of the engagement.
Configuration Considerations
Amass configuration files are written in YAML and support scope definitions (domains in scope, domains excluded, IP ranges), API key management, resolver lists (custom DNS resolvers reduce dependence on ISP resolvers), and output formatting. Practitioners running Amass in enterprise environments should configure custom resolvers to avoid triggering rate-limiting on public resolvers and should establish output directories for persistent storage of graph data between tracking runs.
---
Organizations consistently underestimate the size of their external attack surface. Security teams inherit infrastructure from acquisitions, retain legacy systems past their documented end-of-life, and find that development teams have deployed cloud resources outside of formal change management processes. Shadow IT and acquisition debt are not theoretical concerns: they are the practical reality of how enterprise infrastructure grows.
The consequences of undiscovered external assets are direct and measurable. An unpatched internet-facing server running an old version of Apache or an exposed development environment with default credentials represents a real entry point. Attackers perform external reconnaissance using the same tools and techniques as defenders, often with more time and patience. The asymmetry is real: the attacker needs to find one overlooked asset; the defender must account for all of them.
Real-World Consequence
A well-documented class of breach involves exposed development and staging environments. In multiple publicly reported incidents (including breaches at major retail and financial organizations), attackers found and compromised internet-facing development servers that held production credentials, database connection strings, or copies of production data. These servers existed because development teams needed external access for partner integrations or remote testing, created the DNS records, and never removed them after the project concluded. Systematic use of an external asset discovery tool would have surfaced these records during routine monitoring, allowing the security team to remediate before attackers found them.
Common Misconceptions
A recurring misconception is that asset discovery is a one-time activity performed at the start of a penetration test. This misframes the problem. The attack surface changes continuously as development teams deploy new services, as cloud infrastructure scales dynamically, and as organizational changes (mergers, acquisitions, contractor relationships) introduce new domains and IP ranges. Asset discovery must operate as a continuous process, not a periodic audit.
A second misconception is that the organization's own IT team always knows what is externally exposed. Amass findings routinely contradict internal asset inventories, not because IT teams are negligent, but because the pace of infrastructure change outstrips manual documentation in most organizations. The tool provides an independent, externally observed view that complements internal records.
---
CDA approaches external asset discovery through the Planetary Defense Model (PDM), specifically within the Vulnerability Surface Discovery (VSD) domain. VSD is predicated on a single operational reality: you cannot protect assets you have not identified. The methodology CDA applies within VSD is Continuous Surface Reduction (CSR), governed by the principle: "Every surface you expose is a surface we eliminate."
Amass is a primary instrument in CDA's VSD workflow, but CDA does not treat Amass as a standalone point-in-time scanner. CDA deploys Amass as part of a scheduled, automated enumeration pipeline that runs against client scope definitions on a defined cadence (typically weekly for large enterprise clients, with continuous API-based monitoring supplementing scheduled full enumerations). Output from each enumeration run is ingested into CDA's asset graph, compared against previous baselines using the amass track subcommand, and automatically triaged by asset category.
What CDA does differently is the integration of Amass output into the broader CSR workflow. Newly discovered assets trigger a classification process: each new asset is categorized as expected (known, documented, and within approved change management records), undocumented (present and resolving but not in the client's asset inventory), or anomalous (present in DNS or certificate transparency logs but not resolving, indicating a potential dangling DNS record or subdomain takeover candidate). Undocumented assets are escalated to the client's security team within 24 hours. Anomalous assets are immediately assessed for subdomain takeover risk using automated validation.
CDA also cross-references Amass ASN and IP range discovery against the client's approved cloud and hosting footprint. Cloud services that appear in Amass output but are not in the approved vendor list represent potential shadow IT, and CDA flags these for procurement and security review rather than simply noting them as informational findings.
The CSR methodology treats attack surface reduction as an active, ongoing process. Every asset Amass surfaces that is not operationally necessary is a candidate for decommissioning. CDA works with clients to establish a formal process: discover, classify, evaluate necessity, and eliminate if not required. The goal is a smaller, fully known, and continuously monitored external surface.
---
amass track on a weekly cadence against your primary domains and compare outputs to detect newly created or newly disappeared subdomains, which may indicate shadow IT or infrastructure changes.subjack or nuclei with takeover templates.amass intel -org to map ASN ranges before engaging in any external assessment; organizations frequently hold IP space under subsidiary or legacy company names that will not appear in a domain-scoped enumeration.---
---
CDA Theater missions that address topics covered in this article.
Guide to AWS Security Hub for centralized finding aggregation, continuous compliance monitoring, and automated remediation across AWS organizations.
Vendor assessment guide for HashiCorp Vault.
Wireshark is the leading network protocol analyzer for traffic capture and security investigation.
Written by CDA Editorial
Found an issue? Help improve this article.