Bug Bounty Recon Methodology: My Step-by-Step Workflow

Most of the valid reports I have submitted started with good reconnaissance, not with a clever payload. This post lays out my bug bounty recon methodology as a step-by-step workflow: the order I work in, the tools I reach for at each stage, and where beginners tend to lose time. Everything below assumes you are only testing assets a program has explicitly placed in scope.

Start with scope, not with tools

Recon that ignores scope is not recon, it is noise, and it can get your account banned. Before running anything I read the program policy end to end and note four things:

• In-scope assets: a wildcard such as *.example.com means subdomain enumeration is worth the effort; a fixed host list usually means it is not.
• Out-of-scope assets: marketing sites, status pages, third-party SaaS and specific subdomains are often excluded.
• Testing rules: rate limits, whether automated scanning is allowed, and any required test-account or header rules.
• Excluded bug classes: if a program does not accept missing headers or self-XSS, I do not spend recon time on them.

If you are still learning how programs and platforms work, read the basics of bug bounty hunting first, then come back to this methodology.

Asset discovery: expand the attack surface

A solid bug bounty recon methodology begins by turning one root domain into the full set of hosts you are allowed to test. I work in two directions at once: finding subdomains and finding the organisation’s other roots.

Passive subdomain enumeration

Passive sources never touch the target, so they are safe to run first. subfinder and amass (passive mode) pull from certificate transparency logs, DNS aggregators and search engines:

subfinder -d example.com -all -silent | tee subs-passive.txt
amass enum -passive -d example.com | anew subs-passive.txt

Certificate transparency is worth querying directly too. A browser visit to crt.sh for %.example.com often surfaces internal-looking hostnames that scanners miss.

Active resolution and brute forcing

Next I resolve everything and, where the policy allows active probing, brute force with a wordlist. dnsx keeps only hosts that actually resolve, and puredns brute forces against a trusted resolver list:

dnsx -l subs-passive.txt -silent -a -resp | tee resolved.txt
puredns bruteforce best-dns-wordlist.txt example.com -r resolvers.txt > subs-brute.txt

Combine, de-duplicate and you have your live host list. Keep the raw output files; you will diff them on later visits to spot new assets.

Probing: find what is actually listening

A resolving hostname is not the same as a live web service. httpx probes each host, follows redirects and records the status code, title, technology and content length in one pass:

cat resolved.txt | httpx -silent -title -tech-detect -status-code -follow-redirects -o live.txt

I sort the output by technology and by title. Admin panels, staging environments, old frameworks and anything with a non-standard title go to the top of my manual review queue. This is usually where the interesting work starts.

Content discovery and historical URLs

Once I know which hosts are live, I look for endpoints. Two complementary approaches:

• Historical URLs: gau and waybackurls pull paths that search engines and the Wayback Machine have already seen, including endpoints no longer linked anywhere.
• Active directory brute forcing: ffuf or feroxbuster against a sensible wordlist, respecting any rate limit in the policy.

gau example.com | anew urls.txt
ffuf -u https://target.example.com/FUZZ -w raft-medium-directories.txt -mc 200,301,302,403

From the historical URL set I grep for parameters, file extensions such as .json, .bak and .config, and anything that looks like an API route. Parameterised URLs feed directly into the next stage.

JavaScript is where the secrets hide

Modern single-page apps leak a surprising amount through their JavaScript bundles: internal API hostnames, undocumented endpoints, feature flags and occasionally hardcoded keys. I download every JS file from the live hosts and search it:

cat live.txt | gau | grep '\.js$' | httpx -silent -o jsfiles.txt
# then extract endpoints and secrets from the downloaded files

Tools like LinkFinder and simple regex passes for strings such as api_key, s3.amazonaws.com or /api/v surface endpoints that never appear in the UI. Treat any key you find as untested until you have confirmed it is live and in scope, and never actually use a third-party credential you were not authorised to use.

Prioritise, then test by hand

Automation gives you a map, not a bug. The judgement step is deciding where to spend your limited testing hours. My rough priority order:

1. Authentication, account and object-reference endpoints (access-control bugs pay well and automation misses them).
2. File upload, import/export and anything that fetches a URL you control.
3. Old or forgotten hosts: staging, dev., legacy., and any subdomain pointing at a service that no longer exists, which can indicate a subdomain takeover.
4. Admin and internal tooling behind weak or missing authorisation checks.

I feed the most interesting candidates into Burp Suite and test manually from there. The OWASP Web Security Testing Guide is the reference I check when I want a structured list of what to try against each endpoint class.

Keep recon continuous

The single biggest edge in bug bounty recon methodology is monitoring. Scope changes, new subdomains appear, old ones get redeployed. I keep the enumeration commands in a small script, run them on a schedule, and diff the output against the last run with anew. A fresh host nobody else has looked at yet is often the easiest valid bug on a mature program.

Key takeaways

• Scope first. Everything you enumerate must be something you are allowed to test.
• Passive discovery before active probing; resolve before you brute force.
• Probe with httpx to find live services, then prioritise by technology and title.
• Historical URLs and JavaScript files reveal endpoints the UI never shows.
• Automation builds the map; manual testing finds the bug.
• Run recon continuously and diff the results to catch new assets early.

Want a methodology tailored to your targets?

If you run a program or want structured, in-scope testing of your web and API attack surface, I offer web application penetration testing and API penetration testing built on the same recon-first approach. Get in touch to talk through your scope.