Table of Contents

• Introduction

• Tools

  • The Process

    • Proxying

      • Paid Editions

    • Subdomain Enumeration

    • URLs

    • Nuclei

    • Client-Side

    • Server-Side

    • Miscellaneous

  • Automation

    • How It Works

    • What People Scan For

  • Note-Taking

    • Note-Taking Software

    • LLMs

• Mindset

  • Hacking With Direction

  • Imposter Syndrome

  • Motivation

  • Starting Out

  • Flexible Thinking

  • Assumptions

• Execution

  • Picking Programs

  • Intuition

  • Generating Ideas

  • Taking Breaks

  • Dissecting Attack Surface

  • Collaboration

  • Specialisation

• Experience

  • Starting From Zero

  • Live Hacking Events

  • Self-Education

    • Training Environments

    • Podcasts

    • Newsletters

    • YouTube

  • Coding

  • Conferences and Meetups

  • Comparing Bug Bounty to Pentesting

• Conclusion

Introduction

This article is written from my perspective as a web hacker, but the principles are largely applicable to all disciplines of hacking. It’s mostly aimed at new hackers, or people who’ve found a few bugs already but are struggling to be consistent.

About me: I’m Ciarán, a.k.a monke. I’m Irish but I live in Edinburgh, Scotland. I’ve been in the bug bounty scene for about four years, and I’ve been to four Live Hacking Events between various platforms with a fifth one coming up. I’m a pretty typical web hacker, and at the moment I’m really enjoying client-side hacking. This year I finally switched to full-time bug bounty, and I set up a company called Simian Security. I think I might be the only Irish full-time bug bounty hunter.

If you’re reading this post, you’re probably here to expand your bug bounty methodology, or educate yourself on what a bug bounty methodology is. At a very fundamental level, a methodology is simply how a hacker approaches and attacks a target. Nothing more, nothing less. A methodology has a few core components:

• Tools: What does the hacker use to attack the target?

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

• Execution: Some hackers use checklists. Some hackers guide themselves using their own intuition. How do hackers execute their knowledge?

• Experience: The exact order of executing their methodology depends on the hacker’s previous experiences. Skilled hackers are usually very efficient at this. Efficiency comes from experience.

If you’re not a regular bug bounty hunter then you probably struggle with approaching a new target. It can be a very overwhelming experience. Reading this article won’t help you with that. Having a methodology means knowing exactly where to start, and I cannot teach you this - this is something you need to figure out yourself through consistent practice. Bug bounty is ultimately a skill, and people who practice it more are usually better hackers.

Many of you probably still view bug bounty as a quick buck. It can be, if you’re good. But getting to that point takes months, if not years. I describe my methodology in meticulous detail in this article and you still won’t find everything I find. That’s the great thing about bug bounty. Each of us brings our unique experience to the arena, and as a result, we can use the same tools and get completely different results.

Tools

The Process

Proxying

Depending on the target, I alternate between Burpsuite and Caido. I use Caido for most things these days - I only use Burpsuite for very specific situations such as single-packet attacks. Caido largely does what I need, and it’s easier to write extensions for it because it uses Javascript+CSS, and not Java Swing for user interfaces. If you’re starting out, I’d recommend Caido as it’s simpler to use.

Paid Editions

Is it worth it to get Burpsuite Professional Edition or Caido Pro? My view is yes. You don’t need to pay for a proxy to get your first bug, but it sure as hell makes it easier to find more bugs if you’re able to save your projects. Burpsuite Community Edition doesn’t allow you to save projects at all and Caido’s free edition limits you to two projects. There are other proxies out there but most people use either Burp or Caido these days.

Subdomain Enumeration

I use Subfinder. Nothing special. If I need a larger dataset, I reach out to one of my automation friends. For initial recon, I mostly depend on the ProjectDiscovery suite of tooling. I use httpx for checking active hosts and occasionally I run some port scans. I use a custom tool that I wrote to parse the list of active subdomains and order them by domain. The tool converts the data to a mindmap in Obsidian that I can use for note-taking. I discuss note-taking in some greater depth further down in this article.

For larger scopes I follow Jason Haddix’s Recon Methodology. I cannot recommend this highly enough. If you have some corporate training budget left over, you should look at buying The Bug Hunter’s Methodology Live.

