// LEARNER HUB — ARTICLE

Building a Recon Workflow: From Subdomain Enumeration to First Findings

By Johnthebandit // Genesis Vault

Every experienced bug bounty hunter has a recon routine they run before they've even opened a proxy or looked for a single vulnerability. It's unglamorous work — a lot of it is just cataloguing what exists — but it's usually the difference between hunters who find bugs consistently and hunters who only find bugs on the pages everyone else already tested.

Why Recon Comes First

Most public bug bounty programs get thousands of eyes on their main login page and their main dashboard. The findings that actually pay well tend to live on the parts of the attack surface fewer people bother to map: a staging subdomain someone forgot to take down, an internal admin panel with a predictable name, an old API version still running alongside the current one. You can't test what you haven't found.

Subdomain Enumeration

The first step is building a list of everything that resolves under the target's domain. This combines passive sources — certificate transparency logs, DNS aggregation services, historical scan data — with active brute-forcing against a wordlist of common subdomain names. The goal at this stage isn't depth, it's breadth: get every subdomain that has ever existed onto a list, then filter from there.

Filtering to What's Actually Alive

A raw subdomain list is mostly noise — dead records, parked domains, things that resolve but return nothing useful. The next pass is checking which hosts actually respond, on which ports, and what's running there. This is where a lot of hunters start noticing patterns: a cluster of subdomains all running the same outdated CMS, a set of hosts that all expose the same misconfigured admin login.

Content Discovery

Once you know what's alive, the next layer is finding what's actually on each host beyond the homepage — hidden directories, forgotten API routes, backup files an admin left behind, JavaScript files that reference endpoints the visible UI never links to. Reading a target's bundled JavaScript is one of the highest-value habits a hunter can build: it routinely reveals internal API paths, feature flags for functionality still in development, and sometimes hardcoded credentials or keys that should never have shipped to a browser.

Turning Recon Into Findings

Recon by itself isn't a vulnerability — it's a map. The actual bugs come from taking that map and asking specific questions about each piece of it: does this staging environment use the same weak default credentials as the demo docs? Does this old API version still accept the auth token format the current one deprecated for security reasons? Is this admin panel exposed to the internet at all, and if so, is it actually meant to be?

Building the Habit

New hunters often want to skip straight to "finding the bug," but the ones who consistently place on leaderboards treat recon as a repeatable process they run on every new target, not a one-off chore. Genesis Vault's recon-focused labs and the AI Terminal are built to make that workflow — enumerate, filter, discover, investigate — something you can practice as a repeatable skill rather than something you do once and forget.

// Want to practice this hands-on? Get 50 VC instantly on signup.
[ JOIN THE VAULT ]
← Back to all articles