Bug bounty tools from enumeration to reporting

bug bounty tools

Hello ethical hacker and welcome to the world of hacking and bug bounty hunting. Today, you will learn the bug bounty tools I use when I hunt for vulnerabilities, from reconnaissance, to subdomain enumeration, to finding your first security vulnerabilities. Every craftsman has its toolbox and a bounty hunter is no different. However, it’s easy to get lost in the growing number of bug bounty tools which get published by the community every day. That’s why one of the goals of this article is to provide you with the minimal tools which provide the maximum returns.

Bug bounty tools for general reconnaissance

When you hunt for bugs, the first thing you will do is recon. This step is critical because if you don’t do it well, you will have a hard time down the road. And if you focus primarily on it, it will waste your time. So you must keep a good balance since you are trading your time when you hunt for bugs.

The goal of recon is to gather as much data as possible from about the company you target. 

Unlike a red team assignment, you won’t phish employees since targeting them is out-of-scope in. That’s why I like to focus on finding subdomains, IP ranges, URLs, API keys, etc. To do that, I use the following tools.

Amass as a bug bounty tool for general reconnaissance

OWASP Amass is a swiss-army knife for recon. It performs open-source intelligence and active reconnaissance using various techniques. You can use it to map the external assets of your targets to dress your attack surface and craft your plan of attack. It’s a well-maintained project and you can install it in many ways. I prefer to run it on Docker. It also generates detailed graphs and interfaces with other tools such as Maltego, a famous open-source intelligence software.

Amass has helped many bug bounty hunters find new assets and report vulnerabilities. This tweet is proof of my claims.

Amass is one of the most useful bug bounty tools
Amass is one of the most useful bug bounty tools

GitHub: A search engine and a great bug bounty tool

You can use GitHub to collect a lot of data about your target. Most of the time, you will find sensitive information leaks, from API keys to passwords. This is possible because employees accidentally push code without proper verification. Unfortunately for the company, these commits occasionally contain hard-coded credentials which allow you to access deep services.

Some bug bounty hunters specialize in this area and find highly impactful bugs. Although many tools have been developed to enumerate repositories and find sensitive data, they don’t cover the whole search space. That’s why those hunters invest considerable time conducting manual research. One of the main wizards in this area is th3g3ntl3man and he has made an awesome talk about Github recon on the Bugcrowd university videos. I could have shared a screenshot of some queries, but I’m afraid it will disclose sensitive data.

Shodan is your bug bounty tool for public devices enumeration

While GitHub is the search engine for code repositories, Shodan specializes in internet-connected devices. In other words, if there is a public IP exposing a service on a certain port, it is available for Shodan index. You’d be surprised by the number of exposed services there are online. From IP cameras with default credentials to industrial control systems, Shodan allows you to access all of them. There is a great Defcon talk by Dan which is both scary and amusing at the same time. I recommend you watch it to see how exposing services to the public can be so dangerous.

Shodan supports many operators as well. As a bug bounty hunter, you can use them to build your dorks and answer key questions about your target from a network perspective. You can get an idea of the top ports, the IP ranges, the ASN numbers, the country locations, etc. There is also an API which you can use to automate your recon process.

Shodan's Explore feature: It's scary to find such devices publicly available
Shodan’s Explore feature: It’s scary to find such devices publicly available

Wayback machine

What goes online stays online, as long and gets indexed. That’s because there are projects such as the Wayback Machine, which indexes and stores copies of web pages, books, audio, videos, images, etc. The project exists to provide knowledge for everyone. This is useful from a reconnaissance perspective because you can dig into previous copies of a target looking for any information disclosure, old URLs, removed files, etc. 

However, the process of going through tons of indexed content is tedious. Luckily, there are many tools out there which automate the process. I use waybackurls and gau, which give somewhat the same results.

Google hacking database

I’m sure that all of you jump to Google when you first want to learn more about the target you want to test. However, do you make use of google dorks? These are queries that use Google search operators to return precise results, such as only PDF files of a certain website, or administration panels of a certain technology in a range of subdomains, or any other need you might have. The only thing that limits you is your imagination. 

Even if you don’t have enough imagination, people have been sharing their google dorks for ages. You can find them in the Google Hacking Database (GHDB) and get inspiration. For example, if you found that the target uses a certain technology, you can look for it on that database to see previous dorks which might be helpful in your recon process.

You should add GHD to your bug bounty tools
You should add GHD to your bug bounty tools

These are some resources which can serve as bug bounty tools when you perform recon. However, there are certainly many other resources and one article simply cannot include them all.

Bug bounty tools for subdomain enumeration

So far, we have seen how you can perform general reconnaissance. But the hacking process involves enumeration in all stages. And one of the first stages is subdomain enumeration, which aims at finding as many subdomains as possible. The community has developed many bug bounty tools to assist you during this exercise. 

Assetfinder

I’ve already mentioned this tool in my bug bounty methodology. It uses multiple sources like certificate transparency, Facebook, Virustotal, etc. It works out of the box, but if you want more results, you can configure the API keys for the services which need one. 

Provided that you have installed and configured Go, the command is simple, you just have to pipe your target to the tool.

echo domain.com | assetfinder --subs-only

Below is a screenshot demonstrating part of the output of assetfinder against tesla.com

assetfinder output for subdomain enumeration
assetfinder output for subdomain enumeration

 OWASP Amass

We’ve talked about OWASP amass at the beginning of this article as a general bug bounty tool for reconnaissance. Well, you can use it for subdomain enumeration as well. It supports passive and active enumeration, performs DNS resolution and can also brute-force the subdomains based on the wordlist of your choice. The user guide is detailed and gives example commands that you can run. The simplest and quickest subdomain enumeration command would be:

amass enum -d domain.com -passive

Google

You can use Google dorks to find subdomains as well. To do that, you can use the site operator. An example would be site:domain.com. Once you get the results, you can enumerate the subdomains one by one using negative search. For example, suppose we found sub.domain.com, you can eliminate that result using: site:domain.com -site:sub.domain.com. Repeat this process until you no longer get any results from Google.

