# Subdomain takeover: how dangling DNS records get hijacked

A team sets up `shop.example.com` on a cloud service: a DNS record (a
CNAME) points it at `example-shop.azurewebsites.net`. Months later the cloud
resource is deleted, but nobody removes the DNS record. The record now
points at a name that doesn't exist, a **dangling record**.

On many cloud services, anyone can create a resource with any free name.
Whoever creates `example-shop.azurewebsites.net` now serves their own
content on `shop.example.com`, under your domain, with a valid certificate
they can get for it. That's a **subdomain takeover**.

## Why it matters

A taken-over subdomain is more convincing than any lookalike domain: it *is*
your domain. Attackers use them for:

- **Phishing pages** that pass every "check the address bar" test.
- **Scam and spam redirects** that borrow your domain's reputation in
  search results.
- **Cookie theft**, if your site sets cookies for the whole domain
  (`.example.com`), since the subdomain receives them.

In 2025 researchers described a group, nicknamed Hazy Hawk, that took over
subdomains of well-known organisations through exactly these abandoned cloud
resources and used them for scam redirects.

## Which services are affected

The risk exists wherever a deleted resource's name can be claimed again.
For some services that's visible from DNS alone, because the name stops
resolving once the resource is gone:

| Service | Target looks like |
|---|---|
| Azure App Service | `*.azurewebsites.net` |
| Azure Cloud Services, VM DNS names | `*.cloudapp.net`, `*.cloudapp.azure.com` |
| Azure Traffic Manager | `*.trafficmanager.net` |
| Azure Blob Storage | `*.blob.core.windows.net` |
| Azure API Management, CDN, Container Instances | `*.azure-api.net`, `*.azureedge.net`, `*.azurecontainer.io` |
| AWS Elastic Beanstalk | `*.elasticbeanstalk.com` |

Others, such as S3 buckets and GitHub Pages, keep resolving after the
resource is deleted and only show an error page; spotting those takes an
HTTP check. The community project *can-i-take-over-xyz* keeps the full list.

## Find dangling records

For each subdomain, check where it points and whether the target exists:

```
dig +short CNAME shop.example.com
dig +short A example-shop.azurewebsites.net
```

A CNAME with an empty answer for its target is dangling. The hard part is
the list of subdomains: DNS zones are rarely complete documentation. Public
**Certificate Transparency** logs help, because almost every subdomain that
ever served HTTPS has a certificate in them. The
[certificate finder](/tools/find-ssl-certificates) lists them.

## Fix it

1. **Delete the DNS record** if the service is gone for good. That's the
   whole fix.
2. **Recreate the resource** under the same name if the subdomain is still
   needed, before someone else does.
3. **If it's already been taken over**: delete the DNS record first (that
   ends it immediately), then report the resource to the cloud provider's
   abuse team.

## Prevent it

- **Remove DNS before deleting the resource**, not after. Put it in the
  decommissioning checklist.
- **Use the provider's protection** where it exists: Azure, for example,
  can verify domain ownership with a TXT record so only your subscription
  can bind your custom domain, and documents how to prevent dangling DNS.
- **Monitor every subdomain**, not just the ones in your documentation.

## Check your domain

The [subdomain takeover checker](/tools/subdomain-takeover-checker) looks up
every subdomain in the public certificate logs and flags any whose record
points at a missing resource, and Nameward's monitoring alerts you when a
new one appears.

## Sources

- [Microsoft: prevent dangling DNS entries and avoid subdomain takeover](https://learn.microsoft.com/azure/security/fundamentals/subdomain-takeover)
- [can-i-take-over-xyz (community list of vulnerable services)](https://github.com/EdOverflow/can-i-take-over-xyz)
- [BleepingComputer: Hazy Hawk exploits DNS misconfigurations to hijack trusted domains](https://www.bleepingcomputer.com/news/security/hazy-hawk-gang-exploits-dns-misconfigs-to-hijack-trusted-domains/)
- [Cloud Security Alliance: dangling CNAMEs (2026)](https://cloudsecurityalliance.org/blog/2026/06/25/dangling-cnames-the-critical-dns-misconfiguration-most-organizations-still-miss)

---
Source: https://nameward.app/guides/subdomain-takeover (updated 2026-10-30)