Every company has a graveyard. It is not in the office. It is in DNS: the subdomains that were created for a launch, a campaign, a vendor, a product that no longer exists. Nobody visits them. Nobody deletes them. And they do not stay quiet.

In our latest batch of assessments, 19 percent of the companies we attacked had at least one subdomain that was dangling, parked, or pointing somewhere it should not. More than half the companies had forgotten estate of some kind. This is the sixth finding in our field series, after endpoints that skip authentication, exposed internal tools, forgotten staging environments, secrets in JavaScript bundles, and exposed origins. This one is about the names your customers still trust, long after you stopped maintaining them.

What a dangling subdomain is

A dangling subdomain is a hostname that still belongs to your domain but no longer points at anything you control. It may resolve to a dead address, redirect to a stranger's page, or sit parked on someone else's service. MITRE classifies the redirect case as CWE-601, URL Redirection to Untrusted Site. The takeover case is its more dangerous cousin: a hostname pointing at a service you no longer own, waiting for someone to claim it.

Subdomains are trust. Your main domain earns that trust over years. Every subdomain borrows it for free, and keeps borrowing it after it dies.

What an attacker does with it

The attacker does not need to hack anything. They need to notice what you forgot. Real findings from recent engagements, anonymized:

A company's .ai domain was parked on a third-party page. The company had moved to a different domain, but the old one still looked official, and it was free for anyone to impersonate.
A community subdomain redirected to a defunct, unrelated third-party site. Visitors who followed a trusted link landed somewhere the company had never heard of.
An official-looking GitHub organization under a well-known company's name belonged to a private individual who had nothing to do with the company. The brand drove traffic there.
A link-shortener subdomain served a bare third-party landing page, a blank wall where a company service used to be.
A whole family of staging subdomains pointed at a domain that no longer resolved. Dead CNAMEs, waiting for the domain to be registered by someone else, which is exactly how subdomain takeover works.
A subdomain's TLS certificate had expired months earlier. Visitors got a browser warning on a company URL.

None of these required breaking in. They required looking.

Worth saying: the core applications at these companies usually held up under direct testing. The forgotten estate around them did not.

Why this is a real problem

A dead subdomain is phishing infrastructure that you did not build but still own. Attackers use your domain's reputation: the link looks real, the email address looks real, the login page looks real, because the domain is real. When a user checks the URL, it passes. That is the whole point.

Subdomain takeover makes it concrete. If a subdomain points at a cloud service you no longer control, an attacker can claim that service, serve their own content on your hostname, and collect cookies, credentials, and trust. The fix is not user education. The fix is deleting the record before someone else claims it.

There is a quieter cost too. Every dead subdomain is a door in your attack surface that nobody audits. When we enumerate a company, the forgotten estate is where the interesting things hide: old admin panels, old APIs, old staging environments, all still resolving, all unpatched.

Why companies leave dead subdomains

The reason is that DNS has no owner. Subdomains are created by many teams over many years, and deleting one is nobody's job. There is no review, no cleanup sprint, no alert when a record goes stale. A subdomain costs nothing to keep, so it is kept.

Migrations make it worse. A rebrand, an acquisition, a move to a new domain, and the old estate is abandoned wholesale, still resolving, still trusted. The team celebrates the migration and never looks back at what it left behind.

And the services that host subdomains make it easy to forget. A marketing campaign spins up a subdomain on a vendor platform, the campaign ends, the vendor account lapses, and the record stays, pointing at a service that is now free for the taking.

How to fix dangling subdomains

The fix is inventory plus a habit. Four steps.

Step one. Enumerate your own estate. Query certificate transparency logs and DNS for every subdomain your domains have ever used. You cannot clean up what you cannot list. The list will be longer than anyone expects.

Step two. Classify every record. For each subdomain: does it still serve a purpose? Does it point at something you control? Is the certificate valid? Anything dead, parked, or pointing at a lapsed service is a finding, not a footnote.

Step three. Delete or reclaim. Remove records that serve no purpose. For anything that must stay, renew the certificate, move it behind your identity layer, and make someone own it. A subdomain should have an owner the way a service does.

Step four. Re-check on a schedule. New subdomains appear with every campaign and vendor. Old ones die quietly. The inventory from last quarter describes last quarter. This is the same lesson as every finding class we report: the check has to return when the software changes, and DNS changes constantly.

Frequently asked questions

What is a dangling subdomain?

A subdomain that still belongs to your domain but no longer points at anything you control. It may resolve to a dead address, redirect to a stranger's page, or sit parked on a service you no longer own. It keeps your domain's trust without your maintenance.

What is subdomain takeover?

When a subdomain points at a service you no longer control, an attacker can claim that service and serve their own content on your hostname. Visitors see your domain and trust it, while the attacker collects credentials, cookies, or installs malware.

How do I find my company's dead subdomains?

Query certificate transparency logs, such as crt.sh, and DNS records for every subdomain your domains have ever used. Then check each one: does it resolve, where does it point, and is the certificate valid. The difference between what exists and what you knew about is your cleanup list.

Are parked domains a security problem?

Yes, when they still carry your brand. A parked domain that looks official is impersonation infrastructure: attackers can use it for phishing, or simply let it erode the trust your real domain has earned. If you no longer use a domain, it should not resolve.

How often should I audit my subdomains?

On a schedule, and after every migration, rebrand, or vendor change. New subdomains appear with every campaign, and old ones die quietly. Quarterly is a reasonable baseline, with an immediate audit after any domain move.

The point

We keep finding dead subdomains because DNS has no owner and no cleanup. Every record is a promise your domain made years ago, still being kept by nobody.

If you want to know where you stand, it takes a few minutes. Search crt.sh for your domain and read the list. Anything you do not recognize, anything parked, anything with an expired certificate, that is the finding.

And if you would rather have someone enumerate the whole estate, dead names and all, and keep watching as it grows, that is exactly what we do.

Related reading: The Email Finding We Keep Reporting — the DNS record that lets anyone send email as your company. And Your Firewall Protects a Door Next to an Open Window — the other thing hiding in your infrastructure.