As you may have noticed, the process is tedious and takes some time. Luckily, there are tools such as theHarvester and sublist3r which you can use for such queries. However, bear in mind that they can get rate limited, which might return only a subset of the existing subdomains.

Waybackurls and gau

We have seen how digging into indexed content is important during the general reconnaissance phase. Well, it is also equally important when it comes to subdomain enumeration. I find it useful to run waybackurls and gau to grab potential subdomains which might go under the radar of amass. It’s always useful to combine multiple tools to get the most exhaustive results. 

The commands are simple and easy. For either waybackurls or gau, you simply pipe your target domain to them. I like to use unfurl as well to extract the domain part from the result.

echo domain.com | waybackurls | unfurl domains
echo domain.com | gau | unfurl domains

This is part of the output of waybackurls against tesla.com

waybackurls and unfurl bug bounty tools can work together when you perform subdomain enumeration
waybackurls and unfurl bug bounty tools can work together when you perform subdomain enumeration

Altdns

When it comes to enumeration, you can boost your results using brute force. To do that, I usually combine keywords related to my target. Using Altdns, I quickly generate permutations which usually get used by companies. For example, suppose the company’s main domain is XYZ. Well, the wordlist would contain subdomains like staging-XYZXYZ-dev and the like. 

The command is straightforward, you run the tool while providing the domains file and the words you want to use for permutations.

altdns -i domain.txt -o output.txt -w words.txt

Massdns

After generating a list of potential subdomains, I use massdns to resolve the resulting list for valid and existing subdomains. A word of warning though, this process can yield false positives, depending on the quality of the DNS resolvers you are using. You can find more about this problem on this GitHub issue

Rather than using the resolvers.txt file provided by massdns, you can get a list available on public-dns.info. Then, the command is simple, just use the massdns command with the list of resolvers and the altdns wordlist you have generated before:

massdns -r resolvers_file -t A altdns_wordlist -w results.txt

Bug bounty tools for port scanning

When you have a list of subdomains from the subdomain enumeration phase, you can start looking for running services. The technical word for that is port scanning. There are many tools which can assist you during this phase. 

Nmap

When you have a small list of subdomains, let’s say below 50, you can use Nmap to perform port scanning. It allows you to not only enumerate the running services but also fingerprint the server you are targeting. Besides, Nmap has a set of scripts which you can use to scan those services. For example, you can perform directory bruteforcing for HTTP services, or banner grabbing for SSH services, etc. The following command takes a list of subdomains as input, probes all the ports numbers (from 0 to 65535) while scanning the resulting services using their respective Nmap scripts. Finally, it saves the results into a sile named scan.

Nmap -p- -sC -o scan -iL subdomains.txt

masscan

Once you start working with big lists of subdomains, Nmap will take forever. That’s why I prefer to run masscan instead. It’s blazingly fast, but you need to have enough network bandwidth. It’s capable of scanning huge IP ranges. From the Readme file in the Github repository:

[…]the program is really designed with the entire Internet in mind. 

From masscan’s documentation

However, it only accepts IP addresses, no subdomains. Therefore, you have to resolve the IP addresses before running masscan. The following bash one-liner can do just that:

cat subdomains.txt | xargs -n1 host | grep "has address" | cut -d" " -f4 | sort -u > ips.txt

Then, you can run masscan. The following command takes the ips.txt file as input, it probes all port numbers, it uses a rate of 10k packets per second and it outputs the results into the file scan.txt

masscan -iL ips.txt -p0-65535 --rate=10000 -oL scan.txt

Shodan

Port scanning is a loud action from a network perspective. It triggers Intrusion Detection Systems very easily. If you want to avoid detection, you can leverage Shodan to see what ports are open and even gather information about the services that are running. That’s because Shodan continuously performs port scanning for you. You can simply type the IP or range of IP addresses you want, and it will give you the results. I recommend you read about the Shodan operators which are a must. For example, the following screenshot shows the top services running on the whole ASN number AS36647 owned by YAHOO. 

Bug bounty tools for Directory Bruteforcing

Directory bruteforcing allows you to discover hidden directories which are referenced neither in JavaScript files nor in Internet archives such as the Wayback Machine. There are many tools which perform such a task.   

ffuf

Currently, I’m using ffuf to perform directory bruteforcing. It is fast, reliable and capable of more than just looking for directories. The Readme file explains all the capabilities, but let’s focus on directories for now. 

In its simplest form, ffuf takes a wordlist and sends HTTP requests to your target application. The following command illustrates that:

ffuf -w wordlist.txt -u https://url.of.the.application/FUZZ

The term FUZZ is a special placeholder that ffuf uses to insert the elements of your wordlist.

Burp Suite Intruder

When I am analyzing a feature using BurpSuite, I find it practical to run the intruder to discover some endpoints without having to leave Burp. For that, I use the Intruder. The community edition offers only one thread, which is not useful in my opinion. However, the Pro version allows you to use as many threads as your machine can handle. This Intruder documentation from the authors of BurpSuite gives you all you need to start using this awesome tool.

Other directory bruteforcing tools

There are so many other tools that perform directory bruteforcing. Many bug bounty hunters use Gobusterdirsearchwfuzz or similar ones. You can experiment with all of them and choose the one that suits your goals and taste.

Bug bounty tools for Web application testing

Ok, now that you have a list of web applications, it’s time to focus on one of them and hunt for those bugs! However, without the proper tools, you won’t find any. Here are the main tools I use, and so you should. 

Burp Suite

This is the de facto when it comes to pentesting a web application. It is a suite of tools which assist you during your hacking. For example, it allows you to see all the HTTP requests and Websockets thanks to the Proxy tool. You can play with them with the Repeater tool to find security vulnerabilities. If you want to brute force a parameter, a header or anything in a request, the Intruder is your friend. BurpSuite supports extensions as well. You can code your own as I did with GWTab, or download many of them from the BApp Store using the Extender tool.

You can start using the Community Edition, which is free. If you want to benefit from the Scanner tool and some extensions, you can buy the Pro version and get a yearly license. You can earn a three-month license if you have a positive signal and 500 reputation points on HackerOne.

