How To Think Like A Bug Hunter(Part1)

How To Think Like a Bug Hunter & Expert Bug hunters And how Deep Hunting on Your target

الحمد لله والصلاة والسلام على رسول الله وعلى آله وصحبه أما بعد

Hello HackerS

I’m Mohamed also known as 0xMado, a dedicated Web Application Penetration Tester and bug hunter

NOTE: The Write Up is Technical and hunting and The Write up Focus on Technical And How Hunting Get Your Coffee and Lets go If You Liked The Write up Dont Forget 50 Clapped And Thank you

Many people ask me how I start hunting on a new target, especially when the target is huge At first it can feel overwhelming because you might think How am I supposed to test everything on this target But honestly its easier than it looks

I see a lot of people saying Watch live hunting videos or Follow a methodology And honestly both of those can be useful

But if you’re just starting out I think there’s a problem with relying too much on other people’s methodologies You should just copy someone else’s methodology paste it into your own workflow and expect it to work for you

Instead, you should build your own methodology over time

Everything Start with a “Idea”

1- First Step Open Your Target ( Only)

What if I open my target The first thing you need to know is what the application does, how it works, and what services it provides

From the first look at the target, you can start to understand what the application is about For example, I can see that it has features like tasks teams, calendars, and assigning people to tasks

So now I have a basic idea of how the application works and what kind of services it provides

2- first stage ( Notes)

The first step in becoming a better bug hunter is training yourself to notice small details For example when I hunt with my friend (**Felopater Fady)** he once sent me some notes about a new target:

These notes are really important because they give you good scenarios and help you think about what you can test

What does this feature do

For example imagine an application allows an organization to have a maximum of 5 users At first that just a normal business rule But as a bug hunter, I immediately start thinking:

What happens if I try to add the 5th and 6th users at the same time This is where a race condition might become interesting

3- Three stage(Recon Manually)

When you’re hunting for bugs you need to be curious If you dont have curiosity you ll just use the application the way it was designed to be used

Because without curiosity, you’re just a bug without hunt :) For Example :

When I hunt on another target, I see a function called Invite People

I think: Can I find a Privilege Escalation, Session Not Ending, IDOR, etc.?

1. Before finding the bug, I invited a friend to my organization and then removed him from it

2. But I noticed something interesting: the invitation link was still working even after I removed him

3. My friend could use the same invitation link to join my organization again at any time

(Another Bug) I Got Privilege esc From Function Invite people Read The Write up: ***Here***

4- ( DevTools)

Right Click and Click on Inspect or F12 And DevTools Should Open when you open The DevTools Refresh or ctrl + R Your Target For Requests

if you Refresh Your Target You will see all Requests for example :

After Refresh

I always keep an eye on the endpoints , Just like during live recon whenever I open or interact with anything on the target, I take a look at the endpoints being used

Request Working With REST Post

And analyze the request and take a look at the response For example, if the request method is POST, I check what data is being sent to the server and how the server processes it Then, I analyze the response to understand what the server accepted, rejected, or returned

5- Analysis JavaScript ( Files)

I Have Blog Speaking on Analysis JavaScript ( Advanced: Click Here)

Why JavaScript Files Matter:

Although .js Files may look like unreadable gibberish at first, but they often contain: API endpoints , Request parameters , Hidden or unfinished features , API keys or tokens , Developer comments and notes

Over time, the more JavaScript you read, the easier it becomes to recognize patterns and understand what the application is doing

How to GET JS Files:

Look on Second Step up , All of these are JavaScript files, but wait, how can we tell which ones belong to the framework and which ones are actual application (developer-written) files

Click on any file to see the lines Call stack from Web application:

. Click on the Initiator tab to see which lines of the web application triggered the request

When You Click on Tap Initiator:

Now you have all the lines Web application Call it to create the request If you click on any line, it redirects you to the JS File For Read the line it

Example:

That its line Call from File js Working in Target

Critical Keywords to Search For

GET, POST, PUT, DELETE
/api/, /endpoint, /v1/, /v2/
apiKey, token, secret, password
setRequestHeader, Authorization
parameter, params, input, userInput
fetch, XMLHttpRequest, $.ajax
Credentials Hardcode

JavaScript analysis is a critical skill for modern bug hunting as 70–80% of application logic now runs client-side

6- Methodology ( Create My Methodology)

If your just starting out, you can follow other people methodologies They can help you learn what to look for and how other hunters approach a target But dont follow someone else methodology forever Over time, you should start building your own

But wait how do I create my own methodology? Once you understand how you hunt and what your looking for you can create your own simple and fast methodology

It can be as simple as a list of notes about the things you want to check when you first open a target.

This is My notes(Example) :

if you want look on My Methodology: Click Here

The Results:

The goal of this process is to understand the target and build a clear picture of how the application works By the end of my initial recon, I should have a better idea of:

• What the application does
• What features and services it provides
• What endpoints are being used
• What roles and permissions exist
• How users interact with each other
• Where sensitive functionality is located
• Which areas look interesting to investigate further

Most importantly I now have a starting point I dont need to test everything at once I can take what I learned from the application and turn it into questions hypotheses, and tests

And that the main idea of this part:

Don’t try to hunt the entire target. Understand it first then let your curiosity guide you

This is only the beginning. In Part 2 Ill go deeper into how I turn these observations into actual hunting ideas and tests

If You Want To Reach Me All My Contact Info is Here: Click Here

……………Thank You For Reading and I hope This Was helpful………………