Methodology of Bug Bounty: A Guide for Bug Hunters

This article is based on my experience as a web hacker, but the principles described in it are generally applicable to all hacking disciplines. It is mainly intended for beginner hackers and for people who have already found a few bugs but want to make their approach to bug bounty more consistent and systematic.

About me: I am Ciaran (or Monke). I am Irish, but I live in Edinburgh. I have been doing bug bounty for about four years, participated in four Live Hacking Event on various platforms, and the fifth one is coming soon. I am a fairly typical web hacker, and now I enjoy client-side hacking the most. This year I finally switched completely to making money through bug bounty and founded a company called Simian Security. I may be the only Irishman for whom bug bounty is a full-time job.

If you are reading this post, you probably want to improve your bug bounty methodology or find out what bug bounty methodology is. At the most fundamental level, methodology is simply how a hacker approaches and attacks a target. No more, no less. The methodology consists of several key components:

• Tools: what does a hacker use to attack a target?

• Mindset: how persistent is a hacker? How does a hacker overcome mental barriers?

• Approach to work: some hackers use checklists. Others rely on their intuition. How do hackers apply their knowledge in practice?

• Experience: the specific order of implementing the methodology depends on the hacker's previous experience. Experienced hackers are usually very effective at this. Efficiency is the result of accumulated experience.

If you do not engage in bug bounty hunting constantly, you are likely to have difficulties when researching a new target. Sometimes it can be very exhausting. Reading my article will not help you in this area. Having a methodology means knowing exactly where to start, and I cannot teach you this; it can only be mastered through constant self-practice. Ultimately, bug bounty hunting is a skill, and those who practice it more usually grow as hackers.

Many of you may consider bug bounty hunting a way to make quick money. This can be true if you are good at what you do. But to reach that level, it takes months, if not years. In this article, I will explain my methodology in great detail, but you still won't be able to find what I find. That's what is great about bug bounty hunting. Each of us brings our unique experience to this field, so we can use the same tools and get completely different results.

Tools

Process

Proxying

Depending on the goal, I choose either Burpsuite or Caido. Lately, I mostly use Caido and apply Burpsuite only in very specific situations, such as single packet attacks. Caido predominantly has everything I need, and it is easier to write extensions for it because it uses Javascript+CSS for user interfaces, not Java Swing. If you are a beginner, I recommend Caido because it is easier to use.

Should you buy Burpsuite Professional Edition or Caido Pro? I think so. It is not necessary to pay for a proxy to find your first bug. But you will definitely be able to find more bugs if you have the ability to save projects. Burpsuite Community Edition does not allow saving projects at all, and the free version of Caido is limited to two projects. There are other proxies, but today most hackers use either Burp or Caido.

Subdomain Enumeration

I use Subfinder. An ordinary tool, nothing outstanding. If I need a larger dataset, I turn to my friends who are into automation. For initial reconnaissance, I mainly use the ProjectDiscovery toolkit. To check active hosts, I use httpx and occasionally perform port scanning. To parse the list of active subdomains and sort them by domain, I wrote my own tool. It converts the data into a connection diagram in Obsidian, which can be used for note-taking. Below I will tell you more about notes.

When working on large projects, I follow Recon Methodology by Jason Haddix, highly recommend it. If you have extra money for training, consider purchasing The Bug Hunter’s Methodology Live.

URL

I use Waymore, written by XNL-H4ck3r, and Gau by Corben Leo. These are also quite common tools. At this stage, I filter the results with parameters, as they are the most interesting to me. I also study any IIS servers that can be checked with Shortscan for any additional data.

Nuclei

Standard Nuclei templates are good enough, but let's be realistic — you will be much more effective if you master automation yourself. The greatest success can be achieved with custom templates. There is one subtlety: sometimes vulnerabilities can be located on non-standard paths (for example, one or two folders higher or lower), and Nuclei will miss them because it only checks the paths specified in the template. I have found many bugs thanks to this method.

