Cyber-note/Full-Bug-Bounty-Hunting-Methodology-2026: a recon playbook, not a scanner

What this repository actually contains

There is no code here. The repository holds two top-level entries, LICENSE and README.md, and the README is the entire product. It is a written methodology for web application security testing, organised into thirteen numbered phases plus a wordlist reference and an OSINT platform reference. The author describes it as documenting "my methodology, notes and workflow", which is the honest framing: this is one practitioner's ordering of recon work, published as Markdown.

The intended reader is someone who already knows what subfinder and ffuf do and wants a sequence to run them in. The README states the ordering principle directly: phases go by signal-to-noise ratio, starting wide and passive, then narrowing before any exploit is sent. That is the whole editorial claim, and it is a defensible one. Beginners looking for a first tool should look elsewhere, because nothing here explains how to install or configure the underlying utilities.

The 13-phase chain and why the order matters

The phases run in a dependency chain. Phase 1 collects subdomains passively from certificate transparency, API-backed sources and developer code. Phase 2 turns to active resolution and bruteforce. Phase 3 maps infrastructure: domain to ASN, ASN to CIDR, CIDR to PTR records. Phase 4 uses that infrastructure map for WAF bypass and origin IP discovery. Phase 5 merges and resolves everything into a live-host list. Phases 6 through 13 then work the resulting hosts: virtual host enumeration, URL and endpoint discovery, JavaScript analysis, directory and sensitive file discovery, GitHub source intelligence, port scanning, automated vulnerability scanning, and subdomain takeover detection.

The design decision worth noticing is that Phase 3 sits between enumeration and the live-host merge. Most recon checklists treat ASN and CIDR work as an optional extra. Here it is a required step, because Phase 4 depends on it: you cannot look for an origin IP behind a WAF without knowing which address ranges the organisation actually owns. That coupling is the most useful idea in the document, and it is the reason the phase order is not arbitrary.

Setting up the environment and running Phase 1

The README gives no installation instructions for the tools it names. What it does give is a prerequisites block of environment variables that later commands reference, so the first real step is exporting those. The DNS and web wordlists are paths on your own machine, and two API keys are needed for the sources that require them.

export DNS_WORDLIST="/path/to/subdomains-wordlist.txt"
export WEB_WORDLIST="/path/to/directories-wordlist.txt"
export GITHUB_TOKEN="your_github_personal_access_token"
export PDCP_API_KEY="your_projectdiscovery_chaos_key"

With those set, Phase 1 is passive enumeration. The README lists several tools that write to separate files, which is deliberate: each source produces its own output so you can see which one contributed a given host.

subfinder -d target.com -all -recursive -o subs_subfinder.txt
echo target.com | assetfinder -subs-only > subs_assetfinder.txt
amass enum -d target.com -o subs_amass.txt
findomain -t target.com -u subs_findomain.txt
chaos -d target.com -o subs_chaos.txt
github-subdomains -d target.com -t $GITHUB_TOKEN -o subs_github.txt

The README calls the certificate transparency route one of the most underrated passive sources, since every issued SSL certificate is public record. The example pipes crt.sh JSON through jq, strips wildcards, splits comma-separated name values and filters to the target domain.

curl -s "https://crt.sh/?q=%25.target.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | tr ',' '\n' \
  | grep -oE "[A-Za-z0-9._-]+\.target\.com" \
  | sort -u > subs_crt.txt

Expect a sorted, deduplicated list of hostnames in subs_crt.txt. If the file is empty, the query returned nothing or jq is not installed; the README does not troubleshoot either case.

The origin IP phase is the part with real risk

Phase 4 is where the methodology stops being a reading list. The goal, as the README puts it, is finding the origin IP behind a WAF so you can reach the infrastructure the WAF was protecting. The technique is standard: take the CIDR ranges from Phase 3, scan them, and match responses against the target using a favicon hash or a similar fingerprint.

The README does not spell out the boundary here, and it should. Scanning address ranges you have mapped from a public ASN is not the same as scanning ranges you have confirmed belong to your target's scope. An ASN can host unrelated customers, and a shared hosting range can contain hundreds of organisations that never agreed to be tested. The document's passive-first philosophy protects you in Phase 1 and stops protecting you the moment Phase 4 begins. If your scope agreement names specific domains rather than an organisation's whole network footprint, this phase is where you are most likely to step outside it.

Where the methodology breaks down

The most concrete limitation is that nothing here is pinned. Commands reference tools by bare name with no version, and the README does not state which versions were used when the examples were written. Flag behaviour in recon tooling changes often enough that a command copied verbatim can fail silently or produce different output than the author saw. The README also does not document rollback, a changelog or a supported tool matrix, because there is no software to version: the repository holds a README and a LICENSE.

The second limitation is coverage. The phases are web-application recon. There is no cloud asset enumeration, no mobile or API-specific discovery beyond endpoint collection, and no section on scoping or rules of engagement. A red team engagement against an internal network, or any target where the attack surface is not a domain name, gets little from this document.

Third, the README is truncated in this view, and the later phases are described in the table of contents but not shown in full. Treat the phase list as a map of what the document covers rather than a guarantee that every phase is equally detailed.

How it compares to a runnable recon framework

The obvious alternative is a tool like reconftw or reNgine, which wrap the same underlying utilities into an executable pipeline. The difference is in what you get. A framework installs, takes a domain, runs the phases for you and writes a report. This repository does none of that: it tells you which commands to run and in what order, and leaves execution, output handling and judgement to you.

That is not automatically worse. A framework's phase order is baked into its code, and changing it means changing the code. Here the order is prose, so you can drop Phase 11 if you are not doing port scanning, or move JavaScript analysis ahead of directory discovery, without touching anything. You also see every command, which matters when a finding needs to be reproducible in a report. The cost is that you own the glue: merging output files, deduplicating, and deciding when a phase has produced enough to move on. The README's aggregator example, a subenum.sh script that wraps wayback, crt, abuseipdb, Findomain, Subfinder, Amass and Assetfinder in one call, is the closest the document comes to automation, and it still writes to a flat file you have to feed into the next phase yourself.

Licence, maintenance and what upgrading means

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That matters if you want to fork the phase list into an internal playbook. It does not grant you any rights over the third-party tools the README names, each of which carries its own licence, and several of those tools have terms that restrict use against targets you do not own or have permission to test.

The last push to the repository was on 2026-07-05. There are no releases, so there is no version to upgrade to and no changelog to read. Updating means pulling the README and diffing it against your copy. The practical cost of that is low, since the content is prose, but it also means you cannot pin a revision and expect the tool commands inside it to stay accurate. If you build an internal runbook from this, record the date you copied it and re-check the commands against current tool documentation before each engagement. The README itself gives no indication of how often the author intends to revise it.

Editorial conclusion

Adopt this if you already run subfinder, puredns and dnsx and want a phase order that keeps passive collection ahead of anything that touches the target. Skip it if you need a runnable pipeline, an installable package or versioned releases: the repository holds a README and a LICENSE, and the README does not document rollback, a changelog or a supported tool version matrix. Before you follow any phase, check that the tools named in it still exist under those names and that your scope agreement permits active bruteforce against the target.

Frequently asked questions

Official sources

1. Cyber-note/Full-Bug-Bounty-Hunting-Methodology-2026 on GitHub
2. Issues
3. License: MIT
4. README