Attack Surface Management: Mapping and Reducing Your Exposure

Your security tools protect the assets they know about. Your vulnerability scanners scan the IP ranges in their configuration. Your EDR agents monitor the endpoints where they are installed. Your SIEM collects logs from the sources that have been onboarded. But what about the assets nobody told security about?

The development server a team spun up on AWS three years ago and forgot to decommission. The marketing campaign microsite running on an outdated CMS. The VPN appliance from the company you acquired last year that is still Internet-facing with default credentials. The S3 bucket a contractor created with public read access. These are not hypothetical scenarios. They are the actual findings from attack surface management programs at organizations that believed they had complete asset visibility.

External Attack Surface Management (EASM) addresses this blind spot by approaching your infrastructure from the outside in, discovering what an attacker would find. It answers the question that no amount of internal scanning can: what does our organization look like from the Internet? This guide covers the complete ASM discipline from initial discovery through continuous monitoring, prioritization, reduction, and governance.

Understanding the External Attack Surface

Your external attack surface is everything about your organization that is visible, accessible, or discoverable from the Internet. It includes the assets you manage intentionally and the assets you have lost track of. It includes your own infrastructure and the third-party services that bear your brand, host your data, or connect to your systems.

Components of the External Attack Surface

Domain and DNS infrastructure includes all domains your organization owns, their subdomains, DNS records (A, AAAA, CNAME, MX, TXT, NS), and the relationships between them. DNS is the foundational layer of attack surface discovery because domain registration records, certificate transparency logs, and DNS resolution chains reveal the scope of an organization's Internet presence.

IP address space encompasses all IP addresses your organization uses: owned address blocks (ASN allocations), cloud provider addresses, CDN edge addresses, and addresses used by hosting providers. Each IP address potentially hosts services that attackers can discover and probe.

Web applications and APIs represent the most common attack vector. Every HTTP/HTTPS endpoint, whether it is your primary website, an internal tool accidentally exposed, a forgotten API endpoint, or a development instance, is part of your attack surface. Web applications account for the majority of initial access vectors in external compromises.

Cloud resources include compute instances, storage buckets, serverless functions, container registries, databases, and management consoles across all cloud providers your organization uses. Cloud asset sprawl is the fastest-growing component of external attack surfaces because provisioning requires no physical infrastructure and minimal approval in many organizations.

Certificate infrastructure includes all TLS/SSL certificates issued for your domains, their expiration status, cryptographic strength, and configuration. Certificate transparency logs provide a near-complete record of certificates issued for your domains, making certificates both a discovery tool and a monitoring target.

Email infrastructure encompasses MX records, SPF/DKIM/DMARC configurations, and email gateway services. Misconfigured email authentication enables phishing and impersonation attacks that exploit your brand trust.

Third-party digital supply chain includes SaaS applications, marketing tools, analytics platforms, payment processors, and other services that interact with your customers or handle your data. These create indirect attack surface because a compromise of a third-party service can lead to a compromise of your data or your customers' trust.

Why Traditional Inventory Fails

Internal asset management (CMDB, ITAM systems) fails to capture the complete external attack surface for structural reasons:

• Agent-dependent discovery requires that every asset has a monitoring agent installed. Assets created outside standard provisioning processes never receive agents.
• Network-scoped scanning only discovers assets on networks the scanner can reach. Cloud resources, SaaS-hosted infrastructure, and CDN-fronted services exist outside traditional network scan ranges.
• Manual inventory maintenance depends on teams accurately recording asset creation and decommissioning. In practice, asset creation is often recorded (it is part of the provisioning process), but decommissioning records are inconsistent because teams move on to new projects without cleaning up old infrastructure.
• Organizational boundaries create gaps. Acquired companies bring unknown infrastructure. Business units with autonomous IT create assets outside central governance. Marketing and sales teams provision SaaS tools without security review.

The result: the average enterprise has 30-40% more Internet-facing assets than their internal inventory accounts for. EASM closes this gap by discovering assets from the outside, using the same techniques an attacker would use.

Asset Discovery Methodology

External attack surface discovery uses multiple complementary techniques to build a comprehensive inventory of Internet-facing assets. No single technique provides complete coverage. Effective discovery combines all of them.

DNS Enumeration