URLs

I use Waymore by XNL-H4ck3r and Gau by Corben Leo. Again, nothing special. At this point I filter out the results that have parameters as those are the ones that are the most interesting to me at the start. I also pay attention to any IIS servers that I can run Shortscan against for some extra data.

Nuclei

Nuclei’s default templates are pretty good but let’s be realistic here - you’re probably not going to beat the top automation folks. Most success comes from custom templates. A small opportunity does exist, though - sometimes the vulnerabilities might exist on non-standard paths (maybe a directory or two higher or lower) and these will be missed by Nuclei, which only checks for the paths that are hardcoded into the template. I’ve found quite a few bugs this way.

Client-Side

Once I have a list of interesting hosts, I start visiting each page. I have DomLogger++ installed on my Chrome profile as well as Frans Rosén’s postMessage-tracker. Then I proceed to examine the flow of data through the web app, and if a page seems particularly interesting, I run Param Miner on it from Burpsuite to uncover more parameters. I look at postMessage activity and I also keep my eyes peeled for any interesting reflections in the DOM. All of this stuff is quite subjective to the target. Beyond XSS is a great resource for learning the limitations and browser behaviours that you need to know.

Server-Side

The list of server-side tests I do is very much application-dependent.

• APIs are great to test. I test for access control and IDOR quite often, but you’re also more likely to dupe here as these are easy to spot. Often, by digging into the JS files, I can find hidden endpoints to test. Some people automate this part as well, by detecting changes in JS files, but I don’t do that yet.

• I test for secondary context path traversals in parameters and JSON values.

• SQL injections, NoSQL injections, server-side template injections, and so on. You get the idea - the list is too long for me to write out here but I test for all of these depending on the context. My only advice is not to test randomly - don’t test for NoSQL injection if you know that it’s running a SQL database in the backend.

Miscellaneous

• If the site is running Salesforce, I test for Salesforce misconfigurations.

• As mentioned previously, I fire Shortscan at anything running IIS.

• I test for the classic ..; path traversal on Java apps.

• In larger scopes I do virtual host bruteforcing, and some light fuzzing.

• I know the OAuth flow pretty well - this is invaluable for finding ATOs. SAML is also prime attack surface for ATOs but I’m less familiar with it.

Automation

I have a large amount of automation written but I don’t use it - simply because I’ve found that I don’t need it for anything beyond the basics. In the interest of education I’ll describe what I’ve built.

I use DigitalOcean for pretty much all of my VPSes. It’s not too expensive and the UI is simple to use. I’ve done dozens of iterations of my code at this point so I have a pretty refined codebase by now.

Hakluke wrote an excellent article on the evolution of his bug bounty automation. This writeup is largely accurate.

How It Works

That said, nobody has really talked about how automation works, so I’ll try to address that here. To begin with: let’s break tasks down into two types. Continuous tasks and One-time tasks. Continuous tasks are scanning operations like subdomain enumeration. One-time tasks are more intensive operations like fuzzing. In larger automation setups, we want the ability to scale these scans (more continuous tasks = better data throughput, and more one-time tasks means more intensive scans running in parallel). To accomplish this, most automation people use message queues. Message queues allow us to create a backlog of tasks to draw from. If we scale up the number of containers running particular tasks, we can take more tasks from the queue. In Kubernetes this is as simple as changing one number in the YAML specifications. So, what do I use?

• Message Queues: I have a RabbitMQ server. RabbitMQ is effective and it’s easy to write code to integrate with it in Python or Go.

• Database: I prefer to use MongoDB as I feel that the BSON document format is better suited to bug bounty.

The choice of programming language is also important. Python is excellent for data processing, but Go is better suited to scanning programs as it has concurrency built into the language itself through Goroutines. Each language has their place in the ecosystem. My own code is mostly written in Go, but certain tasks are written in Python for flexibility.

Once the tasks have completed, the results are pushed somewhere for you to view them. Most people use Slack or Discord webhooks. In the past I’ve experimented with using Grafana as well.

I’d highly recommend that you try to build your own automation with as little resources as possible. You learn a huge amount by trying this.

What People Scan For

