The 3 Bug Hunting Habits That Made Me Go From $0 to $5k (And None of Them Are “Run a Scanner”)

I'm gonna tell you something that might piss you off.

You've been taught to hunt like it's 2018. Run Nuclei. Check for SQLi. Scan for open redirects. And then wonder why every report you submit gets marked "duplicate" or "informative."

Meanwhile, some hunters are cashing $5k checks for bugs you've probably walked past a hundred times.

The difference isn't skill. It's not tools. It's where they look and how they think.

Here are three habits that changed everything for me.

– -

Habit 1: Stop Hunting on the Main Domain. Hunt on the Forgotten Subdomains.

Everyone and there mother tests www.target.com. It's fortified. It has WAFs, rate limiting, monitoring.

But test.target.com? dev.target.com? api-staging.target.com? Those are often running old code, debug modes, and zero logging.

Here's what I actually do:

I don't just run sublist3r and call it a day. I look for subdomains that follow weird patterns.

Open SecurityTrails or Chaos Project. Search for *.target.com. Then sort by first seen date. The newest subdomains are often the most vulnerable. Why? Because they were just spun up for a new feature and security wasn't a priority.

Real example: Last month I found a subdomain called internal-reports.company.com that wasn't linked anywhere. It had a Jupyter notebook server running with no password. That was a $3k bug. No exploit. No payload. Just someone forgot to lock the door.

What you can do: Next time you pick a target, spend 20 minutes finding subdomains that sound internal or forgotten. Look for dev, staging, test, internal, admin, old, backup. Those words are gold.

– -

Habit 2: Attack the "Between" States, Not the Happy Path

Everyone tests what happens when you succed. Login works? Great. Upload succeeds? Fine.

Nobody tests what happens when something goes wrong.

Think about this:

Password reset, but you request it twice in one second. Does the second token invalidate the first? If not, you have two valid tokens. That's weird. I've seen account takeovers come from this.

Profile update, but you send empty JSON. {"name": ""}. Does it error? Does it accept it? Can you make your name an empty string and break the profile page? I once found stored XSS from an error message that rendered unsanitized input.

File upload, but you upload a 0-byte file. Does the server crash? Does it return a debug stack trace? Stack traces leak internal paths, database names, sometimes API keys.

Comment post, but you paste 10,000 characters. If it truncates badly, can you inject HTML at the exact cut point?

The method I use: Open Burp Suite Repeater. Take any normal request. Start breaking things one field at a time. Send empty values. Send long values. Send arrays instead of strings. Watch how the server reacts.

Developers write code for happy paths. Error handlers are an afterthought. An afterthought with bugs.

– -

Habit 3: Hunt for Logic Flaws Using "Time Travel"

This one sounds weird. Stay with me.

Some bugs only exist if you do steps out of order. The developer assumed users would do A then B then C. What if you do C then B then A?

Real example that paid me $2k:

A site had reward points. Normal flow: Buy product → Get points → Redeem points for discount.

I tried: Request password reset → Use reset link while logged in on another tab → Redeem points before password change confirms.

Turns out, the points system didn't re-authenticate after password reset. I could redeem someone else's points if I started there password reset and never finished it.

Another one from a friend:

A crypto exchange. Normal flow: Withdraw request → Email confirmation → Withdrawal processes.

He tried: Start withdrawal → Before clicking email link, withdraw again with a different amount → Click first email link.

The system processed both withdrawals based on the first email's approval. Double withdrawal.

How to think like this:

For every feature, ask: What happens if I interrupt this flow halfway? What happens if I start two flows at once? What happens if I do step 3 before step 1?

Then just try it. Most times, nothing. But when something works, it's usually high-impact. Scanners don't think in time travel.

– -

The Part I Want You to Remember

Every new bug hunter runs the same tools. Checks the same parameters. Writes the same reports. That's why they get duplicates and low bounties.

The hunters who make real money hunt where scanners can't go. Subdomains that sound like inside jokes. Error states that developers forgot to handle. Race conditions that no automation script would ever attempt.

You don't need to know 1000 exploits. You need to know where to look and how to break logic.

Take advantage of both.

– -

If this helped you think differently about hunting, clap and follow. I post one of these every day. Tomorrow I'm breaking down exactly how I found an IDOR in a GraphQL endpoint by complete accident. Those accidental bugs pay the best.