DNS enumeration discovers subdomains and related infrastructure through multiple sources:

• Passive DNS databases aggregate historical DNS resolution data from participating DNS resolvers worldwide. Querying these databases reveals subdomains that were active at any point, including decommissioned infrastructure that may still resolve to live hosts.
• Certificate transparency (CT) logs record every TLS certificate issued by participating certificate authorities. Because certificates include the domains they protect, CT log queries reveal subdomains that have had certificates issued, often including internal hostnames, development environments, and API endpoints.
• DNS brute-forcing systematically tests potential subdomain names against the target domain's nameservers. Wordlists based on common subdomain patterns (dev, staging, api, admin, test, vpn, mail) and permutation techniques discover subdomains that passive sources may not contain.
• Zone transfer attempts test whether DNS servers are misconfigured to allow zone transfers (AXFR queries) to unauthorized requestors. Successful zone transfers reveal the complete DNS zone, including all subdomains and their IP addresses.
• Reverse DNS lookups query IP addresses in known ranges to discover hostnames that point to those addresses, potentially revealing subdomains not found through forward DNS enumeration.

IP and Port Discovery

After identifying IP addresses associated with your organization, port scanning reveals the services running on those addresses:

• Internet-wide scan data from sources like Censys, Shodan, and BinaryEdge continuously scan the entire IPv4 address space. Querying these databases provides service information without active scanning, including historical snapshots that reveal services that were previously exposed.
• Targeted port scanning probes specific IP ranges for common service ports (HTTP/S, SSH, RDP, FTP, database ports, management interfaces). Full-port scans across 65,535 TCP ports catch services running on non-standard ports intended to evade casual discovery.
• Service fingerprinting identifies the specific software and version running on discovered ports through banner grabbing, protocol probing, and response analysis. This links discovery to vulnerability intelligence: knowing a specific Apache version allows immediate correlation with known CVEs.

Cloud Asset Discovery

Cloud infrastructure requires specialized discovery techniques because cloud assets do not have static IP addresses and may be provisioned and decommissioned rapidly:

• Cloud storage enumeration discovers publicly accessible storage buckets (S3, Azure Blob Storage, Google Cloud Storage) through naming convention patterns, DNS CNAME records, and brute-force enumeration of common bucket name patterns.
• Cloud API discovery identifies exposed cloud management APIs, serverless function endpoints, and container registry interfaces through DNS patterns and known cloud provider URL structures.
• Cloud provider API integration uses read-only API access to your own cloud accounts to inventory all resources, including those created outside standard provisioning processes. This inside-out approach complements outside-in discovery by correlating known internal resources with externally-discovered exposures.

Common Exposure Categories

EASM programs consistently discover the same categories of exposures across different organizations and industries. Understanding these categories helps prioritize initial discovery focus and set expectations for what your program will find.

Shadow IT and Forgotten Infrastructure

Shadow IT encompasses any technology resource deployed without the knowledge or approval of the security team. In the context of attack surface management, shadow IT creates unmonitored, unpatched, and often misconfigured Internet-facing assets that attackers can discover and exploit.

Common shadow IT discoveries include development and staging environments deployed on cloud infrastructure using personal accounts or autonomous team accounts, marketing and campaign microsites built on standalone CMS platforms (WordPress, Wix, Squarespace) with organization branding but no security oversight, proof-of-concept applications and demos deployed to public cloud and never decommissioned, file sharing and collaboration tools adopted by individual teams without security review, and DNS records pointing to test infrastructure that remains accessible months or years after the test concluded.

Cloud Misconfigurations

Cloud environments create attack surface rapidly because provisioning is self-service and often occurs outside security review processes. Common cloud-related exposures include:

• Public storage buckets — S3 buckets, Azure Blob containers, and GCS buckets with public access enabled. These may contain application data, database backups, log files, configuration files with credentials, or customer data. Cloud storage misconfigurations have been responsible for some of the largest data exposures in recent years.
• Exposed management interfaces — Cloud service management consoles, database admin panels (phpMyAdmin, Adminer), container orchestration dashboards (Kubernetes Dashboard, Portainer), and monitoring tool interfaces accessible from the Internet without authentication or with default credentials.
• Overly permissive security groups — AWS security groups, Azure NSGs, and GCP firewall rules that allow inbound access from 0.0.0.0/0 on sensitive ports (SSH, RDP, database ports, management ports).
• Unencrypted services — Database instances, API endpoints, and management interfaces accessible over unencrypted protocols (HTTP instead of HTTPS, unencrypted database connections) exposing credentials and data in transit.