Learn how to download it, install it and configure it with this video I made just for you.

Zed Attack Proxy

ZAP is the free and open-source alternative to BurpSuite. It’s a flagship of the OWASP that can do almost all what Burp does, plus some more. For example, it offers the cool Heads Up Display (HUD) which allows you to use ZAP without leaving your web browser. It comes also in many packages, including docker, which makes it convenient for automated testing. Unlike BurpSuite Community Edition, Zaproxy allows you to run active scans. 

ZAP supports extensions as well, which you can download and update from the Marketplace included in its user interface. You can install it and configure it with this video. Besides, there is a great video on how to use ZAP, including how to use the HUD.

Conclusion

When you are doing bug bounty hunting or penetration testing, you will definitely use some of these tools I have just listed. If you are not familiar with them, take some time to learn how to use them and you will thank me later. However, while using the proper tools can play a key role in finding great bugs, it’s worth mentioning that they will never be a substitute for your brain. They exist to assist you, not replace you. That’s why it’s important to invest in your knowledge.

These are the tools I like to use when performing reconnaissance and subdomain enumeration. I hope you found this content helpful. Don’t forget to like, subscribe and share this content because it supports me to continue sharing such content.

As usual, stay curious, keep learning, and go find some bugs!

Hacking a Google Web Toolkit application

hacking a GWT application

Hello ethical hackers and bug bounty hunters! I’ve recently conducted a successful penetration testing against a web application built using Google Web Toolkit, and I want to share with you the process I followed and the bugs I found. Hopefully, this episode will inspire you to try harder during your own bug bounty hunting and penetration testing journey.

I will briefly explain what Google Web Toolkit is and what research has already been made around it. Then, I will explain why and how I built a Burp extension to help me during the penetration testing process. Finally, I will share with you some vulnerabilities I found, especially a cool one which required further effort. So stay with me as we smash this web application into pieces!

A brief introduction of Google Web Toolkit

Throughout this episode, I will use Google Web toolkit and GWT interchangeably. It is pronounced GWiT according to the official website.

What is Google Web Toolkit?

Throughout my career, I’ve encountered GWT applications two times only. It’s a relatively old technology, but it’s still used by some companies. According to the official GWT website, Google Web Toolkit is

[…] a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.

From the official GWT website

In other words, GWT allows developers to write web applications in Java, without having to worry about client-side technologies. In fact, it cross-compiles Java code into JavaScript ready to be used cross-browsers. 

How do Google Web Toolkit requests look like?

It’s easy to tell when you are in front of a GWT application. Typically, you will mostly see POST requests in your web proxy, with a series of strings separated with pipes. It seems intimidating at first, but when you understand how the POST data is structured, it’s fairly easy to spot what it does with a bit of practice. The following is the kind of data you will encounter in a typical GWT web applications.

GWT body example
GWT body example

Understanding the Google Web Toolkit body

I’ve built my knowledge upon this awesome article which explains the previous work that has been done, the GWT body structure and how you can enumerate the endpoints in such a technology. Although it doesn’t completely apply to recent versions, I still recommend you take some time to read it. However, if you still don’t want to manually analyze the requests, it’s possible to parse the GWT requests and pinpoint exactly where the user input is located thanks to a parser available on GitHub. Using this tool, the following command takes the GWT request body and returns the user input marked with the same highlight that BurpSuite uses in the Intruder tool.

GWT parser script highlighting user input similar to Burp Intruder
GWT parser script highlighting user input similar to Burp Intruder

Even with this, it’s impractical for me to manually copy the request body from BurpSuite and run the parser for each and every request. I think it would be great if BurpSuite automatically highlights the user input whenever it encounters a GWT request.

Writing my own Burp Extension for Google Web Toolkit

I have always wanted to write a BurpSuite extension, and this was the best opportunity for me to do so. In fact, I didn’t find any publicly available extension that would successfully parse this kind of requests. For example, the GWT Insertion Points is an extension which doesn’t seem to work, at least for me. It hasn’t been updated for 3 years. Moreover, ZAProxy supports scanning GWT requests, but it doesn’t support them during manual security testing.

The birth of GWTab

With the penetration testing schedule I had, I planned for one day to write the extension. Therefore, I had to keep it simple. The goal was to show a new tab in BurpSuite containing the user input for every GWT request. That way, I can significantly increase my efficiency by focusing only on the marked strings without having to manually run the parsing command. Hence, GWTab was born.

The process of writing GWTab

Writing GWTab involved three main actions:

  • Show a new tab in Burp: I used the custom editor tab template provided by BurpSuite, which gave me a quick start and let me focus on only the GWT feature I wanted to develop. 
  • Parse the GWT body: I used the parser I mentioned earlier. As I said, it can highlight the user input with the Burp Intruder’s marker, which is useful if I want to perform some automated fuzzing later, or even active scanning based on the highlighted input.
  • Extensive reading: I had to read parts of the Burp Extender API in order to properly understand the signature of the functions, the interfaces to use and what to implement.

After a lot of trial and error, I finally got it working! I made it available for everyone on GitHub. The following screenshot shows the new GWT tab containing the user input that I can focus on.

GWT body shown in directly in a Burp tab thanks to the GWTab extension
GWT body shown in directly in a Burp tab thanks to the GWTab extension

Limitations of GWTab

Some requests containing long values make the GWT parser crash. Therefore, GWTab will sometimes show the message “Parser Failed” whenever that happens. Unfortunately, I couldn’t invest more time to fix this issue on the parser.

Now that I can spot user input in most GWT requests on the fly, I was ready to start hunting for those juicy bugs!

Low hanging fruits

I found many low hanging vulnerabilities during this assessment because developers simply didn’t bother implementing any sort of proper access control.

Security through obscurity is a flaw by design

Because the GWT body seems complex, developers assume hackers won’t be able to understand and exploit it. I guess they ignore the very definition of a hacker. If you are a developer reading this, just know that curiosity and challenge are key drivers for a hacker. Besides, be aware that security through obscurity is a fundamentally false protection. It has only pushed hackers to dig even deeper. 

