Subdomain Takeover: What is It? How to Exploit? How to Find Them?

In this article, we shed light on Subdomain Takeovers and discuss 3 things:

Say your company is called NextAIGen and you’re using an S3 bucket for your app’s static files, called static-stuff. Since you don’t want the domain name for your bucket to be like static-stuff.s3.amazonaws.com, you register a CNAME (=a DNS alias) that says that static.nextaigen.com is an alias for static-stuff.s3.amazonaws.com.

Cool, now you can reference files from your bucket using static.nextaigen.com.

A few years pass and you have some new fancy apps and have forgotten about all that old stuff that you developed in the past. You already deleted the static-stuff S3 bucket, because why pay money for something you don’t need anymore — right?

But there’s one thing you didn’t delete: The CNAME entry that connects static.nextaigen.com with static-stuff.s3.amazonaws.com. Now, an attacker comes along, creates a new S3 bucket, and uses the now free name static-stuff. Do you see where I’m heading?

Since static.nextaigen.com is still an alias for static-stuff.s3.amazonaws.com, the attacker has now de facto taken over static.nextaigen.com and can control its content.

This is why it’s called Subdomain Takeover!

Now, let’s talk about some of the naughty things an attacker can do once they have taken over a subdomain.

So the attacker has just taken over static.nextaigen.com. But what now?

Phishing

The most obvious thing that comes to mind is probably phishing. Considering you now control a subdomain of nextaigen.com, why not change it to a phishing page and try to social engineer e.g. customers or employees of NextAIGen?

Exploiting CORS Misconfigurations

Say you find another app from NextAIGen which is hosted under ai-verse.nextaigen.com. It is configured to allow CORS requests from all subdomains of *.nextaigen.com (I honestly see this all the time!). This by itself is not exploitable and probably wouldn’t even necessarily classify as a “misconfiguration” (although I always report it in my Pentests — as Informational).

However, since you now control a subdomain of nextaigen.com, you can host content on static.nextaigen.com that sends cross-origin requests to ai-verse.nextaigen.com and stores the HTTP responses. You then have to social engineer a user of ai-verse.nextaigen.com to visit static.nextaigen.com. Now, you can then send requests in the user’s name to ai-verse.nextaigen.com.

The severity of this may differ. But this would often be high or critical if there is any endpoint in ai-verse.nextaigen.com that returns sensitive data, and I also found this scenario leading to account takeover in the past if there is an endpoint that returns e.g. a session token in the response body.

Bypassing CSP for XSS

Another example could potentially be bypassing a CSP to get XSS. Say you find XSS but can’t exploit it because of the CSP, but the CSP trusts all scripts from subdomains of *.nextaigen.com.

You can see what’s next right? Just host the XSS payload on static.nextaigen.com then.

In this final part, we talk about how a pentester or bug bounty hunter can find Subdomain Takeovers. This involves 5 main steps.

Step 1: Find Subdomains

Before you can find subdomains to take over, you need to find something first… Subdomains! There are plenty of ways to find subdomains and I won’t cover them in this article.

So say you’re performing like a Pentest on test.com, and you already identified the following subdomains:

mail.test.com
static.test.com
cool-app.test.com

Step 2: Find CNAMEs

It’s very unlikely we can get our hands on e.g. mail.test.com (unless we hack the page itself or like the DNS server or something). Thus, we check if there are some CNAMEs (=aliases) for all identified subdomains, and run e.g.:

dig +short CNAME mail.test.com

Say that there were no CNAMEs for mail.test.comand cool-app.test.com. However, we found a CNAME for static.test.com, and it’s an S3 bucket (static-test.s3.amazonaws.com).

Step 3: Find Abandoned Domains

Next, we need to check if any of the identified CNAMEs have been abandoned, i.e. no longer used. Basically, we want to find indications that the resource is no longer used.

Good indicators for this are for example:

- 404 HTTP response status
- DNS errors that indicate that the domain is non-existent

Say we checked out the identified S3 bucket and found that it doesn’t exist anymore.

Step 4: Check if Takeover is Possible

This is the hardest part… We can only take over static.test.com if we can register a new S3 bucket and can control its domain name. If we can’t, then we won’t be able to register static-test.s3.amazonaws.com. But how we do know if we can register a new resource with the same name, considering there are like a gazillion domains out there?

This isn’t a solved problem yet, but a good starting point is this awesome GitHub repo: https://github.com/EdOverflow/can-i-take-over-xyz.

It contains lots of information on popular domains (e.g. AWS, Azure, etc.), specifies how to fingerprint them, and if they are vulnerable to takeover.

Step 5: Taking Over the Subdomain

Once we confirm we can take it over, the final step is taking over the subdomain. This means for example creating a new S3 bucket with the same name as a previously deleted bucket.

This step can be very easy with things like S3 buckets or Azure Websites but may be more difficult for things like Azure Cloud Apps which require some setup.

This article talked about Subdomain Takeover in a way that I hope was easy to digest. I have created a tool to automate a lot of this work, which I called SubSnipe, and you can find it here: https://github.com/dub-flow/subsnipe

In the meantime, if you have any questions on the matter or wanna share your own experiences, please feel free to reach out to me on LinkedIn: https://www.linkedin.com/in/florian-ethical-hacker/.

Also, if you like my content, feel free to follow me for more 😃.