On the client side

Having compiled a list of interesting hosts, I start visiting each page. I have DomLogger++ and postMessage-tracker by Frans Rosen installed in my Chrome profile. Then I start exploring the data flow through the web application, and if the page seems particularly interesting, I run it through Param Miner from the Burpsuite package to discover new parameters. I monitor postMessage activity and closely examine any interesting reflections in the DOM. All this is situational and highly dependent on the research goal. To study the limitations and behavior of browsers that you need to know, you should use the excellent resource Beyond XSS.

On the server side

The list of tests I perform on the server side depends heavily on the application.

• API is a great choice for testing. I quite often perform access control and IDOR testing, but they are very easy to fix, so the likelihood of finding anything is low. By digging into JS files, you can often find hidden endpoints worth testing. Some people automate this task by detecting changes in JS files, but I haven't gotten to that point yet.

• I perform secondary context path traversal testing in parameters and JSON values.

• SQL injections, NoSQL injections, server-side template injections, and so on. The principle is clear—the list would be too long to enumerate, but I test them all depending on the context. My only advice is not to test blindly: don't check for NoSQL injection if you know that an SQL database is used on the backend.

Miscellaneous

• If there is Salesforce on the site, I test it for Salesforce misconfigurations.

• As mentioned above, I perform Shortscan for everything that has IIS.

• I test the classic directory traversal ..; in Java applications.

• In large projects, I perform virtual host brute force and some fuzzing.

• I know the OAuth flow quite well, this knowledge is invaluable for finding account takeover (ATO) opportunities. SAML is also a major attack surface for finding ATO, but I am less familiar with it.

Automation

I have written a lot of automation, but I don't use it that often—simply because I only need it for the basics. For the sake of completeness, I will describe what I have created.

For almost all of my VPS, I use DigitalOcean. It is not particularly expensive and has a simple UI. I have already done dozens of iterations with my code, so my codebase is quite perfect.

Hakluke wrote an excellent article on the evolution of bug bounty automation. His post is largely accurate.

How it works

I have not found any sensible explanations of how automation works, so I will try to explain it here. First, let's break down the tasks into two types: long-term and one-time. Long-term tasks are, for example, scanning operations like compiling a list of subdomains. One-time tasks are more intensive operations, such as fuzzing. In large automation systems, we need the ability to scale these scanning operations (more long-term tasks = higher data processing speed, more one-time tasks = more intensive scans performed in parallel). To implement this, automation specialists use message queues. Message queues allow you to create a backlog of tasks from which these tasks can be taken. If we increase the number of containers performing certain tasks, we can take more tasks from the queue. In Kubernetes, it is enough to change one number in the YAML specifications. What do I use?

• Message queues: I have a RabbitMQ server — it does its job well and it is easy to write code for it that integrates with Python or Go.

• Database: I prefer to use MongoDB because I think the BSON document format is better suited for bug bounty.

The choice of programming language is also very important. Python handles data processing wonderfully, but Go is better suited for scanning programs because it has built-in concurrency thanks to goroutines. Each language has its place in the ecosystem. I mostly wrote my own code in Go, but some tasks are written in Python for flexibility.

After completing the tasks, the results are sent somewhere so you can view them. Most people use Slack or Discord webhooks. I used to experiment with Grafana as well.

I highly recommend trying to build your own automation using minimal resources. By trying to do this, you will learn a lot.

What is searched for using scanning

There are still many opportunities for subdomain takeover. This class of bugs is gradually dying out, but it can still be exploited. Looking at the big picture, it seems to me that automation is evolving, and people are now scanning for XSS, cache bugs, and, of course, zero-day vulnerabilities. In addition, researchers are reverse-engineering patches and scanning for their presence before public PoCs are released, or finding vulnerabilities in Wordpress plugins and conducting large-scale scans for them.

Note-taking

