A subdomain takeover happens when a DNS record for one of your subdomains points at an external resource you no longer control — a deleted cloud service, an abandoned SaaS account — and an attacker claims that resource, so your subdomain serves their content. It's one of the most common findings in external assessments, and it almost always comes down to the same root cause: DNS records that outlive the things they point to.
How dangling DNS records happen
Modern infrastructure churns quickly, and DNS rarely keeps up. The typical scenarios:
- Marketing stands up campaign.example.com.au on a landing-page platform. The campaign ends, the account is cancelled, the CNAME stays.
- A developer deletes a cloud storage bucket or app service, but nobody removes the DNS record pointing at it.
- A team trials a third-party helpdesk, status page or blog platform on a subdomain, then abandons it.
- A merger, rebrand or agency handover leaves old DNS zones with no clear owner.
The underlying pattern is organisational: creating a DNS record and provisioning the resource behind it are separate processes, often owned by different teams, and deprovisioning almost never includes a DNS cleanup step.
How attackers claim dangling records
Attackers enumerate subdomains continuously using certificate transparency logs, public DNS datasets and brute-forcing, then check where each record resolves. When a CNAME points at a service where the target resource is unclaimed, the takeover is often as simple as signing up:
- Register an account on the SaaS platform and add your subdomain as a custom domain
- Create a storage bucket or application with the same name the record points to
- Claim the abandoned resource on whichever provider the record references
No exploit is required. Whether a takeover is possible depends on the provider — some now verify domain ownership before serving a custom domain, but plenty don't, or didn't when the record was created. Because enumeration and claim-checking are trivially automated, attackers do this at internet scale, not just against targets they've chosen in advance.
Why subdomain takeover matters
It sounds cosmetic. It isn't:
- Phishing with your name on it — content is served from a genuine subdomain of your real domain, inheriting your brand's trust and surviving casual URL inspection.
- Cookie and session attacks — cookies scoped to your parent domain can be readable or settable from the hijacked subdomain, which can escalate into account attacks on your real applications.
- Security control bypass — subdomains are frequently trusted in CORS configurations, content security policies and email security rules.
- Valid TLS certificates — an attacker who controls the content can often obtain a legitimate certificate for your subdomain, making the page look completely authentic.
- Reputation and SEO damage — hijacked subdomains get used for malware distribution, spam and scams that get your domain blocklisted.
How to detect dangling records
- Build a complete inventory of DNS records across every zone, registrar and DNS provider you use. After years of growth this is genuinely hard — it's a core part of external attack surface management.
- Resolve every CNAME, A and ALIAS record and confirm the target exists and is actually yours.
- Check responses against known takeover fingerprints — the distinctive error pages services return for unclaimed resources, such as 'NoSuchBucket' or 'There isn't a site here'. Community projects maintain signature lists for hundreds of services.
- Make it continuous rather than annual. DNS changes weekly in most organisations, and a record that was fine last month can be dangling today.
We check for dangling DNS on every external network penetration test, because it's cheap for us to find and cheap for attackers to exploit.
How to prevent it
Process fixes beat one-off cleanups:
- Make DNS part of your decommissioning checklist — remove the record before deleting the resource it points to
- Centralise DNS change management so every zone has a known owner and an audit trail
- Restrict who can create records, and review changes periodically
- Prefer providers that verify domain ownership before serving custom domains
- Monitor continuously for new subdomains and newly dangling records
FAQ
Is subdomain takeover a vulnerability in DNS itself?
No. DNS is doing exactly what it was told to do. The vulnerability is operational: a record pointing at a resource you no longer control. The fix is hygiene and process, not patching.
How common is subdomain takeover?
It's a routine finding in external assessments and bug bounty programs, particularly at organisations with years of marketing sites, product launches and cloud migrations behind them. The more DNS records and third-party services you've accumulated, the more likely at least one is dangling right now.
What should we do if we find one?
Remove or correct the DNS record immediately — that alone ends the takeover. Then check whether the resource was already claimed (is the subdomain serving content you don't recognise?), review any relevant logs, and treat the finding as a prompt to audit the rest of your zones for the same pattern.
Want your external footprint checked properly? Our external network penetration tests run AU$6,000–12,000 over 4–7 days, with a fixed quote within one business day of a free scoping call and a free retest of fixed issues within 90 days — get in touch.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.