1Introduction: The Invisible Legacy of the Cloud
Two years ago, your team launched a promotional campaign. You spun uppromo-2024.yourcompany.com, pointed a CNAME at a Heroku app, ran the campaign, and moved on. The Heroku app was decommissioned. The subscription was cancelled. The marketing team forgot about it. TheDNS record was never deleted.
This is the origin of aDangling DNS Record— a CNAME (or A record) that still resolves, but points to a resource that no longer exists or is no longer claimed by your organization. From the outside, the subdomain returns a404, a "NoSuchBucket" error, or a "There's nothing here yet" page from the target platform. To an attacker, it reads as an open invitation.
A real scenario — happening right now
Automated tools constantly crawl the internet looking for subdomains that return platform-specific error pages. When one is found, the attacker checks whether the underlying cloud resource is claimable. If it is, they claim it in seconds. Your subdomain — with your brand, your TLS certificate, and your users' trust — now serves the attacker's content. No hacking required. No vulnerability exploited. Just a DNS record you forgot to delete.
Subdomain takeover is not a theoretical risk.
Bug bounty programs at major companies — including Microsoft, Shopify, Uber, and GitHub — have paid out significant rewards for subdomain takeover discoveries. The vulnerability is so common that dedicated tools likesubjack,can-i-take-over-xyz, andnuclei have templates specifically for it. If attackers have automated tooling, your defense needs to be automated too.
2How the Attack Works
Subdomain takeover does not require exploiting a software vulnerability. It exploits aprocess failure— the gap between infrastructure decommissioning and DNS cleanup. The attack unfolds in three deterministic steps.
Identification: scanning for platform error signatures
The attacker enumerates your subdomains using certificate transparency logs, brute-force wordlists, or passive DNS data. They load each subdomain and look for fingerprints: 'NoSuchBucket' (AWS S3), 'There is no app configured at that hostname' (Heroku), 'Repository not found' (GitHub Pages). These messages confirm the subdomain is dangling.
Verification: confirming the CNAME target is claimable
A DNS lookup confirms the CNAME target. The attacker checks whether the cloud service still accepts registrations for that specific resource name — a bucket name, a Heroku app slug, a GitHub Pages repo. Most platforms do.
Takeover: claiming the orphaned resource
The attacker creates a free account on the target platform and registers the exact resource name the CNAME points to. From this moment, all HTTP requests to your subdomain are served by the attacker's server. No further action required — the DNS record does the work for them.
Exploitation: your brand, their payload
The attacker now controls a fully authenticated HTTPS endpoint under your domain. They can serve phishing pages, malicious JavaScript, cookie-stealing scripts, or simply wait — knowing your users trust anything on your domain.
$ dig CNAME promo-2024.yourcompany.com
;; ANSWER SECTION:
promo-2024.yourcompany.com. 300 IN CNAME yourcompany-promo.herokuapp.com.
# Heroku returns: "There is no app configured at that hostname."
# → This app name is available to register. Takeover possible.
3Why This is a Critical Vulnerability
A defaced subdomain is the least of your problems. The real impact of a successful takeover extends into every trust boundary your domain has built — with browsers, with users, and with other services in your infrastructure.
Session Cookie Theft
Browsers scope cookies by domain. If your application sets cookies with Domain=.yourcompany.com, a takeover of any subdomain - including promo-2024 - can read those cookies in JavaScript. Session hijacking, credential theft, and account takeover become trivially possible.
Pixel-Perfect Phishing
It is exceptionally difficult for a user to identify a phishing attack when the URL bar shows https://payment.yourbank.com. The certificate is valid. The domain is correct. Your security training is useless against an attacker who owns your subdomain. The trust has already been established - by you.
CSP and CORS Bypass
Your Content Security Policy and CORS configuration explicitly trust your own subdomains. A takeover turns that trust into a liability: attackers can inject scripts from a trusted origin, exfiltrate data across same-origin boundaries, and bypass protections that cost your security team weeks to implement.
SEO Poisoning and Brand Damage
Search engines index content on your subdomain as if it were yours. An attacker can publish spam, malware pages, or defamatory content under your brand. Safe browsing flags can propagate to the apex domain and impact visibility.
No exploit code. No CVE. Just a missing cleanup step.
Subdomain takeover is classified as a high-severity or critical finding in most bug bounty programs precisely because the attacker effort is near-zero while the impact is severe. The OWASP Testing Guide, SANS, and major cloud providers all list it as a top DNS risk. Its simplicity is what makes it dangerous.
4The Usual Suspects: Third-Party Services
Any cloud service that maps a custom hostname to a user-created resource is a potential takeover vector. The following categories account for the vast majority of confirmed subdomain takeover cases:
Object Storage
AWS S3, Google Cloud Storage, Azure Blob Storage. Custom domain buckets are one of the oldest and most reliable takeover vectors. The bucket name must match the subdomain exactly - making it claimable by anyone if the original bucket is deleted.
Error signature: NoSuchBucket / BucketNotFound
CNAME pattern: *.s3.amazonaws.com / *.storage.googleapis.com
Static Hosting Platforms
GitHub Pages, Netlify, Vercel, Surge.sh. These platforms allow instant deployment with custom domains. A CNAME pointing to a deleted GitHub Pages repo can be claimed by creating a new repository with the same name under any GitHub account.
Error signature: 404 with platform branding, 'There isn't a GitHub Pages site here'
CNAME pattern: *.github.io / *.netlify.app
PaaS & App Hosting
Heroku, Render, Railway, Fly.io. App slug names are global across the platform - first registered wins. A CNAME to a deleted Heroku app can be claimed by any user who registers the same app name, regardless of account.
Error signature: 'No such app' / 'App not found'
CNAME pattern: *.herokuapp.com / *.onrender.com
Marketing & Support Tools
Zendesk, HubSpot, Unbounce, Freshdesk. These tools allow companies to white-label their support portals and landing pages with custom subdomains. When the subscription ends, the DNS record often remains.
Error signature: Platform-specific 'not configured' pages
CNAME pattern: *.zendesk.com / *.hubspot.com / *.unbounce.com
The list is longer than you think.
The open-source projectcan-i-take-over-xyzmaintains a community-updated list of over 100 services with known takeover fingerprints. As of 2026, dozens of major platforms remain exploitable. If your organization has ever used any cloud service that allows custom domain mapping, you have potential exposure.
5How to Protect Yourself: Active Monitoring
Defense against subdomain takeover is not a one-time audit. New dangling records appear every time a service is decommissioned without DNS cleanup. DomainRisk.io monitors your full subdomain inventory continuously — not just the DNS records, but the liveness of the resources behind them.
Permanent Subdomain Inventory
You cannot protect what you cannot see. DomainRisk.io enumerates your subdomains from multiple sources — certificate transparency logs (crt.sh), passive DNS databases, and active DNS brute-forcing — to build a comprehensive map of your attack surface. New subdomains that appear outside your DNS management workflow are flagged immediately.
The golden rule: if a subdomain exists in DNS, it is part of your attack surface — regardless of whether it is "active" or "just a test environment."
CNAME Liveness Validation
A standard DNS check only tells you where a CNAME points. DomainRisk.io goes further: it resolves the CNAME chain, performs an HTTP request to the final destination, and checks the response against a database of known platform error fingerprints. A CNAME that points to a claimable resource triggers ahigh-severity finding— not just a note.
DNS check only
CNAME resolves → record looks healthy → no alert
DomainRisk approach
CNAME resolves → HTTP response → fingerprint match → takeover risk flagged
DNS Hygiene — The Golden Rule
The single most effective mitigation is procedural:delete the DNS record before cancelling the service. This sounds obvious. It is almost never done in practice because DNS management and service decommissioning happen in different teams, different tools, and different tickets.
Operationalize it: add DNS cleanup as a mandatory checklist item in your service decommissioning runbook. Every cloud service retirement, SaaS contract cancellation, or domain migration should include a step that lists and removes all associated DNS records.
Do you have dangling DNS records pointing to nowhere?
Get a complete attack surface scan — subdomain inventory, CNAME liveness validation, SSL/TLS, DMARC, HSTS and 30+ additional risk factors — in under 60 seconds. Free scan, no credit card required.
6Conclusion: Reclaim Control of Your Attack Surface
A secure domain is not just an encrypted domain.
It is a domain where every DNS record points to a resourceyou own and control.Encryption secures the channel. Authentication (DMARC, HSTS, CAA) secures the identity. Subdomain inventory secures the perimeter. All three are necessary. None is sufficient alone.
The attack surface exposed by dangling DNS records is invisible in standard monitoring. It does not trigger SSL alerts, firewall alarms, or WAF rules. It only becomes visible when someone — an attacker or a scanner — specifically looks for it. Attackers look for it systematically and automatically. Your defense needs to match that cadence.
The question is not whether you have dangling DNS records. Statistically, any organization that has used more than a handful of cloud services over the past five years has them. The question is whether you find them first. Run an attack surface scan on DomainRisk.io to see every subdomain, every CNAME target, and every orphaned record in your DNS zone — before someone else does.