Note-taking is the most important part of the process. By taking quality notes, it is much easier to return to what you worked on in the past. In this area, LLMs are gaining more and more power; below I will share a couple of thoughts about them. An organized approach pays off tenfold.

Note-taking software

In fact, anything will do, even TXT files. I recommend Obsidian or Notion. For writing bug bounty reports, I recommend using Obsidian. Notion is good because it works in the cloud, so you don't have to worry about losing your notes and you can easily share them with others. Each of these tools has its own advantages. Connection diagrams (mental maps, mindmaps) are a great way to organize bug bounty notes because they can be sorted by domain, then subdomain, and even by path.

LLM

I highly recommend using ChatGPT or any other LLM that allows you to upload data to query your notes. In particular, if you can export your notes as a PDF file, this will allow you to use ChatGPT's "custom GPT" functionality to create a personal chatbot whose knowledge source will be your notes. This is a great way to generate ideas based on already conducted research when you are working on hacking a target system. In addition, if you send a link to access this GPT to friends, they will also be able to easily query your notes.

Mindset

Hacking with a plan

Hacking without a goal is a common mistake. You may have hacking tools, but they are useless if you don't have a plan. Without a plan or direction, you are wasting your time. Even "poking with a stick to see what happens" is a plan if you understand why you are doing it.

Before hacking daily, set a clear goal. Here are a couple of examples:

• «I want to identify parameters reflected in the DOM».

• «I want to trigger errors to determine the backend technology stack».

• «I want to find files in the internal file system to escalate this SSRF».

Without a plan, mastering what could be learned in a week can take a month. Don't scatter your time.

Impostor Syndrome

It can occur in a person with any level of experience in this field. One day you wake up and feel worse than everyone else. For example, the reason might be that Orange Tsai published Apache web server RCE (someone else did it, not you). Whatever the trigger, it happens, and there's nothing you can do about it. In such situations, it's good to talk to someone, preferably a hacker friend you trust, or someone on a hacker Discord server. The bug bounty community is an amazing support network.

Dealing with imposter syndrome is also helped by an objective view. Think about what you are doing. There are about a thousand hackers in the world who regularly make good money on bug bounties. And you strive to become one of them? Think about what exactly a bug bounty is. You are trying to find bugs in systems that have already been tested by experienced pentesters and red teams, and you are competing with dozens of other hackers. No matter what anyone tells you, this is not an easy task! So don't beat yourself up! Bug bounty is like waves, sometimes you are on top, and sometimes you fall down. Just remember: although much depends on luck, a chance is needed for a successful outcome, and chances arise only if you work hard.

Motivation

This point is tricky. Motivation comes and goes, and ultimately you can't rely on it if you want to achieve mastery in your craft. Come up with a habit ("I will hack for two hours every morning") or work on something else if you feel tired. I often get tired of manual testing, and I switch to writing code for a new tool or something similar, just to change the pace of work. Many hackers suffer from ADHD, and it can be difficult for them to focus on one specific thing; I believe that if you are doing anything, even listening to a hacker podcast, you are already doing well. Step by step, meter by meter. Manage your energy properly, and you will see that making progress becomes easier.

Of course, there are times when you work hard but don't find any bugs. This happens. It's part of the process. Believe in yourself and know that if you keep working, the next bug is inevitable. It must be found sooner or later. Keep moving in the right direction!

Where to start

A little advice for beginners: no one expects you to be a master, and that's okay. Stop comparing yourself to those who have much more experience than you. All that really matters is that you are just starting out and that you are practicing. There are hackers who found five bugs in their first month and then burned out. There are hackers who found nothing for six months, but then something clicked, and now they are constantly successful. In fact, none of this matters. What matters is that you are learning and growing. This progress is not always expressed in the form of rewards. Sometimes you just handle a difficult goal a little easier because you put in hours of effort. Every hour you find nothing brings you an hour closer to the next bug. Believe in yourself, play your cards right, and the bugs will be found.

