How To Earn Your First Bounty

1 year ago 112
BOOK THIS SPACE FOR AD
ARTICLE AD

I hope this finds you all well.

I wanted to share my version and methods on how to find your first bug bounty. If you’ve never found a valid bug, keep getting duplicates or even just want to increase your acceptance rate this will help you.

I remember when I was first starting I had some experience in web application hacking but very limited. I was not finding bugs when searching. I started on HackerOne but kept getting duplicates or N/As to the point I had to create a new account as my rep got so low. I never stopped.

This got me motivated, I wanted to be like the others and have valid reports. I would spend hours a day reading through HackerOne Hacktivity to see the sort of vulnerabilities others were finding. I would also spend hours reading other blogs on medium of vulnerability writeups. I no longer hunt on HackerOne, but on other bug bounty programs.

If you cannot find a valid bug, I must point you to increase your knowledge of Web Security. If you are just hunting for low hanging fruit, you’re always going to get duplicates. Many people run constant VPS that fire scripts at in scope domains to quickly identify low hanging fruits. You must think outside the box. I would recommend reading as many Web Hacking books as possible. Bug Bounty Bootcamp and web hackers handbook 2 + 3, as-well as constantly consuming writeups on Medium. Complete modules on Portswigger, how are you suppose to find the critical and high vulnerabilities if you don’t know what to look for or test? Go beyond the exploit and provide and prove impact. Don’t just use alert(1) with XSS, prove impact, can you steal cookies?

RECON RECON RECON

You must remember, hundreds/thousands of other people are hunting on the same domains as you. If you just run “NUCLEI” you’re just going to get duplicates, sorry to break it to you. Build custom recon scripts, learn bash and Python, find unique tools on github and test them, learn them, know exactly what they do. Don’t just use one tool. Subdomain enumeration should use multiple tools, directory brute forcing should use multiple tools.

Keep notes, map out the application.

DIG DEEP!

Don’t just run a quick scan on a website and give up if you find nothing, that’s what everyone else is doing. Go deep. Register on the site, make multiple accounts. Test every single feature and function on the site. Do what others are not. Do not just run automatic scanners. To put it into perspective, I never run full on vulnerability scanners, I think they are not useful. Learn your vulnerability types and uniquely test for them. I’m not saying I never use automated tools, i’m saying I never just full on run vulnerability scanners. For instance if I am looking for XSS, I will just run a reflection tool and highlight everywhere reflection occurs on the web app. From there I will test manually how my XSS payloads are handled. Are certain tags blocked? Are certain event handlers blocked? Is there DOM elements where my input is reflected or stored? That’s all apart of digging deep.

JAVASCRIPT

Always read JavaScript. There can be a gold mine of information stored in accessible JavaScript. I had 3 vulnerabilities on bbc.com where all I had was a login panel, it seemed everyone gave up here, but I read the JavaScript, I gathered all endpoints I found in the file and I tested here netting myself 3 API vulnerabilities.

KEEP LEARNING

Develop your own methodology and keep learning to add to it. Never copy someone's methodology as what works for them may not work for you, tune yours for you and I can promise the results will start coming. Never give up and never stop reading.

I hope this helps anyone out there.

Read Entire Article