DNS Hygiene Issues

Subdomain takeover occurs when a DNS CNAME record points to a third-party service (GitHub Pages, Heroku, AWS Elastic Beanstalk, Azure, Shopify) where the organization's account or resource has been deleted. Attackers can register the same resource name on the third-party platform and serve content under your subdomain. Subdomain takeover enables phishing under your domain name, cookie theft on your root domain, and reputational damage.

Dangling DNS records point to IP addresses or services that are no longer under your organization's control. When the original IP address is reassigned to a new entity, that entity can serve content or intercept traffic intended for your organization.

Zone delegation issues occur when NS records delegate subdomains to nameservers that your organization no longer controls. Similar to subdomain takeover, this allows the entity controlling those nameservers to respond to any DNS query for the delegated zone.

Certificate and Encryption Issues

Certificate-related exposures create both security and availability risks:

• Expired certificates cause browser trust warnings for users and may lead to downgraded connections. Expired certificates on API endpoints can break integrations silently.
• Weak cryptographic configurations including outdated TLS versions (TLS 1.0, 1.1), weak cipher suites, and certificates using deprecated signature algorithms (SHA-1).
• Certificate mismatch where the certificate does not match the hostname, indicating either misconfiguration or infrastructure changes that broke certificate alignment.
• Wildcard certificate overuse where a single wildcard certificate protects many services across different trust boundaries, meaning a compromise of any single service exposes the private key for all services.

EASM Tooling Landscape

The EASM market has matured significantly, with options ranging from free open-source tools to enterprise platforms. Your choice depends on organizational size, budget, and operational maturity.

Commercial EASM Platforms

Censys provides Internet-wide scanning data combined with asset attribution and risk scoring. Its strength is comprehensive IPv4/IPv6 scanning coverage and historical data that reveals infrastructure changes over time. Censys Search allows querying across 3.8+ billion services. The ASM platform adds automated asset attribution, risk prioritization, and integration with vulnerability management workflows.

CyCognito emphasizes automated discovery and testing. Beyond asset enumeration, CyCognito actively tests discovered assets for common vulnerabilities and misconfigurations, providing findings that combine discovery with lightweight vulnerability assessment. Its attacker-perspective approach models how sophisticated attackers would chain vulnerabilities across related assets.

Mandiant Attack Surface Management (formerly Intrigue) integrates EASM with Mandiant's threat intelligence capabilities. The platform correlates discovered assets with Mandiant's extensive threat actor database, identifying exposures that specific threat groups are known to target. This threat-intelligence-enriched prioritization helps organizations focus on exposures that are actively being exploited rather than theoretical risks.

Microsoft Defender EASM provides attack surface discovery integrated with the Microsoft security ecosystem. Its integration with Microsoft Defender, Sentinel, and Azure infrastructure makes it a natural fit for Microsoft-centric environments. Pricing is consumption-based, making it accessible for organizations already invested in Microsoft security.

Shodan is one of the original Internet scanning services, providing a searchable database of Internet-connected devices and services. While not a full EASM platform, Shodan's extensive historical data, API access, and monitoring capabilities make it valuable for asset discovery and change detection. Shodan Monitor provides alerting when new services appear on specified IP ranges.

Open-Source Discovery Tools

For organizations building custom ASM programs or validating commercial platform results:

• Amass (OWASP) — Comprehensive subdomain enumeration using passive and active techniques. Integrates with dozens of data sources (VirusTotal, SecurityTrails, Censys, Shodan, and more). The most full-featured open-source asset discovery tool.
• Subfinder (ProjectDiscovery) — Fast passive subdomain enumeration using certificate transparency logs and various third-party APIs. Designed for speed and integration into automated pipelines.
• Nuclei (ProjectDiscovery) — Template-based vulnerability scanner that tests discovered assets against thousands of detection templates covering CVEs, misconfigurations, exposed panels, and default credentials. Combines discovery validation with lightweight vulnerability assessment.
• httpx (ProjectDiscovery) — HTTP probing tool that takes discovered hosts and identifies live web servers, technology stacks, response codes, and page titles. Essential for analyzing web application attack surface.
• tlsx — TLS certificate analysis tool for auditing certificate configurations across discovered hosts, checking for expiration, weak ciphers, and certificate chain issues.

