# Subdomain takeover: how it works, how testers prove it, how to fix dangling DNS

Source: https://penetrationtestservices.com/vulnerabilities/subdomain-takeover/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Subdomain takeover and dangling DNS explained: provider fingerprints, a read-only detection script, real cases, safe proof steps and the order to remove records.

> **Short answer:** A subdomain takeover happens when a DNS record points to a service you no longer use, and someone else claims that service name. The attacker then serves content on your subdomain. Prevent it by removing the DNS record before the resource, keeping a DNS inventory, using domain verification, and scanning for dangling records.

A subdomain takeover is an attack in which someone claims control of a subdomain of your domain because its DNS record points to a service you no longer use. OWASP's testing guide names two conditions: a DNS record points to a non-existing or non-active resource, and the hosting provider does not handle ownership verification properly. This page also covers dangling DNS, the record state that makes it possible.

Only test systems you own or have written authorization to test. Every example here uses a fictional app on example.com.

## What is a subdomain takeover?

A takeover starts when a team deletes a cloud resource and forgets its DNS record. Microsoft describes the flow in three steps: you create a resource and point a CNAME at it, you delete the resource but leave the record, and an attacker creates a resource with the same name and receives your traffic. The record is "dangling".

CNAME records are the usual case, because the subdomain follows the target. OWASP's guide also lists A, MX, NS and TXT records. An NS takeover is rarer, and OWASP says it has the highest impact because it can give control of a whole DNS zone. A CNAME that points to an expired domain is a second route: whoever registers that domain controls the subdomain.

### Why does a subdomain takeover matter?

Browsers treat a taken-over subdomain as part of your site. That is why the damage reaches beyond a defaced page.

- Cookies. MDN says a cookie with a `Domain` attribute is available to that domain and all its subdomains. A cookie set for `.example.com` goes to the attacker's server when the victim visits the taken-over name. Microsoft notes this can include secure cookies.
- Certificates. Microsoft says the attacker can get a valid certificate for the hijacked name, so the padlock does not help.
- Trust lists. OWASP lists CSP bypass and OAuth and SSO abuse among the impacts. A CORS rule that trusts every subdomain extends the damage.
- Email. MX and SPF records can let the attacker receive or send mail for the name.

## How the attack works

The attacker finds a subdomain whose CNAME points to a deleted resource, creates a resource with the same name on the same provider, and uploads content. A tester shows the first half and stops.

> **Demonstration only: Harbor Notes, a fictional app:** This is a demonstration against a fictional app. No real customer system was tested. Harbor Notes ran a campaign page at `promo.example.com`, hosted on a fictional provider. The team deleted the hosted site in March but left the DNS record.
> 
> ```bash
> $ dig +short CNAME promo.example.com
> harbor-promo.pages.example.net.
> 
> $ dig +short A harbor-promo.pages.example.net
> 
> $ curl -s -o /dev/null -w "%{http_code}\n" https://promo.example.com/
> 404
> $ curl -s https://promo.example.com/ | head -n 2
> There is no site here
> ```
> 
> The CNAME exists, the target resolves to nothing and the page returns the provider's "unclaimed" message. The tester reports a takeover candidate. The next step needs the owner's written permission and the provider's rules.
The attacker's version adds a claim step. Whether the claim works depends on the provider, which is the point of the next table.

## Which providers are vulnerable? Fingerprints by service

The table uses the can-i-take-over-xyz project, which tracks each service and its status. As of 9 November 2026 the project lists these entries. It states that its authors take no responsibility for correctness and that the data changes, so check the live table and the linked issue for the service before you report anything.

| Service | Status in the project | Fingerprint it lists |
|---|---|---|
| AWS S3 | Vulnerable (verified by its CI) | "The specified bucket does not exist" |
| Microsoft Azure | Vulnerable (verified by its CI) | `NXDOMAIN` on the target name |
| GitHub Pages | Edge case | "There isn't a GitHub Pages site here." |
| Heroku | Edge case | "No such app" |
| Shopify | Edge case | "Sorry, this shop is currently unavailable." |
| Netlify | Edge case | "Not Found - Request ID:" |
| Vercel | Edge case | "DEPLOYMENT_NOT_FOUND." |
| Fastly | Not vulnerable | "Fastly error: unknown domain:" |
| Zendesk | Not vulnerable | "Help Center Closed" |

An error page is a lead. An "edge case" means the claim works only under conditions, such as an account that has not verified the domain, and the project's issue thread for each service explains them. A "not vulnerable" entry still means the record is dangling and should be removed.

Azure deserves a note. Microsoft says that when an `asuid.{subdomain}` TXT record with the domain verification ID exists, no other subscription can validate the custom domain. Those records do not stop someone from creating an App Service with the name in your CNAME, but without proof of domain ownership the attacker cannot receive traffic or control content.

## Real incidents and research

Two documented cases show the same pattern at scale. Each is from the publisher named.

| Case | Date | What the source says |
|---|---|---|
| SubdoMailing (Guardio Labs) | 26 Feb 2024 | More than 8,000 domains compromised, from old subdomains whose CNAME pointed to expired domains. The attacker re-registered the domains, so SPF policies authorized the attacker's mail servers. One example sent mail that appeared to come from a `msn.com` subdomain, and it passed SPF, DKIM and DMARC. |
| watchTowr, abandoned S3 buckets | 5 Feb 2025 (The Record) | About 150 abandoned buckets that software and infrastructure still referenced were re-registered, and they received over 8 million HTTP requests in two months, including requests for updates and VM images. AWS blocked those bucket names from being re-created. |

