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

Imagine visiting a trusted corporate website, like dev.example.com, only to find it hosting a phishing page or a cryptocurrency scam. This isn't necessarily the result of a server breach; instead, it is often the consequence of a "dangling DNS" record. Subdomain hijacking, also known as subdomain takeover, is a high-impact vulnerability where an attacker gains control over a legitimate subdomain of a target organization. This occurs when a DNS record points to an external service that has been decommissioned or deleted, but the DNS entry remains active.

In this guide, we will dive deep into the technical mechanics of subdomain hijacking, explore common exploitation scenarios, and discuss how you can protect your organization using modern attack surface management tools like Jsmon.

Understanding the DNS Fundamentals

To understand how a takeover happens, we must first look at how the Domain Name System (DNS) functions. Most organizations do not host all their services on-site. Instead, they use third-party cloud providers for hosting, support desks, and marketing tools.

When a company wants blog.example.com to point to a WordPress site or a GitHub Pages site, they use a CNAME (Canonical Name) record. A CNAME record acts as an alias, mapping one domain name to another. For example:

blog.example.com.  IN  CNAME  example-corp.github.io.

In this scenario, when a user types blog.example.com into their browser, the DNS resolver sees the CNAME and then looks up the IP address for example-corp.github.io. The browser then sends an HTTP request to GitHub's servers, which use the Host header to determine which specific site to serve.

The "Dangling DNS" Problem

The vulnerability arises when the relationship between the CNAME record and the third-party service is severed on the provider's side, but not in the organization's DNS settings.

Suppose the marketing team decides to stop using that GitHub Pages site. They delete the repository or the custom domain setting in the GitHub dashboard. However, the IT department forgets to remove the CNAME record in the company's DNS zone file. The record for blog.example.com is now "dangling"-it points to a resource (example-corp.github.io) that is now available for anyone else to claim on GitHub.

An attacker can simply create a new GitHub account, create a repository, and claim blog.example.com as their custom domain. Because the DNS record already points to GitHub, GitHub's servers will verify the ownership and start serving the attacker's content under the trusted blog.example.com domain.

Common Scenarios for Subdomain Takeovers

While GitHub Pages is a classic example, many cloud services are susceptible to this vulnerability. Each service has a different mechanism for how they handle custom domains, which changes how an attacker verifies the takeover.

1. Amazon S3 Buckets

Organizations often use Amazon S3 to host static assets or even entire websites. A CNAME might point to assets.example.com -> example-assets.s3.amazonaws.com. If the S3 bucket is deleted but the CNAME remains, an attacker can create a bucket with the exact same name (example-assets) in the same AWS region.

2. Heroku Applications

Heroku uses a similar logic. If an app is decommissioned but the domain app.example.com still points to vulnerable-app.herokuapp.com, an attacker can claim that app name on Heroku and serve malicious code.

3. Zendesk and Help Desks

Customer support portals often live on subdomains like support.example.com. These point to providers like Zendesk. If the Zendesk subscription is canceled but the DNS record is left behind, an attacker can sign up for a trial account and claim that specific subdomain alias.

Step-by-Step Technical Walkthrough

Exploiting a subdomain takeover generally follows a three-phase process: Discovery, Verification, and Claiming.

Phase 1: Subdomain Enumeration

An attacker first needs to find all subdomains associated with a target. They use tools like subfinder, amass, or specialized reconnaissance platforms like Jsmon to map the external attack surface.

Example command using dig to check a specific record:

dig blog.example.com CNAME

Response:

;; ANSWER SECTION:
blog.example.com.   300 IN  CNAME example-corp.github.io.

Phase 2: Identification and Verification

Once the subdomains are listed, the attacker checks the HTTP response of each. They are looking for specific "fingerprints" or error messages that indicate a service is missing.

Common fingerprints include:

• GitHub Pages: "404 Not Found - There isn't a GitHub Pages site here."
• Amazon S3: "The specified bucket does not exist."
• Heroku: "No such app - There is no app configured at this address."
• Azure: "404 Not Found - The resource you are looking for has been removed..."