Building an ASM Program: Implementation Workflow

Implementing an effective ASM program requires more than deploying a tool. It requires organizational alignment, process integration, and ongoing governance.

Phase 1: Seed Asset Identification (Week 1-2)

Every ASM program starts with seed assets: the known starting points from which discovery expands outward. Compile your initial seed list from:

• Primary domains — All domains your organization owns, including brand variants, country-specific domains, and product-specific domains. Check domain registrar accounts, not just the marketing team's knowledge.
• IP address ranges — ARIN/RIPE/APNIC allocations registered to your organization. Include ranges assigned to subsidiaries and acquired companies.
• ASN numbers — Autonomous System Numbers registered to your organization reveal IP address blocks allocated to you.
• Brand keywords — Organization name variations, product names, and acquisition names that may appear in domain registrations, SSL certificates, or cloud resource names outside your known infrastructure.
• Key personnel — Email addresses and names of IT administrators and developers whose accounts may be associated with cloud resources, domain registrations, or code repositories.

Phase 2: Initial Discovery Scan (Week 2-4)

Run comprehensive discovery against your seed assets. If using commercial platforms, this involves configuring your seed assets and letting the platform expand discovery automatically. If using open-source tools, build a pipeline:

1. Subdomain enumeration (Amass, Subfinder) against all seed domains
2. DNS resolution of all discovered subdomains to IP addresses
3. Reverse DNS and ASN lookups on discovered IP addresses to find additional related infrastructure
4. HTTP probing (httpx) of all discovered hosts to identify live web services
5. Port scanning (nmap, masscan) of discovered IP addresses for non-HTTP services
6. Certificate transparency log queries for all seed domains
7. Cloud storage enumeration using organization naming patterns

The initial scan will reveal surprises. Expect to discover 30-40% more Internet-facing assets than your internal inventory accounts for. Document every discovery and begin the attribution process: determining which assets belong to your organization, which belong to third parties, and which are false positives.

Phase 3: Asset Attribution and Inventory (Week 4-6)

Not everything discovery finds belongs to you. Attribution is the process of confirming ownership and organizational relationship for each discovered asset:

• Confirmed assets — Assets clearly owned and operated by your organization. Add to your monitored inventory with an identified owner.
• Third-party assets — Infrastructure operated by vendors, partners, or service providers on your behalf. Track separately with vendor accountability mapping.
• Unattributed assets — Discoveries that could not be confirmed as belonging to your organization. Investigate further before dismissing, as these may be the shadow IT your program is designed to find.
• False positives — Assets incorrectly associated with your organization. Mark and exclude from future scans.

Phase 4: Risk Prioritization (Week 6-8)

With a confirmed asset inventory, apply contextual risk scoring to identify the exposures that require immediate attention. Effective prioritization considers four dimensions:

Exposure severity — What is exposed and how exploitable is it? An unauthenticated admin panel is critical. An information disclosure through verbose error messages is medium. A missing HSTS header is low.

Asset criticality — How important is the affected asset? A customer-facing production application is tier 1. An internal development tool is tier 3. A decommissioned marketing site is tier 4.

Threat context — Is the exposure being actively exploited in the wild? Is the exposed technology on the CISA KEV list? Does threat intelligence indicate targeting of this technology by actors relevant to your industry?

Blast radius — If this exposure is exploited, how far can an attacker reach? An exposed service in a segmented DMZ has limited blast radius. An exposed service on an internal network with flat architecture has maximum blast radius.

Phase 5: Remediation and Reduction (Ongoing)

Attack surface reduction falls into four action categories:

Decommission assets that serve no business purpose. Forgotten development environments, expired campaign sites, unused API endpoints, and legacy infrastructure should be taken offline. Decommissioning eliminates the asset from the attack surface entirely, which is always the strongest mitigation.

Harden assets that must remain Internet-facing. Apply patches, fix misconfigurations, enforce authentication, harden TLS configurations, and resolve DNS hygiene issues. Hardening reduces the exploitability of necessary assets.

