Subdomain Takeover: How to Detect and Prevent It for UK Businesses

What Is Subdomain Takeover?

Subdomain takeover is a vulnerability that occurs when a DNS subdomain points to an external service — a cloud platform, a CDN, a SaaS tool — that has since been deprovisioned or deleted. If the external service allows anyone to claim the target name, an attacker can register the abandoned resource and start serving content from your subdomain.

The result: \`docs.yourcompany.com\` or \`staging.yourcompany.com\` suddenly belongs to an attacker, not you. They can host convincing phishing pages, steal session cookies scoped to your parent domain, bypass Content Security Policy, or issue fraudulent TLS certificates depending on the CA's domain validation method.

It is one of the most underappreciated vulnerabilities in modern web infrastructure because it requires no exploit — only an unchecked DNS record and a free account on a cloud platform.

---

How Subdomain Takeover Works

The attack follows a straightforward chain:

1. **Your company sets up a subdomain** — \`beta.example.com\` points via CNAME to \`example.azurewebsites.net\` for a short-lived Azure Web App project. 2. **The project is shut down** — the Azure resource is deleted, but the DNS CNAME record is never removed. 3. **The record dangles** — \`beta.example.com\` still resolves to \`example.azurewebsites.net\`, but that hostname is now unclaimed on Azure. 4. **An attacker discovers the dangling CNAME** — tools like Subjack, SubFinder, or manual DNS enumeration expose it instantly. 5. **The attacker creates a free Azure account and registers \`example.azurewebsites.net\`** — they now control what \`beta.example.com\` serves.

The attacker's page is cryptographically legitimate from a browser's point of view: it resolves through your DNS, loads over HTTPS (if they configure a certificate), and may inherit cookies scoped to \`.example.com\` depending on the \`Domain\` attribute.

---

Which Services Are Affected?

Subdomain takeover is possible on virtually any external hosting platform that assigns hostnames based on user-chosen names. Commonly exploited platforms include:

- **Microsoft Azure** — App Services, Static Web Apps, Traffic Manager - **Amazon AWS** — S3 buckets, Elastic Beanstalk, CloudFront distributions - **Heroku** — custom domain bindings on deleted dynos - **GitHub Pages** — CNAME files removed from repos that are then deleted - **Fastly and Cloudflare** — CDN origins that have been removed - **Shopify and Squarespace** — deprovisioned storefronts

Each platform has its own behaviour. GitHub Pages, for example, requires anyone claiming a custom domain to add a CNAME file to their own repository — making takeover trivially easy on dangling GitHub Page subdomains. Azure App Services uses a TXT record verification step that slightly raises the bar but does not prevent the attack on all configurations.

The Can I Take Over XYZ repository on GitHub maintains a community-maintained list of which platforms are vulnerable, partially mitigated, or safe. As of late 2025, dozens of widely used platforms remain exploitable.

---

Real-World Impact

Subdomain takeover moved from theoretical to well-documented:

- Security researchers at Detectify demonstrated takeovers on subdomains belonging to major brands including Uber, Shopify, and Starbucks between 2016 and 2020, earning responsible disclosure rewards. - The UK National Cyber Security Centre (NCSC) has flagged subdomain takeover as an attack technique relevant to UK public sector organisations, particularly those running legacy subdomains on decommissioned government projects. - Bug bounty hunters routinely earn £500–£5,000 per takeover finding on HackerOne and Bugcrowd, reflecting the real severity.

The damage is disproportionate to the effort involved. A single forgotten subdomain can undermine an entire organisation's trust:

- **Phishing** — a convincing login page at \`accounts.yourcompany.com\` is far more credible than a random lookalike domain - **Cookie theft** — cookies with \`Domain=.yourcompany.com\` are sent to every subdomain, including the attacker's - **OAuth token interception** — if a forgotten subdomain is registered as an OAuth callback, access tokens can be harvested - **Email spoofing** — some certificate issuance flows use subdomain control as domain ownership proof, potentially allowing fraudulent certificates

---

How to Find Dangling Subdomains

DNS Enumeration

The first step is discovering all your subdomains — you cannot protect what you cannot see. Techniques include:

- **Certificate Transparency logs** — tools like \`crt.sh\` reveal every certificate ever issued for your domain, exposing subdomains you may have forgotten - **Brute-force enumeration** — tools like Amass, SubFinder, and Fierce try common subdomain names against your DNS - **DNS zone transfer** — if your nameservers permit zone transfers (a misconfiguration in itself), an attacker gets your entire subdomain list in one request

CNAME Chain Analysis

For each discovered subdomain, check whether its CNAME destination still exists:

\`\`\`bash # Check if a CNAME points to a valid host dig CNAME staging.example.com # If the result points to something.azurewebsites.net, verify that host resolves curl -I https://something.azurewebsites.net # A 404 "page not found" from Azure's generic error page — not the app — is a red flag \`\`\`

Automated tools like **Subjack** and **tko-subs** can scan lists of subdomains and flag potential takeovers based on known platform fingerprints (the specific error messages each platform returns for unclaimed hostnames).

Manual Verification

Not every dangling CNAME is exploitable — some platforms require verified ownership before a hostname can be claimed. Always verify manually:

1. Resolve the CNAME chain to its final destination 2. HTTP GET the destination and compare the response against known "unclaimed" fingerprints (e.g., "There is no app deployed to this URL" for Heroku; "NoSuchBucket" for AWS S3) 3. If the fingerprint matches, attempt to claim the resource on the platform to confirm exploitability

---

How to Prevent Subdomain Takeover

Remove DNS Records When Deprovisioning

The root cause is always a dangling DNS record. Every decommissioning checklist must include a DNS cleanup step:

- Delete the CNAME or A record pointing to the deprovisioned service **before** or **at the same time as** deleting the service itself - Never leave a CNAME pointing to a hostname your organisation no longer controls

This sounds obvious but fails consistently in large organisations where the team that manages DNS is different from the team that provisions cloud resources.

Maintain a DNS Inventory

Keep a live inventory of every subdomain and what it points to. Tools like **Cloudflare DNS**, **AWS Route 53**, or a dedicated DNS management platform provide programmatic APIs — you can query them to build a complete picture and reconcile it against your live cloud resource inventory regularly.

Use TXT Record Verification

Several platforms offer an additional TXT record verification step before a custom hostname can be claimed. Enable this wherever available:

- **Azure App Service** uses \`asuid.{subdomain}\` TXT records — configure these and an attacker cannot register your subdomain even if the CNAME dangles - **GitHub** offers organisation-level domain verification, preventing takeovers of subdomains under verified domains

Monitor Continuously

One-off audits are insufficient because new subdomains are created — and deprovisioned — constantly. Continuous monitoring is the only reliable defence:

- Schedule regular automated scans of your DNS records against live-service verification - Alert on any subdomain that resolves to an unclaimed hostname on a known takeover-prone platform - Include subdomain takeover checks in your CI/CD pipeline for infrastructure changes

A Yrzo AI automated security scan checks your primary domain and its publicly visible subdomains for dangling DNS records and known takeover-vulnerable platform fingerprints as part of a 44-check assessment. Run a scan at [yrzoai.dev](https://yrzoai.dev).

---

Remediation

If you discover a subdomain takeover vulnerability — or suspect one — act immediately:

1. **Remove the dangling DNS record** — this is the definitive fix; the subdomain stops resolving instantly 2. **If you need the subdomain** — reprovision the external resource first, then verify the CNAME is resolving to the correct origin before re-enabling it 3. **Rotate credentials** — if the subdomain could have been used to harvest cookies or OAuth tokens, treat any existing sessions as potentially compromised 4. **Audit related records** — where there is one dangling record, there are usually more; scan the full DNS zone

---

Summary

Subdomain takeover is a low-effort, high-impact vulnerability rooted in poor offboarding hygiene. An attacker needs nothing more than a free account on a cloud platform and a few minutes with a DNS lookup tool to claim a forgotten subdomain and serve malicious content from it.

The defence is equally low-effort when built into process: remove DNS records when you remove services, maintain a live DNS inventory, and scan regularly. The organisations that get caught are the ones who assumed DNS cleanup was someone else's job.

Related reading: [What Is CORS Misconfiguration?](/blog/what-is-cors-misconfiguration) · [What Is Clickjacking?](/blog/what-is-clickjacking) · [Website Security Audit for UK Small Businesses](/blog/website-security-audit-uk-small-business)