In the current landscape, there is still a lot of subdomain takeovers. It’s slowly dying out as a bug class but it’s very much still exploitable. At the highest level, I think automation is evolving and people are scanning for XSS, cache bugs, and naturally zero days as well. People will also reverse patches and scan for them before public POCs are available, or find Wordpress plugin vulnerabilities and scan for them at scale.

Note-Taking

Note-taking is a crucial part of the process. With good notes, it’s much easier to return to something you worked on in the past. Increasingly, LLMs are becoming a superpower in this area and I’ll throw in a few ideas about that below. Being organised pays itself back tenfold.

Note-Taking Software

Honestly, anything works. TXT files, even. My recommendations are Obsidian or Notion - I’d recommend using Obsidian for writing bug bounty reports. Notion has the added advantage of being cloud-based, so you don’t need to worry about losing your notes, and you can share your notes with other people pretty easily. There are advantages to each. Mindmaps are a great way to organise bug bounty notes, as you can sort them by domain and then subdomain and even by path.

LLMs

Something I would highly recommend is using ChatGPT or any other LLM that allows you to upload data to query your own notes. More specifically, if you can export your notes as a PDF file, you can use ChatGPT’s “custom GPT” functionality to create a private chatbot that relies on your notes as a knowledge source. This is an excellent way to generate ideas based on your existing research when you’re working on a target. Not only that, but by sharing the link to access this GPT with your friends, your collaborators can easily query your notes as well.

Mindset

Hacking With Direction

A common mistake is hacking aimlessly. You may have the tools to hack things at your disposal, but that’s pointless if you’re not hacking with direction. Without a plan or a direction, you waste valuable time in your day. Even “throwing shit at a wall to see what happens” is a direction if you do it intentionally.

Before you start hacking each day, have a clear goal. A few examples:

• “I want to identify parameters that reflect in the DOM.”

• “I want to trigger errors to fingerprint the backend tech stack.”

• “I want to find files in the internal filesystem to escalate this SSRF.”

Without direction, something that could take a week to master might take a month instead. Don’t waste your time.

Imposter Syndrome

This happens at any level in the field. One day you wake up and you feel inferior to everyone else. Maybe Orange Tsai posted an Apache webserver RCE. Whatever the trigger was, it happens, and there’s nothing you can do. At times like this, it’s good to talk to someone, preferably a hacker friend that you trust, or maybe a hacker-oriented Discord server. The bug bounty community is an amazing support network.

It also helps to put things in perspective. Like, seriously. Think about what you’re doing. There are maybe 1,000 hackers in the world who make regular, good money through bug bounty. And you’re trying to be one of them? Think about what bug bounty IS. You’re trying to find bugs on scope that’s already been hardened from teams of experienced pentesters and red-teamers, AND you’re competing against dozens of other hackers. No matter what anyone tells you - this is NOT an easy thing to do! So don’t beat yourself up over it! Bug bounty is like a series of waves - sometimes you’re at the crest, and other times you’re at the trough. Just remember that while a large part of it might be luck - luck comes from having more opportunities to be lucky, and these opportunities only appear if you put in the work.

Motivation

This is a tricky one. Motivation comes and goes, and ultimately you cannot rely on it if you want to be good at what you do. Set yourself a routine (“I will hack for 2 hours every morning”) or work on something else if you’re not feeling it. Often I get sick of manual testing and I’ll switch to writing some code for a new tool or something like that, just to change the pace. A huge number of hackers have ADHD and focusing on one specific thing can be difficult - my view is that as long as you’re doing something, even just listening to a hacker podcast, then you’re doing great. One step at a time, one foot in front of the other. Manage your energy properly and you’ll find that consistency will come more easily.

The other part of motivation, of course, is when you’re in a rut and you’re not finding any bugs. This happens. It’s part of the process. Have faith in yourself and know that if you keep working, then the next bug is inevitable. It must happen eventually. Keep going!

Starting Out

Here’s a short tip to any of you who are beginners: nobody expects you to be good. And that’s fine. Stop comparing yourself to these people with years more experience than you. All that matters is that you start and that you’re practicing. There are hackers who found 5 bugs in their first month and then fizzled out. There are hackers who found nothing for 6 months until something clicked and now they’re finding regular success. Point is, none of this matters. All that matters is that you’re learning and that you’re progressing. This progress isn’t always in the form of bounties. Sometimes it’s just having a slightly easier time on a difficult target because you put in the hours. I think Rhynorater says it often but every hour you don’t find something is an hour closer to your next bug. Have faith in yourself and play your cards right, and the bugs will come.

