6 min readDec 15, 2022

(sub)Domain Takeover

Domain and subdomain takeovers pose a significant risk to organizations, particularly those with lapses in digital asset management, like expired domain names. Law firms, due to their sensitive nature of work, often bear the brunt of such security loopholes. This risk materializes when threat actors manage to register expired domain names, thereby reactivating the email service of the original owner, which could potentially expose sensitive and confidential information.

Understanding the Threat

This concept of domain hijacking, a well-known security vulnerability, results from various factors like social engineering, unauthorized access, and overlooked DNS entries meant for cloud services. Threat actors may exploit an unattended subdomain set up for an obsolete third-party cloud service, which can then serve as a launching pad for an array of attacks against the victim company.

Cloud services are commonly used by enterprises of all sizes due to their ease of configuration. Companies can easily create the needed resource via a cloud service and use records like CNAME or DNAME to guide users from their subdomain to the external cloud service. However, these very DNS entries often go unattended when a company stops using a cloud service, creating security risks. Also, companies may overlook the re-registration of domain names, which could lead to domain takeovers.

Domain Takeover Examples

— Example 1

Theoretically, a Subdomain Takeover flaw is when an attacker can hijack the subdomain of a company and control what content is being displayed when the users navigate to that particular domain.

Practically, you can do a Subdomain Takeover through hacking or registration of an existing DNS CNAME record of that subdomain.

Let’s take the following example:

We have the domain “xyz.com” with the subdomain “victim.xyz.com.”
The “victim.xyz.com” subdomain has a CNAME record that is pointing to another domain called “promotional-campaign-xyz.com.”
You find that “promotional-campaign-xyz.com” has expired, and you are able to purchase it.
Once you get “promotional-campaign-xyz.com” in your control, you will have a page displaying any arbitrary content you want, which will be displayed once a user accesses “victim.xyz.com.”

— Example 2

To assist you in understanding the fundamentals, if you have never carried out a subdomain takeover or would like a new introduction, here is another example scenario.

For this scenario, let us assume that example.com is the target and that the team running example.com has a bug bounty program. While enumerating, all of the subdomains belonging to example.com,a hacker stumble across a subdomain pointing to GitHub pages. We can determine this by reviewing the subdomain's DNS records; in this example, subdomain.example.com has multiple A records pointing to GitHub's dedicated IP addresses for custom pages.

$ host subdomain.example.com
→ subdomain.example.com has address 192.30.252.153
→ subdomain.example.com has the address 192.30.252.154
$ whois 192.30.252.153 | grep “OrgName”
→ OrgName: GitHub, Inc.

When navigating to subdomain.example.com, we discover the following 404 error page. Figure 1.

At this point, most hackers’ senses begin to tingle. This 404 page indicates that there is no content under the top-level directory and that we should try to add this subdomain to our personal GitHub repository. Please keep in mind that this does not imply that a takeover is possible in all cases. Some application types necessitate checking both HTTP and HTTPS responses for takeovers, while others may not be at all vulnerable.

Once the custom subdomain has been added to our GitHub project, we can see that the contents of the repository are served on subdomain.example.com we have successfully claimed the subdomain. For demonstration purposes, the index page now displays a picture of a frog. Figure 2.

Detection and Mitigation of (Sub)Domain Takeover

Detecting potential vulnerabilities for (sub)domain takeovers requires a diligent search for forgotten or misconfigured domains. DNS enumeration can help unearth these by scanning all domains (both past and present) via DNS servers and resource records.

Prevention Strategy

Preventing (sub)domain takeovers involves a few key steps:

Routinely review all DNS entries, deleting those that point to unused external services.
Build a comprehensive list of subdomains by examining DNS entries and records.
Create a list of domains that have CNAME entries directed to a live, third-party site.
Whenever a new service is integrated with a new subdomain, ensure that it’s added to the monitored subdomains list.

Additionally, perform regular scans on various platforms to identify potential vulnerabilities:

Scan Amazon Route53 across AWS Organization for domain records prone to takeover.
Check Cloudflare for vulnerable DNS records.
Take control of susceptible subdomains before attackers and bug bounty researchers do.
Detect vulnerable domains in Google Cloud DNS using tools like Domain Protect for GCP.

Testing for (Sub)Domain Takeover

Black-Box Testing is often the first step in checking for possible domain takeovers. This involves enumerating the victim DNS servers and resource records through various methods like DNS enumeration using common subdomains dictionary, DNS brute force, or web search engines, and other OSINT data sources.

Using the ‘dig’ command, the tester looks for DNS server response messages such as NXDOMAIN, SERVFAIL, REFUSED, and “no servers could be reached”, which could indicate a potential vulnerability that requires further investigation.

Testing DNS A, CNAME Record Subdomain Takeover

Perform a basic DNS enumeration on the victim’s domain (victim.com) using dnsrecon:

Identify which DNS resource records are dead and point to inactive/not-used services. Using the dig command for the CNAME record:

The following DNS responses warrant further investigation: NXDOMAIN.

To test the A record the tester performs a whois database lookup and identifies GitHub as the service provider:

The tester visits subdomain.victim.com or issues an HTTP GET request which returns a “404 - File not found” response which is a clear indication of the vulnerability.

The tester claims the custom domain using GitHub Pages. Figure 4.