Subdomain Takeover: When a Dead DNS Record Becomes Your Entry Point

A forgotten CNAME record is sometimes all it takes to hijack part of a domain. Subdomain takeover doesn't need a zero-day. It only needs one thing which is a DNS record that nobody cleaned up. If example.target.com still points to a GitHub Pages repo, an S3 bucket, or a Heroku app that's since been deleted, whoever claims that same resource now controls whatever loads under the victim's domain — SSL cert included.

What Is Subdomain Takeover?

When an organization sets up a subdomain like staging.target.com, they typically point it at an external service like GitHub Pages, an S3 bucket, Heroku, Netlify, and so on. That's done via a CNAME record, which essentially instructs DNS to forward anyone hitting that subdomain over to the external resource.

The problem happens when the external resource gets deleted — the app is removed, the bucket is gone, the account is closed — but the CNAME record stays. The DNS still points to something that no longer exists.

If the platform allows anyone to claim that same resource name, an attacker can register it and start serving content directly under the victim's subdomain. The domain hasn't been hacked in any traditional sense. The DNS is doing exactly what it was configured to do. It's just pointing at the wrong person now.

Why It Actually Matters

The content loads under a domain the browser trusts. That's the core of the impact.

Phishing. A fake login page with a valid TLS cert is far more convincing than anything an attacker could build on their own domain. Users see the right URL, the padlock is green, and they have no reason to be suspicious.

Cookie Hijacking. If the target scopes their session cookies to *.target.com, any taken-over subdomain under that domain can read those cookies. A single misconfigured DNS record can expose active user sessions.

CSP Bypass. If the target's Content Security Policy whitelists *.target.com as a trusted script source, an attacker-controlled subdomain becomes a valid script host. That CSP is now meaningless.

The HTTPS certificate just makes it worse. Most platforms automatically provision TLS for custom domains, so the attacker gets a trusted cert for free along with the takeover.

The Attack Process

To simulate how this exploit works in practice, I picked up a lab from writeup-db.com. The full attack process follows this sequence: Enumerate → Check DNS → Verify Service is Dead → Fingerprint the error → Claim the resource → Exploit.

1) Enumerate

Start by building out the full list of subdomains for the target, using tools like subfinder or ffuf. The lab has already provided which subdomain for anyone to exploit, but I'll still run subfinder here to show what the enumeration output looks like as a demonstration.

2) Check DNS

Once enumeration is done, we check the CNAME record of the target. In this case, our target is token-scanner.can-i-take-over.online. A CNAME pointing to an external platform is what we're after.

The result from using dig shows the subdomain resolves to s3.amazonaws.com, an AWS S3 endpoint. A CNAME pointing to S3 makes this a strong candidate, but it's not yet confirmed as vulnerable. The bucket might still be active and properly claimed by the original owner.

3) Verify Service is Dead

Before proceeding to any exploit, we need to verify that the subdomain is indeed unclaimed. For this step, I used nuclei and also accessed the subdomain directly to confirm.

Based on the scan result, nuclei flagged it immediately as [aws-bucket-takeover] with a severity of high. That confirms that the service is indeed dead and the platform is AWS S3.

To double-check, visiting the subdomain directly in the browser gave us a response in a raw XML error from AWS showing NoSuchBucket and confirming the bucket name as token-scanner.can-i-take-over.online. This is the fingerprint signature for an unclaimed S3 bucket, and it means the bucket is free for anyone to grab. Each platform has its own version of this error, and recognizing it is what tells you whether a takeover is actually possible.

4) Claiming the Resource

Once the service is confirmed dead and identifiable, the actual exploitation is surprisingly straightforward. First, we need to create an S3 bucket with the exact same name as the subdomain. That's what ties the claim back to the CNAME. So for our case, it must betoken-scanner.can-i-take-over.online.

Next, enable static website hosting on the bucket under the Properties tab.

The endpoint gets assigned as http://token-scanner.can-i-take-over.online.s3-website-ap-southeast-2.amazonaws.com. Then under the Permissions tab, turn off Block Public Access and apply a bucket policy to allow public read on all objects.

With everything configured, trying to access the subdomain directly returns AccessDenied , it redirects to the S3 bucket that was created previously. To prove the takeover was successful, I uploaded a simple text file to the bucket and access it through the subdomain. Based on the results, the file loads cleanly. We now control what gets served under token-scanner.can-i-take-over.online.

Conclusion

Subdomain takeover is one of those vulnerabilities that feels almost too simple — no exploit code, no reverse shell, just AWS console and a bucket name. But that simplicity is exactly what makes it dangerous. Most organizations don't audit their DNS records regularly, and decommissioned services rarely get cleaned up properly.

Depending on how the target handles cookies and CSP, a taken-over subdomain can go from a medium-severity finding to something that compromises active user sessions entirely.

References

• can-i-take-over-xyz — community database of takeover status across 100+ services
• nuclei-templates/http/takeovers — automated detection templates
• subfinder — passive subdomain enumeration
• MITRE ATT&CK: T1584.001 — Compromise Infrastructure: Domains
• HackerOne Hacktivity — public bug bounty reports, many subdomain takeover examples
• Subdomain Takeover Lab — lab used in this walkthrough