Post cover image

June 30, 2026

Things Nobody Tells You When You Start Bug Bounty (I Learned the Hard Way)

I wasted three hours last month staring at this error:

By Makishima_ShogO

4 min read

"The remote name could not be resolved"

Three hours. On a private bug bounty program. Thinking the target was down. Refreshing. Retrying. Convinced I was doing something wrong with my tools.

Turns out I just didn't have a VPN connected.

That's the kind of stuff nobody writes about. Everyone posts writeups about the cool RCEs and critical IDORs. Nobody writes "here's how I spent an afternoon debugging my own setup before I even sent a single request."

So this is that article.

Who This Is For

If you just got invited to your first private program on YesWeHack, HackerOne, or Bugcrowd and you're sitting there wondering why nothing is working — this is for you. I'm not going to teach you how to find bugs. I'm going to teach you how to not block yourself before the hunting even starts.

Mistake 1: Not Reading the Program Rules Properly

I know. Everyone says read the rules. But I mean actually read them.

Most beginners skim the scope list and jump straight to testing. That's how you get your IP banned in the first ten minutes.

Private programs often have requirements buried in the rules that are easy to miss. Things like:

Mandatory User-Agent headers. Some programs require you to append a specific string to every request. Something like:

User-Agent: Mozilla/5.0 -BugBounty-[program-name]-[code]

Without this, your IP gets flagged and blocked. Automatically. The WAF doesn't care that you're a legitimate researcher.

How to set this in Burp Suite so you never forget:

Proxy → Options → Match and Replace → Add
Type: Request header
Match: ^User-Agent:.*        ← enable "Regex match" checkbox
Replace: User-Agent: Mozilla/5.0 -BugBounty-yourprogramname

Set it once. Forget about it. Every request going forward will have the correct header.

Mistake 2: Testing Without a VPN (and the Wrong VPN)

Here's what happened to me.

I was testing a private program. All my requests were failing with DNS resolution errors. I tried different tools. Checked my internet connection. Restarted Burp. Everything.

Then I noticed the program rules mentioned VPN.

Some programs — especially European financial companies — restrict access to specific regions or IP ranges. An Indian IP hitting a Spanish financial system at 3 am looks suspicious. The WAF will silently block you, or the DNS simply won't resolve outside their expected geography.

Once I connected to a Netherlands VPN server, everything started working.

Which VPN to use:

ProtonVPN free tier gives you 10 countries — Netherlands, Poland, Romania, Norway are all there. For European targets, the Netherlands is usually enough. For free hunting, it works.

One thing I noticed with Imperva-protected sites specifically: if you send too many requests from the same VPN IP, Imperva flags it. Then your browser starts getting "refused to connect" even though PowerShell was hitting the same domain fine ten minutes ago. Solution: disconnect, reconnect, get a fresh IP, slow down.

Mistake 3: Using PowerShell When You Should Use a Browser

Windows PowerShell's curl is actually Invoke-WebRequest. It behaves differently from real curl. And sites protected by WAFs like Imperva use JavaScript challenges to verify you're a real browser.

PowerShell can't execute JavaScript. So you get a 200 response that's actually just Imperva's challenge page with no real content. Looks like success. Isn't.

powershell

# This looks like it works but it doesn't
$r = Invoke-WebRequest -Uri "https://target.com" -UseBasicParsing
# Response is 200 but it's Imperva's JS challenge

The actual content of the page never loads because the JavaScript verification never runs.

Fix: use a real browser for initial recon. Use Burp with a browser proxy for actual testing. Use PowerShell only for quick DNS checks and header inspection.

Mistake 4: Ignoring What "Acceptance Environment" Means

A lot of programs list their staging/acceptance environments as scope. These have "-test" or "acc" in the domain name. They exist specifically for testing.

But sometimes these environments are internal only. Not accessible from the public internet.

I spent time trying to reach one such environment before I noticed: the DNS CNAME was resolving to a privatelink domain. Azure Private Link. Internal Azure VNet only. No amount of VPN switching was going to fix that.

CNAME → something.privatelink.westeurope.azurecontainerapps.io

That keyword — privatelink — tells you everything. This environment is behind private networking. If you see it, message the program and ask for IP whitelisting. Don't waste hours on it.

Mistake 5: Not Checking Spring Boot Actuator

This one is specific, but I keep seeing it.

Java applications built on Spring Boot often have an /actuator endpoint. In development it exposes everything — environment variables, configuration, heap dumps, HTTP traces. In production it should be locked down.

Should be.

https://target.com/actuator/health
https://target.com/actuator/env
https://target.com/actuator/mappings
https://target.com/actuator/heapdump

Try all of them. The /health endpoint being public is usually fine — it's just a status check. But if /env returns 200, you're looking at exposed environment variables. Database passwords. API keys. JWT secrets. That's a Critical.

If you find /actuator with only health exposed, note the response. Sometimes the health check leaks version info or internal hostnames. Useful for the bigger picture even if not reportable alone.

The Setup That Actually Works

Here's what I run now before touching any program:

1. Read rules completely. Note the User-Agent requirement. Note any VPN requirement.

2. Set User-Agent in Burp Match & Replace with regex enabled.

3. Connect VPN to appropriate country. Verify with:

https://whatismyip.com

4. DNS check on primary targets:

powershell

Resolve-DnsName "target.com"

If it fails, either the VPN is in the wrong country, or the target is internal.

5. Browser through Burp proxy. Browse the target normally first. Let Imperva's JavaScript challenges run. Build session cookies.

6. Then start actual testing from Burp with proper cookies and headers.

This sounds obvious. When I started, I was doing none of it.

One More Thing

The best finding I've come across so far wasn't from a fancy exploit. It was from reading JavaScript files in the browser's Sources tab.

Modern web apps ship their entire frontend logic as bundled JS. Inside those files are API endpoints, error handling logic, authentication flows, redirect parameters — everything the developer wrote, just minified.

Developer Tools → Sources → assets/ folder → search for "api/"

You'll find endpoints that aren't in any documentation. You'll see how authentication works. You'll find the redirect parameter that might be vulnerable to open redirect. You'll see error messages that reveal how the backend responds to edge cases.

Read the JS. It's the closest thing to source code review you'll get in a black-box program.

To Summarize

  • Read the rules. Actually read them.
  • Set the User-Agent in Burp before sending a single request.
  • VPN to the right country. Check for privatelink in DNS — it means internal-only.
  • Use a real browser through Burp, not PowerShell for everything.
  • Check Spring Boot Actuator endpoints.
  • Read the JavaScript source files.

None of this is glamorous. But it's what separates hunters who find things from hunters who spend their first two hours debugging their own setup.

I'm Raju Ranjan — bug bounty hunter and pentester with 100+ assessments under my belt.

I'm not the guy with a perfect track record. I'm the guy who debugged a VPN issue for three hours thinking the target was down. I still face problems on almost every engagement.

I write about the unglamorous side of this field — the parts nobody posts about.

If this helped, follow for more