Flexibility of thinking

I often see this mistake: people look for certain patterns in programs. I think this is a huge misconception. It is much more effective to observe how programs react, rather than putting them in some mental box of expected behavior. By observing, you can learn how a web application is built, discover unique features of the program, and find bugs specific to that web application.

For example, if you are only looking for IDOR and access control, you may miss completely obvious system bugs because you never thought about what you are doing. Here is an example:

I tested a program with a standard SaaS model. It had administrators, users with reduced privileges, and a bunch of functionality with a role-based permission system. The application was small, and the program was written about two years ago - ideally, the permission system should have been thoroughly tested. However, in reality, everyone missed that when inviting a new user, they were assigned the "Administrator" permission by default, and this permission could only be changed after the new user accepted the invitation. This created a privilege escalation window for the new user, which attackers could exploit. I wrote a report about this, and it was paid as a High-level issue. If I, like everyone else, had focused on IDOR and access control, I would have completely missed this.

Assumptions

Another common mistake is assuming that a system or part of it is secure. This is a flawed approach, and the human brain is prone to many logical errors that lead it down the wrong path. Test what you think cannot be vulnerable, because it often turns out to be so. In my career, I have seen bugs that I thought were simply impossible. But they were found.

Approach to work

Program selection

I have several bug bounty programs that I return to every year, but I usually change them quite often. Fortunately, last year HackerOne published a list to understand which bug bounty programs are more likely to be scammed by organizers.

In fact, I don't really care about the scope — if it's too narrow, I dig deeper, and if it's too wide, I apply reconnaissance methodology. If you organize bug bounty programs, don't cheat hackers! Seriously, information about such cases spreads instantly.

If you are a relative beginner and trying to find bugs, choose something with a narrow attack surface that forces you to go deeper. This way you will learn more.

Intuition

I would call myself a hacker driven by instincts. I don't use a checklist. I understand why some hackers need it, but it's just not for me. My intuition has been honed by practice, and I believe I can hack anything if I put enough time and effort into the right spot. Checklists are for pentesters, and pentesting methodologies don't work in bug bounty.

Idea Generation

I'm sure you're familiar with this phenomenon: how often have you been stuck on the same thing, only to come back the next day and solve the problem in a few minutes? Sometimes all you need is a fresh perspective. If you're stuck somewhere, I recommend taking a break and going for a walk. Don't wear headphones, just be alone with your thoughts, and your brain will naturally start to wander and come up with ideas. This kind of "boredom" is an integral part of creativity. If you're stuck and it's frustrating you, stop, take a shower, have a snack, and then come back with a fresh perspective.

Breaks

Bug hunting can often be an exhausting process, so in the long run, it's more effective to take regular breaks, even if you feel like you can hack forever. Working on projects with a complex attack surface for a long time can cause burnout. If bug bounty is your main source of income, allocate at least one day or a few hours a day for recovery.

The Pomodoro technique also helps to divide the day into parts. I understand that the nature of hacking doesn't always allow for its use, but if you're going to conduct intensive research, it's almost a necessity.

Attack Surface Analysis

Perhaps the most important thing in bug bounty is the severity of the vulnerability found. Therefore, you should approach the choice of vulnerabilities you want to find wisely. In the case of financial companies, it's anything that affects payments or financial data. For chat applications, it's the ability to access other users' conversations. And so on.

Let me elaborate: you will find more critical vulnerabilities if you target the parts of the application that have more value to the company. A serious vulnerability is unlikely to be given a Low status.

Moreover, if you feel that you have studied the program enough but found nothing, do not give up. Keep moving. Perhaps after 50-60 hours, it is worth moving on to something else, but spend at least 30 hours on the target before thinking about switching. Every program has a layer of complexity that you will not see until you spend 30 hours or more on it. Every program. I have found bugs in projects with incredibly narrow testing scope simply because I did not give up and dug deeper.

