From Bug Hunter to Pentester: Exploring the differences between these two careers

In the following blog, I will talk about how I transitioned from a Bug Bounty Hunter to a Pentester. We will be exploring the differences and sharing insights into how one can shift their mindset from Bug Hunter to Pentester.

It’s important to note that this content is intended to be an objective comparison. I participate in both bug hunting and pentesting. These professions have individual pros/cons that add value to the security industry as a whole. I’ve met bug hunters who say that they are interested in getting into pentesting, but they keep a bug hunter mindset and struggle to excel in the pentesting arena. The purpose of this blog is to simply examine the differences in the two mindsets. By doing so, this resource can aid individuals that are interested in moving into pentesting.

Before diving into the differences between Bug Bounty and pentesting, I first wanted to start by providing some background on my offensive security journey.

It all started when one of my best friends introduced me to the Metasploit Series of SecurityTube.net back in 2012. Although I didn’t initially grasp all the technical details. After looking into a few videos, I began to grasp the number of possibilities surrounding the world of information security. And after looking at more security blogs and resources, I was encouraged to look more into Cryptography – this led me to take a Cryptography course at Stanford University via Coursera. Although I struggled at first, I kept reading and learned about the Web Application Hacker’s Handbook. After reading just a few chapters, I found myself engaged in the material. It was at that moment that I realized web application security (specifically pentesting) was something I wanted to explore more. I liked that web applications are things that we use in our daily lives, compared to advanced concepts like Cryptography, Binary Exploitation, etc.

In early 2014, responsible disclosure programs were on the rise. Most of them had web applications in their scope. So, I started testing my newly developed web security skills on those programs. It was a great experience that included a lot of rewards (money and swag) for finding interesting vulnerabilities. As I progressed, I started focusing more on private bounty programs and was able to get into the Top 10 on popular Bug Bounty Platforms—all while attending university. By mid-2016, I had completed my university degree and started working as a full-time Bug Hunter till mid-2018. This was a rewarding experience; however, I soon started to realize that this was not my long-term career path. I was looking for my next challenge and a little more job security, and that's when I started looking into pentesting.

In 2018, I got my first full-time pentesting job. I had become a member of the amazing Cobalt Core. At this point, I knew how to find vulnerabilities and write findings reports, but was less familiar with how to write an executive summary or participate in a multi-team member environment. After continually building knowledge through the help of my teammates’ guidance and honing my leadership skills, I was able to complete 250+ pentests over the past three years (on Cobalt and in my full-time job). This led to me becoming a Pentest Lead for the Core. Currently, I have a full-time pentesting job, I participate in freelance pentesting, and participate in a few bug bounty programs when time allows.

Exploring the Differences

In the next section, we’ll walk through some of the major differences I have encountered when transitioning from a Bug Bounty Hunter to a Pentester.

Open vs Closed Programs

One key difference between bug bounty and pentesting is the nature of the program. In this case, it comes down to two types: open and closed.

Bug Bounty Hunter: The programs are generally more open in nature. This means that their accessibility can be available to anyone from anywhere. So, any bug hunter has the freedom to come in and find vulnerabilities in their applications.

Pentester: A pentest implements restrictions (such as testing only from VPN, testing to occur only in specific hours, and location restrictions) which are listed out with the specific constraints, NDA, and any withholding of sensitive information in the agreement contract between the pentester and customer. This gives the pentester a clear understanding that while they may be able to talk about some of their findings in an anonymized way, they cannot disclose any specific information about the pentest, such as company names. For a bug bounty hunter with public bug bounty programs experience, these constraints might feel cumbersome but it is very important that these are followed in a strict manner for a pentest engagement. Although these restrictions also allow you to get creative within certain parameters, it is important that these are followed in a strict manner for a proper pentest engagement.

Vulnerability Reports

A Bug Bounty Hunter is required to submit a report in order to get rewarded. However, the requirements and make up of these reports differ from pentesting reports. For Bug Hunters you can submit a basic report for example: “I have found XSS on this URL and below is the screenshot” and receive a payout. In a pentest, you are required to add a lot more detailed information for vulnerability reports. At Cobalt, we report on the following sections for each finding:

Summary: Cobalt does a really good job here. Considering, they provide templates based on the finding type selected at the start. It is still important to read the template and modify it if changes are needed, sometimes template content doesn’t match exactly to the type of finding identified.

It is also essential to describe more in your own words after the template. For example, suppose you found a privilege escalation vulnerability in “Users” functionality. Then you can add text like “It was identified that “users” functionality is missing access control, due to which a low privilege user with “Viewer” role can add/modify/delete users in the tenant which only Higher Privilege users should be able to do.”

The golden rule here is to assume that the person reading the report doesn’t have a good understanding of security vulnerabilities. For example, it is common that software engineers/developers will be the individuals reading these reports.

Proof of Concept: I would say this is the most important portion of any finding. This section demonstrates both the technical and communication (report writing) skills of a pentester. I would recommend being as thorough as possible in each step and try to provide concise and cropped screenshots (screenshots of your entire screen doesn’t usually look as professional). Highlight and focus on the relevant information in each screenshot. I have also found that including a video for the complex findings, where there are multiple or intricate steps involved, can be extremely helpful.

In order to clearly convey the process of your findings, incorporate short repeatable steps along with concise and cropped screenshots for each step to demonstrate both the technical depth and effective communication of a pentester.

