What Is a Subdomain Takeover? (And Why Microsoft Had 670 of Them)

An attacker doesn’t need to breach your servers to serve malware from yourbrand.com. They just need one forgotten DNS record.

Subdomain takeover is the class of bug that turns your own DNS zone into an attacker’s staging surface. The mechanics are simple: your CNAME still points to a cloud service, but you closed the account. Someone else opens a new account with the same slug — and now they answer traffic on your subdomain.

The impact is not theoretical. In 2020, a single researcher found 670 vulnerable subdomains inside microsoft.com and its child brands (Sophos News, March 2020, retrieved 2026-09-03). Five years on, the class of bug has not gone away — Detectify’s own crawlers still report the finding volume climbing roughly 20% year over year on the surface they scan (Detectify Labs, retrieved 2026-09-03).

The Anatomy of a Subdomain Takeover

Every subdomain takeover walks through the same four steps:

1. Someone in your team creates a CNAME pointing a subdomain at a third-party service.
2. That third-party service is later decommissioned — the S3 bucket is emptied, the Heroku dyno is scaled to zero, the Azure Cloud App is deleted.
3. The DNS record is not removed. It still resolves.
4. An attacker registers the freed resource under the same name. The attacker now controls what is served from your subdomain.

The subtle part is step 3. Almost every takeover in the wild traces back to the same operational gap: the DNS record outlived the resource. If you follow the /learning/dns-record-types-explained primer, you’ll remember that CNAME is an alias — DNS doesn’t know or care whether the alias target is claimed. Nothing in the DNS protocol tells you a target is orphaned. That’s a resource-existence check, and you have to run it yourself.

The Language Around It

Two terms show up constantly and mean the same thing:

• Dangling CNAME — a CNAME whose target hostname exists in DNS but no longer resolves to a claimed resource (e.g., NXDOMAIN, or resolves but the platform serves a 404 saying “this app is not claimed”).
• Dangling DNS — the wider family. Also covers A records to freed cloud IPs and MX records to shut-down mail hosts.

See the /glossary/cname-record entry for the record format itself. In this article we focus on CNAME-based takeovers because they’re the majority of disclosed cases.

The Microsoft 670-Subdomain Story

The most-cited case study in the field is from March 2020. Independent researcher Michel Gaschet reported that 670 subdomains under microsoft.com were vulnerable to takeover (Sophos News, retrieved 2026-09-03).

The pattern was consistent across the corpus:

some-old-marketing-site.microsoft.com.   CNAME   msftazure-app-abc123.azurewebsites.net.

The azurewebsites.net app had been deleted. Any Azure customer could re-register the msftazure-app-abc123 slug and be served automatically as some-old-marketing-site.microsoft.com. Because the target subdomain still lived under microsoft.com, browsers rendered it with a valid TLS certificate through Azure’s shared cert infrastructure, and — critically — cookies scoped to .microsoft.com would have been readable if the attacker chose to weaponise it.

Microsoft cleaned the discovered records. But the story keeps returning, because the underlying gap is organisational, not technical. Ownership of a DNS record and ownership of the corresponding cloud tenant are almost always tracked in different systems, by different teams, on different schedules.

The DangleGeddon Campaign

Between mid-2024 and early 2025, threat-intelligence vendor Silent Push tracked a coordinated campaign it later named DangleGeddon. The campaign sent more than eight million requests to abandoned AWS S3 buckets and other cloud endpoints across dozens of Fortune-500-scale zones, testing which ones were still dangling and re-claimable (SecurityWeek, retrieved 2026-09-03).

Silent Push’s follow-up crawl of just the corporate S3-CNAME surface put roughly 1.1 million CNAMEs in a “dangling or takeover-adjacent” state at the time of publication (Silent Push, retrieved 2026-09-03). Corroborating research from CSC’s global DNS study analysed 440,000 DNS records across the Forbes Global 2000 and found that around 21% of tested CNAMEs were dangling or otherwise unclaimed at the resolver level (Legba field guide, retrieved 2026-09-03).