The S3 case is a close relative of subdomain takeover: a name was released while other systems still pointed to it. The fix is the same: find the references before you release the name.

## How penetration testers detect and prove it

OWASP's test method is to enumerate domains, past and present, and find forgotten or misconfigured ones. With `dig`, look for `NXDOMAIN`, `SERVFAIL`, `REFUSED` or no servers reached.

1. Enumerate subdomains from the zone file if you have it (gray-box) or from wordlists, search engines and certificate logs (black-box). OWASP names dig, dnsrecon, recon-ng, theHarvester, Sublist3r and Amass.
2. Resolve each name's CNAME. Keep the names whose target does not resolve, or whose page shows a provider fingerprint.
3. Match the provider and look up its status in the project table above.
4. For NS records, OWASP's check is whether the nameserver's parent domain can be registered. If it is available, the subdomain is vulnerable.
5. Run controls. Check that the name is not intentionally parked, that the record is not behind a CDN that returns the same error for all misses, and that the owner is the same organization.
6. Decide whether a claim is in scope. Claiming a name on a third-party provider creates a resource in someone else's system. Do it only with written authorization from the owner and within the provider's terms.
7. If you claim, serve one unique harmless text file at a non-root path, such as a file whose name is a random value and whose content is a hash and the date. Do not change the home page. Record the request that retrieved the file, then release the name.

A read-only script helps in the first two steps. It makes DNS and HTTP requests only to names you list.

```bash
#!/usr/bin/env bash
# usage: ./dangling.sh subdomains.txt   (names you own or may test)
while read -r name; do
  target=$(dig +short CNAME "$name" | head -n 1)
  [ -z "$target" ] && continue
  resolves=$(dig +short A "$target" | head -n 1)
  code=$(curl -s -o /dev/null -m 10 -w "%{http_code}" "https://$name/")
  echo "$name -> $target resolves=${resolves:-NO} http=$code"
done ; Secure; HttpOnly; Path=/; SameSite=Lax
```

## DNS zone review checklist

- Does every CNAME target resolve to a resource your organization owns?
- Does every record have an owner and a reason in the inventory?
- Do names that return a provider "not found" page appear in a scan report?
- Do NS records point to nameservers whose domains you control?
- Are MX and SPF `include:` entries for services still in use?
- Do cookies use host-only scope where possible?
- Do OAuth redirect URIs, CSP and CORS lists name exact hosts, not `*.example.com`?
- Does the decommissioning checklist remove the record first and run a final scan?
- Do Certificate Transparency logs show certificates only for names you issued?

## When to get a professional test

A DNS zone review is tedious to do by hand, and the impact depends on cookies, OAuth and trust lists in your applications. A tester needs written scope that names the domains and says whether claiming a third-party resource is allowed. Excession Labs includes subdomain checks in a [web application penetration test](/web-application-penetration-testing/) when the zone is in scope, and reports the controls that held next to the findings.

## Questions

### What is dangling DNS?

A dangling DNS record points to a resource that no longer exists, such as a deleted cloud app or an expired domain. Microsoft calls these entries dangling DNS. The record stays advertised as an active name, so anyone who can register the missing target can receive its traffic.

### Can a wildcard DNS record cause a takeover?

It can widen the risk. OWASP's prevention cheat sheet advises keeping wildcards narrow, adding a hostname allowlist at the proxy and watching Certificate Transparency logs. A wildcard that points at a service you no longer control makes every name under it claimable.

### Are deleted S3 buckets a takeover risk?

Yes. The can-i-take-over-xyz project lists AWS S3 as vulnerable, with the error text 'The specified bucket does not exist'. In 2025 watchTowr registered about 150 abandoned buckets that software and infrastructure still referenced and received over 8 million requests in two months.

### Do HTTPS certificates protect users from a takeover?

No. Microsoft's documentation says a threat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate, which can make the site look more legitimate. Parent-domain cookies are also exposed. Use host-only cookies to limit that.

### Which tools find subdomain takeovers?

OWASP's cheat sheet names dnsReaper, nuclei and can-i-take-over-xyz for dangling record detection. OWASP's testing guide lists dig, dnsrecon, recon-ng, theHarvester, Sublist3r and Amass for enumeration. Run them only against domains you own or have written authorization to test.

## Sources

- [OWASP Cheat Sheet Series: Subdomain Takeover Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html)
- [OWASP WSTG-CONF-10: Test for Subdomain Takeover (v4.2)](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover)
- [Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover](https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover)
- [can-i-take-over-xyz (EdOverflow), service status and fingerprints](https://github.com/EdOverflow/can-i-take-over-xyz)
- [MDN: Set-Cookie header (Domain attribute and __Host- prefix)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie)
- [Guardio Labs: SubdoMailing, thousands of hijacked major-brand subdomains (26 February 2024)](https://guard.io/labs/subdomailing-thousands-of-hijacked-major-brand-subdomains-found-bombarding-users-with-millions)
- [The Record: Researchers warn of risks tied to abandoned cloud storage buckets (5 February 2025)](https://therecord.media/researchers-warn-of-risks-tied-to-abandoned-cloud-storage-buckets)