Flexible Thinking

I often see people making the mistake of looking for certain behaviours on programs. I think that this is a huge mistake. It’s much more effective to observe how programs respond rather than putting them into some kind of mental box of how you expect them to behave. By observation you can learn how the web app is built, uncover program-specific gadgets, and find bugs specific to the web app.

To illustrate this: if all you do is look for IDORs and access control, you might overlook some completely obvious bugs in systems because you never stopped and thought about what you were doing. Here’s an example:

I was testing a program with the standard SaaS model. It had administrators, low-privilege users, and a bunch of functionality here and there with a role-based permissioning system. The app was small, and the program was about 2 years old so it was pretty clear that the permissioning system had been tested extensively. What everyone failed to spot was that when you invited a new user, the default permission was “Administrator”, and you couldn’t change this permission until after the invitation was accepted by the new user. This created a window of privilege escalation for the new user to act maliciously. I reported this, and it was paid out as a High issue. If I had focused on IDOR and access control like everyone else, I would’ve missed this completely.

Assumptions

Another common mistake is assuming that something is secure. This is flawed and the human brain is prone to falling for a myriad of logical fallacies that’ll set you on the wrong course. Test things that you don’t think would be vulnerable - because often, they are. I’ve seen some bugs in my career that I never would’ve thought possible. But here we are.

Execution

Picking Programs

I have a few programs that I return to every year, or every time new scope is released, but mostly I hop between programs quite a bit. Fortunately, in the past year HackerOne has made it easier to see which programs are likely to scam you.

I don’t really look at scope all that much - if the scope is narrow, I dig deep, and if the scope is wide, I run recon methodology on it. If you’re on the program side - don’t screw hackers over! Seriously, information travels fast.

If you’re trying to find bugs as a relatively new hacker, pick something with a narrow attack surface that forces you to dig deeper. You’ll learn more that way.

Intuition

I would describe myself as a hacker that guides himself using his instincts. I don’t use a checklist - and while I can understand why some hackers would use one - it’s not for me. This intuition has been honed through practice and I have faith in the idea that I can hack anything with enough time and effort in the right places. Checklists are for pentesters, and pentesting approaches do not work in bug bounty.

Generating Ideas

I’m sure this is a familiar concept to you - but how many times have you been stuck on something, only to come back to it the next day and solve it in a few minutes? Sometimes all you need is a fresh perspective. If you get stuck on something, I recommend taking a break and going for a walk. Don’t bring your headphones - just leave yourself alone with your thoughts, and your mind will naturally start wandering and thinking of ideas. This “boredom” is a crucial part of creativity. If you’re stuck on something or it’s frustrating you - stop, take a shower, have some food, and maybe go to sleep - then come back to it with a fresh perspective.

Taking Breaks

Bug bounty is a gruelling process a lot of the time, so it’s more effective in the long run to take regular breaks, even if you feel like you can hack forever. Difficult attack surface can wear away at your mental state. If you’re a full-time bug bounty hunter, set aside at least one day or a few hours every day to recovery.

It also helps to use Pomodoro sessions to break up your day. I understand that the nature of hacking doesn’t always allow for this but if you’re doing some intensive research then this is almost a necessity.

Dissecting Attack Surface

Bug bounty is primarily impact-based. This means that the definition of what “impact” is will vary depending on your target. It’s useful to identify what the “crown jewels” of your target is. For financial companies, it’s anything affected payments or financial data. For chat apps, it’s the ability to access other users’ conversations. And so on.

To take this further, you’ll find less lows and mediums if you attack the parts of the application that have more value to the company. Rarely will a cool vulnerability in the authentication system be a Low severity issue.

Also, if you feel like you’ve looked at a program enough and that you won’t find anything - don’t give up. Keep going. Maybe around the 50 to 60 hour mark, you can start moving on, but spend at least 30 hours on the target before you even consider switching. Every program has a layer of depth that you can’t see until you spend 30+ hours on it. Every program. I’ve found bugs on unbelievably narrow scope simply because I stuck around and dug deeper.

