In the beginning everyone’s crap at bug bounty hunting. Apart from all the obvious reasons why, the lack of detailed notes and an organized methodology may also contribute to this. Let me, however, right at the start of this article, reiterate that this is solely my opinion. This piece is from subjective experience and may differ from person to person.

💡Update (20th Jan 2022)

I wrote this piece on “Medium blog” two years ago on the 7th of Jan 2020 (wow, time flies).
I don’t do bug bounty hunting anymore. I know, I quit! Not that I don’t entertain the idea of coming back to it, but at least for now, it is not for me (stressful/frustrating). However on the plus side, I realized that I have a natural inclination towards wanting to learn Open Source Intelligence (OSINT). I find OSINT more interesting. And it is challenging. In fact I have picked up the most recent (8th) edition of Michael Bazzell’s book and also the Video Course called Open Source Intelligence Techniques. Hopefully my OSINT journey would be a great learning experience. Its extremely tough to balance work and learn something like OSINT, but I don’t stress too much and try my best to learn as much as possible.

I might not be some Bug Bounty expert, but this piece would be useful to all those beginning their journey in Bug Bounty, as it was to me, though it was a short stint of just 10 months (of hacking, but around 2 years of learning and part-time hacking, totally).

📄The need for notes and an organized methodology

As a beginner, doing bug bounty hunting for the last 7 months, I have realized there is a need for a solid bug hunting methodology and note making to up my bug bounty game. So, why is this?

Well, all of us know we need to read, learn and practice to improve. I did a lot of reading and learning prior to starting with web application hacking. However, I never made notes and did not have a clear methodology to bug hunt. As a result this was what my methodology looked like when I started with bug bounties. It was crap!

My first bug bounty hunting methodology
My first bug bounty hunting methodology

You see, in spite of all the learning, I felt overwhelmed when I started. This is okay. No problem. After all I just started. I knew I could improve eventually. So, I continued reading a blog post here, watching a video there, confident I was subconsciously absorbing everything. What I did not realize was, all this I was taking in, was not organized and my brain could not connect dots to create neural pathways necessary to have a solid game.

🎥FourZeroThree – YouTube

Heads up! Did you know I also run a YouTube channel by the same name FourZeroThree? I try to create short and entertaining videos out of the articles I post. Don’t forget to check it out!

You start attacking a website, realize you don’t remember a lot of what you had learnt and frantically search your bookmarks and browser history to go back to that blog article or video that taught you something you wanted to apply (no notes). After doing this (and wasting time) you don’t know what to do next (no methodology). Sounds familiar?

Most bug bounty beginners are lost and I see many them on twitter asking established hackers for a step by step methodology to approach a target web app. Don’t do this. You need to get your shit together on your own, and for that learning alone won’t suffice. You need to patiently invest time in note making and crafting (and later tinkering) a methodology to apply.

I think investing time and taking efforts to do so could make you a much better hacker. After 6 months of bug hunting and getting frustrated with my progress, I decided to take time off for a month, went back to reading, made a ton of notes and crafted a methodology for myself to apply during bug hunting. This is very important for beginners, especially when you are still not creative, when you have not fully begun to think like a hacker. Making notes and creating a methodology doesn’t guarantee immediate success, but it greatly amplifies your speed of becoming a better researcher/hacker.

👨‍🎓So why would beginners need to make notes?

It makes learning easy

  1. Making notes reinforces what you have learnt. Also you could always go back to these notes and get a quick refresh when you have to.

  2. Rather than having to go through an entire blog post or quickly scanning through a video again, you could make concise notes of whatever you learnt and go back to the blog post or video only if you really have to.

  3. If you have a list of resources according to different bug classes neatly organized, you don’t have to frantically look through your bookmarks or browsing history to find a particular resource.

Helps you create and adhere to a methodology

  1. Making and organizing notes eventually help you create your own methodology. If you have your notes neatly organized into different chapters/bug classes, creating a step by step methodology of bug hunting becomes a lot easier.

  2. Rather than having a mental checklist of tests, you could have your notes open and check if you have tried everything during bug hunting. This is healthy because a) you would you not miss out on doing something, b) every item in your note checklist would eventually become a part of your mental checklist in the long run.

  3. The habit of making notes all the time, segregating them neatly and taking the efforts to create and tinker your own methodology would also leak into your bug hunting experience. It becomes more organized increasing your chances of success.

