How many subdomains do you have? Your number is probably wrong

Ask your team: how many subdomains does the organization have? The answer comes quickly, often as a round number. Now compare it with what anyone can find in two minutes, from the outside, without asking you anything. The gap between those two numbers is the most honest measure of your exposure: what is online under your name, but owned by no one.

Attackers do not need to force the front door, the one that is watched, patched and documented. They look for the one everybody forgot.

What stays online when the project ends

Exposure without an owner is rarely born of a mistake. It is born of an ending: a campaign wraps up, a project closes, a vendor is replaced, a company is acquired. The project stops, the budget line disappears, the team moves on. What was online often stays there.

The same families show up from one organization to the next:

• The subdomain of an old campaign: a contest site, an event page, a test portal set up by an agency. The contract is over; the address still points somewhere.
• The cloud instance of a finished project: a demo virtual machine, a storage bucket shared "for the duration of the project", a staging database nobody turned off.
• The tool a department bought: a SaaS product paid by credit card by marketing, sales or HR, holding company data and connected to your email. IT does not see it, so nobody reviews it. It is a cousin of the shadow AI our AI series covered.
• The end-of-life server or appliance: it works and does its job, but the vendor no longer ships patches. Every flaw found after end of support stays open for good.
• The orphaned DNS record or certificate: a record pointing to a service that no longer exists, a certificate that expires without anyone getting the warning, because the notification address belonged to someone who left.
• The old site of a subsidiary: after an acquisition, the acquired company's website, email and servers live on next to yours, with their own rules, or none.

What it changes: none of these assets shows up in the remediation plan, because none has an owner to put it there. They are not badly managed. They are not managed at all.

The textbook case: subdomain takeover

One example shows why forgetting is not harmless. Microsoft describes it in detail in its Azure documentation as "dangling DNS", a DNS record left hanging. The scenario takes three steps:

1. Creation. A team creates a cloud resource and adds an alias in your DNS zone, say promo.yourcompany.com, pointing to it.
2. Deletion. The project ends and the resource is deleted. The alias stays in your DNS.
3. Takeover. An attacker spots the orphaned alias, creates a resource with the freed-up name at the same provider, and now receives the traffic meant for your subdomain. They control its content.

Microsoft calls these takeovers a "common, high-severity threat" for organizations that create and delete many resources. The consequences it lists go beyond brand damage: a phishing page hosted under your own domain name, session cookies harvested from unsuspecting visitors, and even a valid TLS certificate issued to the attacker for that subdomain. As Microsoft points out, a certificate does not protect you here, since the attacker can get one. Status: documented by the vendor.

The mechanism is not specific to Azure. Any service that gives you a name you point to from your DNS, then releases it when you delete the resource, can create the same gap. The fix is simple; the inventory is the hard part.

Why your inventory does not see them

Most inventories are built from the inside: what IT bought, installed and declared. Ownerless exposure is visible from the outside. It exists precisely because it never went through the processes that feed the inventory.

That is why CISA made asset discovery an obligation rather than a best practice. Its Binding Operational Directive 23-01, issued on October 3, 2022 for US federal agencies, starts from a simple premise: continuous and comprehensive asset visibility is "a basic pre-condition" for any organization that wants to manage its risk. It requires automated asset discovery every seven days, and vulnerability enumeration across everything discovered every fourteen days. Status: official text. You are not a federal agency, but the order of magnitude applies to everyone: an inventory refreshed once a year describes an organization that no longer exists.

On end of life, CISA is just as clear. Its list of "bad practices" puts the use of unsupported software in critical infrastructure at the top, a practice it calls dangerous and "especially egregious" for technologies accessible from the Internet. An exposed end-of-life device is a known flaw that will never be fixed.

This is exactly the ground covered by external attack surface management (EASM): looking at the organization the way an attacker sees it, rather than the way it describes itself.

The method: find, assign, decide

1. Find, from the outside. Start from your domain names and list what actually exists: subdomains, IP addresses, services that answer, certificates issued in your name. Add what the outside cannot show but accounting knows: SaaS subscriptions paid by credit card, cloud accounts opened per project, domains registered by an agency.

2. Assign an owner, by name. One person per asset, not a department. If nobody raises a hand within two weeks, the asset becomes the default responsibility of whoever leads security, with a deadline to decide. An asset with no name next to it stays exposed indefinitely.

3. Decide: keep, fix or retire. Three outcomes only.

• Keep: the asset is in use; it joins the inventory, the remediation plan and monitoring, like everything else.
• Fix: it is in use but misconfigured, unsupported or poorly protected; upgrade it, replace it, or take it off the Internet in the meantime.
• Retire: it is no longer used. Delete the DNS record then the resource, in that order: if the resource goes first, the alias is left dangling, even for a few days. Cancel the subscription, recover the data.

Then, so the backlog does not build up again, add one line to your procedures for project closure, vendor change and acquisition integration: "remove DNS records and access, and check they are gone". Microsoft makes exactly this recommendation: put removing the DNS entry on the list of required checks when decommissioning a service.

This week's test: twenty minutes, two numbers

1. Ask your team, without letting them look it up: how many subdomains do we have? Write the number down.
2. Open a Certificate Transparency log search engine, such as crt.sh, and search for your main domain. These logs are public and append-only: every TLS certificate issued for your names is recorded there, and anyone can query them. Attackers do.
3. Count the distinct subdomains that appear, then compare.

Three results should worry you. A gap nobody can explain between the two numbers: your inventory describes what you planned, not what you have. Names nobody recognizes: each one is an ownerless asset to deal with this week. Names of finished projects, past campaigns or an acquired company: check that they no longer point anywhere, or that they point to something you still control.

This test only sees what received a certificate. It therefore underestimates the problem: it is a floor, not a ceiling.

What you should have by next Saturday

A list, even a short one, of exposed assets nobody owned, with a name and a decision next to each: keep, fix or retire. And one line added to your project closure procedures. It is modest. It is also the part of the attack surface attackers find first, because nobody defends it.

To go further on the method, our glossary entry on external attack surface management explains how to move from a one-off inventory to continuous discovery.

Sources: Microsoft Learn, Prevent dangling DNS entries and avoid subdomain takeover · CISA, Binding Operational Directive 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks · CISA, Bad Practices · Certificate Transparency, How CT Works