RECON Part 1: Finding Subdomains — How a Hardcoded Password Got Me $300

Hey everyone, Faiz here again. If you've been around bug bounty for even a week, you've already heard this advice a hundred times: "find subdomains, increase your scope." Everyone says it. Almost nobody explains why it matters or how to actually do it well. So in this one I want to share my own perspective on recon, plus the story of how a forgotten staging subdomain turned into my $300 bounty.

Why subdomains matter more than people admit

A company's main domain is usually the most hardened asset they have. Security teams test it, WAFs protect it, everyone's watching it. But subdomains? Those are the forgotten corners — internal tools, marketing pages, staging environments, old products nobody decommissioned properly. More scope means more surface area, and more surface area means more chances that someone, somewhere, made a mistake.

Rule one: never trust a single source

This is the part people skip. A lot of hunters run one tool, get a list, and call it done. But every subdomain tool has blind spots — one might be great at certificate transparency, another might be strong on DNS brute-forcing, another might pull from old web archives. If you only use one, you will miss things.

My approach is to gather from as many independent sources as possible, then merge everything into one clean list before I even start testing. Here's roughly how I structure it:

• Passive sources first — subfinder, assetfinder, Sublist3r, crt.sh certificate transparency logs, VirusTotal, GitHub code search for leaked subdomains, and old URLs pulled from web archives (gau). All of this happens without touching the target directly.
• Merge and dedupe — combine everything into one raw list and strip duplicates so I'm not wasting time on the same host twice.
• Active brute-forcing — once the passive list is solid, I run a proper wordlist-based brute force (Amass with a strong DNS wordlist) to catch anything passive sources never indexed.
• Permutations — this one's underrated. Take the subdomains you've already found and generate variations like dev-api, staging-auth, api-v2, etc. Companies tend to follow naming patterns, so once you find one pattern, permutations often reveal siblings nobody else found.
• Resolve and validate — run everything through DNS resolution so you only keep subdomains that are actually live, not just names that exist on paper.
• Probe with httpx — finally, hit every live subdomain to grab status codes, page titles, and detected tech stack in one pass.

Stacking sources like this is slower than running one tool, but it's the difference between a list of 50 subdomains and a list of 500 — and somewhere in that extra 450 is where the good bugs usually hide.

What I actually do once I have the list

Once I have my clean subdomain list, I open each one and check its tech stack with Wappalyzer and the data httpx already grabbed. This tells me what I'm dealing with — WordPress, a custom React app, an old PHP panel, whatever — and I hunt accordingly based on that stack.

But here's the part I genuinely enjoy the most: staging, static, and testing subdomains. The moment I see something like staging.target.com or static.target.com in my list, it jumps straight to the top of my priority queue. These environments are built for developers, not for the public, which means security is usually an afterthought. Most of the time they're locked behind authentication. But sometimes — not always, but enough times to matter — they're sitting there publicly accessible.

The story: a password that was never meant to be found

On one target, I found a static.[redacted].com subdomain that asked for a password before showing any content. Naturally, I wanted in. My first instinct was to fire up Burp Suite, capture the login request, and attach a wordlist to brute-force it.

Except there was no request. Every time I hit submit, Burp showed nothing — and the page still told me the password was wrong. That was the moment it clicked: this check wasn't happening on the server at all. It was happening entirely in the browser, client-side.

So I opened the browser's dev tools, watched the Network tab while submitting, and traced it to the JavaScript file handling the form. A quick search for "pass" inside that file, and there it was — something close to:

if (password == "PASSWORD_HERE") { loadContent(); }

The password was sitting in plain text in a file anyone visiting the page could download. I copied it, pasted it into the form, and got straight in.

Once inside, honestly, most of it mirrored the live site — except for a section showing some of their unreleased upcoming products. The team triaged it as low severity, but still paid out $300. It was my first real bounty off a subdomain, and at the time I cracked it with nothing fancier than Burp Suite and a habit of actually reading what the browser was doing instead of assuming the obvious path.

Since then I've picked up proper fuzzing techniques, and running fuzzing against staging subdomains specifically has become one of my most reliable sources of findings and bounties across other targets.

The takeaway

Subdomain recon isn't just a checkbox before "real" testing starts — it is part of the testing. Use multiple sources so you're not blind to what one tool misses. Prioritize staging, static, and testing environments, because that's where people forget security exists. And when something doesn't behave the way you expect — like a login that never sends a request — stop and ask why, instead of moving on.

As I always say: "Money follows skill. Focus on the skill first."

If it helped you, follow along — more writeups coming soon and feel free to connect on linkedin https://www.linkedin.com/in/khajafaiz/