DangleGeddon matters not because the technique changed, but because the discovery pipeline did: it can now be run at internet scale by anyone with a Certificate Transparency subscription and a small script. Attackers no longer hunt one target at a time.

Where Dangling CNAMEs Actually Come From

Three scenarios cover the vast majority of disclosed cases in the HackerOne top-subdomain-takeover corpus (retrieved 2026-09-03).

1. S3 Bucket Deleted, DNS Left Behind

static.brand.com.   CNAME   brand-static-assets.s3.amazonaws.com.

The marketing team retires an old static site. Someone empties and deletes the bucket. The DevOps request to remove the CNAME is filed as a P4 in a different queue and never executed. Any AWS customer can now create a bucket named brand-static-assets in the correct region and serve arbitrary HTML on static.brand.com.

2. Heroku App Decommissioned

staging-api.brand.com.   CNAME   brand-staging-api.herokuapp.com.

The staging app is deleted after the team migrates to Kubernetes. The .herokuapp.com slug is freed after ~7 days. Anyone can register a new Heroku app with that slug and Heroku will serve their content on staging-api.brand.com with a valid *.herokuapp.com certificate.

3. Azure Cloud App / Traffic Manager Expiration

events.brand.com.   CNAME   brand-events-2021.azurewebsites.net.

The events team spins up a one-off Azure Cloud App for a launch, then abandons the subscription. Twelve months later the tenant is cleaned. The brand-events-2021.azurewebsites.net slug returns to the pool. As Keytos’s ongoing research shows, Azure’s shared domains have remained one of the most-attacked surfaces since 2020, and the platform still allows re-registration of freed hostnames without domain-verification friction on many product lines (Keytos, retrieved 2026-09-03).

The Five Attack Surfaces You’ll Actually See

Not every SaaS is exposed. The set below covers roughly nine of every ten disclosed cases in public bounty reports:

1. AWS S3 — CNAME → bucket.s3[.region].amazonaws.com. Freed bucket names can be re-registered in the same region.
2. Azure Cloud App / Websites / Traffic Manager — CNAME → *.azurewebsites.net, *.trafficmanager.net, *.cloudapp.azure.com. Re-registration is possible for many freed slugs.
3. GitHub Pages — CNAME → <user>.github.io. If the user or repo is deleted, another account can claim the same repo name and serve pages on your subdomain.
4. Heroku — CNAME → <slug>.herokuapp.com. Freed slugs are re-registrable after a short cool-off.
5. AWS Elastic Beanstalk — CNAME → <app>.<region>.elasticbeanstalk.com. Same pattern; freed environment names can be re-claimed.

Shopify, Fastly, Zendesk, Ghost, Tumblr and Unbounce round out the long tail. The community-maintained fingerprint list at projectdiscovery/nuclei-templates is the closest thing the field has to a canonical inventory.

How to Detect It

Detection matters more than any single control, for the same reason /learning/what-is-blacklist monitoring matters more than any single sender-reputation setting: the fault appears silently between two systems and you only know about it if you look. The audit runs in four steps.

Step 1 — Enumerate Every Subdomain

Pull your zone from Certificate Transparency logs. Every certificate ever issued for your primary domain leaves a trace in CT. The community query surface is crt.sh:

https://crt.sh/?q=%25.example.com&output=json

Combine CT enumeration with a curated top-200 brute-force list (www, mail, staging, preview, docs, api, admin, portal, and the rest). Union the two sets — CT catches subdomains you forgot, brute-force catches subdomains that never got a certificate. See /glossary/dns if you need a refresher on how the resolver chain works.

Step 2 — Resolve Each Subdomain

For every subdomain, run a DNS query and record:

• Does it return NXDOMAIN?
• Does it return a CNAME? If so, what’s the target?
• If A/AAAA, is the IP inside a known cloud range?

