My First Bug Bounty : A Beginner's Web Security Investigation

𝐅𝐫𝐨𝐦 𝐎𝐯𝐞𝐫𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠 𝐭𝐨 𝐌𝐲 𝐅𝐢𝐫𝐬𝐭 𝐑𝐞𝐚𝐥 𝐖𝐞𝐛 𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐈𝐧𝐯𝐞𝐬𝐭𝐢𝐠𝐚𝐭𝐢𝐨𝐧

I wasn't looking for a $1,000 bounty that night.

I was just trying to prove to myself that I could find something.

My name is Bharanidharan S, a 2026 Cybersecurity Graduate and a self-taught beginner in bug bounty hunting.

I'm interested in web penetration testing, and like many beginners, I started with only a basic understanding of how web security testing actually works.

After completing college, I decided that I wanted to understand web penetration testing properly.

Not just the tools.

Not just the commands.

I wanted to understand the workflow.

How does a penetration tester actually think?

Where do you start?

What do you look for?

How do you decide what to test?

And most importantly…

How do you know when something is actually worth investigating?

The Comparison Trap

There was one thing I kept doing almost every day.

Opening LinkedIn.

And every time I opened it, I saw posts like:

"Received my first $300 bounty!"

Then another:

"$600 bounty — finally!"

And then:

"$1,000 bounty from a responsible disclosure!"

I was genuinely happy for them.

But somewhere inside, I felt disappointed in myself.

Because while other people were posting their successful findings…

I hadn't even received a single valid report.

That thought started following me everywhere.

Especially at night.

Around 11:30 PM, when everything became quiet and I was supposed to sleep, my mind would start running.

Am I doing this correctly?

Am I following the right path?

Should I focus on web penetration testing?

Am I learning the right things?

Maybe I'm not good enough.

Maybe I'm wasting my time.

And the more I thought about it…

the less I actually practiced.

Then I Realized Something

After days of repeating the same cycle, I finally asked myself a simple question:

"If I keep overthinking every night, what exactly is going to change?"

The answer was obvious.

Nothing.

Thinking about becoming better wasn't going to make me better.

Watching other people's success wasn't going to give me experience.

And waiting until I felt completely ready…

would probably mean never starting at all.

So I made a decision.

Stop comparing. Start learning. Start practicing.

I decided to go back to the fundamentals of web applications and build my understanding step by step.

No obsession with bounty amounts.

No trying to prove anything to LinkedIn.

Just one goal:

Become better at understanding how the web actually works.

Then came one night I still remember.

It was around 1:30 AM.

I wasn't sleeping.

My room was dark.

My laptop was open.

And my mind was filled with one thought:

"Maybe we can actually find something interesting tonight."

So I opened my laptop.

Instead of scrolling through other people's success stories, I decided to do something different.

I started looking for a target.

I used Google search techniques to discover publicly available bug bounty programs and potential targets.

There were plenty of possibilities. But one particular target caught my attention.

The name looked familiar.

That was enough to make me curious.

I opened the program.

But before touching the target, I stopped.

I went straight to the scope and program rules.

I carefully read what was allowed.

What was prohibited.

Which assets were in scope.

Which testing methods were permitted.

And which activities could get me into trouble.

Because one thing was becoming clear to me:

Finding a vulnerability isn't the first skill a bug bounty hunter needs.

Knowing where you're allowed to look comes first.

I read the scope again.

And then once more.

Only after I understood the rules did I begin thinking about the application itself.

At that moment, I still had no idea whether I would find anything.

I didn't know whether this would become another unsuccessful attempt.

I didn't know whether I was about to discover a vulnerability.

But for the first time in a long time…

I wasn't overthinking anymore.

I was actually doing the work.

And that night was about to teach me something I couldn't learn from someone else's $1,000 LinkedIn post.

The investigation had finally begun.

Target Discovery

To identify potential bug bounty targets, I used the following Google Dorks query:

("Responsible Disclosure" OR "Bug Bounty" OR "Vulnerability Disclosure" OR "Security Reward" OR "Vulnerability Reward" OR "Security Policy" OR "VDP" OR "Found a Security Vulnerability" OR "inurl:security.txt")
AND
("$" OR "bounty range" OR "Monetary Reward" OR "reward scale")

("Responsible Disclosure" OR "Bug Bounty" OR "Vulnerability Disclosure" OR "Security Reward" OR "Vulnerability Reward" OR "Security Policy" OR "VDP" OR "Found a Security Vulnerability" OR "inurl:security.txt")
AND
("$" OR "bounty range" OR "Monetary Reward" OR "reward scale")

After identifying a potential target, I did not immediately start testing it.

I first checked the program's official scope and rules to make sure the assets and testing activities were permitted.

Tools Used

Subfinder — Passive subdomain discovery
Sublist3r — Subdomain enumeration
crt.sh — Certificate Transparency based subdomain discovery
httpx — Identifying live and reachable hosts

My Subdomain Enumeration Methodology

I wanted to avoid relying on a single enumeration tool.

So, I initially ran multiple tools to collect as many subdomains as possible:

Subfinder + Sublist3r + crt.sh

Each tool produced its own list of discovered subdomains.

I then combined the results and removed duplicate entries to create a unique subdomain list.

After that, I used httpx to identify which of those discovered hosts were actually live and reachable.

The workflow was:

Multiple Sources → Combine Results → Remove Duplicates → Check Live Hosts → Analyze the Results

After completing this process, I ended up with approximately 160 unique subdomains for further analysis.

And this was only the beginning.

I now had a much larger attack surface to understand.

The next question was:

"Out of these 160 subdomains, which ones are actually interesting?"

As a beginner, I wasn't sure how to prioritize them. So I used an AI assistant ( Claude )

I provided the discovered subdomains and used the following prompt:

Act as a 30+ year experienced Web & API Security Researcher and analyze my target subdomains to identify and prioritize the most interesting and potentially high-value assets for authorized security testing.

Act as a 30+ year experienced Web & API Security Researcher and analyze my target subdomains to identify and prioritize the most interesting and potentially high-value assets for authorized security testing.

The AI analyzed the subdomain names and suggested a priority order based on the names and apparent functionality.

One subdomain immediately caught my attention:

incident-desk.abc.com

I selected it as my next target for investigation. But there was an important lesson here.

AI didn't tell me that the subdomain was vulnerable.

It only helped me decide where to look first.

So now I had my next question:

What exactly is running behind incident-desk.abc.com?

The login page appeared with User Identifier and Access Key input fields. I decided to test for SQL injection to determine whether the authentication could be bypassed.