Subdomain Takeover: Finding Candidates

After my last posts, many of you have asked me how I found the domains for Starbucks. Although I am not willing to give you exact resources, in this post, I want to describe at least the approach I overtake.

0xpatrik hackitivy

When I received the bounties for subdomain takeover, I was happy and excited, but also felt sorry in some way to other bounty hunters. Since I got automation in place, it usually takes just a few minutes to create PoC and write a report. I received $2,000 for that. Other bounty hunters spend countless hours trying to create a working exploit and receive the only fraction of that bounty. I still don't consider myself as a bug bounty hunter, but rather low-hanging fruit hunter.

The very first thing you need to understand is, that subdomain takeover monitoring is a continuous process. People are often surprised by it. Domains are often working perfectly, but once the administrator removes the resource where CNAME is pointing, the vulnerability is introduced. In my second report, the domain was fully working for several months. It became "vulnerable" at some point in time. 20 minutes after, I already got working PoC. If you want to find subdomain takeovers consistently, you need to create automation for yourself. No exceptions.

Process

As I said above, my code for automation won't be released to the public (yet). However, the process I am going to describe should be more than enough to replicate my automation and come close enough to its results. The process is divided into four main parts:

  1. Scope parsing
  2. Subdomain enumeration
  3. Subdomain takeover verification
  4. Notifications

Subdomain Takeover Automation

Scope Parsing

You need to have a list of scopes for which you want to monitor subdomain takeovers. Bug bounty program specification/rules are your friend here. If we take Twitter for instance, they have clearly defined scope:

Twitter HackerOne

On the other case, for Intel they excluded all report for intel.com:

Intel HackerOne

There is also a grey zone. Some programs like Starbucks, don't have explicitly listed domain wildcards, but rather they specified it differently:

Starbucks HackerOne

It is up to you whether you want to create and automation for that. Keep also in mind that scopes also tend to change as acquisitions often happen and new programs are introduced. You can take inspiration from EdOverflow's script. The output of this step should be the list of domains on which you want to perform subdomain enumeration, like this:

twitter.com
vine.co
twimg.com
pscp.tv
periscope.tv
starbucks.com
starbucks.ca
...

Bug bounty scope parsing

Subdomain Enumeration

I have written several posts about subdomain enumeration. The only thing you need to do is to enumerate every domain from the previous step. Which tools and resources to use is the real secret sauce, however, and highly recommend starting with amass.

amass -nodns -norecursive -noalts -d twitter.com

As you might know, many tools also provide domains which are no longer existing (e.g., NXDOMAIN, SERVFAIL, ...). Personally, I recommend NOT to filter domains and also keep the ones responding with another DNS status then NOERROR. I will explain why in the next section. The output of these sections should be a list of all subdomains of all domains from the previous step.

Subdomain Enumeration

Subdomain Takeover Verification

Once having the full domain list, you need to monitor for subdomain takeover continuously. The easiest way is to setup signatures or rules for true positives. As I explained in this post, every cloud provider has its error message. For CloudFront, it looks like this:

CloudFront Error Message

There is no need to inspect that visually. You can automate that by creating HTTP requests (with correct Host header!) to domains and then finding the unique string in HTTP response. Find some inspiration here. You should also take into consideration that some cloud providers require just DNS status verification (such as Azure). There is no need to create HTTP requests there.

The reason why I said that you should NOT filter domains in the previous step is, that subdomain takeover verification does not end with CNAME subdomain takeover. As I briefly mentioned in subdomain takeover basics post, there are also NS and MX subdomain takeovers. Long story short, when domain responds with NXDOMAIN, it might be a case of NS subdomain takeover. Many people forget about this possibility since there are not many cases of NS or MX subdomain takeover. That being said, there is at least one documented. If you want to take subdomain takeover seriously, I highly recommend reading that post at least twice.

The diagram at the beginning of this post showed two independent loops. I recommend you similarly design your automation. The loop of subdomain enumeration is usually much slower than a loop of takeover verification. You want continuously run each loop and feed results from step two to step three without any intervention.

Subdomain takeover verification

Notifications

The last step, but still as important as others are notification. Once the subdomain takeover is discovered, you have to act on it as fast as possible. The field is becoming more competitive, and there might be a chance that the same domain was discovered by somebody else. The rule the subdomain takeover says: Who creates a PoC first, wins. You want to ideally set up push notifications, even to your phone. There is also a possibility for creating automation that does PoC itself.

Check out my other posts about subdomain takeovers:

Until next time!

Patrik

Buy Me A Coffee