Subdomain Takeover: How It Happens, How to Detect It, and How to Fix It

A subdomain takeover happens when a DNS record on one of your subdomains still points to a third-party service you have already shut down — so an attacker can re-claim that service and serve their own content from your subdomain. To check for one, you find subdomains belonging to your domain and then test each for a dangling, unclaimed target. This guide explains exactly how the attack works, how to detect it, and how to prevent it.

What is a subdomain takeover?

Most subdomains do not point at your own servers directly. They point — via a CNAME record — at a third-party platform: docs.example.com → GitHub Pages, cdn.example.com → an S3 bucket, app.example.com → a Heroku app. That delegation is normal and useful.

The danger appears when the service is removed but the DNS record is forgotten. You delete the S3 bucket, decommission the Heroku app, or stop publishing the GitHub Pages site — but cdn.example.com still resolves to that now-empty target. This is a dangling DNS record.

If the provider lets anyone re-register that exact resource name (a bucket, a Pages site, an app slug) without verifying who owns the domain, an attacker simply claims it. Now their content loads at your subdomain. The browser sees a legitimate example.com address, often with valid TLS, and trusts it accordingly. The OWASP Web Security Testing Guide documents this as a standard test case under configuration and deployment management.

The underlying weakness maps to CWE-284: Improper Access Control — the resource is reachable and claimable by a party who should not have it.

How does a subdomain takeover actually happen?

The chain is short and mechanical:

1. You create status.example.com as a CNAME to a third-party status-page provider.
2. Months later you cancel that provider but forget the DNS record.
3. The provider frees up the resource name you were using.
4. An attacker notices your dangling CNAME and signs up for the same provider, claiming that exact name.
5. The provider now serves the attacker's content for requests arriving at status.example.com.

The tell-tale sign at step 2–3 is a specific "unclaimed" response from the provider. That fingerprint is what a subdomain takeover checker looks for.

The exact list shifts as providers add ownership verification. The canonical, community-maintained reference for which services are currently takeover-able (and which have been patched) is the can-i-take-over-xyz project — treat it as the source of truth before assuming any single fingerprint is still exploitable.

Why is a subdomain takeover dangerous?

It is not just "a stray page." The impact comes from the trust your other systems extend to anything under your domain:

• Phishing on a trusted name. A login page at secure.example.com is far more convincing than one on a random domain, because it really is your domain.
• Cookie theft. Cookies scoped to .example.com (set with a parent-domain Domain attribute) are sent to every subdomain. A hostile subdomain can read them.
• Bypassing CORS and CSP trust. Apps frequently allowlist *.example.com in CORS or in a Content-Security-Policy script-src. A taken-over subdomain inherits that trust and can load scripts or make requests your policy was meant to restrict.
• OAuth and redirect abuse. Redirect allowlists that trust your own subdomains can be turned into token-leaking detours.

Because of this, even a "marketing" subdomain nobody visits can become a foothold into authenticated sessions.

How do I find subdomains and check for takeover?

Detection is always two phases. You cannot check what you have not enumerated.

Phase 1 — find subdomains. Pull candidate hostnames from passive sources (Certificate Transparency logs, passive DNS) and active sources (brute-forcing common prefixes). Tools like ProjectDiscovery's Nuclei ecosystem and its sibling enumeration tools automate this. The goal is a complete inventory of everything that resolves under your domain — including the forgotten ones.

Phase 2 — fingerprint each target. For every discovered subdomain, resolve the DNS chain and inspect what the target returns. If the record is a dangling CNAME and the response matches a known unclaimed signature, flag it. This is exactly what a template-driven scanner does: it carries a library of provider fingerprints and tests each subdomain against all of them.

A practical detection checklist:

1. Enumerate every subdomain (CT logs + passive DNS + brute force).
2. Resolve each to its final target; note any CNAME to a third-party provider.
3. Probe each live host and capture the body/headers.
4. Match the response against the known unclaimed-service signatures (see can-i-take-over-xyz).
5. Triage hits by severity — anything serving a real "claim me" fingerprint is high priority.

For a broader sweep of your external surface, pair this with our web application security checklist, and once you understand the hits, read your vulnerability scan report explained to prioritise them correctly.

Where SteelSuit fits

A deep scan in SteelSuit runs both phases for you as an external, black-box check. It enumerates your subdomains and live-probes each one to filter out dead historical entries, then runs Nuclei's subdomain-takeover templates (76 takeover templates) against the live set to flag any subdomain whose target shows an unclaimed signature. Matches appear as severity-ranked findings in the deduplicated findings list and the PDF report, with the affected hostname and the matched template noted.

A few honest constraints worth knowing: subdomain enumeration and takeover checks are part of the deep scan (roughly 5–6 minutes), which requires a paid plan and DNS-TXT domain-ownership verification. The free fast scan (~26 seconds) does not enumerate subdomains. SteelSuit only detects a takeover risk — it never edits your DNS for you. Fixing the dangling record is your move.

How do I prevent and fix a subdomain takeover?

Fixing one is straightforward once detected; the discipline is in the order of operations.

To fix an existing dangling record:

1. Identify the offending subdomain and its DNS record.
2. Delete the DNS record (the CNAME or A/AAAA) — this immediately stops the subdomain from resolving to the unclaimed target.
3. Only if you still need the service, re-create it and re-point DNS afterward.

To prevent future takeovers:

• Decommission in the right order. When retiring a service, remove the DNS record first, then tear down the resource. A record should never outlive its target.
• Keep a subdomain inventory. Maintain an authoritative list of every subdomain and exactly what it points at. You cannot protect records you have forgotten.
• Avoid loose wildcards. Wildcard CNAMEs to providers you do not fully control widen the blast radius.
• Prefer providers that verify domain ownership. Many platforms now require you to prove control before claiming a host — that single feature kills the attack.
• Monitor continuously. New dangling records appear every time a service is retired. Periodic re-scanning is what catches them before an attacker does — see continuous security monitoring for how to make this routine rather than a one-off.

A subdomain takeover is one of the rare high-impact bugs that is also genuinely easy to prevent: never let a DNS record point at something you no longer own. The hard part is knowing which of your records have gone stale — and that is a detection problem you can solve with regular, automated enumeration and fingerprinting.