Bug Bounty Tips

cc: nahamsec

1. Understand your scope

Going and looking at what they built this application for and what it’s meant to do.

> The more questions you ask yourself, the more you answer and the more you understand the application.

Questions to ask yourself;

I) What is this application built to do?

II) What kind of user roles exist?

III) What do these users have access to regarding the apps?

IV) How do these users interact with each other? i.e. what can I do as a low-level user to elevate my access to maybe out to those API endpoints built for an admin?

V) Check the information that is meant to be public versus those that are supposed to be private. Now I will try to see if I can access that information without being logged in or maybe it’s meant to be for admins. I can access that as a user without admin privileges.

> Develop an approach where I start looking at JavaScript files to find those endpoints that are hidden or maybe my user doesn’t have access to.

Tools like: JS Parser → will take every single JS endpoint, it will highlight that for me so that I can see them within my tools and can also start fuzzing them.

> Automate buncha tasks and break down the methodology into 3 different huge buckets;

Bucket #1: Asset Discovery

I try to find and enumerate as many sub-domains as I can and using tools like Sublist3r e.g.

python3 sublist3r.py -v -t 50 -d (domain name)

Other tools: Knockpy, SHODAN, censys, certspotter

Bucket #2: Content Gathering

This is where I start to automate the idea of finding very interesting folders, every single endpoint, and getting a visual of what every target looks like, Tools like Webscreenshotpie

Bucket #3: Fuzzing

~ Try to find what each endpoint is supposed to do and how I can use it to exploit a vulnerability.

~ There are several bash aliases → These are things you type in instead of having to type the entire syntax for a tool.

Directory brute-forcing tools like dirsearch

2. Searching for answers

When searching for additional sub-domains or endpoints search, put this thing into either a google search or a GitHub search.

> Putting in the results and errors (Noting them down)

3. Keeping historic data

Storing every single report, output from every single tool you use

> Every time you scan make a folder for it, and then within the folder make another folder that has a date when you scanned them, where the output of some of the tools you want to key just in case it comes up later on e.g. of what to keep;

i) Directory of Bruteforce results

ii) Some of the headers you collected

iii) open Ports

iv) Things that you have used and the other tools that matter to you.

4. Fingerprinting

The idea of finding unique ways to identify an application or a vulnerable endpoint across multiple companies or domains.

> Spin these apps locally

> How the company operates and builds its infrastructure, e.g. prod sites

5. Looking for patterns

Looking if what you have identified is shown in other sites, companies, or even other apps.

6. Learn from others

Read blog posts that other fellow bug hunters have written, get one or two tools they have used, and come and learn how they work so that you can apply them to your work.

> Engage with them in discord channels by asking each other questions and asking for assistance when you don’t feel confident about it.

> Collaborate with another hunter once in a while.