An abandoned subdomain, an open door
Your company has blog.example.com pointing to a Heroku application that was decommissioned six months ago. Nobody remembered to remove the DNS record. An attacker registers a new Heroku app with the same name and, without touching your infrastructure, now controls your subdomain. They can serve phishing pages, steal cookies from the parent domain, and bypass security policies like CSP.
This is subdomain takeover, and it is far more common than most organizations realize.
How the attack works
Subdomain takeover exploits a disconnect between an organization's DNS configuration and the external services it points to. The typical attack flow looks like this:
1. The company creates a CNAME record:
blog.example.com --> CNAME --> myapp.herokuapp.com
2. The company deletes the Heroku app,
but does NOT remove the DNS record.
3. The attacker creates a new Heroku app
with the name "myapp".
4. blog.example.com now resolves to the attacker's server.
5. The attacker controls a legitimate subdomain
of the organization.
The critical point is step 2. When the cloud service is decommissioned but the DNS record remains, what is known as a dangling record is created. That record points to a resource that no longer exists and that any third party can claim.
The attacker does not need to compromise any server. They do not need to exploit a software vulnerability. They only need to detect a DNS record pointing to the void and claim the resource on the corresponding service.
Vulnerable services
Not every cloud service is susceptible, but the list of those that are is extensive:
- GitHub Pages: CNAME records pointing to
user.github.io - Heroku: subdomains pointing to
app.herokuapp.com - AWS S3: records pointing to
bucket.s3.amazonaws.com - Azure: subdomains pointing to
app.azurewebsites.net - Shopify: custom domains configured on deleted stores
- Zendesk: unlinked support subdomains
- Fastly, Netlify, Vercel: abandoned CDN configurations
- Surge.sh, Fly.io, Pantheon: hosting platforms with reusable namespaces
The common pattern is clear: any service where the resource name can be claimed by a third party after being released is potentially vulnerable. If the platform does not reserve the names of deleted resources, an attacker can take ownership.
The real danger
Subdomain takeover is not a theoretical curiosity. Its consequences are severe and immediate:
Cookie theft. If the parent domain sets cookies with the Domain=.example.com attribute, the attacker-controlled subdomain can read them. This includes session tokens, user preferences, and any other data stored in parent domain cookies.
High-credibility phishing. A phishing page served from support.example.com is orders of magnitude more convincing than one served from a random domain. The TLS certificate will be valid (many services issue certificates automatically), the URL belongs to the legitimate organization, and no email filter or browser will flag it as suspicious.
CSP bypass. If your main site's Content-Security-Policy allows *.example.com as a script source, the attacker can inject JavaScript from the taken-over subdomain. CSP, designed to prevent XSS, becomes a sieve.
Email interception. MX records can also fall victim to dangling records. If an MX record points to a decommissioned mail service, an attacker can claim that endpoint and receive emails destined for the subdomain, potentially including password reset tokens.
OAuth token theft. If OAuth redirect URIs include the vulnerable subdomain, the attacker can intercept authorization tokens during the authentication flow.
How to detect it
Proactive detection is the only effective defense. When an attacker takes control of a subdomain, the DNS record works correctly from a technical standpoint: it resolves, the service responds, the certificate is valid. Conventional monitoring generates no alerts.
Audit all DNS records regularly. Not just A records. CNAME, MX, NS, and SRV records can point to external services and are equally vulnerable. Export the complete DNS zone and review every entry.
Look for NXDOMAIN or SERVFAIL responses. If a subdomain configured in your DNS zone returns NXDOMAIN (domain not found) when resolving the CNAME target, it is a clear indicator of a dangling record. The record points to a resource that does not exist.
Verify that associated services are still active. For each CNAME record, confirm that the application, bucket, or project still exists on the corresponding platform. If it was deleted, remove the DNS record immediately.
Use automated tools. The can-i-take-over-xyz project database catalogs which services are susceptible to takeover and how to verify it. Tools like subjack, nuclei, or dnsx enable scanning at scale.
UareSafe includes dangling record detection in its DNS scanner. The analysis identifies CNAME records pointing to non-existent or claimable resources and flags them as critical findings. This runs automatically as part of the Technical Security dimension.
How to prevent it
Prevention comes down to operational discipline: rigorous DNS lifecycle management.
Remove the DNS record before decommissioning the service. The order matters. First remove the CNAME record, then deactivate the service. If done in reverse, there is an exposure window during which the record points to a resource that anyone can claim. DNS first, service second.
Maintain a DNS inventory and review it quarterly. Every CNAME record pointing to an external service should be documented with its owner, creation date, and purpose. A quarterly review catches orphaned records before they become a risk.
Implement DNSSEC. While DNSSEC does not directly prevent subdomain takeover, it adds authentication to DNS responses, making cache poisoning attacks more difficult. These could otherwise be combined with a takeover to amplify impact.
Use cloud asset management tools. In organizations with multiple teams deploying across various platforms, a centralized cloud asset inventory tool helps detect orphaned resources that still have associated DNS records.
Set up monitoring for DNS resolution changes. If a subdomain that resolved to a specific IP starts resolving to a different one, something has changed. That change may be legitimate or it may indicate a takeover. A monitoring system that detects variations in DNS resolution enables action before the damage materializes.
Real-world cases
Bug bounty platforms like HackerOne and Bugcrowd receive subdomain takeover reports constantly. It is one of the most frequently reported vulnerability categories, and affected organizations include major technology corporations, banks, government agencies, and universities. Organizations with hundreds or thousands of subdomains are especially vulnerable because the attack surface grows with every record, and the probability that some will become orphaned after a reorganization, migration, or decommissioning is high.
In many publicly documented cases, taken-over subdomains remained under the attacker's control for weeks or months before being detected, precisely because no conventional monitoring system generates alerts for a subdomain that technically "works."
What UareSafe checks
The DNS dimension of UareSafe includes three controls directly related to this attack vector:
- Dangling record detection (
dns-dangling): identifies CNAME, MX, and NS records pointing to non-existent or third-party-claimable resources. Any finding is classified as critical. - MX record validation (
dns-mx): verifies that configured mail servers are legitimate and operational, preventing unauthorized email reception. - DNSSEC compliance (
dnssec): checks that the DNS zone has valid signatures, adding an authentication layer to DNS responses.
These controls run automatically as part of the UareSafe certification and are re-evaluated in every monitoring cycle.
Conclusion
DNS hygiene is as important as patching servers. Every dangling record is an open door that an attacker can walk through without needing to exploit a single software vulnerability. And the fix is simple: audit your DNS, remove what you are not using, and establish a process to manage records with the same rigor as production code.
Your DNS zone is not a static file that you configure once and forget. It is a living attack surface that requires continuous maintenance. Treating every record as an asset with its own lifecycle is the difference between an organization that controls its perimeter and one that has open doors without knowing it.