Hi! I’m Riccardo Malatesta, and in this article I will give you my point of view and show you how to start in bug bounty hunting.
I work in offensive security and have been doing bug hunting for years. It’s been a bumpy ride, but I’ve learned a lot and achieved some decent results.
Recently I shared a couple of payments, and whenever I do, I get some questions about how to get started and advice for beginners.

This really makes me happy, as it validates the work I do even more and gives me the opportunity to help others.
This is why I decided to write this article; a Tweet (or X?) is not enough to express myself at my best.
I’m definitely not the greatest, but I know what I’m doing, and I’m confident in my abilities. I hope that my experience and my point of view can be useful to you.
So, let’s start! Who am I to speak?
My Background
I’ve always been interested in hacking. Since I was 14, I have viewed hackers with fascination. I thought they were some kind of mythical creatures with great powers.
This is why I chose to study computer science. I’ve learned how to program in different languages and in 2018 I encountered the world of bug bounty hunting.
That first attempt ended with 5 or 6 valid reports on HackerOne, and triple that in N/A, informatives and duplicates. Even though it was a failure, it helped me learn many things: how to write a report or even why a vulnerability is worth a payment.
Then I let it go for a while. I only started hunting consistently at the end of 2021, and that’s when the results started coming, bounties included.
In between, a lot happened. I had some work experience with penetration testing, learned a lot more, and met a lot of great people in the industry.
As of today, I have identified over 150 valid vulnerabilities, ranging from low to critical and excluding duplicates, across various bug bounty platforms.
Along the way I’ve hacked some big companies, Google included. I spent a good chunk of that time attacking their AI, and I wrote about it here: “Hacking Gemini: From Indirect Prompt Injection to Data Exfiltration“. Those specific reports ended up as duplicates, but other accepted vulnerabilities got me into their leaderboard.
I have participated in live hacking events, achieving multiple podium placements with my team.

I’ve also obtained my OSCP, an achievement I’ve wanted for many years.
A quick note on this: no, you don’t need certifications to do bug bounty hunting. The OSCP didn’t help me find bugs. I took it because it was a personal goal I’d had for years, not because it was necessary. In this field nobody is going to judge you by the certs on your profile, only by the results you get.
This was my journey in a nutshell. Now, what are the steps to take if you’re just starting out in bug bounty hunting?
What can you do?
I made a lot of mistakes at the beginning and wasted a lot of time. If I could go back in time, I would do things differently. I don’t have a time machine, but at least you can learn from my errors.
The first thing I would do is study the most common web vulnerabilities. PortSwigger’s Web Security Academy is definitely the best resource available, and it’s free too!
If you can spend some money, you should also check out PentesterLab Pro.
Learn the theory and practice as much as you can with the labs, but don’t get stuck in the learning process. You also need real-life validation (more on that later).
After learning how the most common vulnerabilities work, you should read and study public reports. I suggest you focus on reports that have received a bounty. This will help you get an idea on how to write a good report that gets paid.
Check Hacktivity on HackerOne to find all the bugs disclosed on the platform. Also, check this video by @InsiderPhD:
Don’t underestimate the power of a good report! Not only will it guarantee you a bounty, it might even get you a bonus.

