The bugs everyone else missed are usually on the assets everyone else missed. Good reconnaissance isn't a single tool or a one-liner you paste from Twitter — it's a pipeline: a repeatable flow where each stage feeds the next, new assets surface automatically, and you spend your attention on triage instead of typing. This is the shape of the recon workflow I run across bug-bounty targets and VAPT engagements, and the tooling I've open-sourced to support it.
Why a pipeline, not a script
A script runs once and forgets. A pipeline is stateful: it knows what it saw last time, so a subdomain that appeared this week jumps to the top of your queue instead of drowning in ten thousand hosts you already looked at. Scope grows, targets add infrastructure, and DNS changes daily. The organisations with the widest attack surface reward whoever notices the new thing first. Automation exists to make sure that's you.
The pipeline has four stages: seed → expand → probe → triage. Each stage's output is the next stage's input, and the whole thing is idempotent so you can re-run it safely.
Stage 1 — Seed
You cannot enumerate what you cannot anchor. Seeding establishes the roots of the attack surface:
- Root domains in scope, plus acquisitions and alternate brands (these are constantly forgotten by defenders).
- ASNs and IP ranges the organisation owns. Mapping a company to its Autonomous System Numbers gives you netblocks that pure DNS enumeration never reveals — this is exactly what I built
AsN_GrApErfor. - Known cloud tenancy, code repositories, and any published API documentation.
Get seeding wrong and every later stage inherits the blind spot. Get it right and the surface expands to places the target forgot they owned.
Stage 2 — Expand
Now grow the seed into a full asset list.
- Subdomain enumeration from many sources at once — passive (certificate transparency, passive DNS, search indexes) plus active brute-forcing with a good wordlist. No single source is complete, so aggregating and de-duplicating across all of them is the whole game. My tool
SubSpyderexists to merge those sources into one clean list. - Resolve everything and keep the ones that actually answer. A subdomain in a cert log that no longer resolves is noise; a forgotten staging box that does resolve is gold.
- Merge and dedupe the mountain of output. When you're pulling from six sources you drown in duplicates fast —
MergerHunthandles the merge/dedupe/hunt step so interesting entries float to the top.
Stage 3 — Probe
You have a list of live hosts. Now find the interesting ones without hammering anything.
- HTTP probing: which hosts serve web content, on which ports, with what status and title.
- Technology fingerprinting: server, framework, CDN, and — the high-value signal — the odd one out. Ninety-nine hosts on the standard stack and one running something ancient or bespoke? Start there.
- Interesting ports and services beyond 80/443, and API surface discovery. Exposed docs, Swagger/OpenAPI definitions and stray endpoints are frequent wins, which is why I built
APIScoutto map exposed API surfaces specifically. - DNS detail — I wrap dig-style lookups into the flow with
DigITso records, zones and misconfigurations get captured as structured data rather than terminal scrollback.
The discipline here is to stay light. Recon should map the surface, not attack it. Loud probing gets you rate-limited or blocked and burns the target before you've even chosen where to look.
Stage 4 — Triage
This is where a pipeline earns its keep. Run the first three stages once and you get a snapshot. Run them on a schedule and diff each run against the last, and you get a change feed:
- New host appeared → high priority. New infrastructure is under-tested by definition.
- A service changed (new tech, new port, new title) → something was deployed; go look.
- Something disappeared → note it, but the new and the changed are where the bugs are.
Surfacing only what's new is the difference between a wall of ten thousand hosts you'll never review and a short, ranked list of things that changed since yesterday. That list is where your manual testing time actually goes.
Wiring the stages together
The trick that makes it a pipeline rather than four scripts: each stage writes structured output that the next stage reads without you in the loop. A new asset discovered in expand flows into probe, and if probe finds it interesting it lands in triage — so a brand-new subdomain can go from "didn't exist" to "top of my review queue" with no manual re-runs. Keep the storage simple (flat structured files are fine to start), make every stage idempotent, and schedule the whole thing.
Principles that keep it healthy
- Passive before active. Learn everything you can without touching the target, then do the minimum active work needed.
- Idempotent stages. Re-running should never corrupt state or double-count. This is what lets you schedule it.
- Structured output everywhere. Text you have to eyeball doesn't scale; data you can diff does.
- Own the wordlists and sources. Tuning what you enumerate against the target type beats any single "best tool".
- Stay in scope, stay quiet. Recon that gets you blocked has negative value.
Every one of the tools referenced above lives on my projects page — they're the components of this exact workflow. Recon is unglamorous, but it's the stage that decides whether you're testing the same hosts as everyone else or the ones nobody looked at.
Want this methodology pointed at your organisation's real external footprint before an attacker maps it first? That's an attack-surface engagement — let's talk.