My process when I approch a new target

public
5 min read
My process when I approch a new target
Photo by Glenn Carstens-Peters / Unsplash

Table of contents

It can be hard when you first arrive at a new target. You will see that top hackers already went there and found pretty juicy bugs, so it can be hard and you think that you will not find anything. But it's wrong, it's not because a lot of people went there that you will find nothing.

A few weeks ago, I arrived in a program who existed since last year, and a lot of good bugs had already been found by good hackers. But I still found a lot of juicy stuff on it because I looked at different places with a fresh mind. And today I want to explain my kind of methodology.

How do I choose a program?

When I look at a new program, I first look at if I know the company or the app in the program. Simply because if you already use this software, it will be easier to find bugs cause you already know the app.

In my opinion, it's hard to go to a big app you don't know and you don't even like, just because it pays well. I prefer to focus on a small program and find juicy stuff instead of going to a program I don't like. Of course, I look at the payout and if the responsiveness of the program is good, but you never know before pushing a first report on it.

I found that many great hackers only focus on a few targets during months and months to know the app, the business impact, and it works pretty well.

Why do people stop hacking on a target after one week?

A lot of people just start on a target, hunt on it for one week, and then move out to another program because they found nothing. To me, it's the wrong way to do it. It depends on your objective and if you like the program, but if you like it, it's not after one week that you will find something.

There are a lot of programs where I didn't find anything during the first two weeks of hunting, and then, I found a lot of juicy stuff. The reason behind that is simply that I knew the app very well after two weeks. That's why my methodology is not a checklist to apply to every piece of the app.

How do I approach my target?

When I arrive at a new app, I just launch Caido in the background and I use the app as a normal user for a lot of time, just to understand it. Sometimes it will be 1 hour and sometimes 2 or 3 days.

The goal behind that is to fully understand the app and the business. It can be simple to find an XSS but if you don't know how to exploit it and find a real impact, it will not pay well. By looking at the app as a normal user, you will understand which part of the app is important and where to put your focus.

I ( sometimes ) take notes about it where I found a juicy part to go back then. I think that it's important to take notes about your target if you plan to stay on it for a lot of time. I know it's hard, and I don't take a lot, but I'm going to write an article about my way to take notes for bug bounty.

When I started, I just wanted to find bugs and we all want, so we only focus on finding our XSS or IDOR but we don't even know the app and the impact behind those.

Everyone goes to the app and directly looks at bugs. So it's normal if you find nothing, someone already found it and reported it. But if you stay consistent on it, you will find more impactful bugs, with business logic and interesting stuff. Of course, if you directly found an XSS at the beginning, report it, but don't stop looking at the app just because you found nothing.

I don't want to give you a checklist of what I look for, or which kind of bug you can find, simply because It depends on the app. Don't rely on a checklist or the methodology of someone else. Just build yours by looking at the parts you fully understand.

I love access control bugs, they are easy to find in my opinion. So that's were I look for at first. I set up multiple accounts with different levels of privileges, and I check if someone can do some action the others can't. You know, not a lot of people will look at this type of bug. Because it takes time, and you will need to think. Bug bounty is not only automation and putting payloads everywhere. You will see that it's fun to take time to understand a target and to find interesting stuff.

So just pick up a target you like, even if a lot of people went on it. Not a lot of hackers will stay consistent in a lot of programs, they will take one or two and focus on it. Maybe they just found some bugs at the beginning and then moved out to another target.

How to report then?

When it comes to reporting, you need to write the best possible report, even for a simple IDOR with increment. Why? Simply to show the program that you are a pro. My advice is to create a bunch of templates, easy to use to just replicate some bugs you found a lot.

You can create templates using ChatGPT and put on it resources like OWASP links and general stuff to show the impact of this type of bug and how to mitigate it.

Just don't only put your payload and no explanation behind it. The program may pay you, but they will not understand the impact, how you found the bugs, and how to mitigate them. It will be better for you and them if you explain the impact on the business, the app, and how they can fix that quickly.

If you can add a part in your report with the requirements of the bug, it can help the triager to do it faster. For instance, if there are a lot of different privileges, explain well what kind of user you took and how to create a user like that.

I got a lot of messages that my reports were well written and I got a lot of points for that. Programs will be great with you if you come up with a good report instead of a simple payload.

As I told you, my methodology is very simple, maybe the simple one compared to the others. But it's a methodology when you want to stay consistent on a target for a long time.

Next time, I will try to write an article about how to handle news and notes about my targets and my knowledge so feel free to follow me on Twitter to see the next one!

Aituglo

Aituglo

Paris
The author of this blog, a bug bounty hunter and security researcher that shares his thoughts about the art of hacking.