Attack surface management: the assets you forgot you had

Attackers do not need to find a flaw in your flagship product if a forgotten staging server answers on the internet. They enumerate your external surface continuously and automatically. Most organisations enumerate theirs once a year, from a list that was already wrong.

What tends to be exposed and unknown

• Forgotten subdomains - a campaign microsite, an old API version, a demo environment from a project that ended.
• Non-production environments reachable from the internet, usually with weaker controls and sometimes production data.
• Shadow cloud accounts opened with a card by a team in a hurry.
• Acquired infrastructure inherited without a proper inventory.
• Third-party hosted assets - a marketing site on an unpatched CMS, a status page, a support portal.
• Exposed management interfaces - admin panels, databases and dashboards that were never meant to be public.
• Dangling DNS records pointing at deprovisioned cloud resources, which is what enables subdomain takeover.

Subdomain takeover deserves specific attention: a CNAME pointing at a cloud service that no longer exists can often be claimed by someone else, giving an attacker a legitimate hostname on your domain - complete with a valid certificate. It is cheap to find and cheap to fix, and it is missed constantly.

Discovery, not inventory

The asset inventory tells you what you think you have. Discovery tells you what actually answers. The gap between them is the point of the exercise, and it is never zero.

Practical sources: certificate transparency logs, passive DNS, your registrar and DNS zones, cloud provider APIs across all accounts, IP range ownership records, and public code repositories. Run it continuously - the surface changes every time someone deploys something.

Prioritising what you find

A first run produces an overwhelming list. Order it by:

1. Exploitable now - known-exploited vulnerabilities on internet-facing assets. Everything else waits.
2. Exposed management interfaces and authentication endpoints without MFA.
3. Unknown ownership - an asset nobody claims is an asset nobody patches.
4. Data-bearing assets, especially non-production ones with real data.
5. Dangling DNS, which is fast to remediate.

The fix is often deletion

The satisfying part of this work is how much of it resolves by switching things off. A large share of discovered exposure is genuinely unused - old environments, retired campaigns, superseded APIs. Decommissioning removes the risk permanently rather than adding a control to manage it.

Which is why the process needs an owner with authority to turn things off, and a route to confirm nothing broke.

Making it stick

Run discovery continuously, alert on new exposure rather than reporting the whole list monthly, require an owner for every asset, and tie decommissioning into project closure so environments do not outlive their projects. Feed confirmed assets back into the inventory, or you rediscover the same things every quarter.

Key takeaways

• Discovery finds what answers; inventory records what you believe. Mind the gap.
• Dangling DNS enables subdomain takeover and is cheap to fix.
• Prioritise known-exploited issues on internet-facing assets first.
• Much of the fix is decommissioning, which removes risk permanently.