This application was no different. In fact, Broken Access Control and IDOR vulnerabilities were everywhere.

IDOR everywhere

Because of the false assumption I mentioned earlier, almost all endpoints were vulnerable to IDOR vulnerabilities. To make things worse, most requests use increasing numerical identifiers. Besides, it was easy to spot such IDs without even using GWTab since there was only one identifier per request. All I needed was a trained eye, which came naturally with practice. These vulnerable endpoints allowed me to access, edit and even delete resources of other accounts.

However, I want to share details about one bug which required more effort to fully exploit. I chose this one because I want to demonstrate why impact is critical and what techniques you can use to increase it.

Beyond trivial IDOR vulnerabilities

This application is a service exchange platform which allows its clients to offer and consume services. Therefore, if an attacker can delete arbitrary offers, it means that the whole purpose of the application is compromised. Guess what! I found just how to achieve that!

Vulnerability detection

Detecting this vulnerability was easy. In fact, I followed the same approach I mentioned in the video tutorial about Broken Access Control. In a nutshell, I used two separate accounts. Using the first account, I created an offer and triggered the request to delete it. Before deleting it though, I captured the request using BurpSuite and sent it to the Repeater, then dropped the request to preserve the offer. From there, I took the JSON Web Token of the attacking user and inserted it into the vulnerable request. When I sent it to the server, the victim’s offer got deleted.

Impact analysis

Looking at the POST data revealed a huge payload containing multiple objects, IDs and string values. As a bug bounty hunter, you would quickly report this bug right? Well, the impact is still not clear. In fact, I had no idea how an attacker can realistically build such POST data. If you have listened to read the episode about writing a good report, you know that impact plays a huge role in the bug bounty game. To prove the impact, I had to dig deeper into the application.

Exploiting the vulnerability

I first assumed that the server might delete the offer whose ID is present in the request. Therefore, I tried injecting the victim’s offer ID in all the potential inputs present in the POST data. I had to do it by hand since the GWTab extension failed at parsing the POST data. However, after many tries, it became obvious that this was not the right approach because nothing was deleted.

I didn’t want to give up so quickly. I knew that the application allowed users to search for offers of other users. What if I could grab the entire offer object from the results? Unfortunately, this idea failed since both objects didn’t fully match.

It was clear that I needed two requirements if I wanted to successfully exploit this vulnerability.

  • First, I needed a request which uses the same offer object structure.
  • Second, this dream request should be accessible to the attacker.

Based on these two requirements, I started looking through the application features for all the actions a user can perform on offers published by other users. After some time, I found that the user can like and unlike an offer. Lucky for me, the unlike operation uses the exact same offer object as the one used in the offer deletion request! I couldn’t believe my eyes, I was really lucky!

From there, the attack scenario became clear:

  • An attacker browses the offers list, which is public.
  • He/she likes the victim’s offer, then unlikes it.
  • He/she captures the offer object and injects it into the vulnerable request.
  • The victim’s offer gets deleted from the database.

Writing the report

Now that the impact is clear, you can finally and safely report that bug without worrying about rejection. Besides, you might even reduce the probability of getting duplicated since your vulnerability requires more effort to exploit, and not all bug bounty hunters are willing to take the extra steps. Moreover, even if the team accepts your not-so-convincing-impact report, the reward of a clear impact will certainly be much higher.

Conclusion

In the offensive security industry, whether you are a full-time penetration tester or a seasoned bug bounty hunter, curiosity and challenge are the fuel which will push your limits. In my case, I always wanted to write a Burp extension to solve a problem, and this application presented the right opportunity for me to challenge myself. Besides, I always seek ways to achieve the highest impact not only to get higher bounties but to give a better return on investment to my clients as well.

Later I found that the developers were already aware of this issue. However, because of the complexity of the POST data, they assumed that nobody would figure out how to successfully exploit the vulnerability. Thanks to this full exploit, they’ve learnt that they should never rely on obscurity…the hard way!

I hope you found this content useful. If you did, then support me by commenting, sharing and subscribing. Until next time, stay curious, keep learning and go find some bugs.

Bug bounty reports that stand out, how to write one?

how to write good bug bounty reports

Hello dear ethical hackers and welcome to this new article about bug bounty hunting. If you’ve been following along from the beginning, you have hopefully found at least one bug by now. If it’s the case, then congratulations! Now it’s time to report that bug right? Well, I have been working as a triage Analyst for more than a year, and trust me when I tell you that only few hunters master the art of writing good bug bounty reports. If you don’t give enough care and love when writing, be aware that it is a mandatory soft skill which brings you higher bounties. Every hunter should know how to write good bug bounty reports. And today, you will see how you can do just that!

By the end of this episode, I will share with you a bug bounty report template which you can use as a starting point. However, you can’t do much with it if you don’t understand the idea behind it. So make sure to stay with me to get the maximum out of this episode. 

Why you should write good bug bounty reports

A lot of the content on the internet teaches you the skills you need to find bugs. However, few talk about writing good reports. In this section, we will discover the benefits of quality bug bounty reports.

Good bug bounty reports speed up the triage process

To understand how good bug bounty reports speed the triage process, you have to put yourself in the place of the triage analysts. Everyday, they handle countless reports. If you write a poor bug bounty report, it will take him/her more time and effort to understand your bug, reproduce the steps and evaluate the impact. In contrast, if you communicate your bug in a structured way which clearly explains the reproduction steps and the impact, the triage analyst will quickly assess your bug bounty report. Therefore, you get a positive response as quickly as possible without having to bounce comments back and forth, with all the frustration that comes with it.

Quality bug bounty reports increase your rewards

Writing good bug bounty reports increases your rewards in three different ways. Firstly, it allows you to focus on finding new bugs because the team doesn’t have to request any further information regarding the reports you already submitted. Secondly, you might get a bonus if the bounty program’s team finds that your report helped them quickly and efficiently fix the issue. Finally, you might even bypass duplicates! In fact, many programs state in their policy that the first reproducible report is the one to be rewarded.

