Even if you understand the technical information in this book, you may have difficulty navigating the nuances of bug bounty programs. Or you might be struggling to actually locate legitimate bugs and aren’t sure why you’re stuck. In this chapter, we’ll explore some of the factors that go into making a successful bug bounty hunter. We’ll cover how to write a report that properly describes your findings to the security team, build lasting relationships with the organizations you work with, and overcome obstacles during your search for bugs.

Writing a Good Report

A bug bounty hunter’s job isn’t just finding vulnerabilities; it’s also explaining them to the organization’s security team. If you provide a well-written report, you’ll help the team you’re working with reproduce the exploit, assign it to the appropriate internal engineering team, and fix the issue faster. The faster a vulnerability is fixed, the less likely malicious hackers are to exploit it. In this section, I’ll break down the components of a good vulnerability report and introduce some tips and tricks I’ve learned along the way.

Step 1: Craft a Descriptive Title

The first part of a great vulnerability report is always a descriptive title. Aim for a title that sums up the issue in one sentence. Ideally, it should allow the security team to immediately get an idea of what the vulnerability is, where it occurred, and its potential severity. To do so, it should answer the following questions: What is the vulnerability you’ve found? Is it an instance of a well-known vulnerability type, such as IDOR or XSS? Where did you find it on the target application?

For example, instead of a report title like “IDOR on a Critical Endpoint,” use one like “IDOR on https://example.com/change_password Leads to Account Takeover for All Users.” Your goal is to give the security engineer reading your report a good idea of the content you’ll discuss in the rest of it.

Step 2: Provide a Clear Summary

Next, provide a report summary. This section includes all the relevant details you weren’t able to communicate in the title, like the HTTP request parameters used for the attack, how you found it, and so on.

Here’s an example of an effective report summary:

The https://example.com/change_password endpoint takes two POST body parameters: user_id and new_password. A POST request to this endpoint would change the password of user user_id to new_password. This endpoint is not validating the user_id parameter, and as a result, any user can change anyone else’s password by manipulating the user_id parameter.

A good report summary is clear and concise. It contains all the information needed to understand a vulnerability, including what the bug is, where the bug is found, and what an attacker can do when it’s exploited.

Step 3: Include a Severity Assessment

Your report should also include an honest assessment of the bug’s severity. In addition to working with you to fix vulnerabilities, security teams have other responsibilities to tend to. Including a severity assessment will help them prioritize which vulnerabilities to fix first, and ensure that they take care of critical vulnerabilities right away.

You could use the following scale to communicate severity:

Low severity

The bug doesn’t have the potential to cause a lot of damage. For example, an open redirect that can be used only for phishing is a low-severity bug.

Medium severity

The bug impacts users or the organization in a moderate way, or is a high-severity issue that’s difficult for a malicious hacker to exploit. The security team should focus on high- and critical-severity bugs first. For example, a cross-site request forgery (CSRF) on a sensitive action such as password change is often considered a medium-severity issue.

High severity

The bug impacts a large number of users, and its consequences can be disastrous for these users. The security team should fix a high-security bug as soon as possible. For example, an open redirect that can be used to steal OAuth tokens is a high-severity bug.

Critical severity

The bug impacts a majority of the user base or endangers the organization’s core infrastructure. The security team should fix a critical-severity bug right away. For example, a SQL injection leading to remote code execution (RCE) on the production server will be considered a critical issue.

Study the Common Vulnerability Scoring System (CVSS) at https://www.first.org/cvss/ for a general idea of how critical each type of vulnerability is. The CVSS scale takes into account factors such as how a vulnerability impacts an organization, how hard the vulnerability is to exploit, and whether the vulnerability requires any special privileges or user interaction to exploit.

Then, try to imagine what your client company cares about, and which vulnerabilities would present the biggest business impact. Customize your assessment to fit the client’s business priorities. For example, a dating site might find a bug that exposes a user’s birth date as inconsequential, since a user’s age is already public information on the site, while a job search site might find a similar bug significant, because an applicant’s age should be confidential in the job search process. On the other hand, leaks of users’ banking information are almost always considered a high-severity issue.

