How I Made $9,000 in One Month from Bug Bounty

2 days ago 10

BOOK THIS SPACE FOR AD

ARTICLE AD

Hello everyone, it’s Milad! You may know me as Eulex. This is my first write-up in a while — sorry for the delay, but I promise to keep writing more frequently.

If you want to learn how to fish, read this. Otherwise… 💸

Last year, I read a few write-ups about insecure implementations that occur when businesses rush to adopt the latest technologies. As we all know, implementing security properly is always expensive and time-consuming. The golden takeaway here is that most developers don’t fully read the entire documentation when integrating new technologies. Sometimes, a single paragraph or even one sentence can make an entire system vulnerable.

By focusing on these overlooked details, we can discover vulnerabilities that others have missed for years.

Personally, I’m someone who narrows my focus — I can spend few months on a single domain that doesn’t even have many features. This means I read every single line of code to understand exactly how the target functions. I call this “Deutsch it” — meaning, do everything properly, no matter how long it takes, not just finishing.

If you’ve lived in Germany, you know how much time things take — but when they are completed, they are done with the highest quality possible.

Every so often, I revisit programs I have already tested. I open my XMind (a mind-mapping tool) and go through the brain tree I built while testing. This particular program was a big public program that every hacker had probably tested, so I had to approach it differently.

Since it was a shopping website with limited features, I had time to read its JavaScript code. After a month, I found some medium-severity vulnerabilities like IDOR, but my goal wasn’t just to find vulnerabilities — I wanted to test every single feature and break through to deeper issues.

During my testing, I came across a third-party payment service that Target used : PayU. I tried common vulnerabilities like double spending, race conditions, etc., but nothing worked.

Then, I remembered my “Deutsch it” mindset. So, I started reading the entire PayU documentation and watched a few YouTube tutorials (shoutout to my Indian brothers for their great explanations).

First, I drew the workflow and noted down key points. (By the way, I’m thinking about buying an iPad for this, but spending $1,000 on an iPad feels too much right now, so I stick to traditional note-taking! )

After drawing the complete workflow, I sat back and relaxed with my favorite grape juice from Lidl or Penny — they a few cents more expensive than others, but are really tasty 😁. If you curious about how they look, here you go

Not financial advice 😁

Once I had the workflow mapped out, I started thinking:
“What if the developer missed this step?”

I love finding issues in complex implementations, because the harder something is to secure, the higher the chances of mistakes.

After weeks of analyzing PayU, I tested different scenarios until I found this juicy exploit:

I placed some products in the cart and Target was redirected to the PayU payment gateway wich is like below.

Note: Before this, I bought a cheap product to see how the system handled payments.

2. When I canceled the order, PayU redirected me back to the target website with some URL parameters like below.

3. As you see modified the status to “Succeed” and replaced the payment_id with the one from my previous successful transaction.

4. The response came back, and BOOM — I got an invoice confirming the order, without actually paying!

I couldn’t believe it! After just a few minutes, I had successfully bypassed the payment system.

I reported the bug immediately. Within a day, the issue was fixed, and I received a $3,000 bounty for it.

Since I had done reverse engineering, I knew other shops were also vulnerable because their developers followed the same flawed implementation. By exploiting the same issue across different platforms, I eventually earned $9,000 in total!
Cusy trick you can do “Report one bug first, wait for it to be resolved, then report others. If you submit multiple at once, they might be grouped as one!”

This wasn’t an easy find. It took me multiple tests, and I even spent around $1–2 per test buying products just to experiment. Many hackers likely tested this system over the past 10 years but missed the vulnerability because they didn’t persist long enough.

By implementing the same setup in my localhost, I realized the issue:

When an order is created, the shop waits for a response from PayU before confirming the purchase and didn’t let create another Order.If the response contains a valid payment_id with a “Succeed” status, the target system confirms the order — without verifying it internaly with PayU for which order the payment_id actually belonged to!

This seemingly “easy” vulnerability took me three months to discover. But in those three months, I learned so much.

Some people might say, “You should have just focused on this one vulnerability, and you could’ve found it earlier!” But remember:

“You don’t know what you don’t know.”

Socrates

Bug bounty is all about testing thousands of features until one breaks.

I’m still working on similar exploits, and there’s always more to learn.

Big thanks to: @Voorevix (X) @MiniMjStar (X) @_0xaurora (X) Cristi Vlad And everyone who Motivated me in writing this!