Simple Bug Bounty Methodology
Defining your bug bounty methodology is important to ensure you have a defined way to tackle each bug bounty program. In this blog, we detail our simple testing methodology to get you from start to money.
Understand The Scope
The starting point is to review the scope of the bug bounty program. If you see only one URL or IP Address is in scope, we suggest you don't dive into this program, because it's too small. Whereas, if you see a wildcard domain like *.company.com, you have the ability to find many targets verses your peers and you should try this program. It's even better if you see an ASN or IP Address range, because there will be loads of potential targets!
The early bird catches the worm.
We believe the biggest thing to note is that you need to be fast. There are many bug bounty hunters out there, so as soon as a new program shows up, start early. If you don't start immediately, another hunter will already be finding and reporting your bugs. You should know that this is not be be all and end all though. Targets change all the time and you never know when the program might bring vulnerable targets online, so do visit old programs too and keep track of their infrastructure to monitor for new additions!
Finding Targets and Enumeration
Once you know your scope, you need to start doing reconnaissance. This usually means finding related IP addresses, subdomains and endpoints to which you can then assess for bugs. To do this, start passively by using search engines such as Google, Shodan, Censys, WhoisXMLAPI , WayBackMachine, wappalyzer. By using them, we mean try Google dorking, finding IP ranges owned by companies, servers ports, JS libraries, CDNs and pretty much any related information. Data is your friend, use it to guide your hunting.
After passively seaching for targets, move onto active reconnaissance. This means taking what's in scope for the program, using what you found in the passive phase and inputting it all into tools to find you more targets. Here are some good examples:
- sublist3r for subdomain enumeration
- FeroxBuster for directory and file enumeration
- ASNMAP to find IP Addresses associated to ASNs
- dnsx to reverse lookup any IP Addresses and match to domain names
- nmap to find open ports and service information.
There are many wordlists that you can use with the above, but you can also create your own custom wordlists with Alterx which may be more effective.
Where To Begin
At this point, you probably have a lot of data. Lots of subdomains, lots of IP Addresses, lots of services, etc. It can be quite daunting, where do you start with all this? Well, have a think on how you want to hunt and what your capabilities are. Do you only have knowledge to look for low hanging fruit issues. Something like open SSH ports that allow password-based authentication that you can try to brute force a password for? Or do you have the ability to look for business logic flaws, XSS, IDOR and more critical issues?
If you're comfortable with a variety of complex issues, this is where the money is at and realistically, you're likely here to hunt for monetary reward. So with that in mind, you want to be looking for low hanging fruit issues and start looking at web applications and APIs.
With that in mind, take a look at your data. Are there any web services running open open on non-standard ports. These are ports like 8443, 8080, 8000 but really they can be anything. So it's better if you're able to have nmap work out if the p0rt is running a web service and narrow it down that way. We just said that it's better to look for more complex issues. But don't get complacent. If you see an instance of a popular web application, try default credentials, you never know!
More Enumeration
Now you should have narrowed down your hunting to web applications and APIs and know what you have available to work with inside the program scope. You may be bored of this, but you'll have to get used to it. We need to do more enumeration. This is a key theme in bug bounty, as we said earlier, data is your friend!
Enumeration is now going to be a combination of manually looking through the web applications and APIs, looking for parameters, functionality, sitemaps, robots.txt, errors conditions, authentication and CSRF tokens, HTTP Headers and pretty much anything else where you may find an issue. We also recommend using some useful plugins like dotgit or debugHunter that help find a few potentially high risk issue.
This stage is all about understanding the targets you have in front of you, how they work, what their infrastructure consists of and such like. You are going to spend most of your time on this phase, it's where you find places that could be potentially vulnerable.
Finding The Bugs
At this stage, you know what's in front of you. You have seen the targets, you know how they function, you know their parameters, you know their infrastructure. Now is the time where you decide which of the many targets you want to dive into to try and find bugs. This will have to be based on your knowledge and experience. Well, you could try throwing tools like SQLMap, BurpSuite active scanner and more at the various parameters. But this is not advised and it will likely be against the bounty programs terms and conditions.
Select one target you believe could be most vulnerable. If you don't know, try the biggest target or take a wild guess. You could start some rate limited fuzzing on the parameters, HTTP headers, etc with BurpSuite and ffuf to search for errors and maybe expose vulnerabilities. Whilst that is running, take a certain functionality or workflow in the application and start reviewing it's logic. Do note though, don't get caught up in one area. If you believe you have tried everything you can and you are not seeing any potential for a bug, move on. You can come back to it later if you feel like it, but when you stick on a non-starter bug for so long, you motivation drops and that is not where we want to be!
Just a quick note on fuzzing. If you haven't tried using ffuf or the program doesn't allow automated fuzzing. What you should be looking for manually is what occurs in the application or API when you input:
- A minus number
- Various numbers
- A large number
- A string or symbol character
- Directory traversal using ../../../
- XSS vectors
- SQLI vectors
- Non-ascii characters
- Change a true to a false or a string to an array
- Use null characters or no value
Other Considerations
We wanted to add another quick tip before we finish up here. We previously noted that you should be fast because there are so many bug bounty hunters out there doing the same thing. The flip side of this is being a bug bounty hunter that is not the same as the rest and so, have less competition. Two examples of these are:
- Test mobile applications
- Test Blockchain applications
Useful Resources
To end this blog, we just wanted to present some useful starter resources:
vavkamiledoardotttWe wish you the best of luck in your Bug Bounty adventure. If you want to read more, we have a blog series on Bug Bounty hunting, you may start with the below:
Bear
