Learn About Subdomain Takeover

The Art of Hijacking Forgotten Domains

Imagine this: You stumble upon a dusty old map leading to a forgotten corner of a vast kingdom. But instead of buried treasure, you find an abandoned castle ripe for the taking. That's the essence of a subdomain takeover - discovering neglected subdomains and reclaiming them for your own (ethical) purposes. And trust me, the rewards can be as lucrative as any hacker's bounty.

What is a Subdomain Takeover?

Think of subdomains as rooms in a castle. The main domain (e.g., example.com) is the grand hall, while subdomains (e.g., blog.example.com, shop.example.com) are the various chambers. Sometimes, these chambers are left unattended, their doors unlocked. A subdomain takeover occurs when you exploit this neglect, gaining control over a subdomain that's no longer in use by its original owner.

How Does It Work?

1. The Forgotten Link: A company might have used a third-party service (e.g., Heroku, GitHub Pages, Amazon S3) to host a subdomain. If they stop using the service but forget to remove the DNS (Domain Name System) records, the subdomain remains pointing to the service.
2. The Opportunity: You discover this orphaned subdomain. Since the company isn't using the service anymore, you can create an account on that service and claim the subdomain for yourself.
3. The Takeover: By setting up your own content on the service, you effectively take control of the subdomain, even though it still appears to be part of the original domain.

Why Are Subdomain Takeovers Valuable?

● Reputation Damage: A malicious actor could use the subdomain for phishing, malware distribution, or other harmful activities, tarnishing the company's reputation.
● SEO Impact: A hijacked subdomain could negatively impact the company's search engine optimization (SEO) efforts.
● Cookie Theft: If the subdomain shares cookies with the main domain, an attacker could steal those cookies and potentially gain unauthorized access to user accounts.

Real-World Examples

● Tesla: A security researcher discovered that a Tesla subdomain (tsla.co) was vulnerable to takeover. The researcher could have used this to create a fake Tesla website to phish for user credentials.

● Shopify: Multiple Shopify subdomains were found to be vulnerable to takeover due to misconfigurations in their DNS records. This could have been exploited to host malicious content or redirect users to phishing sites.
● Starbucks: A subdomain takeover vulnerability in a Starbucks subdomain allowed a researcher to create a fake Starbucks page that could be used for phishing attacks.

How to Find Subdomain Takeovers

1. Subdomain Enumeration: Use tools like Subfinder, Amass, or Assetfinder to discover subdomains of your target.
2. Check for Dangling DNS Records: Look for subdomains that have CNAME records pointing to services like Heroku, GitHub Pages, or Amazon S3.
3. Verify Takeover Potential: Try creating an account on the service the subdomain is pointing to and see if you can claim the subdomain for yourself.

Subdomain takeovers are a valuable bug class that can lead to significant bounties and recognition in the bug bounty community.

Let's dive into real-world examples of subdomain takeovers and a step-by-step guide on how you, as a security researcher, can uncover these valuable bugs:

Real-World Subdomain Takeover Situations (that I experienced)

1. The Forgotten Blog:
○ A company used to host its blog on blog.example.com using a third-party service like WordPress.com or Medium.
○ They migrated to a new platform but forgot to remove the CNAME record pointing to the old service.
○ An attacker notices this and registers a new account on the old service, claiming the blog.example.com subdomain.
○ Now, they can host malicious content, phishing pages, or even redirect traffic to a competitor's website.

2. The Abandoned Marketing Campaign:
○ A company ran a promotional campaign on promo.example.com using a cloud hosting provider like AWS or Azure.
○ After the campaign ended, they neglected to delete the associated cloud resources.
○ A security researcher discovers that the subdomain is still pointing to the unused cloud resources.
○ By creating a new account on the cloud provider and claiming the resources, the researcher can take control of the subdomain.

3. The Expired Trial Account:
○ A company used a service like Heroku to host a development or testing environment on dev.example.com.
○ The trial period for the service ended, and the company forgot to cancel the account.
○ An attacker notices this and signs up for a new trial on Heroku, claiming the dev.example.com subdomain.
○ This could expose internal development or testing data to the public.

Step-by-Step Guide to Finding Subdomain Takeovers

1. Subdomain Enumeration:
○ Use tools like Subfinder, Amass, or Assetfinder to gather a comprehensive list of subdomains associated with your target domain.
○ You can also use search engines with advanced queries like site:*.example.com to discover subdomains.

