Rat's methodology

What is it?

Over time i ran into some issues when i was following other people's methodologies. I was testing like my mentors and my hero's but it never felt like their way of testing quite fitted my way of life and i never found any bugs doing that.

I am a stubborn rat. When i can't find a way i make my own. I've developed a methodology that i think minimizes dupes beause i focus on out-thinking the competition instead of being the first to find a new subdomain or asset and testing it. I love leftovers 🙃.

The methodology

Picking a platform

This is very important in my opinion. There are 3 major players that i focussed on with each having their own unique advantages and disadvantages. I personally will always recommend Intigriti but that's a personal preference and you will see why.

All these points are based on my opinion. Opinions can change and alter over time, make up your own mind. You need to pick the program that is right for you and i encourage you to fact check these bullet points and even investigate a little for your own.

You have several options here. You can either go with one of the major platforms or try your hand at some google dorking to find a good bug bounty program to fit your needs.

List of Google Dorks to search for companies that have a responsible disclosure program or bug bounty program which are not affiliated with known bug bounty platforms such as HackerOne or Bugcrowd.


This is of course my preferred platform as i have been hunting on it for a while so i'll have a bit more to inform about when it comest to this platform.

➕ Positive items

➖ Negative Items


I don't have much experience with this platform so i won't have as much to say but i did form an opinion in my time using the platform.

➕ Positive items

➖ Negative Items


I have not hacked much on bugcrowd either so i can't tell you much about them, here's what i can tell.

➕ Positive items

➖ Negative Items

Picking a program

Picking a program is like picking a shoe, make sure you pick a program that fits you and that you enjoy hacking on. For the purposes of this chapter, i always try to go for applications where i can create users with different levels of privilege. I love testing on those programs because they contain a fair bit of business logic and we all know where this can lead you to. Examples of these programs are:

I also have some general tips for you as well. A lot of people will have the general tendency to go for a target with a very broad scope. This is a very bad idea if you ask me, let me explain why.

Recon only serves to help you find a target where you can apply your main methodology. After the recon you still need to hack and this is what a lot of people forget. After you spend hours doing your recon, all that work will just be to get you started. This is why i would recommend you try and fine tune your attack strategy on main apps first (No *.target.com domains)

VDP or paid?

VDP - vulnerability disclosure program (points or swag, no pay)

I would highly recommend people to start out on VDP programs, i have several reasons for this recommendation:

Fine tune your strategy and i assure you that the money will follow but you need to give it time! Rome was not built in one day either.

Uncle Rat's attack strategy

Starting out

When you first start attacking your target i want you to keep the following in mind:

Manually exploring the application

So now we have picked a platform, we have a program, now we finally get to the juicy part.

When i approach a new target the very first thing i do is get to know my target. I need to know all the functionality that's available and i do that by registering an account and using the application like a normal user would. while i do this i pay special attention to the privilege levels that are available and the functionality that was added on later like import or export functions. Any function that's added on top of another function brings an integration point because the two functions need to communicate. Often the original feature might be well secured but the additional functionality might not contain the same security features as the original.

While i explore manually i will have burp open and my scope set properly, this will populate the site map while i use the application. I need that for later. I can also read the manual (If there is none, it try google dorking). Reading the manual is very important, we are bug bounty hunters and we are at war with out targets. The manual is like a blue print of the application and in war information is power. As a last thing we can also read the api documentation if there is any or read the swagger docs.

I'll make sure to insert a XSS attack vector and template injection as soon as i create an account wherever possible to give myself the biggest chance of popping an XSS attack later down the line when i use the application.

This whole process of exploring my target and information gathering takes a couple of days easily. I want to know the enemy i am at war with. If it helps you, create a mindmap of your target using xmind.

XMind - Full-featured mind mapping and brainstorming tool.
XMind is the most professional and popular mind mapping tool. Millions of people use XMind to clarify thinking, manage complex information, brainstorming, get work organized, remote and work from home WFH.


When you are doing your initial recon, and especially if you use burp suite pro, you might find a lot of alarms going off. Say for example you use Burp Suite Pro, it might return some issues that it's found. Do not get too excited though, these vulnerabilities are often false positives. It is very important that you confirm ANY finding from ANY tool manually.

In bug bounties we have a saying "PoC || GTFO" which means you need to prove impact or Get The F** out. We say this because it matters, some reports might be totally unexploitable or not even impactful for the companies.

Exploring the requests in burp suite

After i know how my applications works, i am ready and armed with knowledge that will help me recognise vulnerabilities faster. I need to know how my application is supposed to work before i can start attacking it and now that we have a surface level map of our application, we need to go deeper. It's time to go to burp where our site map has been filling.

Burp suite has some amazing tricks in store for us. We can apply a filter so burp will only show us the parameterised requests in the site map. Navigate to the site map tab and click the big square box at the top to apply a filter and now click the checkbox next to "show only parametrised requests".

As a bug bounty my next step would be to go through these requests and see if i can find any interesting parameters i can tamper with. It comes down to common sense which parameters you investigate manually but it goes without saying parameters like "view=week" in a calender are not that interesting to us. We are looking for requests with parameters that trigger some business logic.

An example i am going to give is facebook, we all know facebook and facebook has several features we can use. We will focus on making a post, imagine we have the following requests in our burp window:

When someone makes a POST /CreatePost request we can try several things like XSS, SSTI,... on the Content parameter those are certainly interesting attack surfaces we can explore.

But those might have a bigger chance of duplicates because they are obivious. If you like a post however, a POST /Like request is being sent. If you can manipulate how many likes a post gets, that would be a valid vulnerability so let's investigate this call further.

The call was being sent when we clicked the like button and then the button turned blue and when we clicked it again a POST /Unlike request gets sent to the server so the amount of likes is added by 1 if you click the like button and subtracted by one if you click it again.

A smart hunter would send the POST /Like request to the repeater in burp and try to send it a couple of times and see if the amount of likes keeps going up. If it does, we have a vulnerability.

What parameters do i test for what vulnerabilities?

I will try to go through all the requests and see if I can find any interesting parameters. A parameter looks interesting to me in the following cases:

Automated testing

This will constist of me testing for IDOR but my methods differ. I try to pick a target where i can invite users within the account and I can also create user of different priviledge levels. This way i can:

Make sure you test ALL the priviledge levels and if you can create your own, make sure to do so.

Some targets will call this "roles" others might call it "groups" but as long as you can set different levels of priviledges; you will be fine.

After all is said and done i'll try to fuzz some endpoints for Command Injection and i'll try to identify some other endpoints to attack.

Identifying extra endpoints to attack

Sometimes we can use the presence of an API to determine the presence of another API. Say for example we are making a GET request to the endpoint /api/v2/getInvoices. In this case we might guess that there's possibe also a v1 of that API so i'll manually try to navigate to that URL. This is called inferring new API endpoints and can be very useful as older versions of an API are often less secure than current versions.

Another way of finding endpoints that are not in plain sight is to turn to the javascript files. We can ofcourse use tools such as linkfinder. these tools will scan the javascript file for us and return a list of all URLs found in the javascript file. This might reveal some untested endpoints which we hackers love but we can also manually go over the javascript file which will decrease the chance of hidden endpoints staying hidden for long.

A last possibility we can turn to is Google DORKing or github DORKing. If these don't bring me any new endpoints, i move on to a new target.

General tips