Loading
Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A dangling DNS record pointing at a deprovisioned cloud resource is enough for an attacker to serve content from your own subdomain. How it happens, and how to check for it.
A subdomain takeover doesn't require breaking into anything, it requires finding a DNS record someone forgot to delete. A CNAME record still pointing status.example.com at a decommissioned Heroku app, an unclaimed S3 bucket, or a deleted GitHub Pages site is, by itself, enough for an attacker to claim that same resource under their own account and start serving whatever content they want from a subdomain that still resolves under your organization's real, trusted domain.
Cloud platforms and SaaS tools are built around the assumption that you'll point a CNAME at them and they'll serve your content, Heroku, GitHub Pages, Azure, Shopify, Fastly, and dozens of others all work this way. The problem is a sequencing gap: decommissioning the service (deleting the Heroku app, letting the S3 bucket lapse) and decommissioning the DNS record pointing at it are two separate steps, done by two different teams, often months apart. The DNS record is cheap to forget, it's not costing anyone money, it's not showing up in a cloud spend report, and unless someone is specifically auditing DNS zone files, a dangling CNAME can sit unnoticed for years.
Once the underlying resource is gone but the CNAME still points at the platform, the platform itself has no way to know that hostname isn't supposed to be claimable anymore. An attacker who finds the dangling record simply registers a new resource on that same platform, a new Heroku app, a new S3 bucket with the exact bucket name the old CNAME expects, a new GitHub Pages repo, under their own account, and the platform serves it. DNS still resolves status.example.com to the platform correctly; the platform just hands the request to whoever currently owns the matching resource, which is now the attacker. From that point, the subdomain can host a convincing phishing page, harvest session cookies for any application that trusts *.example.com in its CORS policy or cookie scope, or simply serve malware from a URL that inherits your domain's reputation and any SPF/DMARC trust it carries.
Subdomain sprawl is the real root cause. Marketing spins up a landing page on a third-party builder pointed at promo.example.com for a campaign, the campaign ends, the landing page gets deleted, and the CNAME stays. A dev team provisions a staging environment on a cloud platform, the project gets deprioritized, the environment gets torn down, the DNS entry doesn't. Multiply that across every team that's ever been handed the ability to create a subdomain, over years, and most organizations have more dangling records than anyone currently tracks. Our Domain Doppelganger Finder catches a related but different problem, lookalike domains registered by someone else, while finding your own forgotten subdomains starts with actually enumerating what exists.
A dangling DNS record isn't a code vulnerability, which is exactly why it survives code review, dependency scanning, and even a lot of penetration tests scoped only to the application layer. It's an infrastructure hygiene gap, and it's precisely the kind of external-facing exposure our Network Security Testing engagements are scoped to catch. For the DNS controls that stop a related class of domain-spoofing attack, see our piece on SPF, DKIM, and DMARC.
Tell us about your environment and goals, we'll help you scope the right engagement.