My bug bounty methodology and how I approach a target

How I choose a bug bounty program

, let’s assume you have received some private invitations. How would you choose between them? What program would you pick to start hunting for bugs? On HackerOne where I primarily hunt for bugs, I choose a program based on key metrics shown to me during the invitation process.

Program launch date

First, I see where the bug bounty program was launched to have an idea of how old the program is. This tells me whether I should spend some time on low-hanging fruits or dig deeper during my testing, because, unless there are new assets, most of the easy bugs would have already been found in an old program.

Program responsiveness

The second thing I look for is the response posture. In short, I see what is the average time to resolve a security issue. If the program takes a lot of time to resolve security issues, it means that there is a higher chance of getting duplicates. Usually, all other response metrics, such as time to first response, time to triage, and time to bounty are lower than the resolution time, so the shorter it is, the better.
You can also see the percentage of the reports which have met those response metrics. If it is above 90%, I’d probably accept the invitation if the rest of the metrics is ok.

The scope of the bug bounty program

I usually prefer bigger scopes. For example, I would prefer wildcard domains over a single web application. It reduces competition because there is enough room to play with different assets, and it makes the target less boring. However, I might accept a program with a small scope program if they have a great response time or good rewards.

Bug bounty rewards

This is another criteria I look for. If I am investing my time in looking for security bugs, I would like to have a bigger return on my investment. So I would prefer higher-paying bug bounty programs. I usually avoid programs with no rewards not only because of money but also because the reputation you get is significantly lower.

The business of the company

Alright, now that I have chosen the bug bounty program, how do I approach it? Well, I start with a light subdomain enumeration to gauge the public presence of the bug bounty program and quickly find something to work on. I used to do thorough enumeration, but I realized that it takes considerable time. Because this is my first interaction with the target, I feel it’s a bit early to perform a heavy enumeration.

What does my bug bounty methodology look like for subdomain enumeration?

I start my subdomain enumeration with Tomnomnom’s asset finder tool. The command is straightforward, you just provide your in-scope wildcard domain name.

assetfinder --subs-only domain.name

The thing I love about this tool is that it’s blazingly fast! It provides me with a quick idea of the subdomains naming convention and gives me initial assets to work on. I always avoid brute force at this stage. On the one hand, it takes more time which I prefer to invest in the next steps. On the other hand, I like to increase my success rate by bruteforcing with a custom wordlist tailored just for this domain.

Bug bounty methodology to enumerate web applications

Now that I have a list of assets, I filter only web applications using Tomnomnom’s httprobe. For now, all I’m interested in are ports 80 and 443. The command is again easy to run:

cat domains | httprobe

As a side note, if the program is new, I would probably use Shodan or perform a port scan using masscan to see if any web applications are running on non-standard open ports. These are ports greater than 1024.
Lastly, I run aquatone to screenshot the list of live web applications. There are two reasons I do that. On the one hand, I will be able to quickly spot any visual deviation from the common user interface. On the other hand, I will get a bird’ eye view of the different web application categories and technologies. This is possible because aquatone groups similar user interfaces together and displays the web applications’ technologies in the HTML results.

My bug bounty methodology when choosing a web application

Hopefully, I now have some web applications to choose from. I tend to choose the one which deviates from the herd. For example, if all web applications implement a centralized Single Sign-on authentication mechanism, I would look for any directly accessible asset. If I spot a user interface of common software such as monitoring tools, or known Content Management Systems, I would target them first. Another example is when the application discloses the name and the version of the software being used. In this case, I look online for any available exploits. If I am lucky, I might get easy issues to report.
For the other custom-made web applications, I will generally choose the one whose user interface deviates from the common company’s theme. If I don’t find one, I might repeat my previous steps with deeper enumeration. For instance, I would take the subdomains I found earlier and combine them with the name of the company to generate a custom wordlist. Then, I’d use tools like OWASP amass and brute force the subdomains using the wordlist I constructed.