Great bug bounty reports give more value to your hacking skills

When you master the skill of communicating your findings in a clear and structured way, you add great value to your bug bounty reports. This comes handy when you want to show off your skills. In fact, you can simply reference your publicly disclosed reports in your CV. That way, you are giving a solid proof that you can not only find bugs, but also communicate them to developers in a manner which helps them quickly patch the vulnerabilities. Compared to other candidates, you will have much better chances of being hired.

Alright, now that you understand why writing good bug bounty reports is crucial in your career, let’s see how you can write one.

Your bug bounty reports structure

I’m sure you have done writing assignments at one point or another during your education at school. You certainly learned how important it is to structure your ideas into several sections. Well, writing your bug bounty report is no different. Don’t worry though, you will not have to write countless pages.

Structuring your content is your first key when you want to write good bug bounty reports. To achieve that, ask yourself one simple question: Is my report easy to follow? Then, read your report and be honest with yourself. If you spot any areas where the recipient might struggle with, try to enhance it. If you have no idea where to start, stick around until I give you a template that will make your life easier.

Besides, make sure that your report is well-formatted. Most of the major bug bounty platforms support Markdown, so make sure to learn how to use it. I’ve included an example at the end which should give you a quick start. Trust me, your report will look ugly and unprofessional when it merges raw HTTP requests, code snippets and your explanations without proper formatting.

Respect the scope

One big mistake most new bug bounty hunters make is failing to read the program’s policy, especially the part which details out of scope assets and known vulnerabilities. If you are one of them, pay close attention here.

When you report a bug, the first thing the triage analysts do is verifying if it is in-scope. In other words, they make sure that the asset and the vulnerability type are not listed as out of scope in the program’s policy. If it is out of scope, your report will be closed and you will lose your precious reputation and signal points. For those who don’t know why these are important, the higher they are, the more you are trusted. For example, on HackerOne, your reports will escape the Human-Augmented Signal step which typically captures reports with high noise probability. Therefore, your report will fall directly into the program’s inbox, saving you time. Besides, you will have higher chances of getting more interesting bug bounty program invitations.

So, make sure you double-check the program’s policy before investigating a potential bug.

Read the program policy before sending your bug bounty reports. These are out-of-scope vulnerabilities from Verizon media program
Read the program policy before sending your bug bounty reports. These are out-of-scope vulnerabilities from Verizon media program

Clear impact

A good bug bounty report is nothing without a clear impact statement. This is where you stand your best chances to increase your bounty. Take the time to clearly explain how bad your bug can affect the security of the asset you are targeting. For example, if you can list the content of an S3 bucket, make sure to check if there is any sensitive data. If it does, you should mention it explicitly. Most of the time, the program’s team will realize how bad it is. This is better than just telling reporting that you can list the bucket’s content, especially if it contains mostly static files. Another example is when you find a potential subdomain takeover. You should first claim the subdomain before even thinking of reporting the bug. If you can’t, it’s probably not possible to claim it.

Support your report

When you support your report with additional material, it becomes even easier for others to reproduce your steps and properly evaluate the impact. You can achieve this using different ways.

HTTP request and response

When you find a vulnerability involving HTTP traffic, make sure you include both the vulnerable request and the expected response. However, avoid pasting big content. The most important parts of the HTTP request are the first line and the vulnerable parameter. Don’t forget to properly format your report as explained earlier. To do that, put the HTTP requests inside a code block using Markdown to visually separate it from the rest of your explanations.

Screenshots

Screenshots can be useful in many ways. Sometimes, the user interface can be full of buttons, forms and menus. In this case, it is good to share screenshots pointing the vulnerable area. Other times, you might want to share proof that you have successfully exploited the vulnerability. For example, you can share a screenshot demonstrating your ability to exfiltrate internal files.  

When to share a video?

Sometimes, the reproduction of the bug requires a lot of complicated steps. In this case, the best thing you can do is to include a video. Try to make it short, straight to the point. If you can speak while demonstrating the exploitation steps, it’s even better.

Maintain a professional attitude

Although writing good bug bounty reports reduces time to triage, you might still encounter some hurdles during the report’s lifetime. For example, I once reported a bug which wasn’t reproducible on the triage analyst end. After some comments back and forth, the triage analyst closed the report as Not Applicable. For those of you who are not familiar with the HackerOne report states, this is the worst case after Spam reports and it significantly reduces your reputation. Instead of swearing and yelling at him, I wrote a professional answer and attached a video proof. After further investigation, he found that our environments were not configured the same way, which explained why he wasn’t able to reproduce the bug. Then, he reopened my report and triaged it.

You must think well of others and preserve a professional attitude when you communicate with the triage analysts or the program’s team. At the end, we are all humans and we make mistakes.

Your report template

In this section, I will share with you the template I use for all my bug bounty reports and how I write the content. So far, all the teams I have worked with have positive feedback regarding the quality of such a template.

Title of the bug bounty report

I always give my title the best care. It’s the first contact with the triage team and it plays a critical role in putting their minds in the correct context. I always avoid generic titles which don’t give any clue whatsoever. Remember that you should make their life easier and speed up the triage process. Let’s assume that I found a cross-site scripting vulnerability. Well, I make sure to include the type, the vulnerable asset, the target endpoint and the weak parameter. Your title should look like this:

Reflected Cross-site Scripting on xyz.com on the xyz endpoint in the xyz parameter.

This title will condition the triage analyst’s mind and quickly give him/her an idea of what this report is all about in only one sentence.

The summary section

This is where you write a short paragraph describing the vulnerable feature and how it is vulnerable. You have to do this because, on the one hand, the triage analyst is not necessarily familiar with the application. On the other hand, it is a great introduction to the reproduction steps which come next.

Sometimes, the vulnerability can be complex enough to be summarized in one short paragraph. In this case, you can still preserve the summary section and add a description section which explains more technical details about the vulnerability. The reason behind preserving both the summary and the description is that the triage analyst can quickly look at the summary. If he or she would like to know more, the description part will serve the need.

