A door you built, forgot, and left unlocked

Subdomain takeover is one of the quietest serious exposures a lean team carries, because it's created by the most ordinary act in modern infrastructure: pointing a DNS record at a cloud service. You set up status.yourcompany.com as a CNAME to a hosted status page, docs.yourcompany.com to a docs platform, go.yourcompany.com to a link shortener. Each one works perfectly. Then, months later, someone cancels the status-page subscription or tears down the cloud bucket — and never removes the DNS record. The subdomain now points at infrastructure nobody owns.

That dangling record is an open invitation. If an attacker can register the same resource name on that cloud provider — the same bucket name, the same app slug, the same hosted hostname — the provider happily serves their content at your subdomain. The browser shows yourcompany.com in the address bar. The TLS padlock is green. And the page is now under the attacker's control.

Why a subdomain you forgot about is worth real damage

The instinct is to shrug — it's just an old status page. But the value to an attacker isn't the page; it's the name. A live subdomain under your registered domain inherits your reputation and, depending on configuration, more:

  • Convincing phishing. A login page hosted at secure-login.yourcompany.com defeats the single best defense employees and customers have: checking the domain. The domain is real.
  • Cookie and session theft. Cookies scoped to .yourcompany.com are sent to every subdomain. A controlled subdomain can read session cookies and CSRF tokens that were never meant to leave your real app — a same-origin assumption quietly broken.
  • Brand abuse and malware delivery. Malware served from your own domain sails past reputation filters and lands the blame, and the cleanup, on you. This is the same outside-your-perimeter reputational hit that brand impersonation monitoring exists to catch — except here the attacker didn't even need a lookalike domain; you handed them the real one.

Why your normal scans miss it

A subdomain takeover usually doesn't show up where you look. Your vulnerability scanner checks the hosts you tell it about — and a dangling record points at a host you no longer run, so it isn't in your inventory. The dangerous gap is precisely the one between what you meant to deploy and what your DNS still advertises, which is the whole reason attack surface management takes the attacker's outside-in view: enumerate every name your domain resolves, then ask which ones resolve to nothing you control.

This is the resolution chain to watch:

  • Dangling CNAME records pointing at a deprovisioned SaaS host, the classic case — the third-party service is gone but the pointer remains.
  • Stale A/AAAA records pointing at a released cloud IP that's since been reassigned to someone else's instance.
  • Unverified or unclaimed service names where the provider returns a telltale "no such app / bucket not found" page — the fingerprint that the resource is up for grabs.

Finding the dangling records before an attacker does

The fix is mostly inventory discipline applied to DNS, and a lean team can absolutely finish it.

  • Enumerate every subdomain you publish, not just the ones you remember. Certificate-transparency logs are a goldmine here: every TLS cert ever issued for your domain names a subdomain, including the ones the marketing team spun up and forgot.
  • Resolve each record and check what answers. A subdomain whose target returns a provider's "unclaimed resource" page, or no longer resolves to anything you operate, is a candidate takeover. This is the same asset-inventory reconciliation — what we advertise versus what we actually run — pointed at DNS.
  • Make decommissioning remove the record. The root cause is a process gap: tearing down a service should always include deleting its DNS entry, the same way secure offboarding closes accounts on the way out. Tie the DNS record's lifecycle to the resource it points at.

Treat a dangling record as a finding with a clock

A confirmed or suspected takeover isn't a cleanup task for someday — it's a finding with an owner and a deadline, ranked by what the subdomain can reach. A dangling record under a name that shares session cookies with your main app, or one that looks like a login or payment host, is an emergency; a forgotten marketing microsite is lower. That's the same exposure-first triage you apply everywhere, and the remediation is blunt and fast: delete the orphaned DNS record, or reclaim the resource so you control it again.

And because DNS changes constantly, this is a continuously monitored check, not a one-time sweep. New subdomains appear every time a team tries a tool; the gap between "we cleaned this up in March" and "marketing launched four subdomains in April" is exactly where the next takeover hides. It belongs in the broader DNS and domain hygiene routine you run on a cadence.

It maps to the audit, too

No framework says "subdomain takeover" by name, but they all ask how you manage your assets, control changes to infrastructure, and protect the systems your customers depend on. A maintained DNS inventory, a decommissioning process that removes records, and evidence that you monitor for dangling entries answer those questions directly, and they drop into continuous evidence collection alongside the rest of your posture.

One honest caveat: a platform can enumerate your subdomains, flag the records that resolve to unclaimed infrastructure, raise them as findings, and track the fix — it organizes, watches, and proves the work. It does not delete your DNS records, reclaim a cloud resource, or grant or guarantee any certification; the record deletion and the decommissioning discipline are operational steps your team owns, and which obligations apply to you is a question for counsel.

A subdomain takeover is a door you built, forgot, and left unlocked — and the attacker who walks through it does so wearing your name, with a real TLS padlock and your domain in the address bar. The defense is unglamorous inventory: enumerate every subdomain (certificate-transparency logs will surface the forgotten ones), check what each record actually resolves to, delete the dangling ones, and make "remove the DNS record" a non-negotiable step of every teardown. Close the door before someone else moves in.