Bug Bounty Hunting Process

Rules

1. Read the Bug Bounty program and save it in the work environment.
   • Scope of approved / refused vulnerabilities should be defined for you to not waste time.
2. Dedicate a structure / vault / setup for the scope you’re working with.
   • No need to mix everything. Tools should still be available obviously.
3. Don’t go in every direction :
   • Identify the environment framework and features on the website.
   • Map out the important functionalities of the app before digging.
4. Follow a methodology :
   • if you find something that looks strange or exploitable don’t dig right away.
   • Take a step back and look around, note it down and then you’ll have a better understanding.
5. Respect Code of Conduct and Rules of Engagement, any specific actions that are prohibited are mentioned.

Methodology

The chances automated search and usual vulnerabilities were thoroughly checked are important. You can try to go wide and do a very broad assessment but I wouldn’t recommend that.

1. Enumerate everything in scope and get as much contextual information as possible. Bug bounty isn’t tied to a definite time restriction so you can really understand the workflow and go in depth.
2. Focus on the vulnerability tied to the technology used in scope.
   • This involves getting really comfortable with a defined set of vulnerabilities instead of trying to find everything.
3. Automating is good but everyone has already done that, so we’ll have to get our hands on what’s not flagged by tools.
4. Look to replicate every checks you could have seen in Portswigger Labs by considering the actual work environment.

Reporting a vulnerability

In a similar way you would make a report for a pentesting mission the structure should look like :

• Vulnerability Title
• CWE of the vulnerability and CVSS Scoring Quickly give a idea of the severity of the vulnerability
• Vulnerability description The reader is not supposed to know each vulnerability beforehand. A concise explanation of the vulnerability has to be done without being too technical
• POC Give the step by step guidelines to reproduce the vulnerability. Screenshots, scripts are mandatory to push the reasoning clearly. Add any contextual information needed to trigger the vulnerability.
• Impact Define clearly the consequences of such a vulnerability. This should be explained in a business level not technical so anyone is able to understand it.
• Remediation While you are not supposed to fix the vulnerability, you should advice for the “total solution” (eg. not the quick fix that can be bypassed) measures to apply. In a pentesting engagement you would need to give estimation of 1. Implementation difficulty : Does the remediation imply changing many parts of the application / environment or a simple config file can be edited ? 2. Time taking : How long would this fix take to be implemented ? 3. Remediation complexity : Is there easy documentation available to achieve it or it will require researching to the client’s context ?

Examples of reports

I intend to add a reporting section along next write-ups. This way the publishing format will be

1. Write-up / Walkthrough
2. Findings reports