2. Identify Dangling DNS Records:
○ Analyze the DNS records of each subdomain, looking for CNAME records pointing to third-party services.
○ Common services that are vulnerable to takeovers include:
● Cloud providers: AWS (S3 buckets, CloudFront distributions), Azure, Google Cloud
● Web hosting: Heroku, GitHub Pages, Netlify, Tilda
● Other: Shopify, Desk, Zendesk, Help Scout, Tumblr, Bitbucket, etc.

3. Verify Takeover Potential:
○ Visit the subdomain in your browser. If you see a default error page or message indicating that the service is no longer available, it's a strong indication of a potential takeover.
○ Try creating an account on the service the subdomain is pointing to and see if you can claim the subdomain.
○ If successful, you've successfully taken over the subdomain!

4. Document and Report:
○ Take screenshots of the error message and any other relevant information.
○ Write a detailed report describing the vulnerability, steps to reproduce, and potential impact.
○ Submit the report to the company's bug bounty program (if they have one) or responsible disclosure process.

Tips and Tricks:

● Automation: Use automation tools like "Subjack" or "Nuclei" to scan for subdomain takeovers at scale.
● Custom Wordlists: Create custom wordlists based on the target company's products, services, or past marketing campaigns to find more potential takeovers.
● Stay Informed: Keep an eye on new vulnerabilities and exploit techniques related to subdomain takeovers.

Remember, finding subdomain takeovers requires persistence, creativity, and a good understanding of DNS and web technologies. But with the right approach, you can uncover these valuable bugs and earn substantial rewards. Happy hunting!

Sublist3r: Your Reconnaissance Sidekick

Sublist3r is a popular tool for enumerating subdomains of a target domain. It works by querying various public sources (search engines, DNS dumpsters, etc.) to gather a list of known subdomains. While it doesn't directly identify subdomain takeovers, it gives you a starting point for further investigation.

Step-by-Step Guide

1. Installation:
○ If you don't have Sublist3r installed, you can easily install it using pip:

      `pip install sublist3r`

2. Basic Usage:

     ○ The simplest way to use Sublist3r is to provide the target domain:

     `sublist3r -d example.com`

     This will output a list of subdomains found.

3. Additional Options:

     ○ To use specific search engines, you can specify them with the -e flag:

    `sublist3r -d example.com -e google,bing`

    ○ To increase the number of threads used for faster enumeration, use the -t flag:

    `sublist3r -d example.com -t 20`

    ○ You can also output the results to a file for later analysis:

    `sublist3r -d example.com -o subdomains.txt`

Identifying Potential Takeover Targets

Analyze the Subdomain List: Look for subdomains that seem inactive or abandoned. These might include:
○ Subdomains that return errors (e.g., 404 Not Found)
○ Subdomains that redirect to the main domain or another site
○ Subdomains with outdated or placeholder content

Check DNS Records: Use a tool like dig or online DNS lookup services to check the CNAME records of suspicious subdomains. Look for records that point to services like:
○ Heroku (*.herokuapp.com)
○ GitHub Pages (*.github.io)
○ Amazon S3 (*.s3.amazonaws.com)
○ Other cloud providers

Verify Takeover Potential:
    ○ Manual Verification: Visit the subdomain in your browser. If it shows a generic error message from the service provider (like "There's nothing here yet" on GitHub Pages), it's a strong indicator of a potential takeover.

○ Automated Tools: Use tools like Nuclei or Subjack to automate the process of checking for potential subdomain takeovers.

Remember:

● Don't Take Over Without Permission: Always obtain permission from the domain owner before attempting a takeover.

