How to Map Your Attack Surface

Every internet-facing asset your organization exposes -- domains, subdomains, IP addresses, open ports, APIs, cloud storage buckets, login portals -- is part of your attack surface. Knowing how to map your attack surface is the foundation of any security program because you cannot protect assets you do not know about. Attackers do not limit themselves to the systems your team remembers deploying; they scan your entire perimeter and target whatever they find, including the forgotten staging server, the marketing microsite from 2019, and the S3 bucket a contractor left open.

Attack surface management is the continuous process of discovering, inventorying, classifying, and monitoring these assets. This guide covers the methodology, tools, and operational practices you need to build an effective ASM program.

What Is an Attack Surface?

Your external attack surface is everything an attacker can see from the outside without any credentials or insider access. It includes:

• Domains and subdomains: Your primary domains plus every subdomain ever created -- dev, staging, internal, legacy, marketing, partner portals
• IP addresses: Assigned ranges, cloud-provisioned IPs, CDN edge nodes, third-party hosting
• Open ports and services: Every listening service -- web servers, databases, SSH, RDP, API gateways, message brokers
• Web applications: Every page, form, API endpoint, file upload, login screen
• Cloud resources: Storage buckets, serverless functions, container registries, Kubernetes API servers
• Email infrastructure: Mail servers, SPF/DKIM/DMARC configurations, open relays
• Third-party integrations: Embedded scripts, OAuth connections, webhook endpoints

The challenge is that most organizations only have visibility into the inner ring. The middle ring (known but unmanaged assets) and outer ring (completely unknown assets) are where attackers find their easiest targets.

Why Attack Surface Discovery Matters

The consequences of an incomplete asset inventory are tangible:

• Unpatched systems: A forgotten staging server running a two-year-old version of WordPress with known RCE vulnerabilities becomes an entry point.
• Exposed credentials: A development environment with default database passwords, visible to anyone who finds the subdomain.
• Data leakage: An S3 bucket created for a one-time project that still contains customer data, publicly accessible.
• Subdomain takeover: A CNAME record pointing to a deprovisioned cloud service that an attacker can claim.

Vulnerability scanning addresses individual known assets. Attack surface discovery addresses the problem of not knowing what assets exist in the first place. You need both, and discovery must come first.

Attack Surface Mapping Methodology

A thorough attack surface mapping exercise follows four phases: subdomain enumeration, port and service discovery, technology fingerprinting, and continuous monitoring.

Phase 1: Subdomain Enumeration

Subdomain enumeration is the foundation of attack surface mapping. A single organization can have hundreds or thousands of subdomains, and many of them were created years ago by teams that no longer exist.

Passive enumeration collects subdomains without sending any traffic to the target. Sources include Certificate Transparency logs (every SSL certificate ever issued is logged publicly), DNS datasets from aggregators, search engine indexes, and web archives. Tools like Subfinder query 40+ passive sources simultaneously.

