Article image
The "Subdomain Takeover" Vulnerability: Why Dangling DNS Is an Agency Liability
For digital agencies, web design firms, and managed service providers (MSPs), rapid deployment and prototyping are standard operating procedure. Teams constantly spin up staging sites, client preview environments, and campaign micro-sites on platforms like Vercel, Heroku, AWS S3, Azure App Services, Netlify, or GitHub Pages. To streamline client review, developers point custom subdomains — staging.clientbrand.com, dev-app.agencyclient.com — at these external cloud endpoints with a CNAME record.
The failure happens later: the project ships, the temporary cloud instance gets deleted or the subscription lapses, and the CNAME record stays active in Cloudflare, Route 53, or GoDaddy. That's a dangling DNS record — and it's currently one of the most actively exploited, lowest-effort attack paths on the internet. Security researchers describe it less as a software vulnerability and more as a DNS hygiene failure: a record you own still resolves to infrastructure you no longer control.
This is not a theoretical risk. A threat actor tracked by Infoblox and nicknamed "Hazy Hawk" has been hijacking dangling CNAME records since at least December 2023, and its victim list is a case study in how bad this can get for a brand: the U.S. Centers for Disease Control and Prevention, Deloitte, PwC, Ernst & Young, government agencies on multiple continents, and dozens of universities including MIT, Harvard, and Stanford.
This guide breaks down how the CNAME vulnerability actually works, which cloud platforms carry the most current risk, what's changed recently, and a practical audit framework agencies can run against their client portfolios.
- Anatomy of an Attack: How a CNAME Record Goes "Dangling" A subdomain takeover doesn't require cracking passwords or finding a server-side zero-day. It exploits the gap between cloud resource provisioning and DNS record management — two tasks that are frequently owned by different people on different tools.
[ Client DNS Zone ] [ Public Cloud Provider ]
staging.clientbrand.com --- (CNAME Record) ---> app-xyz.azurewebsites.net
|
(Resource Decommissioned)
|
v
[ Unclaimed Endpoint ]
|
(Attacker Registers Name)
|
v
[ Victim Web Browser ] =======================> [ Attacker Controlled Server ]
The exploitation sequence:
Creation — A developer provisions a staging app on Azure App Services at app-client-dev.azurewebsites.net, then creates a CNAME record mapping preview.client.com to that endpoint.
Deprovisioning — Months later, the agency deletes the staging container to stop recurring billing. The CNAME record for preview.client.com is never removed. It is now dangling.
Discovery — Attackers routinely scan DNS records and Certificate Transparency (CT) logs for CNAMEs pointing at known cloud-provider domains (*.azurewebsites.net, *.s3.amazonaws.com, *.github.io, *.herokuapp.com, and similar) that return errors like 404 Not Found or NoSuchBucket.
Takeover — The attacker registers a new resource on the same platform, using the exact name the dangling record still points to.
Hijacking — Because the DNS record never changed, all traffic to preview.client.com now lands on infrastructure the attacker controls.
- Why Subdomain Takeovers Cause Disproportionate Damage The attack rides on the client's own domain reputation, which is exactly what lets it bypass the defenses people normally rely on.
High-fidelity phishing. Because the hijacked page loads under the client's real domain, browsers, email filters, and security tooling generally trust it by default. Convincing login pages hosted there have no obvious tell.
Session cookie exposure. Applications that scope authentication cookies to the root domain (.client.com) will hand those cookies to whatever is running on any subdomain — including one an attacker now controls.
Valid TLS certificates. Once an attacker controls routing for preview.client.com, they can pass an automated domain-validation challenge with Let's Encrypt or a similar CA and get a certificate with a valid padlock, removing the usual browser warning signs.
Agency liability. If a client traces a breach back to a staging environment the agency built and never cleaned up, most current Master Services Agreements have cybersecurity and data-protection indemnification language that treats this as basic negligence.
This isn't hypothetical severity-inflation. Infoblox's research into Hazy Hawk found the group uses hijacked government, academic, and corporate subdomains to run people through traffic-distribution systems into scams, fake antivirus pages, and malware — leaning on the credibility and search visibility of the parent domains rather than needing anything more sophisticated. Separately, a 2024 investigation found that researchers who deliberately re-registered roughly 150 previously deleted AWS S3 buckets logged over eight million incoming requests, including software update checks and deployment artifact pulls — traffic that had nowhere legitimate to go and would otherwise have been available to whoever claimed the bucket name.
- Current Risk by Platform (as of Mid-2026) Not every cloud platform is equally exposed, and the picture has shifted meaningfully in the last year. This table reflects current documentation and reporting rather than the static risk levels often repeated in older takeover guides.
Platform Vulnerable Pattern Current Risk What Changed
AWS S3 (buckets in the classic global namespace) *.s3.amazonaws.com High for existing buckets AWS introduced account regional namespaces for S3 general purpose buckets in March 2026, letting teams reserve bucket names permanently within their own account and region so a deleted bucket's name can't be reclaimed by anyone else. But existing buckets are unaffected, can't be migrated into the new namespace, and the classic global namespace is still the default when creating a bucket through the console, CLI, or SDK — so most existing infrastructure remains exposed until someone deliberately opts in.
Azure App Service *.azurewebsites.net High Unchanged. Microsoft's own remediation guidance is still manual: review DNS zones for CNAME records pointing at FQDNs of resources that no longer exist, remove them, and provision replacement resources at the same FQDN if the subdomain needs to keep resolving.
GitHub Pages *.github.io High unless verified GitHub's own documentation now recommends verifying a custom domain before adding it to a repository specifically to reduce takeover risk, but verification isn't mandatory by default, so unverified dangling CNAMEs remain claimable. GitLab Pages had a comparable, publicly disclosed takeover issue reported via HackerOne in 2024.
Vercel *.vercel.app / cname.vercel-dns.com High Still an active, well-documented target. Deleted projects or unlinked domains leave the CNAME resolving to Vercel's infrastructure with no automatic reservation of the old hostname.
Netlify *.netlify.app Medium Netlify requires a DNS TXT-record verification challenge before it will attach a custom domain to a site, for any domain that hasn't already been added to Netlify's own DNS — once a subdomain is added there, no other account can claim it. That raises the bar over GitHub Pages or Vercel, though misconfigured or previously-linked domains still surface in bug bounty reports.
CDN / edge platforms (Akamai, Bunny CDN, Cloudflare CDN, Fastly) Various CNAME patterns High — actively exploited at scale This is the category behind Hazy Hawk's campaign: dangling DNS CNAME records pointing to abandoned cloud infrastructure across Amazon S3, Microsoft Azure, Akamai, Bunny CDN, GitHub, and Netlify, hijacked and reused since December 2023.
The AWS change is worth flagging to clients directly: it's a real structural fix, but it only protects newly created, opted-in buckets — it does nothing for the staging buckets your team already has sitting in client accounts today.
- How to Conduct a DNS Security Audit [ Step 1: Enumerate Subdomains ] │ ▼ [ Step 2: Query DNS Records (dig / nslookup) ] │ ▼ [ Step 3: Validate Target Status (Active vs. 404/Unclaimed) ] │ ▼ [ Step 4: Decommission & Delete Record ] │ ▼ [ Step 5: Log the Asset and Its Removal Date ] Step 1 — Enumerate subdomains. Pull together every domain your agency manages access to. Certificate Transparency logs (searchable at crt.sh) are the fastest way to surface subdomains that were issued a certificate at some point, even ones nobody currently remembers creating.
Step 2 — Identify CNAME targets. For each subdomain, check what it currently resolves to:
dig CNAME preview.clientbrand.com +short
Output: app-client-dev.azurewebsites.net
Step 3 — Verify the target is still live. Request the URL and check the response. Every platform in the space has known "fingerprint" error strings that indicate an unclaimed resource — GitHub's Pages service returns a distinct not-found message, S3 returns NoSuchBucket, and so on. The community-maintained can-i-take-over-xyz reference list on GitHub is the closest thing to a canonical, continuously updated catalog of these fingerprints across dozens of providers, and it's a reasonable first stop before assuming a given 404 is exploitable.
Step 4 — Purge or repoint. If the cloud resource is gone for good, delete the CNAME record. AWS's own security guidance on this point is specific and worth following regardless of provider: delete the DNS record first, wait for the TTL to expire, and only then delete the underlying resource — reversing that order is exactly what leaves the window open. If the subdomain still carries SEO value, a 301 redirect to a live page is safer than leaving a bare CNAME pointing at an external host.
Step 5 — Log it. Whatever ticketing or asset system your agency uses, the decommissioning step needs a paper trail: who owned the subdomain, what it pointed to, and when the CNAME was actually removed — not just when the cloud resource was torn down.
For agencies managing this across dozens or hundreds of client domains, doing steps 1–3 by hand doesn't scale well. Open-source scanners built for this (subdomain enumeration plus CNAME fingerprint checks) can be run on a schedule, and several commercial attack-surface-management vendors now sell continuous dangling-DNS monitoring as a standing feature rather than a one-time audit.
- Where InstaRenewal Fits — and Where It Doesn't It's worth being precise about what a renewal and asset-tracking tool like InstaRenewal actually does here, because it's easy to overstate.
InstaRenewal is a manually-maintained ledger for tracking domain, hosting, and SaaS renewal dates alongside who owns each asset. It does not run live DNS scans, does not integrate with cloud provider APIs to detect deprovisioned resources, and does not automatically flag dangling CNAME records. Closing that specific gap — actually finding dangling records — is a job for the dig/CT-log workflow above, or a dedicated DNS-scanning tool.
Where InstaRenewal genuinely helps is upstream of the technical scan: it gives an agency a single place to log every staging subdomain it creates, which hosting provider it points to, and — critically — a target decommission date at the time the subdomain is first set up. That record is what turns "someone should probably check for old DNS entries at some point" into a specific, assignable task: when a project or hosting subscription is marked as ended in InstaRenewal, that's the trigger for a human to actually run the DNS audit and confirm the CNAME was pulled, not a system that verifies it automatically. The audit itself — the dig commands, the fingerprint checks, the actual deletion — still has to be done by a person or a separate scanning tool.
In other words: InstaRenewal keeps you from forgetting a subdomain exists. It doesn't check whether that subdomain has gone dangling. Those are two different problems, and conflating them is how agencies end up assuming a manual ledger is doing detection work it was never built to do.
- Conclusion A single abandoned CNAME record can escalate into a security incident that damages client trust and creates real legal exposure — and the Hazy Hawk campaign shows this isn't a niche risk reserved for careless small operators; it's been running against the CDC, Deloitte, and top-tier universities for years. The fix isn't exotic: enumerate what you have, check whether the targets are still live, delete what isn't, and keep a record of when you did it. Building that into a recurring SOP — with an asset ledger flagging when to check, and a real DNS-scanning process to do the checking — is what separates agencies that catch this before an attacker does from the ones that show up in the next research report.
Top comments (0)