If you’re unsure which severity rating your bug falls into, use the rating scale of a bug bounty platform. For example, Bugcrowd’s rating system takes into account the type of vulnerability and the affected functionality (https://bugcrowd.com/vulnerability-rating-taxonomy/), and HackerOne provides a severity calculator based on the CVSS scale (https://docs.hackerone.com/hackers/severity.html).

You could list the severity in a single line, as follows:

Severity of the issue: High

Providing an accurate assessment of severity will make everyone’s lives easier and contribute to a positive relationship between you and the security team.

Step 4: Give Clear Steps to Reproduce

Next, provide step-by-step instructions for reproducing the vulnerability. Include all relevant setup prerequisites and details you can think of. It’s best to assume the engineer on the other side has no knowledge of the vulnerability and doesn’t know how the application works.

For example, a merely okay report might include the following steps to reproduce:

1. Log in to the site and visit https://example.com/change_password.
2. Click the Change Password button.
3. Intercept the request, and change the user_id parameter to another user’s ID.

Notice that these steps aren’t comprehensive or explicit. They don’t specify that you need two test accounts to test for the vulnerability. They also assume that you have enough knowledge about the application and the format of its requests to carry out each step without more instructions.

Now, here is an example from a better report:

1. Make two accounts on example.com: account A and account B.
2. Log in to example.com as account A, and visit https://example.com/change_password.
3. Fill in the desired new password in the New password field, located at the top left of the page.
4. Click the Change Password button located at the top right of the page.
5. Intercept the POST request to https://example.com/change_password and change the user_id POST parameter to the user ID of account B.
6. You can now log in to account B by using the new password you’ve chosen.

Although the security team will probably still understand the first report, the second report is a lot more specific. By providing many relevant details, you can avoid any misunderstanding and speed up the mitigation process.

Step 5: Provide a Proof of Concept

For simple vulnerabilities, the steps you provide might be all that the security team needs to reproduce the issue. But for more complex vulnerabilities, it’s helpful to include a video, screenshots, or photos documenting your exploit, called a proof-of-concept (POC) file.

For example, for a CSRF vulnerability, you could include an HTML file with the CSRF payload embedded. This way, all the security team needs to do to reproduce the issue is to open the HTML file in their browser. For an XML external entity attack, include the crafted XML file that you used to execute the attack. And for vulnerabilities that require multiple complicated steps to reproduce, you could film a screen-capture video of you walking through the process.

POC files like these save the security team time because they won’t have to prepare the attack payload themselves. You can also include any crafted URLs, scripts, or upload files you used to attack the application.

Step 6: Describe the Impact and Attack Scenarios

To help the security team fully understand the potential impact of the vulnerability, you can also illustrate a plausible scenario in which the vulnerability could be exploited. Note that this section is not the same as the severity assessment I mentioned earlier. The severity assessment describes the severity of the consequences of an attacker exploiting the vulnerability, whereas the attack scenario explains what those consequences would actually look like.

If hackers exploited this bug, could they take over user accounts? Or could they steal user information and cause large-scale data leaks? Put yourself in a malicious hacker’s shoes and try to escalate the impact of the vulnerability as much as possible. Give the client company a realistic sense of the worst-case scenario. This will help the company prioritize the fix internally and determine if any additional steps or internal investigations are necessary.

Here is an example of an impact section:

Using this vulnerability, all that an attacker needs in order to change a user’s password is their user_id. Since each user’s public profile page lists the account’s user_id, anyone can visit any user’s profile, find out their user_id, and change their password. And because user_ids are simply sequential numbers, a hacker can even enumerate all the user_ids and change the passwords of all users! This bug will let attackers take over anyone’s account with minimal effort.

A good impact section illustrates how an attacker can realistically exploit a bug. It takes into account any mitigating factors as well as the maximum impact that can be achieved. It should never overstate a bug’s impact or include any hypotheticals.

Step 7: Recommend Possible Mitigations

You can also recommend possible steps the security team can take to mitigate the vulnerability. This will save the team time when it begins researching mitigations. Often, since you’re the security researcher who discovered the vulnerability, you’ll be familiar with the particular behavior of that application feature, and thus in a good position to come up with a comprehensive fix.

However, don’t propose fixes unless you have a good understanding of the root cause of the issue. Internal teams may have much more context and expertise to provide appropriate mitigation strategies applicable to their environment. If you’re not sure what caused the vulnerability or what a possible fix might be, avoid giving any recommendations so you don’t confuse your reader.

Here is a possible mitigation you could propose:

The application should validate the user’s user_id parameter within the change password request to ensure that the user is authorized to make account modifications. Unauthorized requests should be rejected and logged by the application.

You don’t have to go into the technical details of the fix, since you don’t have knowledge of the application’s underlying codebase. But as someone who understands the vulnerability class, you can provide a direction for mitigation.

Step 8: Validate the Report

Finally, always validate your report. Go through your report one last time to make sure that there are no technical errors, or anything that might prevent the security team from understanding it. Follow your own Steps to Reproduce to ensure that they contain enough details. Examine all of your POC files and code to make sure they work. By validating your reports, you can minimize the possibility of submitting an invalid report.

Additional Tips for Writing Better Reports

Here are additional tips to help you deliver the best reports possible.

Don’t Assume Anything

First, don’t assume that the security team will be able to understand everything in your report. Remember that you might have been working with this vulnerability for a week, but to the security team receiving the report, it’s all new information. They have a whole host of other responsibilities on their plates and often aren’t as familiar with the feature as you. Additionally, reports are not always assigned to security teams. Newer programs, open source projects, and startups may depend on developers or technical support personnel to handle bug reports instead of having a dedicated security team. Help them understand what you’ve discovered.

Be as verbose as possible, and include all the relevant details you can think of. It’s also good to include links to references explaining obscure security knowledge that the security team might not be familiar with. Think about the potential consequences of being verbose versus the consequences of leaving out essential details. The worst thing that can happen if you’re too wordy is that your report will take two extra minutes to read. But if you leave out important details, the remediation of the vulnerability might get delayed, and a malicious hacker might exploit the bug.

Be Clear and Concise

On the other hand, don’t include any unnecessary information, such as wordy greetings, jokes, or memes. A security report is a business document, not a letter to your friend. It should be straightforward and to the point. Make your report as short as possible without omitting the key details. You should always be trying to save the security team’s time so they can get to remediating the vulnerability right away.

Write What You Want to Read

Always put your reader in mind when writing, and try to build a good reading experience for them. Write in a conversational tone and don’t use leetspeak, slang, or abbreviations. These make the text harder to read and will add to your reader’s annoyance.

Be Professional

Finally, always communicate with the security team with respect and professionalism. Provide clarifications regarding the report patiently and promptly.

You’ll probably make mistakes when writing reports, and miscommunication will inevitably happen. But remember that as the security researcher, you have the power to minimize that possibility by putting time and care into your writing. By honing your reporting skills in addition to your hacking skills, you can save everyone’s time and maximize your value as a hacker.

Building a Relationship with the Development Team

Your job as a hacker doesn’t stop the moment you submit the report. As the person who discovered the vulnerability, you should help the company fix the issue and make sure the vulnerability is fully patched.

Let’s talk about how to handle your interactions with the security team after the report submission, and how to build strong relationships with them. Building a strong relationship with the security team will help get your reports resolved more quickly and smoothly. It might even lead to bigger bug bounty payouts if you can consistently contribute to the security of the organization. Some bug bounty hunters have even gotten interviews or job offers from top tech firms because of their bug bounty findings! We’ll go over the different states of your report, what you should do during each stage of the mitigation process, and how to handle conflicts when communicating with the security team.

Understanding Report States

Once you’ve submitted your report, the security team will classify it into a report state, which describes the current status of your report. The report state will change as the process of mitigation moves forward. You can find the report state listed on the bug bounty platform’s interface, or in the messages you receive from security teams.

Need More Information

One of the most common report states you’ll see is need more information. This means the security team didn’t fully understand your report, or couldn’t reproduce the issue by using the information you’ve provided. The security team will usually follow up with questions or requests for additional information about the vulnerability.

In this case, you should revise your report, provide any missing information, and address the security team’s additional concerns.

Informative

If the security team marks your report as informative, they won’t fix the bug. This means they believe the issue you reported is a security concern but not significant enough to warrant a fix. Vulnerabilities that do not impact other users, such as the ability to increase your own scores on an online game, often fall into this category. Another type of bug often marked as informative is a missing security best practice, like allowing users to reuse passwords.

In this case, there’s nothing more you can do for the report! The company won’t pay you a bounty, and you don’t have to follow up, unless you believe the security team made a mistake. However, I do recommend that you keep track of informative issues and try to chain them into bigger, more impactful bugs.

Duplicate

A duplicate report status means another hacker has already found the bug, and the company is in the process of remediating the vulnerability.

Unfortunately, since companies award bug bounties to only the first hacker who finds the bug, you won’t get paid for duplicates. There’s nothing more to do with the report besides helping the company resolve the issue. You can also try to escalate or chain the bug into a more impactful bug. That way, the security team might see the new report as a separate issue and reward you.

N/A

A not applicable (N/A) status means your report doesn’t contain a valid security issue with security implications. This might happen when your report contains technical errors, or if the bug is intentional application behavior.

N/A reports don’t pay. There is nothing more for you to do here besides move on and continue hacking!

Triaged

Security teams triage a report when they’ve validated the report on their end. This is great news for you, because this usually means the security team is going to fix the bug and reward you with a bounty.

Once the report has been triaged, you should help the security team fix the issue. Follow up with their questions promptly, and provide any additional information they ask for.

Resolved

When your report is marked as resolved, the reported vulnerability has been fixed. At this point, pat yourself on the back and rejoice in the fact that you’ve made the internet a little safer. If you are participating in a paid bug bounty program, you can also expect to receive your payment at this point!

There’s nothing more to do with the report besides celebrate and continue hacking.

Dealing with Conflict

Not all reports can be resolved quickly and smoothly. Conflicts inevitably happen when the hacker and the security team disagree on the validity of the bug, the severity of the bug, or the appropriate payout amount. Even so, conflicts could ruin your reputation as a hacker, so handling them professionally is key to a successful bug hunting career. Here’s what you should do if you find yourself in conflict with the security team.

When you disagree with the security team about the validity of the bug, first make sure that all the information in your initial report is correct. Often, security teams mark reports as informative or N/A because of a technical or writing mistake. For example, if you included incorrect URLs in your POC, the security team might not be able to reproduce the issue. If this caused the disagreement, send over a follow-up report with the correct information as soon as possible.

On the other hand, if you didn’t make a mistake in your report but still believe they’ve labeled the issue incorrectly, send a follow-up explaining why you believe that the bug is a security issue. If that still doesn’t resolve the misunderstanding, you can ask for mediation by the bug bounty platform or other security engineers on the team.

Most of the time, it is difficult for others to see the impact of a vulnerability if it doesn’t belong to a well-known bug class. If the security team dismisses the severity of the reported issue, you should explain some potential attack scenarios to fully illustrate its impact.

Finally, if you’re unhappy with the bounty amount, communicate that without resentment. Ask for the organization’s reasoning behind assigning that bounty, and explain why you think you deserve a higher reward. For example, if the person in charge of your report underestimated the severity of the bug, you can elaborate on the impact of the issue when you ask for a higher reward. Whatever you do, always avoid asking for more money without explanation.

Remember, we all make mistakes. If you believe the person handling your report mishandled the issue, ask for reconsideration courteously. Once you’ve made your case, respect the company’s final decision about the fix and bounty amount.

Building a Partnership

The bug bounty journey doesn’t stop after you’ve resolved a report. You should strive to form long-term partnerships with organizations. This can help get your reports resolved more smoothly and might even land you an interview or job offer. You can form good relationships with companies by respecting their time and communicating with professionalism.

First, gain respect by always submitting validated reports. Don’t break a company’s trust by spamming, pestering them for money, or verbally abusing the security team. In turn, they’ll respect you and prioritize you as a researcher. Companies often ban hunters who are disrespectful or unreasonable, so avoid falling into those categories at all costs.

Also learn the communication style of each organization you work with. How much detail do they expect in their reports? You can learn about a security team’s communication style by reading their publicly disclosed reports, or by incorporating their feedback about your reports into future messages. Do they expect lots of photos and videos to document the bug? Customize your reports to make your reader’s job easier.

Finally, make sure you support the security team until they resolve the issue. Many organizations will pay you a bounty upon report triage, but please don’t bail on the security team after you receive the reward! If it’s requested, provide advice to help mitigate the vulnerability, and help security teams confirm that the issue has been fixed. Sometimes organizations will ask you to perform retests for a fee. Always take that opportunity if you can. You’ll not only make money, but also help companies resolve the issue faster.

Understanding Why You’re Failing

You’ve poured hours into looking for vulnerabilities and haven’t found a single one. Or you keep submitting reports that get marked informative, N/A, or duplicate.

You’ve followed all the rules. You’ve used all the tools. What’s going wrong? What secrets are the leaderboard hackers hiding from you? In this section, I’ll discuss the mistakes that prevent you from succeeding in bug bounties, and how you can improve.

Why You’re Not Finding Bugs

If you spend a lot of time in bug bounties and still have trouble finding bugs, here are some possible reasons.

You Participate in the Wrong Programs

You might have been targeting the wrong programs all along. Bug bounty programs aren’t created equally, and picking the right one is essential. Some programs delay fixing bugs because they lack the resources to deal with reports. Some programs downplay the severity of vulnerabilities to avoid paying hackers. Finally, other programs restrict their scope to a small subset of their assets. They run bug bounty programs to gain positive publicity and don’t intend to actually fix vulnerabilities. Avoid these programs to save yourself the headache.

You can identify these programs by reading publicly disclosed reports, analyzing program statistics on bug bounty platforms, or by talking with other hackers. A program’s stats listed on bug bounty platforms provide a lot of information on how well a program is executed. Avoid programs with long response times and programs with low average bounties. Pick targets carefully, and prioritize companies that invest in their bug bounty programs.

You Don’t Stick to a Program

How long should you target a program? If your answer is a few hours or days, that’s the reason you’re not finding anything. Jumping from program to program is another mistake beginners often make.

Every bug bounty program has countless bug bounty hunters hacking it. Differentiate yourself from the competition, or risk not finding anything! You can differentiate yourself in two ways: dig deep or search wide. For example, dig deep into a single functionality of an application to search for complex bugs. Or discover and hack the lesser-known assets of the company.

Doing these things well takes time. Don’t expect to find bugs right away when you’re starting fresh on a program. And don’t quit a program if you can’t find bugs on the first day.

You Don’t Recon

Jumping into big public programs without performing reconnaissance is another way to fail at bug bounties. Effective recon, which we discuss in Chapter 5, helps you discover new attack surfaces: new subdomains, new endpoints, and new functionality.

Spending time on recon gives you an incredible advantage over other hackers, because you’ll be the first to notice the bugs on all obscure assets you discover, giving you better chances of finding bugs that aren’t duplicates.

You Go for Only Low-Hanging Fruit

Another mistake that beginners often make is to rely on vulnerability scanners. Companies routinely scan and audit their applications, and other bug bounty hunters often do the same, so this approach won’t give you good results.

Also, avoid looking for only the obvious bug types. Simplistic bugs on big targets have probably already been found. Many bug bounty programs were private before companies opened them to the public. This means a few experienced hackers will have already reported the easiest-to-find bugs. For example, many hackers will likely have already tested for a stored-XSS vulnerability on a forum’s comment field.

This isn’t to say that you shouldn’t look for low-hanging fruit at all. Just don’t get discouraged if you don’t find anything that way. Instead, strive to gain a deeper understanding of the application’s underlying architecture and logic. From there, you can develop a unique testing methodology that will result in more unique and valuable bugs.

You Don’t Get into Private Programs

It becomes much easier to find bugs after you start hacking on private programs. Many successful hackers say that most of their findings come from private programs. Private programs are a lot less crowded than public ones, so you’ll have less competition, and less competition usually means more easy finds and fewer duplicates.

Why Your Reports Get Dismissed

As mentioned, three types of reports won’t result in a bounty: N/As, informatives, and duplicates. In this section, I’ll talk about what you can do to reduce these disappointments.

Reducing the number of invalid reports benefits everyone. It will not only save you time and effort, but also save the security team the staff hours dedicated to processing these reports. Here are some reasons your reports keep getting dismissed.

You Don’t Read the Bounty Policy

One of the most common reasons reports get marked as N/A is that they’re out of scope. A program’s policy page often has a section labeled Scope that tells you which of the company’s assets you’re allowed to hack. Most of the time, the policy page also lists vulnerabilities and assets that are out of scope, meaning you’re not allowed to report about them.

The best way to prevent submitting N/As is to read the bounty policy carefully and repeatedly. Which vulnerability types are out of scope? And which of the organization’s assets? Respect these boundaries, and don’t submit bugs that are out of scope.

If you do accidentally find a critical issue that is out of scope, report it if you think it’s something that the organization has to know about! You might not get rewarded, but you can still contribute to the company’s security.

You Don’t Put Yourself in the Organization’s Shoes

Informative reports are much harder to prevent than N/As. Most of the time, you’ll get informative ratings because the company doesn’t care about the issue you’re reporting.

Imagine yourself as a security engineer. If you’re busy safeguarding millions of users’ data every day, would you care about an open redirect that can be used only for phishing? Although it’s a valid security flaw, you probably wouldn’t. You have other responsibilities to tend to, so fixing a low-severity bug is at the bottom of your to-do list. If the security team does not have the extra staff to deal with these reports, they will sometimes ignore it and mark it as informative.

I’ve found that the most helpful way to reduce informatives is to put myself in the organization’s shoes. Learn about the organization so you can identify its product, the data it’s protecting, and the parts of its application that are the most important. Once you know the business’s priorities, you can go after the vulnerabilities that the security team cares about.

And remember, different companies have different priorities. An informative report to one organization could be a critical one to another. Like the dating site versus job search site example mentioned earlier in this chapter, everything is relative. Sometimes, it’s difficult to figure out how important a bug will be to an organization. Some issues I’ve reported as critical ended up being informative. And some vulnerabilities I classified as low impact were rewarded as critical issues.

This is where trial and error can pay off. Every time the security team classifies your report as informative, take note for future reference. The next time you find a bug, ask yourself: did this company care about issues like this in the past? Learn what each company cares about, and tailor your hacking efforts to suit their business priorities. You’ll eventually develop an intuition about what kinds of bugs deliver the most impact.

You Don’t Chain Bugs

You might also be getting informatives because you always report the first minor bug you find.

But minor bugs classified as informative can become big issues if you learn to chain them. When you find a low-severity bug that might get dismissed, don’t report it immediately. Try to use it in future bug chains instead. For example, instead of reporting an open redirect, use it in a server-side request forgery (SSRF) attack!

You Write Bad Reports

Another mistake beginners often make is that they fail to communicate the bug’s impact in their report. Even when a vulnerability is impactful, if you can’t communicate its implications to the security team, they’ll dismiss the report.

What About Duplicates?

Unfortunately, sometimes you can’t avoid duplicates. But you could lower your chances of getting duplicates by hunting on programs with large scopes, hacking on private programs, performing recon extensively, and developing your unique hunting methodology.

What to Do When You’re Stuck

When I got started in bug bounties, I often went days or weeks without finding a single vulnerability. My first-ever target was a social media site with a big scope. But after reporting my first CSRFs and IDORs, I soon ran out of ideas (and luck). I started checking for the same vulnerabilities over and over again, and trying out different automatic tools, to no avail.

I later found out I wasn’t alone; this type of bug slump is surprisingly common among new hackers. Let’s talk about how you can bounce back from frustration and improve your results when you get stuck.

Step 1: Take a Break!

First, take a break. Hacking is hard work. Unlike what they show in the movies, hunting for vulnerabilities is tedious and difficult. It requires patience, persistence, and an eye for detail, so it can be very mentally draining.

Before you keep hacking away, ask yourself: am I tired? A lack of inspiration could be your brain’s way of telling you it has reached its limits. In this case, your best course of action would be to rest it out. Go outside. Meet up with friends. Have some ice cream. Or stay inside. Make some tea. And read a good book.

There is more to life than SQL injections and XSS payloads. If you take a break from hacking, you’ll often find that you’re much more creative when you come back.

Step 2: Build Your Skill Set

Use your hacking slump as an opportunity to improve your skills. Hackers often get stuck because they get too comfortable with certain familiar techniques, and when those techniques don’t work anymore, they mistakenly assume there’s nothing left to try. Learning new skills will get you out of your comfort zone and strengthen your hacker skills for the future.

First, if you’re not already familiar with the basic hacking techniques, refer to testing guides and best practices to solidify your skills. For example, the Open Web Application Security Project (OWASP) has published testing guides for various asset types. You can find OWASP’s web and mobile testing guides at https://owasp.org/www-project-web-security-testing-guide/ and https://owasp.org/www-project-mobile-security-testing-guide/.

Learn a new hacking technique, whether it’s a new web exploitation technique, a new recon angle, or a different platform, such as Android. Focus on a specific skill you want to build, read about it, and apply it to the targets you’re hacking. Who knows? You might uncover a whole new way to approach the target application! You can also take this opportunity to catch up with what other hackers are doing by reading the many hacker blogs and write-up sites out there. Understanding other hackers’ approaches can provide you with a refreshing new perspective on engaging with your target.

Next, play Capture the Flags (CTFs). In these security competitions, players search for flags that prove that they’ve hacked into a system. CTFs are a great way to learn about new vulnerabilities. They’re also fun and often feature interesting new classes of vulnerabilities. Researchers are constantly discovering new kinds of exploit techniques, and staying on top of these techniques will ensure that you’re constantly finding bugs.

Step 3: Gain a Fresh Perspective

When you’re ready to hack live targets again, here are some tips to help you keep your momentum.

First, hacking on a single target can get boring, so diversify your targets instead of focusing on only one. I’ve always found it helpful to have a few targets to alternate between. When you’re getting tired of one application, switch to another, and come back to the first one later.

Second, make sure you’re looking for specific things in a target instead of wandering aimlessly, searching for anything. Make a list of the new skills you’ve learned and try them out. Look for a new kind of bug, or try out a new recon angle. Then, rinse and repeat until you find a suitable new workflow.

Finally, remember that hacking is not always about finding a single vulnerability but combining several weaknesses of an application into something critical. In this case, it’s helpful to specifically look for weird behavior instead of vulnerabilities. Then take note of these weird behaviors and weaknesses, and see if you can chain them into something worth reporting.

Lastly, a Few Words of Experience

Bug bounty hunting is difficult. When I started hunting for bugs, I’d sometimes go months without finding one. And when I did find one, it’d be something trivial and low severity.

The key to getting better at anything is practice. If you’re willing to put in the time and effort, your hacking skills will improve, and you’ll soon see yourself on leaderboards and private invite lists! If you get frustrated during this process, remember that everything gets easier over time. Reach out to the hacker community if you need help. And good luck!