Steps to reproduce

In this section, you should pay close attention to the details. You have to make sure that you can reproduce the steps yourself based on what you’ve written. Always include HTTP requests as explained earlier to support your steps and don’t forget to verify that they are well formatted.

The steps should give a clear and easy-to-follow walkthrough that anyone can reproduce. If you have used a script, make sure to include it as well. If you feel a screenshot is needed, embed it using Markdown instead of just uploading it. It makes your reproduction steps pretty and easy to read.

Impact

This is where you explain why your bug deserves the biggest bounty possible. Take your time to come up with the highest impact and communicate it well in this section.

Mitigation

This is optional, but if you have a suggestion to fix the issue, you can add it in this section. For example, if you have already done your analysis and found exactly where the problem lies, it would be a plus to include a mitigation paragraph. Who knows, you might get a bonus if you save the team countless hours of debugging and root cause analysis.

Below is the bug bounty report template with the Markdown code, followed by a screenshot of how it looks like on HackerOne.

## Summary:
An introduction to the application's feature and your vulnerability.

## Description:
In-depth technical details in case the bug is complex.

## Steps to Reproduce:
1. Step 1
1. Step 2

```
Raw HTTP request and response goes here
```

## Supporting Material:
Screenshots, video

```
script you have used goes here
```
## Impact
Clearly explain how the vulnerability affects the system

## Mitigation
A bonus if you want to explain how to fix the vulnerability
Bug bounty report template
Bug bounty report template preview on HackerOne

Conclusion

Writing good bug bounty reports is a rare skill. If you master it, you will notice that your experience in reporting your bugs is smoother than before. As you saw in this episode, it’s no magic! You just have to put yourself in the shoes of the recipient and maintain a professional attitude. Besides, with the template I shared with you, you already have a solid structure to start with.

I hope this episode was helpful to you. I encourage you to like and share it. If you’re not subscribed yet, join us to get updates whenever I publish new content. The newsletter is on your right. Until then, stay curious, keep learning and go find some bugs!

My bug bounty methodology and how I approach a target

my bug bounty methodology

Last time, I showed you the best resources I use to stay up to date in bug bounty hunting. Today, I will share with you my bug bounty methodology when I approach a target for the first time. This is going to be divided into several sections. First, I will show how I choose a bug bounty program. Then, I will dive into how I enumerate the assets. From there, I will explain how I pick a web application and how I test it. Finally, I will evaluate this bug bounty methodology by enumerating its pros and cons so that you know exactly what to expect from it. There are plenty of bug bounty tips and tricks along the way, so make sure to stick around until the end.

How I choose a bug bounty program

When I first started hacking, Hacker101 didn’t exist yet. I had to work on public programs which were tough to crack. In fact, there is simply a lot of competition on those programs with the level of expertise I had. Luckily, you don’t have to struggle as before. If you’ve seen my previous episodes, you have probably earned your first 26 points on Hacker101 by now and got your first private invite from a bug bounty program. If you haven’t done it yet, then you’re probably starting your bug bounty hunting journey on the wrong foot.

Anyways, let’s assume you have received some private invitations. How would you choose between them? What program would you pick to start hunting for bugs? On HackerOne where I primarily hunt for bugs, I choose a program based on key metrics shown to me during the invitation process.

HackerOne program displaying some metrics of its bug bounty program
HackerOne program displaying some metrics of its bug bounty program

Program launch date

First, I see where the bug bounty program was launched to have an idea of how old the program is. This tells me whether I should spend some time on low hanging fruits or dig deeper during my testing, because, unless there are new assets, most of the easy bugs would have already been found in an old program.

Program responsiveness

The second thing I look for is the response posture. In short, I see what is the average time to resolve a security issue. If the program takes a lot of time to resolve security issues, it means that there is a higher chance of getting duplicates. Usually, all other response metrics, such as time to first response, time to triage and time to bounty are lower than the resolution time, so the shorter it is, the better.
You can also see the percentage of the reports which have met those response metrics. If it is above 90%, I’d probably accept the invitation if the rest of the metrics is ok.

The scope of the bug bounty program

I usually prefer bigger scopes. For example, I would prefer wildcard domains over a single web application. It reduces competition because there is enough room to play with different assets, and it makes the target less boring. However, I might accept a program with a small scope program if they have a great response time or good rewards.

Bug bounty rewards

This is another criteria I look for. If I am investing my time looking for security bugs, I would like to have a bigger return on my investment. So I would prefer higher paying bug bounty programs. I usually avoid programs with no rewards not only because of money, but also because the reputation you get is significantly lower.

The business of the company

If all the previous metrics look good to me, I still have to check if the company’s business matches my values. If it doesn’t, I simply reject the invitation.

Alright, now that I have chosen the bug bounty program, how do I approach it? Well, I start with a light subdomain enumeration to gauge the public presence of the bug bounty program and quickly find something to work on. I used to do thorough enumeration, but I realized that it takes considerable time. Because this is my first interaction with the target, I feel it’s a bit early to perform a heavy enumeration.

What does my bug bounty methodology look like for subdomain enumeration?

I start my subdomain enumeration with Tomnomnom’s assetfinder tool. The command is straightforward, you just provide your in-scope wildcard domain name.

assetfinder --subs-only domain.name

The thing I love about this tool is that it’s blazingly fast! It provides me with a quick idea of the subdomains naming convention and gives me initial assets to work on.
I always avoid brute force at this stage. On the one hand, it takes more time which I prefer to invest in the next steps. On the other hand, I like to increase my success rate by bruteforcing with a custom wordlist tailored just for this domain.

Bug bounty methodology to enumerate web applications

Now that I have a list of assets, I filter only web applications using Tomnomnom’s httprobe. For now, all I’m interested in are ports 80 and 443. The command is again easy to run:

cat domains | httprobe

