TL;DR: As a pentester, when I first started bug bounties, it was hard. I had to change my hacking style to start earning decent money. Read on to find out exactly what changed.
When I first started bug bounties, I had some web development experience, OSCP, and I’d been a penetration tester full-time for about a year. I definitely had a lot to learn, but by this point I could confidently perform a pentest and I had a good understanding of the main vulnerability classes, especially for web apps.
With the skills I’d gained as a penetration tester, I was consistently finding bugs quite easily in pentests so I thought that bug bounty hunting would be an easy side hustle to earn some extra cash. Before I started bug bounties, I would estimate my potential bug bounty earnings based on the amount of bugs I was finding in my day job. Sometimes, I’d sit down for a new engagement at 9am and find a SQL injection before 10. In this scenario it’s easy to have the thought “if this was a bug bounty program, I’d have earned $5000 already!”. For this reason, I started doing bug bounties in my spare time.
Let’s just say that starting bug bounties was a huge ego hit. It took me months to find anything valid. I’d constantly see people posting their bug bounty successes online and I was confused about how I could be doing so much worse than they were. Is there some magic knowledge that they possess? Some crazy hacking secret that they had not divulged? It was a mix of frustration, curiosity and raw motivation that kept me going.
The Tipping Point
One day, everything changed. I attended a security meetup in Sydney. I don’t remember which meetup it was now, but I do remember that Shubs (@infosec_au) was doing a talk that night and it was the first time I met him. I already knew who he was because I’d been following him on Twitter. He was one of the unicorns I’ve been talking about, he was able to consistently find high quality bugs on huge bounty programs. Naturally, I was very keen to hear what he had to say.
His talk was about using automation to discover ephemeral bugs and interesting targets, but for me it was much more. The way that he spoke about bug bounty hunting implied a completely different model of thinking. I had always approached bug bounty targets as if I were performing a penetration test – and this is why I wasn’t finding many bugs – because hundreds of people had already taken exactly the same approach. Any bugs that could be discovered with this approach had already been discovered.
The Key Takeaway
In a nutshell: As a pentester, you are paid for your time. As a bug bounty hunter, you are paid for impact. This key difference is more than surface level – it changes the whole game. Your hacking style should be altered significantly.
Below I’ll explain exactly how this should alter your hacking style, and the realisations that lead me here. I’m hoping that by posting this, penetration testers wishing to dip their toes into the bug bounty space will not make the same mistakes that I did.
In a penetration test you get paid to spend a specific amount of time on a target. In that time, you are generally expected to perform the most thorough testing possible, provide full coverage and provide assurance that the target is secure. If we’re all being honest though – no security tests (pentesting or bug bounty programs) can 100% guarantee security. This is especially true if there are time constraints on the testing process. The best that we can do is guarantee that a malicious attacker with exactly the same processes, time constraints and skillset as the tester will not discover any vulnerabilities.
In bug bounties the main struggle is that other people have already tested the target before us. Our main goal is not to provide coverage or assurance in a set amount of time, it is to provide maximum impact in minimal time. A full standard pentesting methodology has likely been performed on the target many times over by many different people before we turned up. For that reason, if we are hoping to find impactful, unique bugs on a bug bounty program, a standard pentesting methodology is likely not a very profitable place to focus our attention. Instead, we should focus on the gaps; the types of vulnerabilities that a pentest would not usually cover. These come in many forms, which I’ll outline below.
Methods for Success
Extreme Reconnaissance
Let’s say that a web application test runs for five days. What if you want to run a directory brute force that takes ten days? What if that directory brute force would have uncovered an unprotected admin portal on the sixth day? It cannot be done during a pentest, but it can in a bounty program – this means that we’ve identified a gap that we can focus on!
In bug bounties it pays to have large, customized, program-specific wordlists for cases like this. It doesn’t matter if the brute-force takes a month to complete because requests are free, and there are no time constraints. The same goes for discovering hidden parameters. Use your creativity to conjure up some other ideas for more extreme reconnaissance.
Extreme Depth
Again there are no time constraints so going deeper than everyone else is a huge advantage. Some examples may include:
- Manually test every endpoint for everything
- Take the time to fully investigate and understand the purpose and flow of every feature
- Understand the purpose of every parameter and cookie
- Understand what every line of JavaScript does
This kind of deep understanding of the target will lead to the discovery of bugs that most would miss.
Scalability
Most often, penetration tests are performed on a single target or a few targets and you will only be required to focus on one engagement at a time. Bug bounties are the opposite. There are hundreds of bug bounty programs that are available to hack every minute of every day. For this reason, it pays to scale out your hacking efforts through automation.
Continuity
There are so many targets that are available to hack – and they are constantly changing. There are many components of a target that we can monitor for changes including HTTP responses, DNS records, acquisitions and ports. When any of these change, it pays to be one of the first to look at it. This type of continuous monitoring and testing is an excellent way to gain an advantage in our hunting, namely that the targets we attack are more likely to be new and untested.
Keep in mind that we are no longer performing point-in-time tests, we are performing ongoing tests. This opens up a whole new level of opportunity to find bugs.
Chance Blind Exploits
There are times where you enter a payload somewhere and it doesn’t get executed until much later. For example, you might enter a blind XSS payload into some random form, and it doesn’t fire until months later on a completely different application. It is advantageous to perform these attacks on the off-chance that some day in the future, some staff member will just stumble upon the right page in their internal tooling for the payload to fire. Make sure you have good logging to detect when/if it does!
Creativity and Experimentation
Pentesting tends to get you in the habit of performing high quality work to a set of standards, but it doesn’t usually allow the time to explore new/unique ideas or research that might lead to novel bugs. Many of the top bug bounty hunters have made a lot of money through security research, finding new and novel attack vectors and then applying exploitation of those vectors over a large set of programs.
We are competing with hundreds of other researchers, so your own personal creativity is a huge asset.
Start Hunting
If you want to start hunting today – sign up to Bugcrowd and check out our public programs here.
Stay in Touch
If you’d like to get more involved with the Bugcrowd community, you can join our Discord, follow us on Twitter, or check out our video content on YouTube including loads of technical content for bug bounty hunters.
If you’d like to see more from the author personally, follow hakluke on Twitter, YouTube, Instagram or check out his website.
