subfaster Tutorial & Review 2026: Faster Passive Subdomain Enumeration for Bug Bounty and Pentest Recon
Three hours into a bug bounty recon phase, my subfinder run against a large enterprise target was still crawling through fifty-plus passive sources, half of which were either rate-limited or dead. I had a narrow testing window and a scope list of over 200 apex domains. That's the exact pain point that pushed me toward subfaster — a lean, speed-tuned fork of ProjectDiscovery's subfinder that strips the tool down to what actually matters during time-boxed recon: fast, clean, sorted subdomain output with almost zero startup overhead.
This isn't a rewrite of the GitHub README. This is what I found after actually running subfaster against real bounty scopes and comparing it side-by-side with subfinder on the same targets.
Table of Contents
- What Is subfaster & Who It's For
- Key Features Breakdown
- Installation & Setup
- Hands-On Usage / Command Walkthrough
- Real-World Use Case: Bug Bounty Recon
- Pros & Cons
- subfaster vs Alternatives
- Pricing / Licensing
- Expert Tips & Common Mistakes
- Legal / Ethical Use Note
- Related Articles
- FAQ
- Verdict / Final Rating
What Is subfaster & Who It's For
subfaster is a fork of subfinder — the widely used passive subdomain discovery tool from ProjectDiscovery — rebuilt around a single goal: get a clean, sorted subdomain list out the door as fast as possible. It keeps subfinder's passive-source engine intact but changes the defaults, cuts startup cost, and drops dead weight so a typical scan finishes in seconds instead of tens of seconds.
It installs as its own binary with its own config directory (~/.config/subfaster/), so it runs side-by-side with an existing subfinder install without any config collision. This matters if you're already scripted around subfinder and don't want to touch that pipeline.
Who actually benefits from this:
- Bug bounty hunters running recon against large or multi-domain scopes where every second of startup latency compounds across hundreds of runs
- Pentesters doing external attack surface mapping during time-boxed engagements
- Red teamers automating recon pipelines where CLI startup time and noisy output actually slow down chained tooling
- SOC/threat intel teams mapping an organization's own external footprint for exposure monitoring
Key Features Breakdown
| Feature | What It Does |
|---|---|
| Curated fast source set | Defaults to 7 fast, keyless sources (thc, submd, crt, shodanct, rapiddns, hackertarget, sitedossier) instead of subfinder's full source list |
| HTTP keep-alive | Reuses connections instead of a fresh TCP+TLS handshake per request; sources like thc drop from ~32s to ~11s on large domains |
| Update check disabled by default | Startup drops from ~1s (subfinder's blocking registry call) to ~30ms |
| Preflight probing | Block-prone sources (sitedossier, hackertarget) get a cheap 3s homepage probe first — if your IP is blocked, it bails in 3s instead of hanging to full timeout |
| Lower default timeout + Cloudflare-only resolvers | 10s timeout (was 30s) and 1.1.1.1/1.0.0.1 resolvers for -active mode, avoiding slow legacy resolvers |
| Silent-by-default output | Only subdomains hit stdout; alphabetically sorted, no ASCII banner, clean for piping |
| Honest source errors | Quota/captcha failures on free sources get reported in -stats instead of silently returning zero results |
| Go library support | Can be imported directly into custom recon tooling, not just run as a CLI |
Installation & Setup
subfaster is CLI-only, written in Go, and requires Go 1.24+. No GUI, no Docker image maintained by the author at time of writing — you build from source via go install.
go install -v github.com/melvinsh/subfaster/v2/cmd/subfaster@latestThis pulls the module, compiles it, and drops the subfaster binary into your Go bin path (typically $HOME/go/bin). Make sure that directory is on your $PATH or the command won't resolve.
Verify the install:
subfaster -hIf you get the grouped, terse help output instead of a "command not found," you're good to go.
For sources that need API keys (used with -all), subfaster reads from its own provider-config.yaml, using the exact same format as subfinder's. If you've already got a subfinder provider config with your Shodan, Censys, or SecurityTrails keys, you can copy that file over to ~/.config/subfaster/provider-config.yaml and it'll work as-is. Alternatively, set environment variables directly, e.g. SHODAN_API_KEY.
Hands-On Usage / Command Walkthrough
subfaster -d example.comThe bread-and-butter command. Runs against the 7 default fast sources, prints only resolved subdomains to stdout (silent mode is default), sorted alphabetically. In my testing, this returns results noticeably faster than an equivalent subfinder run because there's no ~1s update-check delay and no cold TCP handshake per source hit.
subfaster -dL domains.txt -o out.txtThis is the one I actually use in production. Feed it a file of apex domains — for a bounty program with a wide scope or a client engagement with dozens of business units — and dump the combined output to a file. I run this as the first step of every external recon pipeline before feeding results into httpx for live-host filtering.
subfaster -d example.com -active -oIResolves each discovered subdomain and keeps only the ones that are actually live, outputting Host,IP pairs. This is your pruning step — passive sources return a lot of stale or decommissioned subdomains, and -active filters that noise before it hits your scanning tools. Note the Cloudflare-only resolver default here (1.1.1.1/1.0.0.1) — if your target environment has DNS quirks that Cloudflare resolvers handle differently than, say, Google's 8.8.8.8, you'll want to override with -r.
subfaster -d example.com -allSwitches from the 7 fast keyless sources to the full source list — same breadth as subfinder's default. Most of these additional sources require API keys (Shodan, Censys, SecurityTrails, etc.). I reach for this when the fast-mode run comes back thin and I suspect the target has assets sitting in sources that need authenticated access — common with cloud-heavy targets that show up in Shodan/Censys datasets but not the free CT-log-style sources.
subfaster -d example.com -oJ -csJSON output with source attribution — each subdomain tagged with which source found it (-cs for "current source"). I use this specifically when I need to audit source reliability for a target, or when building a dataset to feed into a downstream dedup/scoring script that weights results by source trustworthiness.
A few flags worth knowing that subfaster deliberately dropped from subfinder: there's no -rl/-rls rate-limit flags anymore, and the crt.sh source is HTTP/JSON only now (the old Postgres backend and its driver dependency got removed). If your workflow depended on subfinder's rate-limiting engine for staying under an API quota, that logic simply isn't there — you'll need to throttle at the orchestration layer instead.
Real-World Use Case: Bug Bounty Recon
On a recent private bounty program with a scope list of 40+ apex domains spanning a mid-size fintech's marketing sites, internal tooling subdomains, and legacy acquisitions, I ran subfaster in bulk mode as step one of recon:
subfaster -dL scope.txt -active -oJ -cs -o recon_raw.jsonThe combination of -active filtering and keep-alive connections meant the full scope finished well inside the time it took subfinder to complete a comparable run on a previous engagement against a similarly sized scope — largely because startup overhead and per-request handshakes stopped compounding across 40 sequential domain lookups.
From there I piped the live subdomains into httpx for HTTP probing, then into nuclei for a first-pass template scan. The -cs source attribution turned out to be genuinely useful during triage — a handful of subdomains flagged by sitedossier turned out to be stale DNS records for a decommissioned legacy product, easy to deprioritize once I could see where each result actually came from instead of treating the list as a flat blob.
The preflight probing on sitedossier and hackertarget also saved real time — on one target my IP had clearly hit hackertarget's free-tier quota, and instead of the whole run hanging to the timeout waiting on that one source, it bailed in three seconds and moved on, with the quota hit logged honestly in -stats instead of just silently returning nothing.
Pros & Cons
| Pros | Cons |
|---|---|
| Genuinely faster startup and per-source latency vs subfinder | Smaller default source set means fewer results out of the box unless you use -all |
| Runs alongside subfinder without config conflicts | No rate-limit controls — you manage throttling yourself now |
| Honest error/quota reporting instead of silent zero-results | Smaller community than subfinder; fewer StackOverflow/GitHub issue threads to lean on |
| Can be used as a Go library, not just a CLI binary | No official Docker image maintained by the author |
| Preflight probing saves time on block-prone free sources | Still a young fork (single maintainer, ~20 stars) — long-term maintenance is unproven |
subfaster vs Alternatives
| Criteria | subfaster | subfinder (original) |
|---|---|---|
| Startup time | ~30ms (update check off by default) | ~1s+ (blocking update-registry call) |
| Default sources | 7 curated fast, keyless sources | Full default source list, mixed speed |
| Rate limiting | Removed entirely | Built-in -rl/-rls flags |
| crt.sh source | HTTP/JSON only | HTTP + Postgres backend option |
| Output defaults | Silent, sorted, no banner | Verbose/banner by default |
| Community size | Small, single maintainer | Large, ProjectDiscovery-backed, active ecosystem |
| Best for | Quick, repeated scans across many domains where speed matters most | Comprehensive one-off scans with full source coverage and rate-limit control |
I don't treat this as an either/or. subfaster lives in my pipeline for fast first-pass sweeps across large scope lists; I still keep subfinder around for deep, single-target dives where I want the full source list and rate-limit control by default without extra flags.
Pricing / Licensing
subfaster is fully free and open-source under the MIT license. There's no paid tier, no SaaS version — it's a self-hosted CLI binary. The only cost implications come from the passive sources themselves: some (used via -all) require paid API keys from third parties like Shodan or SecurityTrails, but that's a cost of the underlying service, not the tool.
Expert Tips & Common Mistakes
- Don't assume the default fast-mode output is comprehensive — for high-value targets, always run a follow-up pass with
-allif you have API keys configured, since the 7 default sources will miss assets that only show up in Shodan/Censys-type datasets. - If you're migrating scripts from subfinder, remember the rate-limit flags are gone — add your own delay/backoff logic at the orchestration layer if you're hitting API quotas on paid sources.
- Copy your existing subfinder
provider-config.yamlover rather than re-typing API keys — the format is identical. - Use
-oJ -cswhenever you're triaging a large result set — knowing which source found a subdomain makes it much faster to spot stale or low-confidence hits. - Because it's a young, single-maintainer fork, pin a specific release in CI/automation pipelines rather than always pulling
@latest, to avoid unexpected breaking changes.
Legal / Ethical Use Note
Use subfaster only on domains and infrastructure you own or have explicit written authorization to test, such as within a defined bug bounty scope or a signed pentest engagement. Passive enumeration itself queries third-party public data sources rather than the target directly, but the -active resolution step does touch target-adjacent infrastructure — treat it accordingly and stay within your authorized scope at all times.
Related Cybersecurity Topics You Should Explore
- 737 Fake VPN Extensions Are Spying on Chrome Users Right Now
- GhostDesk Spyware Alert: Fake CCleaner Steals Passwords & Crypto
- Zoomsday Flaw: Hackers Hijack Zoom Users With Zero Clicks
- SonicWall SMA1000 Flaws Now Fuel Ransomware Attacks – CISA Warns
- HP ThinPro's 'Encrypted' Drives Aren't Actually Safe — Here's Why
- GRR Rapid Response: The Free Google Tool That Hacks 100K PCs Remotely
- One Failed Login, Full Server Takeover: WordPress XSS2Shell
- I Traced a Webshell Using Just 6 Linux Commands — Here's How
- How a Fake Movie File Can Empty Your Bank Account in Seconds
- CaptiveCrunch: How Russian Hackers Turned Hotel Wi-Fi Into a Weapon
- CVE-2026-12935: The TP-Link Bug Every Router Owner Should Fix Now
- Adform Hack Turns Trusted Ad Script Into a Crypto Stealer
FAQ
Is subfaster free?
Yes, it's fully open-source under the MIT license with no paid tier.
Is subfaster legal to use?
Yes, for domains you own or are authorized to test. Passive subdomain enumeration queries public data sources, but using it against systems outside your authorization is not legal.
Does subfaster replace subfinder?
Not entirely — it's better for fast, repeated scans across large domain lists. subfinder still has the larger default source set and built-in rate limiting, which some workflows depend on.
Do I need API keys to use subfaster?
No, the default fast mode uses 7 keyless sources. API keys are only needed if you run with -all to access the full source list.
Is subfaster beginner-friendly?
Yes — if you've used any subdomain enumeration CLI tool before, the flag structure will feel immediately familiar, and the terse -h output makes onboarding fast.
Can I use subfaster and subfinder on the same machine?
Yes, they use separate config directories and separate binaries, so there's no conflict.
What are the best subfaster alternatives?
subfinder (the original), OWASP Amass, and Sublist3r are the closest comparable open-source passive enumeration tools.
Verdict / Final Rating
| Criteria | Score (/5) |
|---|---|
| Ease of Use | 4.5 |
| Accuracy / Analysis Depth | 4 |
| Documentation | 3.5 |
| Community Support | 3 |
| Value for Money | 5 |
Overall Rating: 4.0/5
subfaster earns its place in a recon pipeline where speed across many domains matters more than exhaustive single-target coverage. It's not a replacement for subfinder in every scenario — the smaller community and missing rate-limit controls are real trade-offs — but for bulk bounty scope sweeps and time-boxed pentest recon, the reduced startup latency and cleaner output genuinely save time on every single run. If you're already comfortable with subfinder's flag structure, there's almost no learning curve, and it costs nothing to add to your toolkit alongside your existing recon stack.