An attacker might use a simple curl command to check the headers and body:

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

If the response returns a 404 with a provider-specific error message, it is a prime candidate for a takeover.

Phase 3: Exploitation (The Takeover)

The final step is to register the missing resource on the third-party platform.

• On GitHub, the attacker creates a repository and adds a CNAME file containing blog.example.com.
• On AWS, the attacker creates a bucket named example-assets in the correct region.
• On Zendesk, the attacker sets their account "subdomain" to the one expected by the target's DNS.

Once completed, the attacker now has full control over the content served at blog.example.com.

Real-World Impact and Risks

Subdomain hijacking is often rated as a High or Critical severity vulnerability in bug bounty programs because the impact is multi-faceted.

Phishing and Credential Theft

Users trust the main domain. If login-internal.example.com is hijacked, an attacker can mirror the company's actual login page. Users will see a valid SSL certificate (often easily obtained via Let's Encrypt once the domain is hijacked) and the correct domain name, making the phishing attempt nearly impossible to detect for the average employee.

Session Cookie Hijacking

This is perhaps the most technical and dangerous impact. Many web applications set cookies at the parent domain level to allow for Single Sign-On (SSO) across subdomains. For example, a cookie might be set with Domain=.example.com.

Because the hijacked subdomain (attacker.example.com) is part of .example.com, the browser will automatically send the user's session cookies to the attacker's server. The attacker can then use these cookies to hijack the user's active session on the main application.

Bypassing Content Security Policy (CSP)

If an organization's CSP whitelists *.example.com for script execution, a hijacked subdomain allows an attacker to host malicious JavaScript that the browser will execute without question, effectively bypassing Cross-Site Scripting (XSS) protections.

How to Detect Subdomain Hijacking

Manual detection is tedious and prone to human error. To effectively find these vulnerabilities, security teams use a combination of tools and techniques.

1. Automated Scanning

Tools like subjack or nuclei have built-in templates to detect the fingerprints of over 50 different cloud providers.

Example nuclei command:

nuclei -l subdomains.txt -t takeovers/

2. Continuous Monitoring

The attack surface is dynamic. A subdomain might be safe today and vulnerable tomorrow when a developer deletes a test environment. Continuous monitoring tools like Jsmon are essential for tracking changes in DNS records and alerting security teams the moment a dangling record appears.

3. DNS Audits

Regularly exporting your DNS zone files and cross-referencing them with active cloud resources is a manual but effective way to ensure no records are left behind.

Prevention and Mitigation Strategies

Preventing subdomain hijacking requires a shift in how organizations manage their infrastructure lifecycle.

Implement a Decommissioning Process

The most effective prevention is a strict policy: DNS records must be deleted before the service they point to is deleted.

1. Identify the CNAME record.
2. Remove the record from the DNS provider (Cloudflare, Route53, etc.).
3. Verify the record is gone using dig.
4. Only then, delete the S3 bucket, GitHub repo, or Heroku app.

Use Verification Records

Many modern providers have moved toward using TXT records for domain verification. Instead of just pointing a CNAME, the provider asks you to add a unique string to a TXT record. This makes hijacking much harder, as the attacker cannot easily replicate the unique verification string required by the provider.

Restrict Cookie Scope

Whenever possible, avoid setting cookies for the entire parent domain. Use specific subdomains for cookies to limit the blast radius if one subdomain is compromised.

Conclusion

Subdomain hijacking is a deceptively simple yet devastating vulnerability. It exploits the gap between DNS management and cloud service lifecycle management. By understanding the mechanics of CNAME records and the specific fingerprints of cloud providers, security professionals can identify these "dangling" risks before attackers do.

As organizations scale, the number of subdomains grows exponentially, making manual tracking impossible. Security teams must adopt automated solutions to maintain visibility over their evolving digital footprint.

To proactively monitor your organization's external attack surface and catch exposures like dangling DNS records before attackers do, try Jsmon.