Beginner Bug Bounty Guide — Part 4

Previous: Beginner Bug Bounty Guide — Part 3

Next: Beginner Bug Bounty Guide — Part 5

Note: These articles are my take (opinion) on “How to start Bug Bounty”, inspired by security community. These details will be updated as an when I learn new insights. These articles are for ethical and educational purposes only.

Improve Your testing skills

• People talk less about testing, because this keeps on changing, although the vulnerability working is the same but the test cases are different. There are new tools created, new attacks identified, new test cases. Hence even if people try to explain their testing methodology it is valid for that instant of time, in future it may not cover all test cases or sources.
• This article does not focus on test cases or what exactly you need to do, but gives an idea for begineer how first start creating your own testing methodology and then be update with new tools and test cases.

Step 1: Understand the Vulnerabilities and Attacks

This step contents you will find readily in the internet, where people explain how a particular attack works. Generally the do all their pratical demo in a lab or well known webapp testing environments.

Goal of this step to understand as many vulnerabilities as possible, it does not mean to get all test cases, just understanding is what the goal is and few examples to explain them is sufficient. Below are some of the sources or way you can achieve this step. All these will help “after” you have detected that an SQLi, XSS or any other attack could be possible. Or the test cases used for detection does not cover new test cases and approaches. Generally all the basic test cases or already performed by free automated vulnerability scanner.

Note: Online courses, even bug bounty specific courses, Practice labs, etc are part of this step, and are generally intended to understand the bug. These don't give how to do the actual testing in the wild. Actual testing will be discuss in later sections.

• Free Vulnerable applications: Buggy Web Application (BWAPP), Damn Vulnerable Web Application (DVWA), OWASP Mutillidae
• Youtube videos on working of attacks: Example, SQL Injection Complete Guide, etc.
• Online courses: Like Udacity, college courses, lectures on web app testing, etc.

Step 2: Creating an initial testing approach

From step one you would have got a wordlist from github or noted a few test cases while you were learning the course. But these are incomplete and trivial. Generally these will be covered by even a simple web vulnerability scanner. Even if they are covered, we still need something to start testing.

Goal here is to create an “initial” testing methodology which will be improved in later sections of this article.

How to achieve this step? I have already written in-depth article on this in first part of this series. Beginner Bug Bounty Guide — Part 1. There is a .drawio file which tells in details how to create your testing approach, below are some brief points.

• Portswigger academy.
• Specialized Udemy courses on bug bounty
• Payload Resources like: Payload of all things, Payload box, SecLists, etc.

Note: Simply dont waste time in finding a more richer payload list. This can be done later, the urgent thing now is to start testing first.

Things not covered in the part 1 of this guide.

• Practice Labs : This article give you top free and commercial online practice labs which are better than ones that you tested in Step 1 of this article. Note, these labs does not cover all test cases, and it does not mean that completing a lab easily means you can do the same in the wild. Hence you should not waste much time here. They are good places to know a testing approach or learn a particular attack, etc.

Step 3: Improving your test cases and approach for the wild

Until now we either were testing an old real life example (which you probably will not find now) or simple lab environment which were designed in such a way that the bug got easily detected and exploited.

But in real production environment, there are experienced and specialized teams which keeps all software updated, do testing, do penetration testing on their application, have Firewall, WAF and other monitoring in place, adhere to security guidelines and are compliant with the industry standard security requirements. And they keep on doing all this frequently (every month or every quarter). Here you will not see just a single parameter like /?q=something or /?query=otherthing, there will be header fields that you do not know of, even to get a single webpage, a lots of requests are made to server, etc. Now this is where the real web application is and goal is to find bug here.

Problems faced during starting in a real production web application.

• There are lots of parameters.
• As the web application is big have lots of features, it is difficult to understand how a data flows, or it is time consuming the understand the complete application working, and this time you can spend on some other program/project/target to get low hanging fruits.
• A lot of automated scanning like OWASP ZAP and burpsuite audit scans. Now how will I find bugs?

Solution (Approach) that helped me to tackle all these problems.

• Don’t get overwhelmed by the complexity of website. You just test what you know and what you think interesting out of all this data, if you dont know, you may give it a try given it does eat up much of your time, else simply ignore it. Yes if you ignore, you may miss bugs which otherwise you might have detected after you have understood each and every part of application working, but it is fine. You will eventually improve and test it these in future. Currently your only goal should be finding your “first” bug or just “one” bug.
• The need of bug bounty is mostly after penetration testing, and in penetration testing all these automated testing and very trivial bugs will be detected. So running the scan again may help but rarely, yes new test cases are updated in these tools, but there are a lot of people (on that day itself) which have performed the same scan that your are about to run.
• So what to do now? These automated scans should not be the main reason or the approach to find bugs, these should be run in background, if these tools find bugs or not, in both scenario your testing approach should not be dependent on these tools. These tools are not intelligent, even if they report that no XSS is found, people still find XSS on that website. But have could I find it like other security researchers do?

Step 1: Read as many bug bounty writeups, submissions and keep update to date with new submissions. Below is order that you can follow to save time.

1. https://github.com/twseptian/Bug-Bounty-Testing-Essential-Guideline-Startup-Bug-Hunters
2. https://github.com/ngalongc/bug-bounty-reference
3. https://github.com/reddelexc/hackerone-reports
4. Hacktivity
5. Twitter handles to follow for bug bounty tips. (already discussed in part 1 of this series).

This is what you will need to understand how actually bugs are found. But all these many not give you details on how the bug was detected, for this you need to read writeups.

1. InfoSec Write-ups
2. topicwise — writeups 1
3. topicwise — writeups 2
4. List of bug bounty writeups · Pentester Land

After some time like 1–2 months imply reading different bug submission and bug bounty writeups, you should have an idea and until now collected new test cases.

Step 2: This is simply organizing step 1, the easy way to organize everything is automated. Automate as much as possible and keep on improving your automation. Keep track of everything so that you don't missing testing. And this is also important for removing the test cases that are not relevant to that target.

You need to improve your testing methodology based on the new information you identified in Step 1. Not all can be automated, but you can always note any new test cases or approach in your notes, and then try this out in your existing or next testing.

These should be sufficient enough for finding your first bug in the wild. The bounty program does not matter whether it is private or public. Following step 1 and step 2, you will definitely find your first bug.

Repeat Step 1 and Step 2, is what successful bug bounty hunters do.

Step 3: It is not exactly a step, but extension of Step 1 for experienced bounty hunter which want to do more.

• Help infosec community
• Collabroate with other bug bounty hunters.
• CTF competitions.
• Attending security conferences.
• Read research paper, create alerts on newly published research papers in website like google scholar and similar websites. Note that these are not free.
• Watch youtube videos on how some bug bounty hunters and penetration testers discovered new attacker surface or attack approach, generally these will part of some conference or some presentation in Youtube, then use these ideas to try to do research on any interesting topic which you feel should be explored more.
• Focus on automation of Recon methodology and new attack surfaces.
• Focus on attack chaining, and what normally would be two low severity bugs, and be combined to form a medium/high severity threat.