So what does a good report look like? This is the structure I use every time:
- Description: what you found and why it’s a vulnerability. Brief, but complete.
- Impact: what an attacker can actually do with it.
- Steps to reproduce: how to get there, in order.
- PoC: a video or screenshots showing it happening.
- Remediation: how it should be fixed.
Two of these matter more than the rest.
The impact has to be provable, and as high as you can honestly take it. Not “this could allow an attacker to…” with nothing behind it. Show what you actually did, without causing any damage of course. Speculation doesn’t land, and triagers read a lot of it.
The steps to reproduce have to be simple to follow. My own test: if I write them and then struggle to follow them myself, they’re not good enough yet and I rewrite them. Same idea for the PoC, it should make it obvious what’s wrong and why it’s a vulnerability, without the reader having to work it out.
If you have done things correctly, by now you should know how to discover a vulnerability and how to report it properly. It’s time to get your hands dirty!
Time to hunt!
Explore bug bounty hunting platforms, find a program worth your time and search for your first vulnerabilities!
HackerOne and Bugcrowd are the biggest platforms out there, so you should definitely spend some time on them.
You can also find many more opportunities here: “Bug Bounty Platforms: Open-Sourced Collection of Bug Bounty Platforms“.
How do I decide if a program is worth my time? I look at three things: how fast they respond, how much they pay (at least 300€ for a medium and 3000€ for a critical), and whether there’s enough surface to actually test.
That said, I don’t follow this rigidly. Most of the time I go with my gut, and if I feel like giving a program a shot anyway, I go for it.
The fastest way to find out what a program is really like is to send them something small first. Pick a low or medium hanging fruit, report it, and watch what happens: how long they take, how they triage it, how they pay. That will tell you more about a program than anything written on its page.
One more thing, and it’s the tip I’d insist on the most: aim for the big programs from the start. Google, Meta, AWS. Are they hard? Absolutely. Will you find your first bug in a few weeks? Maybe, but most probably not. Go for them anyway. A big program with a lot of top hackers actively hacking on it is always worth your time.
It might take months, or more, before your first valid bug. Keep that in mind, remind yourself that what you’re doing is hard and that you’re not supposed to see immediate results, and keep going.
A tip: look for a single vulnerability category at a time. Pick one, go deep, learn every variant of it. This will allow you to be more focused and increase your chances of success.
A lot of people start with XSS, and I get why: they’re common and relatively easy to find. But here’s the thing, focus on vulnerabilities that actually pay. An alert popping your document.domain will usually get you a low or a medium. Nothing wrong with that, it’s a great way to learn, just don’t expect it to be your bread and butter.
I’m telling you this because it’s the exact mistake I made. XSS was my category, and for a long time I stopped at the alert box. Find the injection, pop a simple payload, write the report, move on to the next one.
It capped me twice over: lows and mediums on the payout side, and a skill set that stopped growing the moment the alert fired. If I had pushed every finding further, asking “ok, and now what can I actually do with this?”, I would have had better results from the start and learned a lot more along the way.
If you want to stick with XSS, that’s fine, but make sure every one of them has an undeniable high or critical impact: privilege escalation, account takeover, or a chain with another bug like cache poisoning. Otherwise, specialize somewhere else early on. The effort is the same, the payout is not.
In the long run, you’ll need to understand the entire OWASP Top 10, but to start and get some tangible results, I think this focused approach works well.
One final tip: look for people who are on the same journey as you. You learn very quickly when you study with others, share resources and ask for help when you don’t know where to turn. Twitter (or X) is still a great place for this: I met every hacker I shout out at the end of this article there, and we’ve been talking on Discord ever since.
On Recon, Automation and AI
Let’s talk about it. Recon, automation, AI: everyone wants to jump straight there. If you’re just starting out, don’t.
Think about it for a second. How do you do recon if you don’t know what you’re looking for, or why? How do you automate something with a script or an AI agent if you have no idea what should be automated in the first place? You’d just be running other people’s tools on targets you don’t understand, hoping something falls out. It rarely does.
The only exception, maybe, is using AI to learn. Ask it to explain a vulnerability class you’re struggling with, to review a report you wrote, to walk you through a payload you don’t fully get. That’s a good use of it.
For everything else, just take the first steps: study, practice, hunt. Automation, recon and AI will come naturally. One day you’ll catch yourself thinking “wait, every time I hunt for this bug I do the exact same five things, a script would do it for me in half the time”. That’s the moment. Not before.
For me it was subdomain discovery. There are a lot of great tools out there and they all give you slightly different results, so every single time I was running them one by one and then merging and cleaning the output by hand. That’s what I automated first. From there it kept adapting, one piece at a time, until it became EasyG, plus a pile of separate scripts I wrote for specific occasions.
These things are a consequence of building your own skill set, not a shortcut to it. You learn them by doing, not because someone sits you down and teaches them to you.
Conclusion
To recap, here are the steps to get started with bug bounty hunting:
- Study the most common vulnerabilities
- Learn how to write a good report that gets paid
- Pick a program worth your time, and don’t avoid the big ones
- Hunt for your first vulnerability
- Meet and collaborate with other hackers
- Let recon, automation and AI come later
It’s simple, definitely not easy, but if you truly have a passion for this field, keep going no matter the difficulties.
You’ll encounter N/A, informatives and duplicates, everyone does. Understand why it happened, learn from it, and keep moving forward.
I want to share with you a video that was very useful for me when I was getting started, by STÖK:
I also wanted to give a shout-out to some great hackers: MOPAM, drak3hft7, Leo Rac and Al7eX. They are incredibly skilled and have helped me a lot on my journey, and still do. Give them a follow!
I hope this article was useful to you. If so, let me know in the comments or let me know what else you’d like me to talk about!
Until next time!
Riccardo

Leave a Reply