🤘How you could create your methodology

A) Making notes (while learning), organizing them and recognizing different attack patterns

When I sat down to create a methodology I was confused and overwhelmed. Where does one start? You start with the most simple methodology.

The most simple methodology
The most simple methodology

From here you start to ramify/diversify. Lets say you want to start with attack vectors. How do you start? For best results, pick a vulnerability class and learn as much as possible from many different resources even if it is reading about the same stuff. Dedicate at least 2–3 days (minimum) to learn a particular attack. Read as many articles and watch as many videos as you can. The next step is to make notes after (or while) reading, organizing them and trying to recognize different attack patterns.

🗣Let me tell you what happened when I did this.


I started with the most simplest of attacks


trying to tamper with the “Forgot password”

functionality (this of course can be classified as an attack based on functionality rather than a particular bug class. I also made notes this way because it helps in real world bug hunting). After reading many reports and articles on this, I made notes and organized them. What I got out of this was different patterns of attacks.

  • Leaking of password reset token in the response (immediately after requesting a password reset via “forgot password”).

  • Getting the password reset token to the attacker’s email address via HTTP parameter pollution.

  • Host header poisoning (setting the Host header to the attacker’s server)

  • IDOR → changing the victim email or user ID to attacker email or user ID

  • Password reset token not expiring

  • Brute forcing password reset tokens

  • Logic flaws in “forgot password” functionality

You see, now while testing I would have a checklist. This would become a part of my methodology.

This is where I found PortSwigger’s Web Sec Academy to be very useful. They start with a bug class and keep leveling up just like how you might encounter stuff in real world web applications.

Take CSRF for example, they have different labs:

  • Validation of CSRF token depends on request method

  • Validation of CSRF token depends on token being present

  • CSRF token is not tied to the user session

  • CSRF token is tied to a non-session cookie…

and so on. After practicing these labs, I literally made note of all types of CSRF attacks listed there. So, now I have a methodology for CSRF when testing in real world applications.

You get the point don’t you? This of course is a laborious process but well worth it in my opinion. Start doing this and a methodology unique to you magically starts to evolve.

B) Getting into the minds of your favorite hackers

Another method I tried doing was to literally get into the minds of successful hackers.

I want…

a) to know what successful hackers are doing

b) want to validate my methodology with theirs to know I am headed in the right direction.

This is what noobs try doing when they ask elite hackers on twitter for a methodology. Apart from the lazy newbies wanting a methodology to be literally handed over to them, hardworking newbies on a deep level want validation for their methods of bug hunting.

You see, our favorite hackers are literally dropping cool tips left and right in their tweets without us realizing. We tend to follow so many hackers on twitter and our newsfeed is literally cluttered with tweets which we read and eventually forget.

In order to get more value off of the tweets of successful hackers, I started doing an advance search of their tweets. Navigate to Twitter’s advance search, type in the names of hackers, type in some keywords and hashtags.

Remember that

“keywords have to be related to what you want to learn about”.

For example, if you want to read someone’s tweets on recon, then type in keywords like…

  • “recon”,

  • “content discovery”,

  • “discovery”,

  • “subdomains”

and so on. Get creative. I did this, spent hours going through tweets and taking notes. What is underestimated here are the twitter conversations. I literally opened up every twitter reply and also read conversations with regards to a particular tweet. You then build on these notes and do further research and reading. This massively helps

  • you learn about a particular vulnerability class.

  • build your bug hunting methodology.

  • validate your bug hunting methodology.

I have realized that my desire to have a solid game, lies in becoming organized, making notes and having a methodology crafted out. Every bug hunter’s methodology is unique and what makes it interesting is that it is dynamic. It keeps evolving. In fact it has to. Know that your progress plateaus if your methodology does not evolve. It may be the most subtlest of changes, but it has to keep evolving over the long run.

🏃‍♂️Where to next?

And hey, by the way, please do give FourZeroThree a shout-out to your friends and colleagues, would you? Would really appreciate it! Cheers and happy reading 🙂

Share FourZeroThree