NXDOMAIN alone is not a takeover — the whole record chain is gone. The dangerous state is: your record resolves, the CNAME target is inside a shared cloud namespace, and the target itself returns NXDOMAIN or a “not claimed” fingerprint.

Step 3 — Fingerprint the Target Service

Match the CNAME target against the known-vulnerable service list. *.s3.amazonaws.com, *.azurewebsites.net, *.herokuapp.com, *.github.io, *.elasticbeanstalk.com — these are your top-five triggers.

Step 4 — Confirm Resource Existence

Issue an HTTP request. Read the response body against a small library of takeover fingerprints:

If the DNS resolves and the fingerprint matches, you have an active dangling CNAME. Rotate through your list on a schedule — this class of bug appears whenever a team ships, so a one-time scan is worthless.

Real Bounty Payouts

The public bounty record confirms this is a paid, active bug class. A short sample of disclosed reports:

• Starbucks — Patrik Hudak disclosed a subdomain takeover on HackerOne report #325336 and received $2,000. Two separate reports on adjacent Starbucks assets each paid the same amount (HackerOne report #325336, retrieved 2026-09-03; 0xpatrik.com, retrieved 2026-09-03).
• Uber, 2017 disclosed a subdomain takeover of saostatic.uber.com. Paid $5,000 (see the HackerOne top-subdomain-takeover disclosure list).
• High-water mark on public HackerOne data sits around $8,000 for chains where the takeover leads to session or OAuth compromise on the parent domain.

The pattern in the data: bounties scale not with the takeover itself but with the authentication surface it opens. A takeover on a marketing subdomain pays roughly $500–$2,000. A takeover on a subdomain that shares session cookies with an authenticated app pays $5,000+. Everything above $8,000 typically involves a chain — takeover → cookie theft → account access.

Prevention Checklist

Run through this list once, then bake steps 4–7 into whatever change process ships DNS.

1. Own the CNAME lifecycle. Every DNS change must reference the ticket that provisions or deprovisions the resource it points at.
2. Delete DNS before you delete the resource. If DNS is deleted first, worst case a page 404s. If the resource is deleted first, worst case someone owns your subdomain.
3. Use domain-verification tokens. Where the cloud vendor supports it (AWS Route 53 for S3, GitHub Pages custom-domain verification, Azure App Service domain verification), turn it on. Re-registration of the target slug then can’t attach to your DNS.
4. Scope cookies tightly. Set cookies on the exact host (app.brand.com), never on the eTLD+1 (.brand.com). A takeover on a sibling subdomain then can’t read them. This is one of the highest-ROI mitigations against takeover-chain attacks.
5. Enumerate subdomains at least weekly. CT + brute-force + resolve + fingerprint. Automate — human memory is where the class of bug lives.
6. Add DNS hygiene to offboarding. When a service, vendor, or team’s tenant is retired, one of the checklist items must be “grep the zone for any CNAME still pointing at their space.”
7. Treat email-auth DNS the same way. SPF include, DMARC rua, and DKIM selectors also drift and rot; the /learning/what-is-dmarc guide walks through that side.
8. Alert on new dangling CNAMEs, not just existing ones. A drift alert on your zone tells you when a new CNAME is added that resolves into a shared cloud namespace. The best time to catch a future takeover is the day the record is created.

The Compliance Angle

Regulators have started treating dangling CNAMEs as data-processing failures rather than technical debt. ICANN’s Domain Abuse Activity Reporting has begun surfacing dangling-DNS categories as measurable abuse signals in its recent reports (ICANN DAAR, retrieved 2026-09-03). Under GDPR Article 32, if a takeover leads to credential theft on a customer-facing subdomain, the loss of personal data through inadequate technical measures is reportable within 72 hours. Under HIPAA, a takeover on a subdomain that displayed patient-facing content can trigger the breach-notification rule. The financial impact of one incident dwarfs the cost of running a weekly zone scan.

Where DomainScan Fits