● Report Responsibly: If you discover a valid subdomain takeover vulnerability, report it through the appropriate channels (e.g., the company's bug bounty program).

Happy hunting! 🔍

Subdomain Takeover on Bug Hunting

What's the methology?

Let's say your business is called Netflix and the static files for your app are stored in an S3 bucket called static-files. You register a CNAME (=a DNS alias) stating that static.netflix.com is an alias for static.s3.amazonaws.com because you don't want the domain name for your bucket to be similar to static-files.s3.amazonaws.com.

It's wonderful that you can use static.netflix.com to reference files from your bucket.

After a few years, you have some nice new apps and have forgotten about all the old stuff you used to develop. Since you no longer require the static-files S3 bucket, you have already deleted it, so you shouldn't have to pay for it.

However, one item remains that you did not erase: the CNAME entry establishing a connection between static-files.s3.amazonaws.com and static.netflix.com. Now, an attacker appears, uses the now-free name static-files to establish a new S3 bucket. Can you see my direction?

As long as static.netflix.com remains an alias for static-files.s3.amazonaws.com, the attacker effectively controls the content of static.netflix.com.

It is named Subdomain Takeover for this reason!

How Can I Take Advantage of It?

Let's now discuss some of the unscrupulous things an attacker can do after gaining control of a subdomain.

static.netflix.com has now been taken over by the attacker. But what happens now?

Phishing

Phishing is probably the first thing that springs to mind as the most evident. Given that you currently have control over a subdomain of nextaigen.com, why not turn it into a phishing page and attempt to social engineer NextAIGen clients or staff members?

Taking Advantage of Misconfigured CORS

Let's say you come across a different Netflix app that is housed at ai.netflix.com. It is set up to accept CORS requests from any *.netflix.com subdomain (I swear, I see this all the time!). This is not vulnerable on its own, and it's unlikely that it even qualifies as a "misconfiguration."

You can host content on static.nextaigen.com that makes cross-origin queries to ai.netflix.com and saves the HTTP responses, though, as you now have ownership over a subdomain of netflix.com. The next step is to visit static.netflix.com via social engineering a user of ai.netflix.com. Subsequently, queries can be sent to ai.netflix.com using the user's name.

This may or may not be severe. However, if any endpoint on ai.netflix.com produces sensitive data, this would typically be high or critical. I have also discovered that in the past, this scenario has resulted in account takeover if there is an endpoint that returns, for example, a session token in the response body.

XSS bypassing CSP

One more instance might be getting XSS by avoiding a CSP. Let's say you discover XSS but are unable to take advantage of it due to the CSP; nonetheless, the CSP accepts scripts from *.netflix.com subdomains.

You do realize what comes next? At that point, simply host the XSS payload on static.netflix.com.

How Can I Locate Them?

In this last section, we discuss how Subdomain Takeovers can be discovered by a pentester or bug bounty hunter. There are five primary steps in this.

First, look for subdomains.

You must locate something first before looking for subdomains to take control of. Subdirectories! I won't go into all of the methods for finding subdomains in this article.

Let's imagine you're using test.com as a pentesting platform and you've already located the following subdomains:

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

Step 2: Look up CNAMEs

It is highly improbable that we will be able to access mail.test.com, for example, unless we manage to compromise the website or the DNS server. Consequently, we do e.g.: to see if any CNAMEs (=aliases) exist for any of the specified subdomains.

$ dig +short CNAME mail.test.com

Assume that mail.test.com and cool-app.test.com did not have any CNAMEs. Nevertheless, we discovered that static.test.com has a CNAME that points to an S3 bucket (static-test.s3.amazonaws.com).

Step 3: Look for Expired Domains

Subsequently, we must determine whether of the discovered CNAMEs have been abandoned, or are no longer in use. In essence, we are looking for signs that the resource is no longer in use.

Among the best signs of this are:

○ 404 HTTP response status
○ DNS problems indicating non-existence of the domain

Let's say we discovered the S3 bucket we identified is no longer there after checking it out.

Verify if a takeover is feasible in step four.

The hardest thing is this. Only if we are able to register a new S3 bucket and manage its domain name will we be able to take control of static.test.com. We won't be able to register static-test.s3.amazonaws.com if we are unable to. Given that there are a seemingly endless number of domain names available, how can we determine whether we can register a new resource under the same name?

Although the issue hasn't been resolved yet, this fantastic GitHub repository, https://github.com/EdOverflow/can-i-take-over-xyz, is a great place to start.

It provides a wealth of details on well-known domains (such AWS, Azure, and so forth), including how to fingerprint them and whether or not they are susceptible to takeover.

Takeover of the Subdomain in Step Five

The last step is to take control of the subdomain after we're sure we can take it over. This entails, for instance, naming a newly created S3 bucket after a previously removed bucket.

For items like S3 buckets or Azure Websites, this step can be quite simple; but, for items like Azure Cloud Apps, which need some setup, it might be more challenging.

Happy Hacking

Author: Ayush khatkar is a cybersecurity researcher, technical writer and an enthusiastic pen-tester at Asecurity. Contact here.

#bugbounty #infosec #cybersecurity