Criticality: This is a section where you should describe the possible impact of the vulnerability to the application in scope or to the organization. If you would like to increase the vulnerability by chaining vulnerabilities, then this is the area to mention those details. For example, there is an IDOR in the application where you can change the “Last Name” of every user on the application. Now if you identified an XSS on the “Profile” page where “Last Name” input fields inputs are reflected directly. Now in the criticality section, you can mention that since there is an IDOR in the application, this XSS can be used to trigger malicious javascript payload in every user account.

Remediation: Again, assume that the person who is reading the remediation advice has never fixed a security vulnerability. Try to be as thorough as possible and try to give proper references like OWASP.

Read more details on what should go into a vulnerability report.

Collaboration and Communication

How offensive security professionals collaborate is a key differentiator between bug hunters and pentesters. Let's take a look at those differences by exploring how individuals collaborate with customers and teammates.

Collaboration with the Customer:

Bug Hunter: When you are a bug hunter, communication with the customer is limited. This means that it can be easier to avoid unwanted conversations, but it also gives you less access to valuable information that could lead to more interesting findings and professional growth.

Pentester: During a pentest, customer communication is key. Each customer collaborates in their own way, but in the end you need to work with them to ensure complete scope coverage. During Cobalt pentests, the Customer Success team works to ensure alignment on expectations which contributes greatly to positive pentest collaboration. However, as a pentester you need to also do your part in being responsive, empathetic, and supportive during the engagement and remediation process.

Collaboration with Teammates :

Bug Hunter: You are a lone wolf during the entirety of the engagement, and you must rely on your own expertise.

Pentester: In a pentest, you will collaborate with your pentest teammates, collectively working together to find vulnerabilities. Each Core member brings their own unique skill sets to the table allowing you to divide and conquer. You are able to leverage one another to think about things in different ways and tag-team off of findings. Any bug hunter or pentester will agree that any one person cannot be the master of each vulnerability type (which we will talk more about below). When doing a pentest for Cobalt, collaboration is an effective way to get the best results. Never hesitate to reach out to other team members, everyone here is happy to help in their best capability.

Team Updates

This might seem like a completely new thing for a bug bounty hunter, as team updates are not required for bug bounty programs. However, updates play a very important role during a pentest engagement. Cobalt requires team updates from each pentester and they are pivotal in providing insight to the different parties involved in the pentest process:

Customer: On a Slack channel, updates can give customers a complete idea of what assets and vulnerability types that are being covered. These detailed team updates provide essential information, especially during a particularly tough application pentest. This gives assurance to the customer that the application is being properly tested and that the pentester may have not found many vulnerabilities because the application was built from a security-in-depth perspective.

Pentest Teammates: With the team updates, your pentester colleagues will get to know what areas of the scope you have covered, so that they can properly delegate certain vulnerabilities, and focus on other areas that match their own strengths. Also, sometimes observations made by other pentesters can be used to escalate that observation into a vulnerability.

Cobalt Team: Pentester Team updates give the rest of the Cobalt team an overall picture of how you are approaching the scope and this can showcase your professional skills as a pentester. Also, if any questions or issues arise, the Cobalt Team is always there to help.

Coverage: Breadth vs Depth

As offensive security professionals, our vulnerability knowledge can range from focusing on one specific vulnerability to familiarity on a range of different types. But when it comes to bug hunters and pentesters there are some differences, let’s take a look:

Bug Hunter: As a bug bounty hunter, you can harness your skills by strictly focusing on specific vulnerability types (such as Access Control, XSS, SSRF, SQL Injection, etc).

Pentester: A pentester is expected to look for each type of vulnerability in the application in order to offer coverage during an engagement. Hence, the breadth of coverage is more important in a pentest rather than spending most of the allotted time on a specific vulnerability. It is essential to find as many vulnerabilities as possible in the application and ensure that contracted hours are completely utilized. In a pentest, you often work with other pentesters, and that allows you to divide the vulnerabilities/test cases with your teammates. Pentesters provide coverage which is essential in fulfilling the security compliance requirements and aid in avoiding future chains of vulnerabilities.

Fixed Reward vs Variable Income

When it comes to bug hunter vs pentester, one of the most notable differences comes from how you are compensated.

Bug Hunter: As a bug hunter you are paid for what you find and you are racing against others to find vulnerabilities first. A hunter can encounter stress due to several reasons, such as the chances of duplication in identifying the same findings, late payouts, tough targets, and others. For those who are working in bug bounty full-time the amount of stress can be even more present because that is their main source of income. And there is no certainty that you will get paid.

Pentester: On the other hand, a pentester is paid a set amount that is established before initiating any testing. There is no stress or uncertainty around whether you will be compensated for your work because you agree on that before the engagement begins.

Final Takeaways

Bug Hunter and pentesting both are valuable and important in the cybersecurity space, and it is important to note that they require different mindsets. When it comes to pentesting the engagement is not just about finding issues but also communicating and collaborating with others. It’s not about you working on your own solo finding bugs. It’s about working with customers to ensure that they are getting the most from their engagement and that they understand the issues that arise. It’s also about working with other pentesters to ensure coverage and find more interesting vulnerabilities.

Remember when it comes to pentesting:

• Good reporting is not a-nice-to-have, it’s a necessity.
• Communication, whether with your pentesting peers or the customer, is a valuable resource. Don’t silo yourself, work collaboratively.
• Provide proper coverage, don’t spend all your time on only one vulnerability type.

Thanks for reading, and hope you enjoyed this article! I orginially wrote about this topic on US Cybersecurity Magazine. You can find that article here.