DomainScan monitors dangling CNAMEs continuously as part of the Subdomain Enum + Attack Surface capability on the Pro tier. Add a domain, run the discovery once, then get alerts on every new dangling CNAME your team ships — no more one-off audits that go stale in a week. The Free tier scans two domains continuously so you can pilot the check on a live property before rolling it across your estate. No credit card, no time-limited trial.

Frequently Asked Questions

What is a subdomain takeover in one sentence?

A subdomain takeover happens when your DNS still points a subdomain at a third-party service (S3 bucket, Azure Cloud App, Heroku dyno, GitHub Pages site) that you no longer own — allowing an attacker to re-register the abandoned resource and serve their own content from your subdomain.

What is a dangling CNAME?

A dangling CNAME is a DNS record that resolves to a hostname whose underlying resource has been deleted or de-provisioned. The DNS entry still exists in your zone, but the target no longer belongs to anyone — until an attacker claims it. Dangling CNAMEs are the raw material of nearly every disclosed subdomain takeover.

Which cloud services are most vulnerable to subdomain takeover?

Public research consistently names AWS S3, Azure Cloud Apps / Azure Websites / Azure Traffic Manager, Heroku, GitHub Pages, Elastic Beanstalk, Shopify, and Fastly as the most-abused surfaces. The pattern is the same across each of them: any service that lets a customer claim a hostname on a shared parent domain (*.s3.amazonaws.com, *.azurewebsites.net, *.herokuapp.com) becomes a candidate the moment the customer forgets to remove their DNS after they leave the service.

How much damage can a subdomain takeover cause?

More than most teams assume. An attacker with control of a subdomain on your primary brand can host phishing that passes SPF and DKIM alignment for your domain, steal cookies scoped to .yourbrand.com, bypass CORS on the parent, and abuse OAuth redirect allow-lists. If session cookies are not domain-scoped strictly, a takeover on abandoned.brand.com can hijack sessions on app.brand.com. Under GDPR and HIPAA, credential theft on a customer-facing subdomain is a reportable data-processing incident.

How do bug-bounty programs pay for subdomain takeovers?

Payouts scale with target sensitivity, not with the takeover itself. Patrik Hudak’s disclosed Starbucks takeover on HackerOne report #325336 paid $2,000, with a second adjacent report paying the same amount. Uber’s 2017 disclosure paid $5,000. The industry-wide corpus of subdomain-takeover reports on HackerOne ranges from a few hundred dollars up to about $8,000 for chains where the takeover leads to session or OAuth compromise on the parent domain.

How does DomainScan detect subdomain takeover risk?

DomainScan enumerates every discoverable subdomain via Certificate Transparency logs and a curated brute-force list, resolves each one, and flags CNAMEs that point to unclaimed resources on 30+ known-vulnerable services. The Subdomain Enum + Attack Surface capability runs on the Pro tier and above. The Free tier scans two domains continuously so you can pilot the check on one live property before rolling it out across your estate.

Related Learning

• /learning/dns-record-types-explained — how CNAME, A and MX resolve
• /learning/what-is-dmarc — the email-auth side of DNS hygiene
• /learning/what-is-blacklist — the other silent DNS-adjacent failure mode

Sources

• Sophos News — “Researcher finds 670 Microsoft subdomains vulnerable to takeover”, March 2020
• Detectify Labs — subdomain takeover research
• SecurityWeek — “DangleGeddon: AI Could Weaponize Forgotten DNS Records at Global Scale”
• Silent Push — “Subdomain Takeovers and Other Dangling Risks”
• Keytos — “Azure Domains Still Vulnerable to Subdomain Takeover”
• Legba — “Subdomain Takeover: A Dangling DNS Field Guide”
• 0xpatrik.com — Starbucks subdomain takeover write-up
• HackerOne report #325336 — Starbucks subdomain takeover
• reddelexc/hackerone-reports — Top subdomain takeover reports
• ICANN — DAAR recent-patterns announcement