Active enumeration supplements passive results with DNS brute-forcing (trying wordlists of common subdomain names against the target's DNS servers) and permutation scanning (generating variations of known subdomains to discover related ones). Puredns handles DNS brute-forcing with built-in resolver validation, while Alterx generates intelligent permutations from discovered subdomains.

The output is a comprehensive list of subdomains, each of which needs to be validated (does it resolve?) and then scanned for services.

Phase 2: Port and Service Scanning

Once you know which hosts exist, the next step is finding what services they run. Port scanning (using tools like Nmap or Naabu) reveals open TCP and UDP ports, and service detection identifies what software is listening on each port.

This phase commonly reveals:

• Web servers on non-standard ports (development instances on 8080, 3000, 8443)
• Databases exposed to the internet (MySQL on 3306, PostgreSQL on 5432, MongoDB on 27017)
• Remote access services (SSH on 22, RDP on 3389) that should be behind a VPN
• Administrative interfaces (Jenkins, Grafana, phpMyAdmin) with default credentials

HTTP probing (using tools like Httpx) goes a step further by visiting every discovered web service and recording the response: status code, title, technology headers, content length, CDN provider, and redirect chains. This transforms a list of IP:port pairs into a structured inventory of web applications.

Phase 3: Technology Fingerprinting

Technology fingerprinting identifies what software stack each asset uses. This is critical for vulnerability correlation: knowing that a server runs Apache 2.4.49 or WordPress 6.1 lets you immediately check for known CVEs against those versions.

Fingerprinting tools analyze HTTP headers, HTML content, JavaScript libraries, CSS frameworks, favicon hashes, and error page signatures to identify web servers, CMS platforms, programming frameworks, JavaScript libraries, and WAF products. WhatWeb and Httpx handle most of this automatically.

WAF detection (via Wafw00f) is particularly useful -- knowing which assets are behind a WAF and which are not helps prioritize scanning efforts toward unprotected hosts.

Phase 4: Continuous Monitoring

Attack surfaces are not static. Every deployment, DNS change, and infrastructure modification changes what attackers can see. Point-in-time mapping catches what exists today but misses what appears tomorrow.

Continuous monitoring transforms ASM from a periodic exercise into an ongoing process. Key monitoring targets include:

• DNS record changes: New subdomains, modified A/AAAA records, changed MX records, weakened SPF/DMARC policies
• SSL certificate changes: New certificates (indicating new services), approaching expiry, configuration regressions
• New open ports: Services that appear between scans
• Subdomain takeover opportunities: CNAME records pointing to deprovisioned cloud services

Shadow IT: The Biggest Blind Spot

Shadow IT refers to systems deployed outside the IT department's knowledge and control. Marketing teams spin up landing pages on third-party hosting. Developers deploy test environments on personal cloud accounts. Business units subscribe to SaaS tools with custom subdomains. None of these appear in the official asset inventory.

Shadow IT is not a compliance problem -- it is a security problem. These assets are typically deployed without security review, lack patching processes, use weak or default credentials, and are forgotten within weeks of creation.

The only reliable way to discover shadow IT is external enumeration: scanning from the outside, the same way an attacker would. Internal asset inventories (CMDBs, cloud console dashboards) only contain assets that were provisioned through official channels.

Passive subdomain enumeration finds everything that was ever issued an SSL certificate or indexed by a DNS aggregator, regardless of how it was deployed.

Asset Classification and Risk Scoring

After discovery, every asset needs to be classified by business criticality and risk exposure. Not all assets warrant the same level of protection -- a public marketing site has different risk characteristics than an internal API handling payment data.

Effective classification uses two dimensions: data sensitivity (what data does the asset handle or have access to?) and exposure level (how accessible is it from the internet?). An internal-only database management interface handling PII is high-risk even with moderate exposure. A public documentation portal with no user data is low-risk even with high exposure.

This classification drives scan prioritization, patching urgency, and monitoring frequency. Critical assets need continuous monitoring and regular deep scanning. Low-risk public assets need periodic baseline checks.

Continuous vs. Point-in-Time Discovery

A one-time attack surface mapping exercise has a half-life of about two weeks. After that, new assets have been deployed, old ones have been modified, and the inventory is already incomplete.

The shift from point-in-time to continuous discovery is what separates a security program from a security exercise. Continuous ASM requires:

• Scheduled subdomain enumeration running weekly or daily to detect new subdomains as they appear
• DNS change monitoring to detect record modifications, especially NS, A, and MX changes that could indicate compromised infrastructure
• SSL certificate monitoring to detect new certificates (indicating new services) and approaching expirations
• Periodic vulnerability scanning against the full discovered asset inventory
• Alerting when new assets appear, configurations change, or risk scores increase

Metric Tower's asset inventory is designed around this continuous model. Scheduled scans run against your target list on a configurable cadence, with new findings tracked over time so you can see when assets appear, disappear, or change. DNS monitoring, SSL monitoring, and uptime monitoring run as always-on background checks that alert when your infrastructure changes, complementing the periodic deep scans.

Subdomain Takeover: The Silent Threat

Subdomain takeover is one of the most common and dangerous findings in attack surface assessments. It occurs when a subdomain's CNAME record points to an external service (like a cloud hosting provider, CDN, or SaaS platform) that has been deprovisioned, but the DNS record was never cleaned up.

An attacker can claim the dangling resource on the external service, effectively taking control of your subdomain. This gives them the ability to serve content under your domain, intercept cookies scoped to the parent domain, and bypass CORS policies that trust your domain.

Detection requires comparing discovered CNAME records against known vulnerable providers and checking whether the target resource still exists. Tools like TakeoverWatch (which Metric Tower runs as part of its scanner pipeline) automate this by checking discovered subdomains against a database of takeover-vulnerable CNAME patterns.

Building Your ASM Program

If you are starting from zero, here is a practical sequence:

1. Start with your known domains. List every domain your organization owns. Check domain registrars, DNS providers, and ask business units about marketing domains, partner portals, and regional sites.
2. Run passive subdomain enumeration. Use Subfinder, Amass, and CrtSh against each domain. This will immediately reveal subdomains you forgot about.
3. Port scan the discovered hosts. Run Nmap or Naabu against every resolved IP. Expect surprises -- databases on the internet, admin panels on non-standard ports, services you didn't know existed.
4. Fingerprint the tech stack. Run Httpx and WhatWeb to identify what software each asset runs. This enables targeted vulnerability scanning.
5. Set up continuous monitoring. Schedule weekly subdomain scans, enable DNS change monitoring for your primary domains, and configure SSL monitoring for every discovered web service.
6. Integrate with vulnerability scanning. Feed discovered assets into regular vulnerability scans. New assets should be automatically scanned when discovered.

Metric Tower handles all six steps in an integrated workflow. Subdomain enumeration feeds into port scanning and HTTP probing, which feeds into technology detection and vulnerability scanning, with results tracked in a persistent asset inventory. For a comparison of dedicated ASM platforms, see our guide to attack surface management tools.

Attack surface management is not a tool -- it is an operational discipline. The technology matters (you need good enumeration, scanning, and monitoring tools), but the process matters more. Continuous discovery, prompt triage of new assets, and integration with your vulnerability management workflow are what turn a list of subdomains into a secure perimeter.

Start with discovery, automate what you can, and monitor continuously. Your attack surface will change tomorrow, and the question is whether you find the changes first or an attacker does.