An organization’s official inventory and what is actually reachable from the Internet are rarely identical. The difference may be small, but a single forgotten asset can create a path that no one is monitoring.
That is the central challenge of the external attack surface. An attacker does not need to understand the organization chart, the CMDB, or the intended architecture. They observe what responds publicly, connect signals, and look for opportunities.
A blind spot in the external attack surface is an asset that answers publicly without appearing in the inventory the organization defends from. The seven that show up most often are: subdomains that outlived the project that created them; cloud services created outside the main workflow; accessible ports and administrative interfaces; certificates that reveal uninventoried assets; APIs that keep working after the integration ended; dependencies and suppliers connected to the brand; and known assets whose context has changed. What they share is not a technical flaw but their absence from the inventory: an attacker looks at what answers, not at what is documented.
Here are seven blind spots that commonly appear in the gap between the known environment and the observable one.
1. Subdomains that outlived the project
Campaigns, proofs of concept, staging environments, and temporary integrations create subdomains. The project ends, but the DNS record remains. Sometimes the destination still responds. In other cases, the record points to a third-party service the organization no longer controls.
The problem is not simply having many subdomains. It is not knowing which ones still have a legitimate purpose, who owns them, and whether they remain secure.
2. Cloud services created outside the main workflow
Product teams need to move quickly. A bucket, function, application, or virtual machine may be published to meet an immediate need. If that resource never enters the inventory and review process, a gap develops between the managed cloud and the cloud that is actually exposed.
Accounts inherited through acquisitions, supplier projects, and lab environments add even more fragmentation.
3. Reachable administrative ports and interfaces
Administration panels, VPN gateways, consoles, databases, and remote access services should not be publicly available without a clear need and appropriate safeguards. Yet firewall changes, migrations, and default configurations can make an interface reachable from the Internet.
CISA’s Internet Exposure Reduction Guidance starts by identifying accessible assets, deciding whether that exposure is necessary, and removing or restricting anything that does not need to be public.
4. Certificates that reveal untracked assets
TLS certificates leave useful clues. Alternative names, issuers, and relationships between domains can reveal applications that do not appear in a simple search. A newly issued certificate can also indicate that a service has just been published.
This is why external discovery should not depend on a single source. DNS, certificates, IP addresses, services, and technologies are different parts of the same map.
5. APIs that remain after the integration
An API can remain active after the application that used it has been replaced. Old endpoints, legacy versions, and public documentation all expand reconnaissance opportunities.
Not every old API contains a vulnerability. But a forgotten interface is likely to receive less maintenance, monitoring, and testing precisely because it has disappeared from the operational view.
6. Dependencies and suppliers connected to the brand
The external perimeter does not end with directly operated assets. Supplier portals, marketing platforms, support services, and other components may use domains, certificates, or identities associated with the organization.
The goal is not to treat every third-party service as owned infrastructure. It is to understand the relationship, the potential impact, and who needs to act when an exposure appears.
7. Known assets whose context has changed
An asset can remain in the inventory and still become a blind spot. The team knows it exists but misses a newly opened port, obsolete technology, active exploitation of a vulnerability, or the end of vendor support.
Visibility without continuous monitoring grows stale. The surface changes through new assets and through changes in the context of assets already present.
One blind spot, followed to the end
The seven above describe categories. It is worth following one of them all the way through, because the real work happens in the detail.
Consider a subdomain created for a campaign that ended two years ago. The DNS zone still holds the record:
promo.example.com. CNAME campaign-2024.page-hosting-provider.example.From the inside, nothing stands out. The subdomain is not in the CMDB because it was never a service; it was an address pointed at a page hosted by a third party. The agency that ran the campaign closed its contract, the account with the provider was cancelled, and the DNS zone was never reviewed alongside it.
From the outside, it reads differently. The CNAME still resolves, so the name
exists. But the provider no longer recognises campaign-2024 as an active site
and answers with its generic “project not found” page. That combination — a
record pointing at a service that no longer claims the name — is what makes the
subdomain a candidate for subdomain takeover: with several hosting
providers, whoever creates a project under that identifier begins serving
content at promo.example.com.
The check is straightforward and needs no privileged access:
- Resolve the chain.
dig promo.example.com CNAMEshows where the name points and whether the target still resolves. - Ask for the page. An HTTP request to the subdomain returns either the expected content or the provider’s default response for a project that does not exist.
- Confirm the name is claimable. This is the difference between a useless record and an exploitable one, and it depends on the provider: some require proof of domain ownership before accepting a name, others do not.
- Decide who answers for it. Marketing created it, IT administers the zone, and neither has the subdomain on its list.
The fix is cheap once somebody knows the record exists: remove the entry from the zone, or claim the name at the provider before anyone else does. The cost is not in the repair. It is in the finding.
And this is where the example stops being about subdomains. The asset had no vulnerability, was not out of date and was not misconfigured. It left the inventory because the project that justified it ended while the record that published it remained. The other six blind spots fail the same way: a resource keeps answering after its reason has gone, and the defence starts working from a map older than the territory.
Turning discovery into exposure reduction
A practical process begins with four questions:
- What is reachable? Discover domains, IP addresses, services, applications, APIs, and cloud resources from an external perspective.
- Is the exposure necessary? Confirm its purpose, owner, and operational justification.
- What can be exploited? Connect vulnerabilities, configurations, credentials, and possible paths.
- What should change first? Prioritize based on exposure context, attack feasibility, and potential impact.
This avoids two extremes: trusting only the internal inventory or generating a huge external list without enough context to act.
The value of Attack Surface Management is not finding the largest number of assets. It is reducing the gap between what the organization believes it owns and what an attacker can observe.
References
- CISA — Internet Exposure Reduction Guidance
- NIST — Attack Surface
- OWASP — Attack Surface Identification
Continue exploring
Want to see your organization from the outside in?
See how Lion Focus helps discover, monitor, and prioritize cyber exposures before they become incidents.
Leonnes Cybersecurity
Cyber Exposure Platform
