The subdomain nobody remembered

In 2023, a marketing team launched a campaign. They needed a landing page fast, so they spun one up on a cloud hosting service and pointed a subdomain at it — promo.thecompany.com. In the DNS, that's a single line: a CNAME record aiming the subdomain at the hosting provider's address. It worked. The campaign ran. Everyone moved on.

In 2024, the campaign ended. Someone deleted the hosting account to stop paying for it. Reasonable. Tidy, even.

Nobody deleted the DNS record.

In 2026, a stranger found it — and for the price of nothing, published whatever they liked on a subdomain of a company they had never worked for. This is subdomain takeover, and the reason it's worth understanding is that every step in the story is something a normal, competent team does. There is no mistake here to feel superior about. There is only a loose end nobody was watching.

When you point promo.thecompany.com at a cloud service with a CNAME, you're saying: whoever answers for this name over at the hosting provider, that's us. While your account exists, the provider answers with your page. Clean.

When the account is deleted, the provider stops answering for that name — but your DNS record still confidently points at it. The subdomain now aims at a slot on someone else's infrastructure that belongs to no one. In the trade it's called a dangling record. It resolves to nothing… until someone claims the slot.

And claiming it is often trivial. Many cloud platforms let anyone register any unused project name, first-come. An attacker who finds your dangling CNAME simply signs up for that same platform, registers the exact name your record still points to, and now they are who the provider answers for. Your subdomain — with your company's name in it — serves their content.

A page hosted at promo.thecompany.com isn't a stranger's site. As far as browsers, users, and often other systems are concerned, it is the company.

• Phishing that defeats the one rule everyone's taught. "Check the URL before you enter your password" fails completely here, because the URL is real. A login page served from a taken-over subdomain passes the exact check people are trained to trust.
• Cookies can be in scope. Depending on how cookies were scoped (a Domain=.thecompany.com cookie, for instance), a page on a subdomain may be able to read session cookies set by the main site.
• Reputation and reach come free. The subdomain may already be trusted by email filters, allow-lists, and integrations. The attacker inherits all of it without earning any of it.
• It can escalate. Control of a subdomain sometimes lets an attacker obtain a valid TLS certificate for that name, or receive email addressed to it — deepening the impersonation.

And the discovery cost, for the attacker, is near zero. They don't target you specifically. They run automated scans across millions of domains looking for CNAME records that point at unclaimed slots on popular platforms, and they harvest whatever falls out. Your forgotten subdomain isn't found because someone was hunting you. It's found because someone was hunting everyone, constantly, and your loose end was in the net.

There's nothing clever to build here. The defense is inventory and hygiene, and it fails for the most human reason: it's boring, it's nobody's job, and the thing it protects against is invisible until it isn't.

1. Enumerate every subdomain your domain has ever had. Not the ones you remember — all of them. DNS records, old certificates (certificate transparency logs are a public list of every cert ever issued for your domain, and a great place to find subdomains you forgot), analytics, that campaign from three years ago.
2. For each one, ask a single question: does the thing it points to still exist, and do we still control it? A CNAME aimed at a live service you own is fine. A CNAME aimed at a deleted account is a live vulnerability.
3. Delete the dead records. An unused subdomain is not neutral. It is attack surface with your name on it.
4. Then keep looking. The zone you audit clean today grows a new loose end the next time a team needs a landing page fast.

Most security advice is about doing something. This one is about un-doing — about the records, accounts, and endpoints that were fine when you created them and became dangerous only through neglect. Your attack surface isn't the diagram you drew when you designed the system. It's everything your DNS still admits to, including the things you've forgotten you own.

The question worth sitting with: when did anyone last look at your full DNS zone — not the records you use every day, but the complete list — and ask, of each one, do we still control what this points to? For most companies, the honest answer is never. Which is the same answer the marketing team would have given in 2024, right before the story started.

Mapping a domain's exposed and dangling subdomains is one of the first things a [Webcuris](/) scan does — because your attack surface is defined by what's reachable, not by what you remember deploying. You can [run a free scan, no signup](/scan). Or just pull your DNS zone and read it top to bottom today. Either way, look before someone else does.