Finding P1 Vulnerabilities: A Step by Step Guide

Disclaimer: This article is for informational purposes only. Do not attempt to maliciously use information in this article to harm or otherwise commit harmful acts. I am not responsible for any actions taken using these techniques.

Great. Now that we’re done with that, we can get to the real thing this article’s about. I’m not going to clickbait anyone or delay your interest, so I’ll get right to it. Upon researching a few neat domain based bug bounties on sites like HackerOne and BugCrowd, I’ve found a good few vulnerable sites that pay good money if you locate something useful. If you’re a beginner, you might want to check out this post, and this one for platforms with less competition.

Step 1. Determine if a website looks like it’s worth hacking

This is a very important step. If the site you’re doing recon on just doesn’t realistically look like it might be vulnerable (i.e. modern libraries for back-end [internal], utilizes PLP [Principle of Least Privilege], front-end [client side/external] is clean), it might indicate that the developers put a lot of work into the site and have cleaned up any insecure backend functionality. If you’ve done one or two basic scans on the site and back-end programs are up to date, it might not be worth going further on.

Outdated programs are common sources of vulnerabilities, and eliminating that reduces possible hacking vectors by a significant amount.

Obviously if you poke hard enough there’s usually something, but just starting out look for fairly outdated front-end or back-end code can be helpful.

Step 2. Initial penetration test of the site

This step is where you’ll find out if the developers are lazy, if they made some silly mistakes, or if there’s a bug somehow nobody’s been able to find. Some starting scans might occur here, with tools like Nuclei or Gau. There’s a ton of bug bounty articles written on this, with fairly easy vulnerabilities found using just those two. Most people write scripts for their initial pen-testing and use at least those two tools. Mine’s linked in my Github, feel free to take a look and utilize the code if you’d like.

Step 3. Figuring out if the site is worth looking at or exploiting smaller exploits

In this stage, you’ll find out if there’s anything interesting and look at exploiting the things you’ve found in the initial tests. These will usually be quite small, but if the developers have forgotten patching a certain medium-high level vulnerability, they’ve usually forgot patches somewhere else.

Essentially, if you’ve found anything meaningful, dig deeper. This has lead me from something like interesting javascript sinks to DOM-based XSS, and I’ve gotten a couple bug bounties just using automated ‘deep’ scans.

Step 4. Chain em for more $$$

If you’re in it for the money, or just to be a good samaritan, chaining those vulnerabilities can get you even further. Chaining things like XSS to SQLi or certain header request vulnerabilities to Vertical Privilege Escalation. This can multiply the payouts and increase the severity tenfold in some cases. Make sure after you’ve scanned and manually exploited just about everything you can on a site (legally of course), go back around and double check there’s nothing else you might access with your exploits.

Follow due process in chaining exploits and take note of ‘safe-havens’ in the bug programs.

Even more in-depth and the actual tools and programs to exploit each of these steps →

Basically, use these links if you want to further your bug hunting skills:

Hopefully, you found something here that piqued your interest and that you were able to use. If you’d like to learn more about computer science and hacking, check out The Gray Area.

To support me as a writer, and get access to all of my (and thousands of other writer’s) articles, become a member using my referral link →

Thanks!