A common question nowadays is “How to get started in Bug Bounties?” and I keep on getting this message on a day to day basis. It’s not possible for me to respond to each and every message, so I thought I’d rather do a blog post and would direct all those beginners to this blog post.
I am a learner in Hacking Stuff and I’ve been in the bug bounty field for 3+ years now. still, there is so much to learn each and every day, I’m yet not an expert and this post is for mainly those peoples who are an absolute beginner, or someone who is thinking to get started into bug bounty, or someone who is planning to change their field.
What are Bug Bounties?
A bug bounty program is a deal offered by many websites, organizations, and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those pertaining to security exploits and vulnerabilities. These programs allow the developers to discover and resolve bugs before the general public is aware of them, preventing incidents of widespread abuse. Bug bounty programs have been implemented by a large number of organizations, including Facebook, Google, Twitter, Microsoft, Uber, Github, Internet bug bounty, and many more. Companies outside the technology industry, including traditionally conservative organizations like the United States Department of Defense, have started using bug bounty programs hosted on HackerOne.
Formal Education vs Information Security
I’ve seen a lot of guys think someone needs to be from a computer science background to be good in Hacking kinds of stuff. But this is not correct. I am too from a Power Engineering background but I am very much interested in the information security field from school time but joined the Power Engineering field with the advice of family members but my main focus has always been Information security.
Being from a computer science background helps but it is not compulsory but you have to learn the computer science fundamentals yourself. So, If you are from a non-technical background you should get started only if you’re more interested in learning about information security not ONLY interested in $$$.
Keep in mind
- No one will be able to tell you everything about this field, It’s a long path but you have to travel it alone with help from others.
- Do not expect someone will spoon feed you everything.
- Focus less on $ and more on learning.
- If you think you will become successful overnight or over the week or a month, this is not a field you should join.
- Doing bug bounties are very competitive nowadays, it took me more than six months to find my first valid vulnerability, so be patient and practice every day.
Basic Technical things to get started
You must have a basic understanding of how things work on the internet. Learn how things work before getting started into Bug bounty hunting so you don’t have to ask random people why a payload isn’t working. There are many things you have to learn but I cannot list all of them here. I’m listing a few important topics and you should learn more by yourself.
- HTTP/HTTPS: HTTP is a communication protocol that was designed for communication between web browsers and web servers. From this deception, you should understand how important it is. You should go through the below resources to get the basic idea about HTTP Protocols, HTTP Requests, Response, Status Codes, Encoding/Decoding, SOP, Cookie, MIEM & HTML Pharising what will definitely help you later.
- Basic Networking: A basic understanding of networking is important for anyone who’s into a computer. I enrolled Certified Network Security Specialist and I personally found it really helpful for me. I can suggest the below resources to learn the basics of Networking.
- Linux Commands: You should have knowledge of Linux OS commands.
- Programming/Coding: To be a Good Hacker you don’t really need to be a Good Programmer but it’s always good to cover the basic level so that you understand what’s happening there after looking at a chunk of codes. If you understand the code Sometimes It increases your chances of successfully identifying and exploiting a vulnerability and also you may need code to escalate a bug with a low/medium severity to high/critical. Back in 2016 when I was just learning XSS vulnerability and I don’t have good knowledge of programming and all I used to do is just copy-paste XSS payloads in user inputs without understanding a thing and the fun fact is I used to test with below payloads without understanding that all those were the same and I was just wasting my time 😷
<img src=x onerror="alert(document.domain)"> <IMG SRC=A onerror="alert(document.domain)"> <IMG SRC=B onerror="alert(document.domain)"> <IMG SRC=b onerror="alert(document.domain)"> <IMG SRC=# onerror="alert(document.domain)"> <IMG SRC=x onerror="alert(document.domain)"> <IMG SRC=y onerror="alert(document.domain)"> <IMG SRC=Z onerror="alert(document.domain)">
After reading my story hope you guys understand how basic knowledge in coding can save your time and give you more advantages in the future with automation and exploration. I’ll suggest a few languages that one should properly have basic to medium level knowledge about and keep advancing it.
SQL(Structured Query Language):
"Never send a human to do a machine’s job". Knowledge in the below languages will help you to automate your tasks easily. Knowledge in these languages will help you to code your own tools and understand many other common tools and modify them according to your needs.
Chose a Path to learn
Now it’s time to learn about vulnerabilities. In a Bug Bounty program, you may encounter different types of assets testing like
- Source Code
- Reverse Engineering
- Mobile Application
- Web Application
You have to choose one of them to start learning. Most of the guys choose the Web application asset first because it’s the easiest one.
Learning about Vulnerabilities
One vulnerability at a time. Look at OWASP’s Top 10 vulnerabilities and pick one vulnerability then master it. Create your own local sandbox environment and test for that type of vulnerability. Play with the application and try to find out why it is vulnerable. Then look for it everywhere on the internet [Test with proper permission or responsible disclosure policy]. While learning for a vulnerability keep the below points in mind
- How to test for that vulnerability and identify it?
- How to bypass WAF and other common defenses?
- How a fixed/secured application endpoint looks or reacts like?
Let’s me show you guys my way of learning new things, let’s start with XSS vulnerabilities. Whenever I try to learn new things in infosec I first ask google as “Google is your friend”. So I will just search using the below dorks and open all results in new tabs and read them all and try to figure out how those were discovered and how those vulnerabilities were tested.
- XSS site:hackerone.com
- XSS site:medium.com
- XSS POC site:youtube.com
Then I will test what I learned on my localhost. I was able to find below codes that I used when I was practicing XSS back in 2016.
<?php $val=htmlspecialchars($_GET['no_xss'],ENT_QUOTES); $val2=$_GET['xss']; $val3=htmlspecialchars($_GET['r_xss'],ENT_QUOTES); ?> <html> <body> <center> <h1> Injection Point 1 :- <?=$val2?><br> Injection Point 2 :- <?=$val?><br> <a href="<?=$val3?>">Tricky XSS :')</a> </h1> </center> </body> </html>
There are many other vulnerable apps available. You can use them to gain practical experience on a vulnerability. Some of them are:
CTFs are not always great for learning:
- Real targets are never going to be as vulnerable as a CTF is.
- The more you rely on learning from them the harder the jump is to real targets.
- Although the experience will help you in Bug Bounty but the transition is never going to be easy.
Learning new stuff while testing:
While you are testing for a specific vulnerability type you may encounter something fishy. For example, you discover a graphQL endpoint but you don’t know much about that. So would you ignore that? No! note that endpoint, stop testing then
- Go to google and learn about that technology and then came back to that endpoint to test for vulnerabilities.
- If that didn’t work setup that technology or application in sandbox and test there for gaining experience.
Read other Researchers write-ups and disclosed reports
Regularly read other researcher’s writeups to understand their methodology and learn about how they approach vulnerabilities. I will suggest starting with InfoSec Write-ups what contains a huge amount of POC write-ups for many researchers. Also regularly keep eye on Hackerone’s Hacktivity. Reading other researchers write-ups and Hackerone disclosed reports allows you to
- Learn about other hackers thinking and what they found.
- Understand other researchers thinking and testing process.
- How they are approaching a vulnerability.
- How they tested for that vulnerability.
Recon is a set of processes and techniques (Footprinting, Scanning & Enumeration) used to covertly discover and collect information about a target system. During reconnaissance, an Ethical Hacker attempts to gather as much information about a target system as possible. For recon, I will suggest reading Dirty-Recon.pdf
Should you rely on automated tools?
As a beginner, you should avoid automated tools unless you know what and how that tool is working,
- Don’t rely on tools, except for a proxy.
- Use tools only when you understand how and why they work.
Which targets should you choose as a beginner?
As a beginner, you should avoid the bounty program and give those efforts to VDP programs to earn reputation points, Hall Of Fames, and swags. You will also earn experience with it. Focus less on $$$ and more on learning, test programs with VDP, or independent sites that offer Hall Of Fame or Swags. There are lots of queries you could search for such a program on google, however here are some popular search queries: (don’t forget to try different languages!)
inurl:responsible disclosure inurl:security site:target.com "report security vulnerability" "vulnerability disclosure" "powered by hackerone" "submit vulnerability report" indesc:bug bounty|vulnerability disclosure inurl: bug bounty white hat program "vulnerability reporting policy" inurl:responsible-disclosure-policy
Pick a program you love and hunt there for a long time.
Writing a Decent Vulnerability Report
In BugBounty Writing a well-explained Report is the most important part. If you don’t write a good and well-described report you may end up making confusion with the Triage team, what could result –
- Less Payment than expected.
- Report closed as N/A.
- Will take more time to confirm the vulnerability by the Triage team.
On the other hand, if your report is well explained / clear and contains all the info then it will take less time to confirm the vulnerability and you will get your reward soon. Even you may get Bonus rewards for your creative and detailed report. I got many such rewards where that report should be closed as Won’t Fix or Out Of Scope. See a few example scenario below –
Scenario 1: In the below screenshot it was a vulnerability in Out Of Scope asset, but I showed them how it can lead to a good impact attack by writing a detailed report and they rewarded me $800 and appreciated my detailed report.
Scenario 2: In the below screenshot the company was an online Banking service and the vulnerability was using an expired/used password reset token of a user attacker can brute-force for login password which could lead to account takeover. But it was a vulnerability of the PHP framework and according to the policy, it will go under Not Accepted vulnerability. But for my detailed report, they paid a €50 bonus for a report what was Closed as Won’t fix.
From the Above Scenarios, you should understand that how much important it is to write a detailed and well-explained report. A vulnerability report should contain the below contents:
- Vulnerable Endpoint
- How You discovered it
- How to reproduce
- Impact & Scenario
- Recommended Fix
Title: In a vulnerability title you have to give a title about the vulnerability you are going to report. For example, you discovered a Reflected XSS in the 0xPrial.com domain’s contact endpoint. So the title will be something like: Reflected XSS in 0xPrial.com domain’s contact endpoint.
Summary: In this section give a short summary of the vulnerability.
Description: In description give detailed information about the vulnerability. For example, if you are reporting an XSS in the contact form then describe how XSS is happening on that endpoint and how it’s working.
Vulnerable Endpoint: List down all the URLs/endpoints/assets that are vulnerable to that security issue.
How You discovered it: In this section describe how you discovered that endpoint and vulnerability, list all scripts or tools you used to do it here.
How to reproduce: This is the most important part of a report. In this step write down all the necessary steps to reproduce the issue you discovered step by step. So-that triage team can follow it and reproduce the issue. It will be easy to follow your steps by the triage team if you add screenshots with every step. Also, you can create a video POC and add it to your report.
Impact & Scenario: Your bounty reward amount mostly depend on this section. In this section, you have to explain how an attacker can use that vulnerability to do something malicious against that organization. Describe what is the impact of your discovered vulnerability. What else you can do with this vulnerability, What an attacker can achieve using this vulnerability, How an attacker can attack another user using this etc. Also, add a real-life attack scenario in this section if possible to make the report more impactful.
Recommended Fix: Suggest a fix for that vulnerability. Dev team will push a fix according to suggestions and will ask you to retest again the fix.
Always keep the below points in mind while writing a report :
- Never upload your POC screenshot/Video to a place where everyone can see it. But You can use youtube to upload your POC video but ask about uploading it to youtube from that organization’s security team + upload it as an Unlisted Video.
- Never publicly disclose your report or vulnerability details before it’s fixed properly.
- Before publicly disclosing a vulnerability take permission from the company.
- If possible Use a public PGP key to encrypt your message while reporting.
Some write-ups on writing a quality report
- Writing Successful bug Submissions Bug Bounty hunter methodology
- Writing a good and detailed vulnerability report
- What does a good report look like?
- Web Hacking 101 [ Get a free copy from https://hackerone.com/resources/web-hacking-101 ]
- Resources for Beginner Bug Bounty Hunters
- Web Application Hacker’s Handbook
- Mastering Modern Web Penetration Testing
- The Hacker Playbook 1, 2 and 3
- The Mobile Application Hacker’s Handbook
- Breaking into Information Security
Twitter # tag you should follow
Blogs You should follow
There are plenty of blogs Shared by Hackers daily that you can read to learn more and more. [ Any Blog Link Missing? Kindly add it in Comments ]
YouTube Channels You should follow.
These Channels are Shared By Hackers where They Upload their Video POC’s. Watching them you can understand how to demonstrate these types of attacks. [ Any Channel Link Missing? Kindly add it in Comments ]
- Black Hat
- Shawar Khan
- Hacking Simplified
- Saad Ahmed
- Hisham Mir
- Devil Killer
- Girish Kumar
- Muhammad Khizer Javed
- Suleman Malik
- Harsh Jaiswal
- Frans Rosén
- josue Fernandez
- Vijay Kumar
- Mohamed Niyaaz
- Web Development Tutorials
- Jan Wikholm
- Bhargav Tandel
- ErrOr SquaD
- Arbin Godar
- Ameer Assadi
- Penetration Testing in Linux
- Behroz Alam
- Behroz Alam
- Farah Hawa
- 0xPrial 😜
At last pro tips for asking questions
asking good questions pic.twitter.com/nRKvVHaRQM
— 🔎Julia Evans🔍 (@b0rk) December 31, 2016
Thanks for reading. Is there anything I missed? Feel free to let me know on the comment or contact me on Facebook.