Collaboration

I attribute a large part of my learning to working with other people. By seeing how others hack and find bugs, I can fill the holes in my own process and see where I’m going wrong. Not only that, but as a full-time bug bounty hunter, it makes my daily work much more fulfilling. I tend to go for a 50/50 split most of the time, but I’ll alter that split after speaking with the other person if I feel that the weight of work has been unequal in either direction. Fairness is important.

Never, ever betray the person you’re collaborating with. Bug bounty is a small field and everyone knows everyone. Breaching trust is a one-way road to ruining your reputation and putting future hackers off from working with you.

Collaborations can also help you escalate the impact of your existing findings. Pretty much everyone at the top level knows that Alex Chapman is the go-to hacker for turning headless browser SSRFs into RCEs using Chrome exploits. By speaking with more people you can learn what their strengths are; likewise they can learn what your strengths are, and you can rely on each other when you have something cool to escalate.

If you have any hackers near you, work together in-person as well! Throwing ideas at each other can lead to some really great findings and it’s hell of a lot more fun this way.

Specialisation

At a certain point in your hacking career, it helps to specialise in a specific technology or bug class. Establishing your reputation in a particular field or bug class means that hackers will come to you with this behaviour in the interest of collaboration. It also helps to do new research into these areas - you could push the boundaries of what’s currently known and find some zero-day vulnerabilities.

Picking what you want to specialise in is difficult, but generally it should be an intersection between what you enjoy and what is profitable. Follow your interests and you’ll naturally gravitate into your specialisation.

Specialising in a technology is also useful for finding jobs in the industry. Your portfolio of work might be exactly what a company is looking for. Maybe you’ve specialised in game hacking - this puts you in a prime position to find good game pentesting jobs.

Experience

Starting From Zero

People often ask how they should get started, or what they should learn. I cannot stress this enough: do not skip the fundamentals. By taking shortcuts, you’re just hurting yourself in the future. Refer to the Self-Education section for practical resources. The only way to become a successful bug bounty hunter is to be patient and consistent. You won’t become a hacker god in a day. Don’t put pressure on yourself to succeed and instead enjoy the learning process and hunting process, and take joy in working on targets.

Mentorship is incredibly useful for starting out but don’t message people begging for it. Experienced hackers are often busy with their own work. If you’re a complete stranger, why the hell would they help you? Think about it. Seriously, why would they help you if you’re clearly there just to take shortcuts? At the very least, demonstrate that you’re dedicated to the fundamentals and that you’re not just someone who takes and takes from others without giving anything in return. Mentorship is reserved for friends, not strangers, so make some friends in the space first.

Lastly, on reporting non-issues: this is not a necessary part of your growth. Do not report bugs if you’re uncertain of the impact. Before you report something - stop, and ask yourself, what is the impact of this? What harm could it cause to the company? If you’re struggling to come up with an answer here - do not report it. Have some standards for yourself! Many top hackers dislike reporting Lows. If you want to be one of them, hold yourself to the same standard.

Live Hacking Events

Trust me when I say that the top folks use the same tools that you do. If you ever go to a Live Hacking Event, you’ll find that people are duping on each other a lot, even for complex bugs. Why? Because we all think the same! Everyone at the event has accumulated enough experience to largely have the same thought process. Ask any decent hackers for 5 ideas on a particularly niche problem and at least 3 of them will be common with each other.

Every ambitious bug bounty hunter should strive to attend a Live Hacking Event. You get to meet so many cool people and Show & Tells have been an huge part of my growth as a hacker. It’s easier to qualify on the smaller platforms such as Intigriti but it’s still a Herculean task to make it to one.

Self-Education

Arguably the most important part of bug bounty is teaching yourself how to learn. Most importantly you need to enjoy the process. Don’t force yourself to learn. If you’re not enjoying the heck out of it then bug bounty isn’t for you.

Training Environments

• Portswigger Labs: It’s age-old advice and it’s correct. These labs are the single best free resource out there for learning to hack.

• XSS Gym by BruteLogic: For getting better at XSS, this is a really really good training ground. Also free.

• PentesterLab: Very good lab environments. Paid. Especially worth it for learning source code review.

