Subdomain Takeover: The Silent DNS Vulnerability

This is a subdomain takeover. It's one of the most common DNS vulnerabilities, and it's entirely preventable.

How It Happens

Subdomain takeovers exploit a simple gap: a DNS record points to a third-party service, but the resource on that service no longer exists.

The typical flow:

1. Your team creates docs.example.com and adds a CNAME pointing to example-docs.s3-website-us-east-1.amazonaws.com
2. The S3 bucket serves your documentation site
3. Months later, the team migrates docs to a different platform and deletes the S3 bucket
4. The CNAME record stays behind; nobody remembers to remove it
5. An attacker creates an S3 bucket with the same name in the same region
6. docs.example.com now serves the attacker's content, under your domain

The attacker controls the content, but the domain belongs to you. From a user's perspective, they're visiting a legitimate subdomain of your organization.

Vulnerable Services

Any service that allows user-controlled resource naming is potentially vulnerable. The most commonly exploited:

Cloud platforms: AWS S3, Azure Blob Storage, Google Cloud Storage. Bucket names in many configurations can be claimed by anyone.

PaaS providers: Heroku, GitHub Pages, Netlify, Vercel, Fly.io. App names and custom domain bindings can be reclaimed after deletion.

CDN providers: AWS CloudFront, Azure CDN, Fastly. Distribution endpoints that are released can sometimes be reclaimed.

SaaS tools: Help desk portals, status pages, campaign landing pages. Any service that maps a custom domain to a resource that can be recreated.

The common thread: the DNS record points to a namespace where the attacker can register the target name.

The Real-World Impact

Subdomain takeovers aren't theoretical. They're actively exploited, and the consequences range from embarrassing to dangerous.

Credential theft. An attacker can serve a phishing page on your subdomain. Since the domain is legitimate, users are more likely to trust it. If your organization uses SSO, cookies scoped to .example.com may be sent to the attacker's server instead.

Cookie hijacking. Cookies set on a parent domain (such as .example.com) are sent to all subdomains, including the taken-over one. Session tokens, authentication cookies, and CSRF tokens can be captured.

Reputation damage. An attacker serving malware, spam, or objectionable content on your subdomain damages your brand and can get your domain flagged by security services worldwide.

Email receiving. If an attacker can configure the taken-over service to handle email, they may be able to receive emails sent to addresses at that subdomain; this could include password reset links.

How to Find Dangling Records

Manual audit. Review your DNS zone for CNAME records pointing to third-party services. For each one, verify that the target resource still exists and is under your control. This is tedious for large zones but effective.

Automated scanning. Tools like subjack, nuclei, and can-i-take-over-xyz automate the detection process by checking known vulnerable service fingerprints.

DNS monitoring. Continuous monitoring catches the problem at the source. When a CNAME record's target returns an error page or a "this resource doesn't exist" message, that's a signal that the record is dangling.

The key insight: the vulnerability is created when the resource is deleted, not when the attacker claims it. If you detect the dangling record before an attacker does, you can remove it and close the window.

Prevention

Remove DNS records when decommissioning services. This is the obvious fix and the one that's most often skipped. Add "remove DNS records" to your decommissioning checklist as a required step, not an afterthought.

Use a DNS inventory. Maintain a mapping of which DNS records point to which services and who owns them. When a service is decommissioned, the corresponding DNS records should be flagged for removal.

Monitor for dangling records. Automated monitoring that periodically resolves your DNS records and checks whether the targets are still alive catches the cases where someone forgot to clean up.

Limit wildcard DNS records. A wildcard record (*.example.com) pointing to a service where subdomains can be claimed is especially dangerous, as it creates an infinite attack surface.

Consider record-level ownership. In larger organizations, assign ownership to DNS records so there's always someone responsible for cleanup when a service changes.

What to Do If You're Vulnerable

If you find a dangling CNAME or A record:

1. Remove the DNS record immediately. Don't wait for the next maintenance window. A dangling record is an open vulnerability.
2. Check if the subdomain has already been claimed. Resolve the record and see what's being served. If it's not your content, someone else has taken it over.
3. Review server logs and analytics. If the subdomain was taken over, assess what data may have been exposed (cookies, credentials, user traffic).
4. Audit your entire zone. If one record was missed during decommissioning, others may have been too.

Subdomain takeovers are the DNS equivalent of leaving a key under the mat after you've given the house to someone else. The fix is simple: remove the record. The hard part is remembering to do it, or having monitoring that catches it when you don't.