The phenomenon known as Sub-Domain Takeover presents a subtle yet significant security risk. While it often stems from a configuration management error rather than a traditional software flaw, its impact is recognized by security platforms, including prominent bounty programs like HackerOne, making it a crucial topic for discussion.
This vulnerability arises in scenarios where a sub-domain is left pointing to an external service or domain that has since expired and become available for anyone to register. If a malicious user claims the expired domain, they can effectively take control of the original sub-domain’s traffic and content.
The Mechanics of Sub-Domain Takeovers
A core concept in understanding this vulnerability is the Canonical Name (CNAME) record.
What is a CNAME Record?
A CNAME record is a specific type of Domain Name Service (DNS) register. Its purpose is to specify an alias (another name) for a domain name. Essentially, it allows one domain to point to another domain or service.
For instance, a sub-domain like hello.domain.com might use a CNAME record to point to an external service at fulanito.com. This is common practice, especially for organizations that utilize cloud services (third-party, internet-based computing platforms). The CNAME register helps to clearly identify that the service is owned and maintained by another domain.
How the Takeover Occurs
The entire pointing process is totally transparent to end-users because the redirection happens during the DNS resolution phase, long before the user’s browser loads the page.
The problem emerges over time:
- A sub-domain (e.g.,
hello.domain.com) is configured with a CNAME record pointing to an external domain (e.g.,fulanito.com). - The external domain,
fulanito.com, expires and is not renewed. - Since the domain is now available, anyone can register it as new.
- Crucially, the original sub-domain’s CNAME record (
hello.domain.com) is still pointing to the now-availablefulanito.comname. - A malicious user registers the expired
fulanito.comand then uploads their own malicious content.
Now, if a user attempts to visit hello.domain.com, they are seamlessly redirected to the malicious content on the newly claimed fulanito.com. This allows the attacker to upload fake sites, spread malware, perform phishing, and generate a negative impact on the original domain owners.
The problem is currently widespread due to the extended number of users of cloud providers. In the cloud, it is very easy to create buckets (which are like instances or storage containers) that use available domains, allowing an attacker to quickly create fake sites that leverage the compromised sub-domains.
Different Types of Sub-Domain Takeovers
Sub-domain takeovers are categorized by the specific type of DNS record that has been misconfigured and expired.
CNAME Takeovers
This is the most common scenario. A CNAME takeover occurs when the domain the record points to is available for registration. Malicious users simply need to register the expired domain, and the pointing will become active as long as the CNAME record is maintained on the target system.
NS Takeovers
An NS (Name Server) record stores the DNS servers that are authorized for a domain. Organizations typically use multiple NS records for load balancing (distributing network traffic across multiple servers). For example, hola.fulanito.com might point to ns.mimamamemima.com and ns.chompiras.com.
If one of these Name Servers is owned by a malicious user, the load is effectively divided. This means users will be pointed to a malicious site some percentage of the time (in a two-server setup, approximately 50%).
MX Takeovers
An MX (Mail Exchange) record is used to forward the mail service for a domain and defines the server priority for mail being sent.
The impact of an MX takeover is that a malicious user could receive emails intended for the original domain. While some might doubt the severity, the security risks remain high due to the potential for data and information disclosure (leaking sensitive company or user correspondence).
Identifying and Tracking Takeovers
To identify these available or expired domains, security professionals and bug bounty hunters need to go beyond standard domain registration services.
Utilizing Passive DNS Tools
While common register services such as GoDaddy can show domain availability, advanced exploration is critical. It is recommended to use tools like RiskIQ, a passive DNS tool that provides more information, including historical changes in DNS records. Passive DNS services collect and maintain a massive historical database of DNS records, which is vital for identifying domains that have recently become available.
Manually accessing the domain using a web browser is essential, as sometimes a domain might appear to navigate to an internal website even if it is technically expired. RiskIQ is helpful here because it can show the historic changes of a domain, allowing for confirmation of its availability status over time.
Internet-Wide Scans
For researchers interested in monitoring CNAME resolution and tracking takeovers globally, there is a dedicated project that archives and publishes scanning data. This project provides a public resource for security teams to follow the takeover problem as it happens across the internet. The project can be accessed at: https://scans.io/ ****
Proactively monitoring and auditing DNS records is the most effective defense against this tricky configuration error.
Detecting Possibly Affected Domains: A Step-by-Step Guide to Identifying Vulnerabilities
Identifying domains susceptible to a sub-domain takeover requires a structured and systematic approach. This process, as outlined by researcher Patrick Hudak, involves defining a scope, extensive enumeration, and rigorous monitoring.
Step 1: Generating the Target List (Scope Definition and Enumeration)
The first crucial step is to define the scope of the investigation. In professional environments, this scope is usually pre-defined within a Bounty program (a formal arrangement where security researchers are rewarded for finding and reporting vulnerabilities).
Once the target is clear, the next task is to enumerate all of the possible sub-domains associated with the main domain.
Using Amass for Sub-Domain Enumeration
Sub-domain enumeration can be effectively performed using Amass. Amass is a powerful, open-source tool created as part of the OWASP project (Open Web Application Security Project) that is designed to gather sub-domain names from various data sources. Beyond just domain names, Amass uses the collected IP addresses to discover related netblocks (a range of IP addresses) and ASNs (Autonomous System Numbers, unique identifiers for network groups).
The tool is launched from the command line in the system. For example, to perform a basic search on a domain, the following snippet is used:
$ amass -d bigshot.beetA more detailed command, which includes gathering information from different sources (-src), resolving IP addresses (-ip), brute-forcing sub-domains (-brute), and setting the minimum number of sources for recursive searches (-min-for-recursive 3), looks like this:
$ amass -src -ip -brute -min-for-recursive 3 -d example.comThe output provides a list of discovered sub-domains and the source of the finding:
[Google] www.bigshot.bet
[VirusTotal] ns.bigshot.beet
...
13139 names discovered - archive: 171, cert: 2671, scrape: 6290, brute: 991, dns: 250, alt: 2766
This detailed enumeration provides the exhaustive list of targets for the next step.
Step 2: Monitoring the Detected Sub-Domains
After receiving the comprehensive list of sub-domains from the enumeration, the next step is to monitor them. The most basic idea is to visually determine the sub-domain’s availability by manually entering each one into a web browser.
For efficiency and scale, security professionals often use specialized tools. The following code snippet, representing the structure of a tool like Subjack (discussed below), illustrates how monitoring can be automated in Go, handling a large list of URLs concurrently using goroutines (functions that run concurrently with other functions) and wait groups for coordination:
package subjack
import (
"log"
"sync"
)
type Options struct {
Domain string
Wordlist string
Threads int
Timeout int
Output string
Ssl bool
All bool
Verbose bool
Config string
Manual bool
}
type Subdomain struct {
Url string
}
/* Start processing subjack from the defined options. */
func Process(o *Options) {
urls := make(chan *Subdomain, o.Threads*10)
list, err := open(o.Wordlist)
if err != nil {
log.Fatalln(err)
}
wg := new(sync.WaitGroup)
for i := 0; i < o.Threads; i++ {
wg.Add(1)
go func() {
for url := range urls {
url.dns(o)
}
wg.Done()
}()
}
for i := 0; i < len(list); i++ {
urls <- &Subdomain{Url: list[i]}
}
close(urls)
wg.Wait()
}
Step 3: Confirmation and Proof of Concept
Once a potential sub-domain takeover is detected, it is necessary to prepare a proof of concept to report the vulnerability. Several tools are available to help confirm a takeover quickly:
| Tool Name | URL | Primary Function |
| Aquatone | https://github.com/michenriksen/aquatone | Tool for visual inspection of websites across a list. It helps define an HTTP-based attack surface for penetration testing and takeover detection. |
| SubOver | https://github.com/Ice3man543/SubOver | A tool totally focused on sub-domain takeovers that checks different sources for a domain’s availability to confirm the takeover. |
| Subjack | https://github.com/haccer/subjack | A tool that scans a list of sub-domains to determine which ones could be hijacked. |
While these tools are designed for speed, they can sometimes provide false positives (incorrectly flagging a domain as vulnerable). Manual confirmation is therefore always recommended when detecting a potential takeover.
Manual Verification Based on Provider
Confirmation often relies on checking for specific error messages returned by a service provider when a resource (like a storage bucket or application) is missing, but the DNS record still points to the service.
The following table provides verification techniques based on common cloud and hosting providers, using http -b GET (a command to make an HTTP request and check the body of the response):
| Provider | Regular Expression (Regex) Pattern to Check DNS Record | Verification Command (Checking for Specific Error Text) |
| Amazon S3 | ^[a-z0-9\.\-]{0,63}\.?s3.amazonaws\.com$ and other region-specific patterns | http -b GET http://{SOURCE DOMAIN NAME} | grep -E -q 'NoSuchBucket|Code: NoSuchBucket' && echo "Subdomain takeover may be possible" || echo "Subdomain takeover is not possible" |
| GitHub Pages | ^[a-z0-9\.\-]{0,70}\.?github\.io$ | http -b GET http://{SOURCE DOMAIN NAME} | grep -F -q "There isn't a GitHub Pages site here." && echo "Subdomain takeover may be possible" || echo "Subdomain takeover is not possible" |
| Heroku | ^[a-z0-9\.\-]{2,70}\.herokudns\.com$ | http -b GET http://{SOURCE DOMAIN NAME} | grep -F -q "//www.herokucdn.com/error-pages/no-such-app.html" && echo "Subdomain takeover may be possible" || echo "Subdomain takeover is not possible" |
| Readme.io | ^[a-z0-9\.\-]{2,70}\.readme\.io$ | http -b GET http://{SOURCE DOMAIN NAME} | grep -F -q "Project doesnt exist... yet!" && echo "Subdomain takeover may be possible" || echo "Subdomain takeover is not possible" |
A successful match of the specific error text (e.g., “NoSuchBucket” for Amazon S3) confirms that the DNS record is pointing correctly, but the resource itself is missing and potentially claimable by an attacker.
Exploiting Sub-Domain Takeovers: Understanding the Impact
The primary goal of a bug bounty hunter is to confirm that a sub-domain takeover is possible and gather evidence of this vulnerability. The consequences of a successful takeover are significant, as control over a sub-domain can lead to several high-impact attacks against the parent domain and its users.
The major impacts derived from a sub-domain takeover include:
- Cookies: If the parent domain, such as
fulanito.com, manages a cookie that is valid for that entire domain, a newly controlled sub-domain (e.g.,sub.fulanito.com) can create cookies that are also valid. This allows an attacker to inject a malicious cookie to exploit vulnerabilities like input validation flaws or session management errors, which the parent domain will subsequently trust and accept. - Cross-Origin Resource Sharing (CORS): Web browsers implement a security restriction called the same-origin policy, which prevents web pages from sharing resources (like data or scripts) that do not originate from the exact same domain. However, if an attacker controls
sub.fulanito.com, they can bypass this policy. They can share resources with the main domain (www.fulanito.com) and all other sub-domains included in*.fulanito.com, potentially leading to a severe Cross-Site Request Forgery (CSRF) attack. - OAuth Whitelisting: OAuth is an authorization framework designed to allow applications to share session information securely. It controls where a session is created and where it is valid. Similar to the same-origin bypass, if an attacker’s domain is valid for
www.fulanito.com, it will likely be considered valid for all sub-domains included in*.fulanito.com, potentially allowing session hijacking or unauthorized access. - Intercepting Emails: If an attacker performs an MX takeover (Mail Exchange record takeover), they can redirect and receive emails intended for the legitimate domain. This can lead to the discovery of sensitive information, confidential credentials, internal communication, and even security alerts related to the company’s services.
- Content Security Policies (CSPs): CSPs are security policies based on trust between applications operating under the same domain. As the previous examples show, a security policy designed to trust sites included in
*.fulanito.comwill mistakenly trust the attacker’s newly claimed sub-domain. - Clickjacking: This technique involves tricking a user into clicking on a malicious link or button without their knowledge. This is typically done by overlaying a transparent layer (using JavaScript or CSS) on the original site. If an attacker controls a sub-domain that is already trusted by the user, they can leverage that trust to socially engineer users into clicking on the malicious element.
- Password Managers: Some password managers operate based on domain trust. If a sub-domain is hijacked, the password manager may automatically fill in forms on the malicious site with the user’s stored credentials, believing it is a legitimate part of the trusted domain.
- Phishing: A classic exploit is Phishing, where an attacker copies the legitimate site to cheat users. For example, they could direct
bank.fulatino.comto an exact copy at the controlled sub-domain, such asfakebank.fulatino.com, stealing login credentials. - Black SEO: An attacker can create fake websites on the controlled sub-domain and leverage the SEO (Search Engine Optimization) reputation of the original parent domain to increase the ranking and reputation of the fake site in search engine results.
Mitigation: Continuous DNS Record Review
The root cause of a sub-domain takeover is a simple configuration oversight—a domain pointing rule that was set and then forgotten about.
The only effective way to solve this problem is to constantly review all of the DNS records within an organization’s infrastructure. It is essential to ensure that every CNAME, NS, and MX record points to a service that is currently active and owned by the organization.
To effectively monitor for changes in domain infrastructure, the use of passive DNS tools, such as RiskIQ, is highly recommended. These tools provide continuous surveillance and alert the team to any changes in the organization’s DNS landscape.
Sub-Domain Takeovers in the Wild: A Case Study
Reviewing real-world reports helps illustrate the practical application and impact of this vulnerability.
Ubiquiti Sub-Domain Takeover
On February 6, 2017, a bug bounty hunter known as madrobot published a report detailing a sub-domain takeover vulnerability affecting Ubiquiti, a major networking technology company.
madrobot discovered that one of Ubiquiti’s sub-domains was incorrectly pointing to a Google IP address, as demonstrated by the following DNS information:
216.58.203.243 moderator.ubnt.com216.58.203.243 ghs.google.com216.58.203.243 ghs.l.google.com
The DNS configuration showed that the sub-domain moderator.ubnt.com was pointed via a CNAME record to a Google-hosted service that had not been properly claimed by Ubiquiti.
When a user entered the sub-domain moderator.ubnt.com into their web browser, the browser was redirected to a standard Google page indicating the site was not set up.
This demonstrated that any user could claim the sub-domain for themselves by registering a Google service account and pointing it to that specific domain. An attacker could have used this control to impersonate Ubiquiti and cause significant brand damage.
For further details on this vulnerability, the complete report is available to read: https://hackerone.com/reports/181665.
Real-World Case Studies of Sub-Domain Takeovers
The following examples illustrate how security researchers have successfully identified and reported sub-domain takeover vulnerabilities across major platforms, demonstrating that even large, well-resourced organizations can fall victim to these configuration errors.
Case Study 1: Scan.me Pointing to Zendesk
On February 16, 2016, security researcher HarryMG found that the sub-domain support.scan.me was pointing via a CNAME record to the external service scan.zendesk.com.
The crucial factor was that the website located at scan.zendesk.com was not available for use by the original domain owner. This meant that the researcher could claim the unavailable Zendesk page.
When a user attempted to visit the legitimate support portal at support.scan.me, they were seamlessly redirected to the content the researcher had placed on scan.zendesk.com.
For more information on this reported bug, visit: https://hackerone.com/reports/114134.
Case Study 2: Starbucks’ Sub-Domain Takeover
Researcher Patrik Hudak, known for his work in defining the sub-domain takeover detection process, reported a vulnerability on Starbucks.com on June 25, 2018.
He discovered that the sub-domain svcgatewayus.starbucks.com was incorrectly pointing to the Microsoft Azure platform. Since Azure is a major cloud provider, it is relatively easy for an attacker to create a new storage bucket or instance associated with that sub-domain name.
By claiming the resource on Azure, an attacker could have put Starbucks at significant risk by hosting malicious or phishing content under a trusted Starbucks sub-domain.
To read more about this report, visit: https://hackerone.com/reports/325336.
Case Study 3: Vine’s Sub-Domain Takeover
On November 3, 2014, bug bounty hunter Frans Rosén published a report regarding a sub-domain takeover at media.vine.co, which was pointing to AWS (Amazon Web Services).
As proof of concept, Frans Rosén included a screenshot demonstrating the potential impact: a popup created with JavaScript was displayed to users, which is a common component of phishing attacks.
The page could easily have been a phishing attack designed to steal credentials or sensitive information from users who trusted the main vine.co domain.
More details on this bug can be found here: https://hackerone.com/reports/32825.
Case Study 4: Uber’s Sub-Domain Takeover
On December 12, 2016, Fran Rosén (the same researcher who reported the Vine bug) published a sub-domain takeover affecting Uber.
The sub-domain rider.uber.com failed for approximately three hours because it was pointing to a non-existent Cloudfront instance. Cloudfront is a content delivery network (CDN) service provided by AWS.
Fran Rosén successfully claimed the sub-domain in Cloudfront by creating a new instance with the matching name. The subsequent proof of concept demonstrated full control. The impact of this vulnerability was considered critical, despite being a temporary error from Uber’s side, because rider.uber.com was one of the most-visited URLs in the Uber application, making it a prime target for phishing.
To read the full report on this bug, visit: https://hackerone.com/reports/175070.
Summary of Sub-Domain Takeovers
A sub-domain takeover is fundamentally a configuration management error where control of a sub-domain is lost when its CNAME, NS, or MX record continues to point to an external service or domain that has expired or become unclaimed.
The impact of this vulnerability is significant for the domain’s owner and its users, often leading to severe security risks like phishing, session hijacking, and information disclosure. While maintaining an updated DNS database is conceptually simple, it often becomes complicated for bigger organizations with vast infrastructures.
In conclusion, key takeaways regarding sub-domain takeovers include:
Discovering such vulnerabilities is often expensive—both financially and in relation to the time and resources required for continuous auditing and bug bounty programs.
They originate from a forgotten or stale DNS service registry that another user can easily register and claim.
Mitigation is easy: it primarily involves the simple act of deleting the obsolete registry (the CNAME, NS, or MX record) from the organization’s DNS configuration.
A range of tools is available for monitoring DNS services; however, automated monitoring can still complicate things by providing false positives, necessitating manual review.