• BugBountyHunter.com: Realistic training environment for bug bounty, created by Zseano. I haven’t tried this myself, but Zseano is a good guy and very highly regarded in the industry, so I’d trust this platform to do a good job of teaching you to hack.

• HexTree.io: Paid. The new kids on the block of teaching security, with industry veterans LiveOverflow and StackSmashing behind it.

Podcasts

• Critical Thinking: The go-to bug bounty podcast. I’m a regular listener. Highly recommended. Makes commutes or flights a breeze.

• Day[0]: Awesome podcast discussing many advanced topics. One of my acquaintances, Zi, is one of the people behind it and I can personally vouch for his experience.

Newsletters

• Hive Five: Probably the best of the bunch. I would not be where I am without Securibee’s newsletter.

• Bug Bounty Reports Explained: Very detailed case studies on various bug types. Grzegorz himself is also very skilled.

• MonkeHacks: My own newsletter. If you’ve read this far, then you probably like my writing, so stop reading for a second and subscribe.

YouTube

• InsiderPHD: A great channel for starting out in bug bounty. Katie is an acquaintance of mine and she’s super friendly in-person as well.

• PwnFunction: Some nice videos on topics that other channels might miss.

• Bug Bounty Reports Explained: Awesome channel for explaining complex vulnerabilities in a simple way. Grzegorz’s original venture into bug bounty content, I think?

• Stök: Stök is one of the OG hacker-influencers. His videos were a huge part of how I originally got into hacking - especially his videos on Live Hacking Events. His video of H1-4420 from 2019 was a huge inspiration for me and I had the chance to compete in H1-4420 last year so… full circle I guess?

• NahamSec: I never really watched much of his videos, but many of my friends got into bug bounty through watching his live recon videos. Highly recommended.

• Codingo: Great technical videos. He’s been successful in the space for a long time, and if you watch his content you’ll understand why.

• g0lden: His channel was created more recently but his content is excellent. Discusses a lot of topics that the other channels overlook, such as automation.

Coding

It’s not a necessity in bug bounty to know how to code, but it’s very useful. Coding allows you to write your own tooling, of course, but at a certain level of proficiency you can find vulnerabilities by making educated guesses on how certain backends were built. Having a solid programming background turns blackbox assessments into dark greybox assessments - you can get a small bit more visibility into what’s happening and it equips you with the skills to adapt to unfamiliar technologies as well.

Knowing Javascript is a prerequisite to any effective client-side hacking anyway, so taking the time to learn it properly and work on some hobby projects is hugely beneficial to your hacking career as a whole.

I’d also recommend rewriting existing tooling where it makes sense. Sometimes, public tools can miss things and you may not notice at all.

Conferences and Meetups

As with any security field, networking with other professionals is very important. The community as a whole is very wholesome and welcoming - if you’re respectful and nice to others, the world is your oyster. Check if there’s any HackerOne clubs in your country through HackerOne’s Brand Ambassador Program, or just join one of the main Discord servers on any of the major platforms and they’ll point you in the right direction.

Naturally Def Con is a major event every year and if you’re fortunate enough to have the means and time to go, I would recommend it. I went in 2022 and I had my many starstruck moments, such as seeing James Kettle present his latest research in-person. It’s a rite of passage for any aspiring security professional.

Comparing Bug Bounty to Pentesting

There’s a big difference between the two, and that is: pentesting is point-in-time. Bug bounty is continuous. Companies are constantly releasing new features. These features are rarely tested very thoroughly before they make it to production. Pentesting skills will be useful, of course, for hacking, but pentesting is usually easier than bug bounty. It doesn’t accommodate for changes in company infrastructure over time.

Conclusion

I hope this gave you an insight into what bug bounty methodology is. It’s not just the tools that you run. It’s everything - the tools, your mindset, your experience, and even the people you work with. There are no shortcuts, and if you do find shortcuts, then congratulations! You’re a great hacker. Finding gaps in systems is what we do. There’s so much more to doing well in bug bounty that I can’t write here, but this much should put you on the right track for a long time.

If you want more content, you can subscribe to my free newsletter or follow me on Twitter here. Don’t reach out to me for mentorship or whatever, I won’t respond if I don’t know you. Now that you’re armed with the knowledge to take on the world, go forth and find some cool stuff!