Dangling Subdomains and Subdomain Takeover

What it is

A dangling subdomain is a DNS record that points somewhere it should not. The classic shape is:

• You created a marketing campaign on a hosted platform.
• The platform gave you a hostname like yourcampaign.cloudprovider.com.
• You created a CNAME from promo.yourcompany.com to that platform hostname.
• A year later, the campaign ended. Someone deleted the platform account.
• Nobody deleted the CNAME.

Now promo.yourcompany.com resolves to a hostname the platform considers free. Anyone can register that hostname on the platform and claim it. The first attacker who notices owns content served from promo.yourcompany.com. The browser shows it as a valid subdomain of your trusted brand. Cookies scoped to the parent domain may be readable. Users will trust whatever the attacker puts there.

The same pattern shows up across dozens of hosting platforms. AWS S3 buckets, AWS CloudFront distributions, Azure Web Apps, Azure Traffic Manager, Heroku, GitHub Pages, Shopify, Fastly, Tumblr, Bitbucket, Tilda, Read the Docs, Webflow, Statuspage, Zendesk, Intercom, Helpjuice, and a long tail of smaller services have all been documented as takeover surfaces. The list grows every year.

Why it matters

The damage from a successful subdomain takeover varies with what the attacker chooses to do, but the upper bound is uncomfortable:

• Phishing under your trusted brand. Login pages on secure-portal.yourcompany.com are far more convincing than the same page on a typosquat domain.
• Cookie theft and session hijacking. If you set cookies with the parent domain scope (Domain=.yourcompany.com), the attacker on a subdomain can read them. Single sign-on tokens, analytics IDs, and session data leak.
• Bypassing CSP and CORS controls. Same-origin policies treat your real assets and the attacker's content as the same trust zone in many configurations.
• Malware distribution. Software downloads served from downloads.yourcompany.com will be trusted by users and signed-installer policies.
• SEO poisoning and reputation damage. Search results carry your brand. Content on the takeover host gets indexed.
• Email spoofing. If the takeover subdomain is included in your SPF record, the attacker can send authenticated mail in your name.

Microsoft, the US Department of Defense, the UK government, EA, Vine, multiple major banks, and a long roster of well-known brands have all been hit. A 2017 takeover of success.uber.com was famously demonstrated by a researcher. Arne Swinnen's research catalogued many of the early cases. More recent examples surface regularly on bug bounty platforms, often paying out four to five-figure rewards.

How attackers exploit it

The attacker workflow is mechanical:

1. Enumerate subdomains for the target organisation. Tools like amass, subfinder, and assetfinder pull from certificate transparency logs, passive DNS, and search engines. The output is typically thousands of subdomains.
2. Resolve each one. Some return IP addresses. Some return CNAMEs to third-party platforms.
3. Identify CNAMEs pointing at takeover-prone services. Public lists (the can-i-take-over-xyz repository on GitHub is the canonical reference) catalogue the fingerprints of every known takeover surface.
4. Test for the takeover signature. Each platform has a specific response when the underlying resource does not exist. AWS S3 returns "NoSuchBucket". GitHub Pages returns a specific 404. Azure Web Apps return a custom error page.
5. Claim the resource. Register an S3 bucket with the matching name, deploy a GitHub Pages site at the right repo, create the Azure Web App with the matching subdomain. The platform now serves attacker content under the dangling DNS.
6. Weaponise. Phishing, cookie capture, SSO bypass, malware delivery. Sometimes the attacker just lurks and waits to see who shows up to a previously legitimate URL.

Automation makes this scale. Adversaries run continuous scans across millions of subdomains and claim takeovers as they appear. Defenders who clean up dangling DNS quickly are rare. The window between a subdomain becoming dangling and being claimed is often measured in hours.

How to detect it

Detection is mostly about discipline rather than cleverness. The methods that work:

• Subdomain enumeration combined with CNAME resolution. For every subdomain you own, follow the DNS chain. Note any CNAME pointing to a third-party hosting platform.
• Active validation against takeover fingerprints. For each of those CNAMEs, fetch the response and compare against the known takeover signatures. A match is a critical finding.
• Continuous monitoring. New dangling subdomains are created every week as projects end and DNS records are forgotten. Daily scanning is the right cadence.
• Certificate transparency log monitoring. Catches new subdomains being created in the first place. Useful for finding unmanaged subdomain creation by business units.
• Cloud account audit. Compare DNS records pointing to AWS, Azure, GCP and other providers against the resources actually provisioned in your accounts. Records pointing to nothing in your account are dangling.
• Passive DNS history. Useful for finding subdomains that resolved to something in the past but no longer do, which is sometimes a sign of a recent takeover or imminent one.

Severity depends on the parent domain, the cookie scope, and what content lived at that subdomain previously. A dangling subdomain on your primary brand domain is a much higher priority than one on a domain used only for internal tooling.

How to remediate

When a dangling subdomain is found, the response is straightforward:

1. Delete the DNS record immediately. This is the only definitive fix. Removing the CNAME means the subdomain no longer resolves anywhere, and the attacker has no path to serve content.
2. If the subdomain is still in use, repoint it. Sometimes the underlying service was migrated and DNS was not updated. In that case, point the record at the correct current resource.
3. If the subdomain is not in use, retire it cleanly. Delete the record. Document why. Add it to whatever tooling tracks decommissioned assets.
4. If a takeover has already happened, remove the DNS record first, then take additional steps. Notify the hosting platform if possible (some have specific takeover reporting processes). If the attacker captured credentials or sessions during the window, treat it as an incident with normal containment, eradication, and recovery steps.
5. Audit cookie scope. Move cookies that were set on the parent domain to specific subdomains where possible. The fewer subdomains can read your sensitive cookies, the smaller the blast radius of any future takeover.
6. Audit SPF includes. If the dangling subdomain was in your SPF chain, remove it. An attacker who took it over could otherwise send authenticated mail in your name.

The lifecycle problem is the actual fix. Subdomain creation is easy and decentralised. Subdomain decommissioning is forgotten and centralised. Aligning the two takes ongoing process work, not just a one-off cleanup.

Best practices

• Treat DNS as code. Version control your zone files. Require pull requests for changes. Make the history of every record visible.
• Tie DNS records to ticket-tracked owners. Every CNAME has a person who is responsible for it. When that person leaves, ownership transfers explicitly.
• Build decommissioning into project workflows. When a hosted resource is taken down, removing the DNS record is part of the closeout checklist.
• Continuously monitor for dangling subdomains. This is one of the highest-yield checks any external monitoring programme can run. The fix per finding is cheap. The cost of missing one is high.
• Restrict cookie scope on the parent domain. Avoid setting sensitive cookies with Domain=.yourcompany.com. Use the most specific subdomain that works.
• Subscribe to takeover fingerprint updates. New takeover-prone services appear every year. Detection rules need to keep up.
• Use DNS providers that integrate with cloud account audit. Some providers let you flag records that no longer have valid back-end resources. Use those features.
• Reserve resource names you do not currently use. If your DNS includes static-assets.yourcompany.com.s3.amazonaws.com, register the S3 bucket name yourself even if you do not actively use it. Cheap insurance.