Shield assets that cannot be immediately hardened. Place vulnerable assets behind WAFs, add IP allowlisting for management interfaces, move non-public services behind VPN access, and deploy CDNs to obscure origin infrastructure. Shielding adds protective layers while root cause remediation is planned.

Monitor all assets continuously for changes. New services appearing on known assets, certificate expiration, DNS changes, and new vulnerability disclosures affecting your technology stack all require detection and response.

Integrating ASM with Existing Security Programs

Attack surface management does not replace existing security programs. It feeds them with better asset visibility.

Vulnerability Management Integration

ASM discovered assets should be automatically added to vulnerability management scanning scope. When ASM discovers a new Internet-facing web server, that server should appear in your next vulnerability scan. This closes the most common gap in vulnerability management programs: scanning an incomplete inventory. Integration approaches range from API-based synchronization between ASM and VM platforms to manual periodic import for smaller programs.

Incident Response Integration

When your IR team investigates an incident, ASM data provides immediate context. Which other assets share infrastructure with the compromised system? What services are running on adjacent IP addresses? Has the attacker's observed infrastructure appeared in your attack surface before? ASM platforms that maintain historical data also reveal whether an exploited asset was recently deployed (suggesting supply chain compromise) or has been exposed for months (suggesting missed detection).

Threat Intelligence Integration

Bidirectional integration between ASM and threat intelligence amplifies both programs. Threat intelligence about targeted technologies drives focused monitoring on assets running that technology. ASM discovery of infrastructure matching known threat actor patterns (similar domain registration patterns, hosting providers, or certificate characteristics) can identify pre-operational attacker infrastructure targeting your organization.

Cloud Security Posture Management (CSPM)

ASM and CSPM are complementary. CSPM audits cloud configurations from inside your cloud accounts (inside-out). ASM discovers cloud exposures from the outside (outside-in). Together, they provide complete cloud security visibility. CSPM catches misconfigured IAM policies, overly-permissive storage policies, and compliance drift. ASM catches cloud resources deployed outside managed accounts, exposed management interfaces, and services that CSPM cannot see because they exist in unmonitored accounts.

ASM Governance and Metrics

Sustaining an ASM program requires governance structures that ensure discovered exposures are actually remediated and that the attack surface does not regrow after reduction efforts.

Key Metrics

• Total discovered assets — Your complete Internet-facing inventory count. Track trends: a consistently growing attack surface indicates provisioning is outpacing decommissioning.
• Unknown asset percentage — Percentage of discovered assets not previously in your CMDB or asset inventory. Target below 10% as your program matures. Higher percentages indicate governance gaps.
• Mean time to discovery (MTTD) — Average time between when a new asset appears on the Internet and when your ASM program detects it. Commercial platforms target under 24 hours. Manual processes may take weeks.
• Critical exposure count — Number of critical-severity exposures in your current attack surface. This is your primary risk metric. Track weekly and set reduction targets.
• Mean time to remediation (MTTR) — Average time from exposure discovery to confirmed remediation. Track by severity tier with SLAs: Critical under 24 hours, High under 72 hours, Medium under 14 days.
• Attack surface reduction rate — Net change in total attack surface over time. Effective programs show a declining trend as decommissioning and hardening outpace new provisioning.

Ownership and Accountability

Every discovered asset needs an identified owner. Unowned assets are the most dangerous because nobody is responsible for patching, monitoring, or decommissioning them. Establish a process for assigning ownership to newly-discovered assets within 72 hours of discovery. If an asset cannot be attributed to an owner within 14 days, escalate for decommissioning. Maintaining unowned Internet-facing assets is an unnecessary risk.

Attack surface management is not a tool deployment. It is an operational discipline that continuously answers the question: what does our organization look like to an attacker? The organizations that manage their attack surface effectively are those that treat discovery as continuous rather than periodic, prioritize based on genuine risk rather than theoretical severity, integrate ASM findings into existing security workflows rather than creating isolated dashboards, and hold asset owners accountable for the exposures on their infrastructure. Start with seed assets and a discovery scan. You will likely be surprised by what you find. The goal is to ensure attackers are never surprised by what you did not know about.