Collaboration

I believe that I have learned a lot from working with other people. By studying how others hack and find bugs, I can fill gaps in my own methodology and understand what I am doing wrong. Moreover, collaborative work energizes and increases dedication. Most often, I split the workload in half, but if after talking with a colleague it turns out that he has an unreasonably large amount of work, we change the ratio. It is important to adhere to a fair approach.

Never and under no circumstances betray the person you are collaborating with. The bug bounty world is very small, everyone knows each other. Betrayal of trust is a direct road to destroying your reputation and the contempt of colleagues.

Collaboration also helps to turn a relatively harmless vulnerability into something more serious. Almost all high-level hackers know that Alex Chapman should be contacted if you need to use Chrome exploits to turn an SSRF of a "headless" browser into an RCE. By communicating with other people, you can learn what their strengths are; they will learn what yours are, and you can rely on each other to find opportunities for vulnerability escalation.

If there are hackers around you, meet and work together! Sharing ideas can lead to great discoveries, and work becomes much more fun.

Specialization

At a certain stage of a hacker's career, it helps to choose a specialization in a specific technology or class of bugs. If you build a reputation in a particular area or class of bugs, hackers will contact you and offer collaboration. Conducting new research in these areas also helps — you can push the boundaries of the known and even find zero-day vulnerabilities.

Choosing a field of specialization is difficult, but in general, it should be at the intersection of what you like and what makes money. Follow your interests, and you will naturally come to your specialization.

In addition, specialization is useful for finding jobs in the industry. Your portfolio may be exactly what a company is looking for. For example, if you specialize in game hacking, your chances of finding a good job in game pentesting will be higher.

Experience

Starting from scratch

People often ask where to start and what to study first. I constantly repeat: do not neglect fundamental knowledge. Cutting corners, you harm your future self. Below in the "Self-study" section, I will share a list of useful resources.

The only way to become a successful bug bounty hunter is to be patient and methodical. You will not become a brilliant hacker in a day. Do not pressure yourself too much for success, enjoy the process of learning and hunting, and have fun working towards your goals.

For beginners, mentorship is extremely important, but do not write to people and beg them for help. Experienced hackers are often busy with their own work. Why should they teach you if they do not know you at all? Will they help someone who is looking for easy ways? At the very least, show that you are already familiar with the basics and that you are not someone who constantly only takes without giving anything in return. Mentorship is done with friends, not strangers, so first make friends in this field.

Finally, I will say a few words about submitting reports on harmless bugs. Such reports are unlikely to help you grow professionally. Do not report bugs if you are not sure about their impact. Before writing a report, stop and ask yourself: what does the bug affect? Can it really harm the company? If you are struggling to answer, then do not send the report. Have standards! Experienced hackers usually do not report bugs with Low status. If you want to become one of them, stick to the same standards.

Live Hacking Event Activities

Believe me, the best hackers really use the same tools as you do. If you ever attend a Live Hacking Event, you will see that people largely copy each other, even when working on complex bugs. Why? Because we all think alike! Participants in such events have accumulated enough experience for their thought processes to be approximately the same. Ask experienced hackers to come up with five ideas for solving a niche problem, and at least three will agree.

Every ambitious bug hunter should strive to attend a Live Hacking Event. Personally, I met a lot of people whose performances became an extremely important part of my growth. It is easier to get on small platforms like Intigriti, but it will still take a lot of effort.

Self-education

Perhaps the most important part of bug bounty is "teaching yourself to learn." The most important thing is that you should enjoy the process. Don't force yourself to learn. If you are fundamentally unable to enjoy the process, then bug bounty is probably not for you.

Training resources

• Portswigger Labs: an old and reliable resource. Their labs are the best free resource for learning hacking.

• XSS Gym by BruteLogic: a very good platform for mastering XSS. Also free.

• PentesterLab: a very good lab environment. Paid. Especially useful for studying source code review.

