External attack surface: the complete guide

Your external attack surface is every point at which your organisation can be reached from the internet without authenticating first. A web server, an API, a login portal, a mail server, a storage bucket, a forgotten staging machine — anything that answers a request from outside belongs to it.

The distinction that matters: this surface is not what you decided to publish. It is what is actually reachable. The gap between the two is precisely where incidents happen.

Exposure is not the same as vulnerability An exposed service is not a flaw. A public web server is normal — that is its job. Risk comes from unintended exposure: an admin interface reachable without a VPN, a database open to the world, a test environment running on production data.

Reducing your attack surface is therefore not about closing everything. It is about making sure that everything exposed is exposed deliberately.

No organisation decides to widen its attack surface. It widens by accumulation, and almost always along the same paths:

• An agency spins up a campaign site on a subdomain. The campaign ends; the subdomain stays.
• A team deploys a staging environment behind a CNAME. The project ships; the DNS record outlives it.
• A SaaS product is trialled and dropped, but the subdomain still points at it.
• A certificate is issued for an internal host, and that hostname lands in a public log anyone can read.

What these have in common is that nobody made a visible mistake. Every step was reasonable at the time. It is the absence of an inventory, not an error, that produces the drift — which is why it is worth periodically looking at your own domain through the eyes of someone who only has public sources.

An attacker preparing an intrusion does not start by attacking yourdomain.com. They start by listing everything that exists around it: vpn., admin., staging., jenkins., backup., old. Each of those names is a candidate target, and the interesting ones are rarely the ones you monitor.

How that list is built without touching you Subdomain enumeration is almost entirely passive today, and the sources are all public.

• Certificate Transparency logs record every certificate ever issued, and each one names the hosts it covers. crt.sh will show you yours in a browser.
• Passive DNS providers keep historical resolution data, including records you deleted years ago.
• Search engines have already indexed pages nobody meant to publish.
• Internet-wide scanners publish what they found on your IP ranges.

None of this sends a single packet to your infrastructure. That is the part worth sitting with: the reconnaissance leaves no trace in your logs, so you cannot detect that it happened, and you cannot know whether it already has.

What to do with the list Enumerate first, judge second. Build the full inventory, then sort every entry into one of three piles: it should be public and is configured accordingly, it should not be public and needs to move behind a VPN or an allowlist, or it should no longer exist and its DNS record must go.

That third pile is usually the largest. It is also the cheapest to clear, which makes it the right place to start.

Every certificate issued by a publicly trusted authority is recorded in Certificate Transparency logs. These logs exist for a good reason. They let anyone detect a certificate issued fraudulently for a domain they own. They also have a side effect that is easy to overlook.

The moment you request a certificate for an internal host, its name becomes world-readable. Names like vpn., jenkins., sap-preprod. or backup-admin. hand an attacker a map of your internal naming conventions, and usually a list of new targets, even when those hosts are not reachable from outside.

You can see your own in about five seconds:

https://crt.sh/?q=%25.example.com

ReconScope reads the same logs, through certSpotter with crt.sh as a fallback, and flags the entries whose names look internal rather than public.

What to do about it - Do not put purely internal hostnames into publicly trusted certificates. Use a private certificate authority for internal services. - Consider split-horizon DNS, so internal names never need a public certificate in the first place. - Use a wildcard certificate where individual names would describe your architecture.

One caveat that changes how you should think about this: a name already published in a CT log cannot be withdrawn. The logs are append-only by design, which is precisely what makes them trustworthy. There is no cleanup available to you. The only remedy is to stop adding, and to treat everything already in there as known to your adversary.

Subdomain takeover is one of the few findings that is almost always a real, immediately exploitable problem rather than a theoretical risk. That is why it deserves to be checked first when you find an unfamiliar record.

The mechanism is simple. A subdomain points, via a CNAME, at a third-party service: a hosting platform, a documentation tool, a CDN. The service is later cancelled or the resource deleted. The DNS record is not. The name now points at an unclaimed slot on that provider.

dig +short CNAME shop.example.com
example-shop.someprovider.net.
  the provider account no longer exists
  anyone may register that name and serve content from it

Whoever claims that slot serves content from a hostname carrying your brand, your reputation and, depending on how your cookies are scoped, potentially your sessions. It makes an ideal phishing platform precisely because the domain genuinely is yours. Browser warnings will not fire. Your customers have no way to tell.

What to do about it Delete dangling DNS records immediately, or reclaim the resource at the provider. Then make the fix structural: add a CNAME audit to your decommissioning checklist, so retiring a service and retiring its DNS record become one task instead of two. The second one is what everybody forgets.

Beyond names, there is what actually answers. Internet-wide scanners continuously catalogue open ports, running software and its version. That catalogue is public and searchable, which means an attacker can find your exposed services without scanning you — and therefore without appearing in any of your logs.

Two things are worth separating here, because they are frequently confused.

What is yours, and what belongs to your host On shared hosting, most of the services visible on your IP address belong to the hosting provider, not to you. Reading that list as a catalogue of your own failures is a mistake, and it leads people to chase findings they cannot act on.

What does remain yours, on any kind of hosting, is anything where your own credentials travel: an unencrypted FTP service, a control panel served over plain HTTP, an administration interface reachable from anywhere. Those are worth acting on regardless of who operates the machine.

Known vulnerabilities When a scanner records a service version, correlating it with published CVEs is trivial. An unpatched service with a public exploit is not a hypothetical risk: it is a target that requires no reconnaissance effort at all.

The work is less about tooling than about sequence. In practice:

• Inventory first. You cannot protect what you have not listed, and the list is almost always longer than expected.
• Delete before you defend. Every dangling DNS record and every decommissioned service you remove is a target that no longer needs protecting.
• Move administration behind a boundary. VPN or an IP allowlist for admin panels, staging environments and internal tooling.
• Separate staging from production data. A test environment holding real data is a production breach waiting for a weaker password.
• Make decommissioning a checklist. Most drift comes from services that were switched off without their DNS record, their certificate or their storage bucket being switched off with them.
• Re-check on a schedule. The surface is not a state, it is a flow: it changes every time a project ships.

None of this requires a large budget. It requires knowing what exists.