Bug Bounty Recon 101: Subdomain Enumeration Methodology

Most bug bounty findings do not come from clever exploit chains, they come from finding a target nobody else looked at. A forgotten staging subdomain, an old admin panel, a service someone spun up two years ago and never decommissioned. Good recon methodology is what surfaces those targets before anyone else on the program does.

Start with scope, not tools

Before running a single tool, read the program's scope document line by line. Note the exact domains and wildcards in scope, anything explicitly excluded, and any rules around rate limits or automated scanning. It is common for programs to include a wildcard like *.example.com but explicitly carve out a specific subdomain, such as a third-party support portal, that is out of bounds. Missing that distinction is the fastest way to get a report closed as out-of-scope, or worse.

Passive collection first

Once scope is confirmed, start with passive sources: certificate transparency logs, passive DNS aggregators, and historical web archives. This step sends no traffic to the target and builds a broad initial list quickly, often surfacing subdomains that no longer resolve but still reveal naming patterns worth exploring, such as api-staging or internal-v1, that hint at what else might exist.

A good passive pass alone regularly turns up dozens or hundreds of hostnames on a large target, most of which the security team has forgotten about entirely.

Active validation second

With a candidate list in hand, move to active validation, resolving each hostname to confirm it is actually live, and running a wordlist-based brute-force against the target's DNS to catch anything passive sources missed. This step touches the target's infrastructure, so it should only run against confirmed in-scope assets and at a rate that respects any limits the program has set.

Live-host filtering and screenshotting

A raw subdomain list is not a target list. The next step is filtering for hosts that actually respond on common ports, typically 80 and 443, then taking a screenshot of each live host. Screenshotting at scale turns a list of hundreds of hostnames into something visually scannable in minutes, letting you spot login pages, default error pages, exposed dashboards, and obviously outdated software at a glance instead of opening each one manually.

Prioritizing targets

Not every live subdomain deserves equal attention. A practical priority order looks like this:

1. Admin and internal-sounding panels, such as admin, internal, or ops, which often have weaker external hardening.
2. Staging and development environments, which frequently run debug modes or outdated dependencies not present in production.
3. Old or legacy subdomains tied to deprecated products, since these receive the least maintenance attention.
4. Newly created subdomains, which can indicate infrastructure still being configured and not yet fully secured.
5. Core production subdomains last, since these are typically the most reviewed and hardened.

A repeatable workflow

The methodology above works best as a repeatable loop rather than a one-time pass: re-run passive collection periodically, since new certificates and DNS records appear constantly, diff the results against your last scan, and focus fresh active validation on whatever changed. Programs with large, actively developed attack surfaces reward hunters who catch new subdomains within days of them appearing, not months later.

Frequently asked questions