Attack surface discovery is the process of finding, attributing and continuously monitoring internet-facing assets that belong to or expose an organisation. It combines passive data sources with active validation to uncover domains, subdomains, certificates, IP space, cloud assets, APIs, services and mobile-linked infrastructure that known inventories can miss.
Security teams often begin with inventories created by IT, cloud teams, vulnerability scanners, or a CMDB. Those sources are useful, but they can miss infrastructure created outside standard processes, inherited through acquisitions, left behind after migrations, or exposed by teams that never registered the asset centrally.
Attack surface discovery works from the outside in. That makes it the discovery layer inside external attack surface management, which adds assessment, prioritisation and ongoing monitoring around the discovered footprint.
How does attack surface discovery work?
A practical discovery process follows five stages: seed, expand, attribute, validate and monitor. Each stage reduces uncertainty before an asset becomes part of the working attack-surface inventory.
Seed: Start from assets or identifiers already known to belong to the organisation, such as a primary domain, registered entities, known IP ranges or public applications.
Expand: Use DNS, certificate transparency data, registries, web references, cloud indicators and other external sources to find related assets and infrastructure.
Attribute: Decide whether each candidate is actually owned, operated or meaningfully connected to the organisation. Shared cloud infrastructure and reused IP space make this harder than simple enumeration.
Validate: Confirm reachability, ownership clues, service behaviour and supporting evidence. Weak or conflicting evidence should remain low-confidence until corroborated.
Monitor: Repeat discovery and validation as the environment changes so new assets and stale relationships do not disappear between scheduled scans.
What assets can attack surface discovery identify?
Attack surface discovery can identify externally observable infrastructure including domains, subdomains, IP addresses and ranges, certificates, cloud-hosted resources, websites, public APIs, internet-facing services, mobile applications and the technologies exposed through them.
Coverage depends on what is observable and how confidently an asset can be attributed. A discovered hostname may be easy to prove. A shared cloud IP may require several independent signals before it should be treated as owned infrastructure. ThingsRecon's Attack Surface Discovery product applies outside-in discovery across these asset types and attaches evidence to findings so teams can validate what was found.
What is the difference between active and passive discovery?
Passive discovery collects information that is already available through public or third-party sources, while active discovery sends requests to internet-facing systems to confirm what is reachable, exposed or running.
Passive methods can include certificate transparency logs, DNS datasets, registries, public application stores, and historical internet data. Active methods can include DNS queries, HTTP requests, service detection, and controlled scanning of identified hosts.
The distinction matters in supplier-side work because passive techniques can reveal relationships without requiring credentials or direct participation from the supplier. Active validation can then be used where scope and authorisation allow it. A strong discovery process uses both selectively instead of treating either method as complete on its own.
How does domain and subdomain discovery work?
Domain and subdomain discovery expands a known root domain into related hostnames and web properties that may expose applications, environments or services missing from the internal inventory.
Root domains provide a useful seed because DNS and certificate data can reveal related names. Subdomains often expose business applications, development environments, regional services, authentication portals, and legacy systems.
The main challenge is attribution. A name that contains the company brand may be unrelated, parked or controlled by a third party. Discovery should therefore combine naming evidence with DNS, certificate, hosting and content signals before ownership is assumed.
How do certificate transparency logs support attack surface discovery?
Certificate transparency logs provide a public record of many TLS certificates and can reveal hostnames that organisations have secured for internet-facing services.
Searching certificate names can surface subdomains that never appeared in a known asset list, including short-lived environments and services created by separate teams.
CT data is valuable because certificate issuance leaves a durable public clue. It also has blind spots: not every hostname receives a publicly logged certificate, certificates can contain stale names, and a listed name does not prove that a live service still exists.
How does DNS enumeration support asset discovery?
DNS enumeration maps records and relationships around known domains to reveal hostnames, mail infrastructure, name servers, service endpoints and third-party dependencies.
Passive DNS sources can show historical and observed relationships without querying the target directly. Active DNS queries can confirm current records and help distinguish live configuration from stale historical evidence.
DNS is highly informative, but shared hosting, CDNs, managed DNS providers and old records can create misleading associations. The result should feed attribution, not bypass it.
How are IP ranges and ASNs used in attack surface discovery?
IP and ASN analysis helps identify network space associated with an organisation and can reveal internet-facing hosts that do not share an obvious domain name.
Public routing and registry information can connect organisations to allocated address space or autonomous systems. Reverse DNS, certificates and service fingerprints can then help identify what is actually operating inside that space.
Cloud adoption makes ownership harder to infer from IP address alone. Large providers host many unrelated customers, so shared or ephemeral cloud addresses should not be assigned to an organisation without stronger evidence.
How are cloud assets discovered externally?
Cloud assets can be discovered when public hostnames, certificates, storage endpoints, service banners, DNS patterns or application references expose a link to a cloud-hosted resource.
Discovery may surface public web applications, storage endpoints, load balancers, API gateways, serverless endpoints and temporary environments. These assets can appear and disappear quickly as teams deploy new workloads.
Cloud-provider ownership and customer ownership are different questions. A public IP owned by a cloud provider says little about which tenant controls the workload, so attribution should rely on customer-specific evidence.
How are exposed APIs discovered?
Exposed API discovery looks for internet-reachable endpoints through application references, documentation, scripts, hostnames, traffic patterns and active validation of candidate routes.
Public APIs may sit behind obvious API subdomains, while others appear only inside JavaScript, mobile applications, developer documentation or linked services. Discovery establishes that an endpoint is observable; it does not by itself mean the API is vulnerable.
Once an endpoint is found, teams still need to confirm ownership, intended exposure, authentication requirements, and whether the API handles sensitive data.
How are internet-facing services discovered?
Internet-facing service discovery identifies reachable ports, protocols and applications on public hosts so teams can see what an external observer can interact with.
Controlled active scanning can confirm whether web servers, remote-access services, mail systems, administrative interfaces or other network services are reachable. Banners, TLS metadata and protocol behaviour can add technology context.
Reachability changes over time, and service identification can be ambiguous when proxies, CDNs or load balancers sit in front of the application. Service findings should therefore be tied back to asset ownership and current business use.
How do mobile applications connect to the attack surface?
Mobile applications extend the external attack surface because public app packages and store listings can reveal domains, APIs, authentication endpoints, analytics services and other infrastructure used by the application.
A mobile application can expose technical relationships that are difficult to see from the corporate website alone. Embedded endpoints and configuration references may point to production APIs, third-party SDKs or supporting services.
App-store presence does not prove every referenced endpoint is active. Mobile findings should be correlated with live DNS, certificates, API reachability and ownership evidence before they enter the inventory.
Why no single discovery technique is sufficient
No single source can produce a reliable attack-surface inventory because every technique sees a different part of the footprint and carries different attribution risks.
Certificate data may reveal a hostname that DNS history confirms. DNS may point to an IP range that active validation shows is no longer used. A mobile application may expose an API endpoint that a domain-only scan would never discover. Confidence rises when independent signals support the same conclusion.
This is also where false positives enter the process. Enumeration is relatively easy. Deciding whether a discovered asset genuinely belongs to the organisation is harder.
Attack surface discovery techniques compared
Technique | What it finds | Active or passive | Confidence | Blind spots |
|---|---|---|---|---|
| Domain discovery | Known and related root domains, branded web properties | Mostly passive | High when registration, content and infrastructure evidence align | Brand matches can be unrelated; parked or acquired domains can be stale |
| Subdomain discovery | Applications, environments and services under known domains | Both | High when DNS and certificate evidence agree | Wildcard DNS, ephemeral hosts and internal-only names |
| CT logs | Certificate names and hostnames associated with TLS issuance | Passive | Medium to high with corroboration | Stale certificates; names may no longer resolve or belong in scope |
| DNS enumeration | Hostnames, mail systems, name servers, service records and provider relationships | Both | Medium to high | Shared DNS, CDNs and stale records can mislead attribution |
| IP ranges / ASNs | Public network ranges and hosts associated with routed address space | Mostly passive, then active validation | High for dedicated allocations; lower in shared cloud | Cloud and shared hosting weaken IP-based ownership |
| Cloud discovery | Public cloud endpoints, storage, gateways, load balancers and hosted apps | Both | Variable | Provider-owned infrastructure does not prove tenant ownership |
| API discovery | Public API hosts and endpoints referenced by apps, code or documentation | Both | Medium to high once ownership is confirmed | Undocumented private APIs and endpoints hidden behind authentication |
| Service discovery | Reachable ports, protocols, applications and exposed management services | Active | High for reachability; variable for ownership | Proxies, CDNs and load balancers can obscure the backend |
| Mobile applications | App-linked domains, APIs, SDKs and supporting services | Mostly passive, with optional active validation | Medium to high with live corroboration | Old app versions and dormant endpoints can create stale evidence |
Discovery is a continuous process because the attack surface keeps changing
A discovery scan gives you a view of the external footprint at one moment. The environment changes as teams deploy applications, create cloud resources, add domains, retire services, complete acquisitions and move infrastructure between providers. New exposure can appear without waiting for the next annual inventory review.
That is why attack surface discovery needs a monitoring loop. Continuous attack surface monitoring repeats discovery, attribution and validation so teams can detect meaningful changes instead of rebuilding the perimeter from scratch each time.
The hardest part remains attribution. Finding another hostname or open service is useful only when the security team can decide whether it belongs to the organisation, who owns it, whether the exposure is expected and what action should follow. A credible discovery programme therefore measures the quality of the evidence as carefully as the quantity of assets found.
See attack surface discovery in action with ThingsRecon Attack Surface Discovery, which maps externally visible assets and monitors how the footprint changes over time.
