Subdomain takeover via a dangling Azure CNAME

A forgotten DNS record pointing at a decommissioned Microsoft Azure resource let any attacker claim a trusted Starbucks subdomain and serve arbitrary content under it - a quiet, low-noise attack that hands an attacker brand credibility for phishing or OAuth token theft.

The Target

A Starbucks subdomain (a hostname under starbucks.com) that had previously been used to serve content hosted on Microsoft Azure. When the Azure resource was decommissioned - the App Service, storage endpoint, or other Azure-hosted service was deleted - the DNS CNAME record that pointed to it was never removed. The DNS entry continued to resolve to an Azure hostname that was now unregistered and available for anyone to claim.

The Vulnerability

This is a subdomain takeover via a dangling CNAME. The DNS infrastructure for starbucks.com contained a record along these lines:

some-feature.starbucks.com.  CNAME  starbucks-feature.azurewebsites.net.

When starbucks-feature.azurewebsites.net was deleted from Azure, the CNAME target became a "dangling" reference - the DNS chain resolved to a name that no longer existed in Azure's namespace. Azure (like many cloud providers) allows any authenticated user to register a new App Service with any available hostname - including one that was previously used by someone else.

The researcher registered starbucks-feature.azurewebsites.net as a new Azure App Service under their own account. From that point forward, DNS resolution for some-feature.starbucks.com resolved to the attacker-controlled Azure app.

How It Was Found

The researcher performed subdomain enumeration on starbucks.com, collecting all DNS records. For each CNAME found, they resolved the chain to the final target and checked whether that target returned a "not found" or "unclaimed" response from the third-party provider.

# Enumerate subdomains passively, then check CNAMEs
subfinder -d starbucks.com -o starbucks-subdomains.txt
 
# For each subdomain, follow the CNAME chain
while read sub; do
  cname=$(dig +short CNAME "$sub")
  if [ -n "$cname" ]; then
    http_code=$(curl -s -o /dev/null -w "%{http_code}" "https://$sub")
    echo "$sub -> $cname (HTTP $http_code)"
  fi
done < starbucks-subdomains.txt

A response code of 404 or a provider-specific "not found" page (like Azure's default "App Service not found") from the CNAME target - but the subdomain itself still resolving - indicates a potentially claimable dangling CNAME.

After confirming the target was unregistered, the researcher registered it through their own Azure account, stood up a benign proof-of-concept page, and demonstrated that some-feature.starbucks.com now served their content - proving the takeover.

Impact

• An attacker who claims the dangling Azure resource owns what gets served from that trusted Starbucks subdomain.
• Phishing at scale: sending users a link to some-feature.starbucks.com with a convincing Starbucks login clone - users see a valid starbucks.com hostname in the URL bar and trust it.
• OAuth and SSO token theft: if any OAuth flows or redirects reference the taken-over subdomain (as an allowed redirect URI), an attacker can harvest access tokens passed as URL parameters.
• Cookie scope: depending on cookie configuration, session cookies set on *.starbucks.com might be readable by the taken-over subdomain, exposing authenticated sessions.
• This is persistent and passive - the attacker does nothing after registration; victims arrive on their own.

The Fix

Subdomain takeover prevention is primarily an operational/hygiene issue:

1. Remove DNS records when decommissioning resources. Before deleting a cloud resource, remove the CNAME (or A record) pointing to it. DNS cleanup must be part of the decommission checklist.
2. Audit all DNS records regularly. Automated tools (e.g., can-i-take-over-xyz, Nuclei subdomain takeover templates) can scan all CNAMEs and flag those pointing at unregistered third-party resources.
3. Maintain a DNS inventory. Track which DNS records exist and what they point to; any record referencing a service that no longer exists is a liability.
4. Monitor for unexpected content changes on subdomains using uptime/certificate transparency monitoring - an unexpected new TLS certificate for a subdomain is a strong signal of takeover.

What You Can Learn

• DNS is foundational trust infrastructure. Users trust a hostname because of the domain name - they do not inspect where the CNAME ultimately resolves. A dangling CNAME transfers that trust to whoever claims the target.
• Cloud resources are claimable by name. Unlike IP addresses, cloud PaaS hostnames (*.azurewebsites.net, *.s3.amazonaws.com, *.github.io, etc.) can be registered by any paying customer - making unclaimed names exploitable.
• Subdomain enumeration reveals forgotten infrastructure. Certificate transparency logs, passive DNS databases, and brute-force wordlists expose subdomains that internal teams have long forgotten exist.
• CNAME chains must be validated end-to-end. The DNS entry existing does not mean the resource at the end of the chain exists. Always follow the full chain.
• Decommission completely. The attack surface from orphaned DNS records is large and often overlooked - it requires discipline across both the infrastructure team (delete the resource) and the DNS team (delete the record).