As a side note, if the program is new, I would probably use Shodan or perform a port scan using masscan to see if any web applications are running on non-standard open ports. These are ports greater than 1024.
Lastly, I run aquatone to screenshot the list of live web applications. There are two reasons I do that. On the one hand, I will be able to quickly spot any visual deviation from the common user interface. On the other hand, I will get a bird’s eye view of the different web application categories and technologies. This is possible because aquatone groups similar user interfaces together and displays the web applications’ technologies in the HTML results.

My bug bounty methodology when choosing a web application

Hopefully, I now have some web applications to choose from. I tend to choose the one which deviates from the herd. For example, if all web applications implement a centralized Single Sign-on authentication mechanism, I would look for any directly accessible asset. If I spot a user interface of common software such as monitoring tools, or known Content Management Systems, I would target them first. Another example is when the application discloses the name and the version of the software being used. In this case, I look online for any available exploits. If I am lucky, I might get easy issues to report.

For the other custom-made web applications, I will generally choose the one whose user interface deviates from the common company’s theme. If I don’t find one, I might repeat my previous steps with deeper enumeration. For instance, I would take the subdomains I found earlier and combine them with the name of the company to generate a custom wordlist. Then, I’d use tools like OWASP amass and brute force the subdomains using the wordlist I constructed.

How I approach a web application

Finally, the time comes for actually engaging with the web application and looking for security bugs. You must reduce the time between your first interaction with the program and this phase. Otherwise, you will be wasting your time doing only recon. In this phase, my bug bounty methodology consists of enumerating as much as possible to draw the largest attack surface possible.

Mapping the application features

This is where I open up my web browser and use the application as a normal user. If there is a signup feature, I create a user and I login. Then, I make sure to visit every tab, click on every link, fill up every form. If it’s an e-commerce website, I create an order using a fake credit card. Meanwhile, I’m capturing all the traffic with Burp.

It’s always tempting to switch between my web browser and Burp, but I find it distracting. Therefore, I do my best to focus on understanding the business features and making note of the interesting ones. For instance, I always look for file uploads, data export, rich text editors, etc.

Understanding the main application architecture and defense mechanisms

This is where I revise my Burp traffic to answer specific questions. How authentication is made? Does the application use a third-party for that? Is there any OAuth flow? Is there any CSRF protection? If yes, how is it implemented? Are there any resources referenced using numerical identifiers? If yes, is there any protection against IDOR vulnerabilities? Does the application use any API? How does the application fetch data? Does it use a front-end Framework? What JavaScript files contain calls to the API? Does it use a back-end Framework? If yes, what is it and which version is being used?

These are the kinds of questions I try to answer when I first interact with a web application. Having a clear idea of the architecture and the defense mechanisms help me make a better plan of attack. I might also find weaknesses right away, which are generally application-wide and have a high impact.

JavaScript enumeration

Whenever I have the opportunity to read some code, I make sure to do so. Since JavaScript files power the client-side of the web application, I like to collect and analyze them. I found many hidden endpoints, Cross-site scripting and broken access control vulnerabilities this way. Using tools like LinkFinder, I collect URLs which I cross-reference with the endpoints I have collected from the mapping exercise. Sometimes, I do it the other way around. In other words, I look for API endpoints in JavaScript files using the naming convention of the endpoints I have in Burp. This allows me to save all the API endpoints into a file. It becomes handy when I want to implement some automation to detect when the developers add new endpoints to the application.

Focusing on one feature at a time

This is where it starts to get really interesting! By now, I am comfortable navigating around and using the application normally, I understand most features. If you quit before this phase and jump to another asset or another totally different program, you will have lost all the time you have invested learning how the application works. In this step, I’m trying to focus on one feature at a time. My goal is to learn the flow in detail, tinker with every user input based on my assumptions. For instance, if the request seems to be fetching data from a database, I would try SQL injection. If the user input gets returned, I will try Cross-Site Scripting. It all depends on your experience, but a solid start would be the OWASP Top 10, which I already covered in much detail in a hands-on training.

Pros and cons of this bug bounty methodology

This bug bounty methodology is powerful in many ways. However, by no means this is the perfect one. It has its limitations as well.

Pros of this bug bounty methodology

Here are the pros of this methodology.

  • Simple and minimal: It is a simple approach which requires minimal tools to yield the best initial results.
  • Speed: One of the best things I love when following this bug bounty methodology is the speed it provides. I can get a general view of the entire program in less than an hour. If the program is big, it takes just a few hours.
  • Low hanging bugs: Using this approach, you can easily find low hanging fruits if the program is new. It doesn’t require a lot of digging and effort. And if the program is old, you can still get a general idea of the company’s cyber presence.

Cons of this bug bounty methodology

These are the limitations of this approach.

  • It doesn’t cover the road less traveled: Because I’m using well-known tools with the default options, without any great deal of deep digging, I don’t expect to stumble upon a hidden asset or a less traveled road. That’s ok for me at this stage because this is my first interaction with the program. Usually, you won’t find easy bugs with it.
  • It doesn’t cover programs with IP ranges: If there is a program which has IP ranges in scope, this methodology wouldn’t work 100%. You need to still perform a port scan, which you can easily do with masscan.

Conclusion

There you have it! An end-to-end bug bounty methodology that you can use when you interact with a program for the first time. Rather than spending a lot of time doing extensive recon upfront, I find it more efficient to first assess the program’s IT infrastructure while focusing on one or two web applications.

I’d love to hear your thoughts and opinions on this bug bounty methodology. If you have any ideas on how to improve it, I encourage you to leave a comment describing how to do it. If you follow a different methodology, I’d love to know how you approach your bug bounty programs.

I hope you found this episode helpful. If you did, then I’d appreciate you liking and sharing it. If you’re not subscribed yet, join us to get updates whenever I publish new content. You’ll find all the social links in the description. Until then, stay curious, keep learning and go find some bugs!

The top 9 bug bounty resources to stay up to date

top bug bounty resources to stay up to date

Last time we talked about how bad habits lead to burnout. In this episode, we will explore the best bug bounty resources and how you can properly use them to efficiently stay up to date. Some are robust resources provided by the bug bounty platforms and the community. Others are general websites which you can customize to fit your bug bounty needs.

Why and how should you stay up to date in bug bounty hunting?