• BugBountyHunter.com: a realistic bug bounty training environment created by Zseano. I haven't tried it myself, but Zseano is a highly respected person in our industry, so I believe this platform will teach you hacking.

• HexTree.io: paid. A new player in the security training field, created by industry veterans LiveOverflow and StackSmashing.

Podcasts

• Critical Thinking: a must-listen podcast for anyone interested in bug bounty. I listen to it regularly and highly recommend it.

• Day[0]: an amazing podcast that discusses many complex topics. One of the hosts is my friend Zi, whose expertise I can personally vouch for.

Newsletters

• Hive Five: probably the best newsletter. I wouldn't have achieved all that I know without this Securibee newsletter.

• Bug Bounty Reports Explained: very detailed breakdowns of various types of bugs by an experienced hacker.

• MonkeHacks: my newsletter. If you liked this article, take a second and subscribe to it.

YouTube

• InsiderPHD: an excellent channel for beginners in the field of bug bounty. Katie is my friend, very pleasant in person.

• PwnFunction: good videos on topics that may be missing on other channels.

• Bug Bounty Reports Explained: an amazing channel that explains complex vulnerabilities in simple terms. It seems that Grzegorz started doing bug bounty content with it.

• Stök: Stök is one of the best hacker influencers. His videos greatly influenced my decision to get into hacking, especially the ones about Live Hacking Event. His video about H1-4420 in 2019 was a big source of inspiration for me, and last year I had the chance to compete at H1-4420, so it seems the story has come full circle.

• NahamSec: I have hardly watched this channel, but many of my friends got into the world of bug bounty by watching his live system exploration videos. Highly recommended.

• Codingo: excellent technical videos. The author has been successful in this field for a long time, and if you watch his content, you will understand why.

• g0lden: the youngest of the channels listed here, but with great content. It covers many topics that other channels bypass, such as automation.

Coding

To engage in bug bounty, it is not necessary to know how to write code, but it is very useful. Of course, coding allows you to write your own tools, but at a certain level of mastery, you will be able to find vulnerabilities relying on your knowledge of backend structures. Having programming experience makes the studied black box a little more transparent — you start to understand what is happening a little better and learn to adapt your skills to previously unfamiliar technologies.

However, for effective client-side hacking, knowledge of Javascript is essential, so take the time to study it — it will greatly help your entire hacking career as a whole.

I would also recommend rewriting ready-made tools to suit your needs. Sometimes public tools can miss something, and you are unlikely to notice it right away.

Conferences and Meetings

Communication with colleagues is very important, as in any other security field. In general, the hacker community is very responsive and welcomes newcomers; if you treat everyone with respect, all roads will be open to you. Check in the HackerOne’s Brand Ambassador Program if there are HackerOne clubs in your country, or just join one of the main Discord servers on any of the major platforms, and you will be guided in the right direction.

Def Con is a major annual event, and if you have enough time and resources, I recommend attending it. I flew to it in 2022 and saw many celebrities, such as James Kettle, who gave a live presentation of his latest research. It is a true rite of passage for any aspiring security professional.

Comparison of Bug Bounty with Pentesting

There is a big difference between these two concepts: pentesting is a one-time activity, while bug bounty is continuous. Companies are constantly releasing new features. These features are rarely thoroughly tested before release. Of course, pentesting skills are useful for hacking, but pentesting is usually easier than bug bounty. It does not adapt to gradual changes in the company's products.

Conclusion

I hope my article has given you an idea of what the bug bounty methodology is. It's not just tools for finding bugs, but also a mindset, experience, and even the people you work with. There are no shortcuts here, and if you found a shortcut, congratulations - you are a great hacker! Finding holes in systems is exactly what we do. To succeed in the bug bounty world, you need a lot more, but what is outlined in the article will help you set your course for a long time. Now that you have all the necessary knowledge, go and do something cool!