Subdomain Takeover

How attackers find and exploit it

• Enumerate the target's subdomains at scale using certificate transparency logs, passive DNS, and brute-force resolvers (tools such as subfinder and amass), building a list of every name the organization has ever published.
• Resolve each name and flag those whose CNAME, ALIAS, or ANAME points to a third-party cloud or SaaS provider rather than to infrastructure the target controls directly.
• Match the resolved target host against the canonical can-i-take-over-xyz fingerprint database to identify providers (GitHub Pages, S3, Heroku, Azure, Shopify, Fastly, and others) that allow first-come name claiming.
• Confirm the backend is unclaimed by requesting the subdomain over HTTP/HTTPS and observing a provider 'not found' page, or by seeing the CNAME target itself return NXDOMAIN, both signals that no active resource is bound to the name.
• Register the exact resource name on the provider (create the Pages site, S3 bucket, Heroku app, or Azure resource matching the dangling FQDN), at which point the still-live DNS record routes the victim's traffic to the attacker's content.
• Escalate by provisioning a valid TLS certificate for the subdomain via ACME, then host phishing, harvest *.example.com cookies, or stand up an OAuth redirect endpoint to capture tokens.

How to detect it on your surface

• Export every record from each authoritative DNS zone you own and isolate all CNAME, ALIAS, and ANAME records, plus A/AAAA records pointing to cloud provider IP ranges.
• For each third-party-pointing record, resolve the target FQDN and check whether it returns NXDOMAIN or resolves to a provider edge that has no active resource bound to your name.
• Cross-reference your cloud and SaaS inventories: confirm that for every dangling-candidate record there is a currently provisioned, owned resource on the named provider account.
• Run a recurring detection job (scheduled scan plus a CI/CD check on DNS changes) rather than a one-time audit, since records become dangling the moment a resource is decommissioned.
• Use Microsoft's Get-DanglingDnsRecords PowerShell tooling for Azure-pointing CNAMEs, and monitor Certificate Transparency logs for unexpected certificates issued against your subdomains.

Detection signals

• The CNAME/ALIAS target itself fails to resolve, returning NXDOMAIN while the subdomain record remains published in your zone.
• An HTTP/HTTPS request to the subdomain returns a provider-specific unclaimed-resource page, for example 'There isn't a GitHub Pages site here', S3 'NoSuchBucket', or 'Heroku | No such app'.
• The subdomain matches a known-vulnerable fingerprint in the can-i-take-over-xyz database used by tools such as subzy and nuclei.
• A subdomain resolves to a third-party SaaS edge (e.g. *.github.io, *.azurewebsites.net, *.herokuapp.com) for which your organization has no corresponding active, owned resource.
• TLS handshake to the subdomain fails or presents a default/provider certificate that does not match an account you control, indicating no claimed backend.

Validate before you report

• Resolve the full DNS chain with dig (subdomain to CNAME to final target) and record the exact backend FQDN the record references.
• Compare the live HTTP/HTTPS response against the documented fingerprint for that provider from can-i-take-over-xyz to confirm the response is an unclaimed-resource page and not legitimate content.
• Confirm the named resource is genuinely unclaimed on the provider without registering it yourself; observing the 'not found' state plus an NXDOMAIN target is sufficient evidence of exploitability.
• Verify the parent-domain cookie and session scope (whether session cookies are set for *.example.com) to establish the concrete impact of a takeover, not just its possibility.
• Determine whether the record is CNAME/ALIAS (single-subdomain impact) or NS (full-zone impact), since the validated severity differs sharply between the two.

What looks like this but isn't

• A subdomain that returns a generic 404 from a backend you actively own is not vulnerable; the provider's resource is claimed, so confirm there is no active owned resource before flagging.
• Some providers (e.g. GitHub Pages and Azure App Service with TXT-based domain verification) require proof of ownership before binding a name; if such verification is in force, the dangling target cannot be re-registered by an attacker and is not a true positive.
• A staging or internal name that resolves to NXDOMAIN with no provider backend at all (no CNAME to a re-registrable service) is a broken record, not a takeover risk.

Remediation

• Immediately remove the dangling CNAME, ALIAS, ANAME, A/AAAA, or MX record from the DNS zone, treating deletion as the first containment action ('cut power at the breaker').
• If the subdomain must keep serving traffic, re-provision a resource you own with the referenced FQDN on the named provider before, or instead of, deleting the record.
• Investigate whether a takeover already occurred: review access logs, sent mail, and any secrets or OAuth credentials the application may have transmitted to the subdomain during the dangling window, and follow your incident-response process.
• Adopt ownership-binding controls where the provider offers them: Azure App Service asuid.{subdomain} TXT verification, Azure DNS alias records that couple record lifecycle to the resource, and equivalent domain-verification mechanisms on other platforms.
• Fix the root cause by ordering decommissioning so DNS records are removed before (or together with) the backend resource, and add 'remove DNS entry' to every service teardown checklist.
• Tighten blast-radius controls: scope cookies to specific hosts rather than the wildcard parent domain, avoid wildcard CSP and CORS allowances, and use exact-match OAuth redirect URIs.

Operational checklist

• Maintain a living inventory mapping every DNS record to a resource owner, the provider it targets, and the resource's expected lifecycle.
• Run automated dangling-DNS detection on a schedule and gate DNS changes through a CI/CD check, not an annual review.
• Apply delete locks or equivalent guardrails to cloud resources that have a custom DNS entry so the record is removed before the resource can be deprovisioned.
• Couple record and resource lifecycles using alias/ALIAS records and provider domain-verification wherever the platform supports it.
• Monitor Certificate Transparency logs for certificates issued against your subdomains as an early indicator of an in-progress or completed takeover.
• Minimize wildcard DNS records; where unavoidable, scope them narrowly and document the owning service.

Weakness references (CWE)

• CWE-672 — Operation on a Resource after Expiration or Release
• CWE-284 — Improper Access Control