I can’t stress it enough, but staying up to date is essential in this career. As we saw in the first episode where we discussed the bug bounty ecosystem, the community here is so active! Every day, it produces new tools, discloses new reports, publishes new videos, tweets about all kinds of bug bounty tips, and the list goes on and on forever.

It’s easy to get lost in the huge amount of information. That’s why it’s important to be strategic in your choices. The idea is to maximize your return on the time you invest. Besides, you should pick the channels that suit your taste. Some prefer to engage in forums, others like to use social networks, while other bug bounty hunters combine them all. It all depends on your favourite style of learning.

Hacktivity is your first bug bounty resource

What’s better than reading findings of other bug bounty hunters? They can teach you a lot in one shot. Firstly, you learn how to practically exploit a vulnerability. Secondly, you understand the hacker’s thinking process. Finally, you get to know how to write a good report. Well, this is all possible thanks to Hackerone’s Hacktivity.

What is Hacktivity?

This awesome feature allows the bug bounty hunter and the hacked program to agree on disclosing the report to the public. When they do, the report automatically gets published on Hacktivity. You can sort them by popularity or age, filter them or search through them using keywords. You can even vote for the reports you like to increase their popularity!

The Hacktivity is a great bug bounty resource
The Hacktivity is a great bug bounty resource

How do I use Hacktivity?

By default, Hacktivity shows you all popular disclosed reports, which are not necessarily the latest. That’s why you can sort by age to see the latest reports first. However, this can result in irrelevant reports.

If I’m looking for inspiration, I search for specific keywords, like SQL injection or Sensitive data exposure. When I find a great report, I usually follow the bug bounty hunter. Next time I use Hacktivity, I sort the reports by age and filter only the hackers I follow to see just the new best reports. This will reduce the noise significantly.

Bug bounty resources for real-time interactions between hackers

If you feel alone when you hunt for bugs, one of the great ways to get updates and combat loneliness is to engage with the bug bounty community. There are many ways you can do that.

For instance, the Hacker101 Discord server allows you to connect in real-time with nearly two thousand active members in the bug bounty community. You can ask questions, read new posts, chat with specific bug bounty hunters, and many more. The topics are not restricted to bug bounty hunting only but cover hacking in general. Who knows, you might find your hacking buddy there!

You can find many bug bounty resources and meet hackers on the Hacker101 Discord
You can find many bug bounty resources and meet hackers on the Hacker101 Discord

Another place you can engage with the bug bounty community is Bugcrowd’s forum. If you enjoy learning and interacting using forums, this one is full of bug bounty topics. From how to get started to how to report a bug, it’s all there!

Bugcrowd's forum is full of bug bounty resources
Bugcrowd’s forum is full of bug bounty resources

Turning Twitter into a Bug bounty resource

Although I’m not a big fan of social networks, I use Twitter every day. That’s because I think most of the bug bounty community is active there. When I first started using Twitter, I followed big names in bug bounties and my feed got flooded with tweets. However, most of them were noise and I realized that I’m spending too much time and effort reading irrelevant tweets.

If you are struggling as I did, I got you covered! First, unfollow all the accounts which generate noise. Then, create a list where you add only the tweets related to bug bounty tips. There are many bots which collect tweets based on such hashtags. For instance, I am using @TheBugBot. Finally, add blacklist expressions to filter out any patterns of irrelevant tweets which you don’t find interesting. For example, Hackerone allows you to tweet about your bounties when you get one. They use a pattern like “Yay! I was awarded X amount of money”. So I just blacklist the expression “Yay! I was awarded”.

The Bug Bot collects bug bounty resources into a single feed
The Bug Bot collects bug bounty resources into a single feed

Bug bounty newsletters are great resources

If you get overwhelmed with online discussion spaces and forums, you might prefer subscribing to newsletters instead and receive updates about bug bounty content directly to your email inbox. Rest assured, the community has your back here as well.

For example, the Pentester Land’s newsletter is one of the best newsletters in the bug bounty world! It sends you a weekly curated list of the best bug bounty content. I recommend you give it a try and take your time reading most of the content you receive. Trust me when I tell you that it’s worth it!

If you want to see through the eyes of a bug bounty hunter, you can also subscribe to thehackerish newsletter and get updates about bug bounty related topics from my humble experience.

Bug bounty resources for practice

Reading bug bounty content is good, but developing new skills through practice is far better. After all, you can’t find a security flaw in a bug bounty program without knowing how to practically exploit them. Guess what, the community shines in this area as well!

Portswigger Academy as a bug bounty resource

This online learning platform is a gold mine for every bug bounty hunter! Developed by the creators of the famous BurpSuite web proxy, it teaches you security vulnerabilities and bug bounty step by step, both in theory and practice. The best part is that it’s free!

If you want to learn a new security vulnerability, make sure to check if they have it there first. You will thank me later.

The great Hacker101 bug bounty resource

There are many online hacking platforms, which we will explore on another occasion. However, the most relevant in the context of this episode is the Hacker101 platform. In fact, it’s a great bug bounty training resource which offers great bug bounty tutorials in the form of videos, as well as a free playground for hackers to practice their skills. The idea is simple, you solve challenges and collect points based on the level of difficulty. When you accumulate a certain number of points, you earn a private invite from a bug bounty program. This is your best go-to if you’re wondering how to start bug bounty in Hackerone.

PentesterLab membership

If you’d like to invest in yourself, PentesterLab is a great bug bounty resource. In fact, it’s a membership platform which teaches you hacking skills through pragmatic bug bounty-like challenges. There are some free topics which you can learn from. However, the Pro version provides you with ready-to-use labs and more interesting bug bounty tips.

Conclusion

As you might have noticed, there are so many bug bounty resources you can choose from to stay at the edge of your career and continue to find meaningful bugs. I’m sure there are other resources, but I feel these are the most important ones in my opinion.

If you use other interesting bug bounty resources and you’d like to share them with the community, feel free to drop a comment. I’ll make sure to include them in my next episode. Until then, stay curious, keep learning, and go find some bugs!