The easiest way to fail as a bug bounty hunter is to search at random without a methodology or process to follow. Here’s what to consider.
It is really easy to jump straight in and wildly throw payloads at a system when you first approach a target. Admittedly, it can feel great for the first hour or so but after that, you can start to become bored and frustrated if you don’t find anything. And without a structured bug bounty hunting process, you probably won’t find anything new.
It is important to develop and follow your own testing process in order to test thoroughly and professionally. When you first start out your process will be weak and immature but you’ll develop and improve upon it the more bug bounty hunting you do. If you do this consciously you’ll have greater results.
Choose Your Approach
The high-level approach you’ll take to bug bounty hunting is entirely up to you. Some people have excellent success by picking out a few specific vulnerabilities and testing them against everything in scope for every company running a bug bounty program. In the video below, Mike Baker discusses his approach using automation to test thousands of servers for a handful of known vulnerabilities and making a lot of money doing it.
Others like to focus on a single company at a time, learning everything they can about how they operate, how they write code, what technologies they use, who works for them and how they think about solving problems, which mistakes they keep making, etc. They might even focus on a single application within that company for a long period of time, especially if that product is constantly evolving.
The balance for you may lie somewhere in between. Just because others have success working one way doesn’t mean you will too. Experiment to see what works best for you then stick with your chosen approach.
Minimum Time on a Target
Just like most things in life, starting down the path of a new bug bounty target has a setup cost. This cost can be measured in the number of hours you need to spend learning their environment before you can become operationally effective. Determine what your own setup cost is for a new target and then commit to spending at least that amount of time plus the time you want to spend hunting for bugs in that environment before moving on. Do this in advance and write it down so that you don’t give up too soon.
If it takes 4 hours to get a feel for a new company or application and you quit after 5 hours total then you’ve wasted the setup time without giving yourself a reasonable chance to find any vulnerabilities. If you’re willing to spend 5 hours looking for bugs in an application, that timer only starts after your setup cost ends. Don’t get disheartened when you don’t find anything within your learning window.
You could never guess the ending to a book without reading enough of it to learn the genre, characters, and initial plot lines. The same applies to bug bounty hunting. Give yourself time to learn the context in which you’re working.
Maximum Time on a Target
It’s as easy to spend too much time on a target as too little. Before you start, specify and write down the maximum number of hours you’re willing to spend digging into a target without finding anything. After you’ve already spent a lot of time learning how a company and application works, sunk cost fallacy will prevent you from moving on. “I’ve spent 80 hours on this application for nothing… if I move on now all of that effort is wasted”.
Your bug bounty hunting process should be for learning as much as it is for earning. By not finding any bugs within an application you haven’t failed, you’ve just learned lots of new ways that didn’t work. Use your time spent without finding bugs to prompt research into new areas and expand your skill set, but don’t keep testing a single target without a defined end time as this will cause burnout.
It’s easy to get demotivated if you haven’t found anything in ages, especially after investing a lot of your time into a project. Commit to an end-time upfront and move onto something else before the fun dries up. You can always come back to a target in future. Make the decision at the easiest time: before you start.
Minimum Time on a Write Up
You don’t get paid for finding vulnerabilities, you get paid for writing reports on vulnerabilities that you’ve found. Companies get value out of your written reports that explain how you found the bug, what causes it, how it could have been avoided, and what you would recommend they do to fix it. That’s why they pay you.
The words “Stored XSS on <URL and parameter>” might be a very concise way of describing the issue but it doesn’t add a lot of value. If you want to maximise your payouts, maximise the value you provide to the developers running the bug bounty program.
Define a minimum amount of time or words that you’ll invest in writing up your finding reports. The desire to rush through it is strong as writing the report is preventing you from finding other bugs, but writing the report is the whole point of what you’re doing. Don’t rush it. Make it count. The team running the bug bounty program will thank you for it. At worst, it will do no harm.
Define your Hands-on Bug Bounty Hunting Process (or Methodology)
Bug bounty hunting is penetration testing without guaranteed pay. You can, therefore, use the standard penetration testing methodology for bug bounty hunting. This is usually along the lines of:
- Scope Review
- Passive reconnaissance
- Active reconnaissance (scanning)
- Manual testing and assessment
- Report writing
As bounty hunters, we’ll only be doing steps 1 to 5. Step 6 is completed by the team running the bug bounty program. It’s our job to make their jobs as easy as possible.
To ensure you operate effectively, define how much time you’re willing to spend on each of the stages from 1 to 5. Stage 4 is the most interesting and the stage we’re always the keenest to get stuck in to but stages 1-3 are where we actually find the bugs. Unless we know what we’re testing we can’t test it effectively. Generic vulnerabilities from automated testing tools will almost always be detected by either the developers or someone else before you get to it. You’ll make the most money by targeting the areas that nobody else is thinking of. This is why your research phases are so important. If you want to find new bugs you must do new things.
Before you go hunting for vulnerabilities within the scope of a bug bounty program, define the process you’ll follow to hunt for them. We work best within constraints and those constraints must be set ahead of time. If you try to define them while in motion, you’ll never stick within them once you’re moving.
Having a solid process will not hold you back. On the contrary, it will support your efforts and keep a level of discipline within your work which, in turn, yields results.