A repeatable recon methodology for bug bounty

The bounty hunters who keep finding bugs are not running smarter tools than you. They are running the same tools in the same order, every week, against a surface they have mapped and keep re-mapping. Recon that pays is a pipeline, not a burst. Each stage feeds the next, and the whole thing runs on a schedule so new surface gets caught while it is still fresh.

This post lays out a repeatable recon methodology and maps each stage onto a Crossfyre workflow. The engines doing the work are voyage (subdomain enumeration), pulse (port and service discovery), and mach (content discovery). The point is not the individual tools, it is the order and the repetition.

Stage 0: scope and authorization

Before any packet leaves a node, write the scope down. Not in your head, in the run. For a bug bounty that is the program brief: which apex domains and wildcards are in scope, which subdomains or netblocks are explicitly excluded, and what the program says about automated traffic and rate limits.

• List the in-scope apex domains. These become the seeds for enumeration, nothing else does.
• List the exclusions explicitly. An out-of-scope subdomain that shows up in passive sources is not a target, it is a thing to filter out.
• Note the rate-limit and automation rules. They decide how aggressive your active stages can be.

Scope is not paperwork you do once and forget. It is the input to every later stage. If a host did not descend from an in-scope seed, it does not get scanned. Keeping that rule mechanical is how you avoid the most common (and most embarrassing) bounty mistake: hammering an asset that was never yours to test.

Stage 1: map the attack surface with voyage

You cannot test what you have not found. Subdomain enumeration is where the surface gets drawn. voyage pulls from passive sources (certificate transparency, passive DNS, and the like) and then brute-forces actively against a wordlist for the names passive sources miss.

bash
# enumerate one in-scope apex
crossfyre run subdomain-enum.cfx domain:example.com

# or launch the same workflow across the fleet from the dashboard,
# seeded with every in-scope apex at once

Run this as a workflow rather than a one-shot command and the output lands in your Findings explorer instead of a scrollback buffer you will lose. Each discovered name becomes a candidate host. Now apply Stage 0: drop anything that is out of scope before it goes any further. Enumeration is exactly where stray acquisitions and shared CDNs sneak in, so this filter is not optional.

Stage 2: resolve and validate

A list of names is not a list of targets. Plenty of enumerated subdomains do not resolve, point at parked pages, or hang off third-party services you are not allowed to touch. Validating before you scan keeps the next stages focused and keeps your traffic off dead and out-of-scope hosts.

• Resolve every name and keep the ones that actually answer.
• Note where they point. A name that resolves into a third-party SaaS range is usually out of scope even if the label looks in-scope.
• Carry forward only live, in-scope hosts. This shortlist is the input to port and content discovery.

Stage 3: port and service discovery with pulse

For the live hosts that survived validation, pulse finds open ports and identifies the services behind them. This is where the surface stops being a list of names and becomes a list of things you can actually talk to: web servers on odd ports, exposed admin panels, forgotten staging services, databases that should never have faced the internet.

bash
# port + service discovery on the validated hosts
crossfyre run port-scan.cfx host:app.example.com host:api.example.com

Mind the program rules here. Port scanning is active traffic, and a noisy full-range sweep across a big host list is exactly the kind of thing a rate-limit clause is written about. Scope the port set and the pace to what you are authorized to do, then let the distributed fleet spread the work so you are gentle per host without being slow overall.

Stage 4: content discovery on live web hosts with mach

Now you point mach at the hosts that turned out to be serving HTTP. Content discovery is where the actual bugs tend to start: hidden paths, forgotten endpoints, exposed config, backup files, and parameters that nobody meant to ship. mach is a stateful, resumable HTTP fuzzer, so a large path-discovery sweep against a slow host does not get lost if a node drops.

bash
# content discovery against a confirmed live, in-scope web host
crossfyre run content-discovery.cfx url:https://app.example.com

Use a wordlist that fits the target. Crossfyre ships defaults, and you can upload your own scoped to your team, which matters once you build program-specific lists from what you learned on previous runs. Recon is iterative: this run's findings are next run's wordlist.

Stage 5: triage and prioritize

Raw output is not a finding, it is a pile. Triage is where you decide what is worth a human looking at. The Findings explorer lets you filter by severity, by active or passive discovery, and by host, then export the set to CSV, JSON or Markdown for your report or your own pipeline.

1. Filter to the high-signal results first: unexpected services, admin and auth surfaces, anything that looks like staging or internal.
2. Cross-reference against what you already reported. New surface since last run is where fresh bugs live.
3. Export the shortlist and verify by hand. Recon points you at the door, it does not walk through it for you.

A finding from automated recon is a lead, not a vulnerability. You still confirm it manually, and you still keep that confirmation inside the authorized scope. The pipeline's job is to make sure the highest-value leads reach you, not to file reports for you.

Stage 6: schedule it so recon never goes stale

The single biggest edge in bug bounty is being early. New subdomains appear, new services come online, a deploy exposes a path that was not there last week. If you only run recon when you remember to, you find that surface after everyone else does. So you stop running it by hand.

Crossfyre lets you schedule a workflow to run on a recurring basis and push the results to you. Wire the pipeline above into a schedule and the surface re-maps itself while you sleep.

• Schedule voyage to re-enumerate your in-scope apexes weekly. New subdomains surface as new findings.
• Schedule pulse and mach against the live host set so newly exposed services and paths get caught quickly.
• Get notified on Discord, Slack, or email the moment something new lands, and triage only the delta instead of re-reading the whole surface.

Because workflows are crash-safe, a scheduled run that hits a reclaimed node or a rate-limit timeout just resumes and finishes. And because billing is reserve-then-reconcile with credits that never expire, a recurring schedule only ever costs you the work that actually completed.

That is the whole methodology: scope hard, enumerate with voyage, validate, scan with pulse, discover with mach, triage the output, and schedule the loop. Nothing exotic. The wins come from doing it in order and doing it again, week after week, inside the scope you were given.