Exploring the risks of subdomain takeovers

Subdomain takeover attacks pose serious risk to organizations around the world. While this type of attack is being discussed more and more, many organizations do not understand the full impact and the risk is often minimized. In this post, we’ll shed more light on the real consequences of subdomain takeovers and share recommendations on how to stay protected from them.

What is a subdomain takeover?

Let’s take a moment to first understand what a subdomain takeover is at a high level (we’ll dive in deeper later in this post).

A subdomain takeover is a situation in which a malicious actor is able to control some or all of the content on a given subdomain. There are two ways to carry out this attack, which we’ve classified as Type 1 and Type 2 subdomain takeovers.

A Type 1 subdomain takeover is a full DNS takeover. In this situation, the attacker compromises a vulnerable subdomain and then uses it to carry out various types of attacks on the owner of that subdomain. These attacks can be anything from setting up a phishing website to serving malicious content to stealing cookies and customer information.

In a Type 2 subdomain takeover, the attacker compromises the target through a third-party service that the subdomain is pointing to. What typically happens is the target’s account with the third-party service gets deleted or delisted in some way, but the DNS record still remains. The attacker can then go in and make use of the existing DNS record by creating a new account using the old information, and they now control it.

For instance, an attacker may compromise Company A by taking over a chat widget via vulnerable Javascript created by Company B, a third-party outside of the host organization. Once compromised, the attacker can replace the compromised Javascript with malicious content.

In both cases, the site owner may not realize they’ve fallen victim to a takeover until it’s too late.

Who is vulnerable to subdomain takeover?

Now that you have an understanding of what a subdomain takeover is, let’s take a look at who’s susceptible to an attack.

Unfortunately, there are a lot more organizations at risk of this type of attack than many realize. According to a recent study of the top 50,000 sites on the Tranco list, 1,520 subdomains across 887 sites were found vulnerable to takeover. Of those sites, 83% were vulnerable because of discontinued third-party services. The remaining 17% were vulnerable due to expired domains.

Additionally, security researchers at RedHunt Labs have discovered more than 400,000 subdomains with misconfigured CNAME records, leaving many at risk of malicious takeover.

There have been several examples of high-profile organizations that were found to be susceptible to subdomain takeover in recent years. In December 2020, an Israeli research group made EA aware of several domain takeover vulnerabilities that would possibly allow attackers to send and read emails from the domains and operate a spoofed site.

In 2017, we learned how a researcher was able to steal valid session cookies on uber.com through SSO due to cookie sharing. And in 2019, Starbucks was vulnerable to session hijacking and cross-site scripting because of a forgotten subdomain that was pointing to a non-existent Azure cloud resource.

How does an attacker carry out a subdomain takeover attack?

The most common type of subdomain takeover begins with a malicious actor identifying a CNAME record that is pointing to an orphaned resource, otherwise known as a dangling DNS record. Once the dangling DNS record has been identified, there are three primary attack vectors that can lead to further exploitation.

These attack vectors include discontinued services, such as Shopify, GitHub, and Tumblr, deprovisioned infrastructure instances, like Azure websites, Azure Traffic Manager, and AWS S3 buckets, and expired domains. Depending on the attack vector that is exploited, the malicious actor will control some or all of the content on the subdomain, allowing them to launch attacks on the primary or a related domain.

Let’s drill down into how a malicious actor uses these attack vectors. We’ll start with a common Type 1 subdomain takeover scenario.

For this example, we’ll feature DemoBank, a fictional company whose primary domain is demobank.net. On demobank.net, there is a resource loading Javascript from subdomain cdn.demobank.net. However, the CNAME for that subdomain is pointing to an AWS S3 bucket that is unclaimed. There could be a number of reasons for why this is the case, one being that the development team decided to make some changes and forgot to notify the security team that they no longer use AWS to host the Javascript and the S3 Bucket was deleted. Whatever the cause, this means that DemoBank has a dangling DNS record.

A malicious actor can discover the dangling DNS record using easily accessible scanning tools. Then, they can claim the unclaimed AWS S3 bucket for themselves in their own AWS account using the information on the 404 page that the broken subdomain now displays. This gives the malicious actor control over the subdomain and enables them to replace the original JavaScript with malware which will then be executed on demobank.net.

A Type 2 subdomain takeover is achieved similarly, however, the main difference is that the attack vector is owned by a third party. For instance, in order to engage with visitors on their site, DemoBank might utilize a live chat widget from DemoWidget, another fictional company. So, demobank.net has a resource loading Javascript from subdomain chat.demowidget.net. The problem would arise if the CNAME pointing to chat.demowidget.net was unclaimed and a malicious actor claimed it for themself. This would allow them to alter the Javascript on chat.demowidget.net and potentially replace it with malware, which would then be loaded on demobank.net

Check out our recent webinar to see a demonstration of a Type 2 subdomain takeover played out step by step.

How to prevent a subdomain takeover

The best way to prevent a subdomain takeover is by having a complete understanding of what’s on your attack surface. Because the attack surface is constantly changing and evolving, this means you need to have tools in place that are continuously discovering and monitoring your domains, subdomains, and their connections for broken resources so that you can find and fix any issues before an attacker can compromise them.

You also need to make sure you’re monitoring your cookies, secure headers, and JavaScript and getting alerts about any changes as that could potentially indicate that they have been tampered with by a malicious actor.

Another thing we recommend is to conduct an audit of the JavaScript and nested resources you’re utilizing and eliminate any that no longer have business importance.

Halo Security makes it easy to monitor for issues that could lead to a subdomain takeover. With the Website Monitoring service, you get a complete picture of all the JavaScript that is loaded on your web applications. You can easily filter down to see Javascript hosted by external domains so that you can keep track of scripts that are out of scope. You can then monitor those scripts and get alerts any time the script changes, which could potentially indicate a malicious action has occurred.

In conclusion

Because subdomain takeovers typically require remarkably few technical skills from an attacker and can be difficult to detect, they present a significant risk to all businesses. Don’t wait until it’s too late to protect your organization. Book a meeting with Halo Security's experts to get a free evaluation of your risk to subdomain takeover.

Editor's note (August 2022): This article was originally posted on the TrustedSite blog in April 2022. It has been updated for the Halo Security blog.