Recon at Scale

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: You can only find a vulnerability in something you have discovered. Page 2.1 taught reconnaissance as a methodology; this page scales it for bug bounty, where the hunter with the best, broadest, freshest map of a target’s attack surface has a structural advantage. The forgotten subdomain, the newly-deployed asset, the overlooked endpoint — these are where the un-duplicated bugs live. In bug bounty, recon is not preparation for the work. Recon is the competitive edge.

Part 1: The Problem

5A.2 was about hunting deeply in what you test. This page is about the other half: hunting widely — making sure you are testing the right things, including things other hunters have not found.

The economics of 5A.1 make this critical. Rewards go to the first reporter; popular programs are crowded. If you and a hundred other hunters all test the same obvious main application, you are all competing for the same bugs — duplicates everywhere. But a large organization’s in-scope attack surface is often far bigger than its main application: many subdomains, many assets, things deployed and forgotten, things deployed yesterday. The hunter who discovers an in-scope asset others have overlooked is hunting with little or no competition.

So in bug bounty, recon is a competitive advantage, not just a first step. This page is about doing it well, broadly, and continuously.

Part 2: The Concept — Why Recon Is the Edge

Recall from 2.1: recon maps a target’s attack surface, and a defender’s version of it is attack surface management. For a bug bounty hunter, recon has a specific strategic value:

   Many hunters, same obvious target:
   [hunter][hunter][hunter][hunter] → all on  main-app.com
        → everyone finds the same bugs → DUPLICATES

   You, with better recon, find an overlooked in-scope asset:
   [you] → forgotten-service.target.com
        → little/no competition → un-duplicated findings

Three things make recon the edge:

• It finds less-contested surface. Overlooked subdomains and assets have fewer (or zero) other hunters on them.
• It finds newer surface. Newly-deployed assets have not been tested by anyone yet — and new deployments are where fresh bugs and misconfigurations appear.
• It is something you can simply do more and better than others. Skill in finding bugs has a ceiling that takes years to raise; thoroughness in recon is something you can improve immediately and decisively.

The hunter’s recon mindset: the in-scope scope is usually bigger than it first appears — my job is to discover all of it, before others do, and keep discovering it as it changes.

Part 3: The Concept — What Recon at Scale Discovers

Recon for bug bounty, building on the 2.1 techniques, aims to discover the full in-scope attack surface. The main targets of discovery:

Subdomains — broadly and exhaustively. A program in-scope for, say, *.target.com may have hundreds of subdomains. The 2.1 techniques — certificate transparency logs, subdomain enumeration, DNS — applied thoroughly and at scale. The forgotten old., dev., staging., legacy. subdomain is a classic source of un-contested bugs.

Assets beyond subdomains. In-scope IP ranges, mobile applications, cloud assets, related services — whatever the program scope includes. Read the scope (5A.1) for the full definition of what is in-scope, then discover all of it.

Content and endpoints. Within each asset, the pages, directories, files, and — especially — API endpoints (5A.2). Content discovery (2.1) applied across the whole discovered surface.

Technologies and versions. Fingerprinting (2.1) across all assets — what each runs, and which versions (which connects to known-vulnerability hunting, 2.10).

Information that aids hunting. Anything that helps: leaked information, exposed files, hints about how the application works.

The output is the same kind of artifact as your 2.1 recon report and 3.1 infrastructure map — but for bug bounty, it is larger, continuously maintained, and treated as a strategic asset.

Part 4: The Concept — Automation

Doing recon “broadly and exhaustively” by hand, repeatedly, across hundreds of assets is not feasible. This is where automation becomes essential to bug bounty recon — and where your developer background (Phase 0.6 scripting) is a direct, significant advantage.

Why automate. Recon involves running many tools across many assets, repeatedly. Automation lets you: cover far more attack surface than manual recon ever could; do it consistently and repeatably; and — crucially — run it continuously (Part 5). Manual recon is a snapshot; automated recon is a process.

What automation looks like, conceptually. Hunters build (or use) recon pipelines — chains of tools that run in sequence: discover subdomains, then probe which are live, then fingerprint them, then discover content on each, then flag interesting things. The output of one stage feeds the next (the piping idea from 0.2, scaled up). The 2.1 toolkit (subdomain enumeration, content discovery, fingerprinting) becomes the stages of an automated pipeline.

Your developer advantage. Building, customizing, and maintaining recon automation is programming — exactly the skill you brought into this curriculum. You can script pipelines, write custom tooling for gaps no existing tool covers, and process recon data programmatically. Many hunters without a development background struggle here; you should lean into it. This is a concrete place your background makes you better, faster.

A note on responsible automation: automated recon must still respect the program’s rules (5A.1). Recon that hammers a target’s systems can violate a program’s rules against degrading the service, and aggressive automated scanning is often explicitly forbidden. Automate broadly, but tune it to be respectful of the target — and never run it against out-of-scope assets.

Part 5: The Concept — Continuous Recon and Monitoring

The single most powerful idea in bug bounty recon: attack surface is not static, so recon should not be a one-time event — it should be continuous.

Recall from 2.1 that attack surface changes over time — new deployments, new subdomains, new features. For a bug bounty hunter, that fact is an opportunity:

   A NEW in-scope asset appears (a fresh deployment).
            │
   Whoever discovers it FIRST hunts it with NO competition.
            │
   Continuous recon = you are often that "first."

Continuous monitoring means automatically and repeatedly re-running recon against a target’s scope, so that when something new appears — a new subdomain, a new asset, a changed application — you are alerted to it quickly. New attack surface is the freshest, least-contested hunting ground there is: a just-deployed asset has been tested by nobody.

This turns recon from “the thing I do before hunting a program” into “a continuously-running system that surfaces fresh opportunities to me.” Many of the most consistent bug bounty hunters are, in large part, running excellent continuous recon and being early to new surface.

Two things make continuous recon practical: automation (Part 4 — only automation can re-run recon continuously) and discipline (a sustained, organized process — 5A.5’s working-practice theme). It is, again, an area where a developer’s mindset — building a reliable, automated, monitored system — is a real advantage.

Part 6: The Concept — Recon as Organized Practice

Recon at scale only delivers its advantage if it is organized. A final framing on doing it well:

• Maintain a recon database. Across the programs you hunt, keep organized, persistent records of discovered assets, technologies, endpoints, and what you have already tested. (Your Notion, or dedicated tooling.) Disorganized recon — re-discovering the same things, losing track of what you tested — wastes the advantage.
• Recon feeds the hunt. Recon is not separate from exploitation (5A.2) — it feeds it. Discovered assets get hunted; fingerprinted versions get checked for known vulnerabilities (2.10); mapped endpoints get tested. Keep the loop tight: discover → hunt → discover more.
• Stay in scope, always. Recon must only ever target in-scope assets. It is easy, when discovering broadly, to wander onto something out of scope — discipline here is the 5A.1 / 1.0 rule, and it applies to recon as much as to testing.
• Balance breadth and depth. Recon gives you breadth (many assets); 5A.2 gives you depth (finding real bugs in them). Both are needed — broad recon that finds many assets you then test shallowly earns little; deep skill with no recon means competing on crowded surface. The strong hunter does both.
• Improve the system over time. Like everything in this field, recon is continuously improved — better tooling, better pipelines, better coverage. Treat your recon capability as something you build and refine across your whole bug bounty practice.

🔑 The deep lesson: in bug bounty, recon is the competitive edge. The hunter with the broadest, freshest, best-organized map of a target’s in-scope attack surface is hunting where others are not — finding un-contested, un-duplicated bugs, and being early to new surface. Recon is something you can decisively out-work others on, automation is what makes it scale, continuous monitoring is what keeps you early, and your developer background is a genuine advantage in building all of it. Recon is not preparation for the work — it is the work.

📓 Key Terms

🧪 Hands-On Lab

Practice recon techniques on your own assets and on in-scope targets of programs you are authorized for. Passive recon techniques (certificate transparency, etc.) can be practiced on any domain. Never run active recon against out-of-scope or unauthorized assets.

Task 1 — Broad subdomain discovery. For a program you are authorized for (or your own domain), do thorough subdomain enumeration using multiple 2.1 techniques. Compare how many subdomains the thorough approach finds vs a quick look. Note the forgotten-looking ones.

Task 2 — Build a simple recon pipeline. Using your Phase 0.6 scripting skills, write a basic script that chains recon stages: take a domain → enumerate subdomains → probe which are live → fingerprint them. Experience recon as an automated pipeline. (Keep it respectful — not aggressive.)

Task 3 — Map a full attack surface. For one authorized program, build a complete recon map: all in-scope subdomains and assets, technologies and versions, discovered endpoints. This is your strategic map for hunting that program.

Task 4 — Set up a recon database. In Notion (or dedicated tooling), create an organized structure to record discovered assets, their technologies, endpoints, and your testing status. Populate it from Task 3.

Task 5 — Think through continuous monitoring. Write a plan for how you would re-run recon against a program’s scope on a schedule and be alerted to new assets. You do not need to fully build it yet — design the approach, and note how automation makes it possible.

Task 6 — Practice scope discipline. For your authorized program, carefully separate, in your recon notes, what is in scope from what your recon discovered that is out of scope. Mark out-of-scope assets clearly as “do not test.” This habit protects you.

Task 7 — Connect recon to hunting. Take three assets from your recon map and, for each, write what you would test (linking to 5A.2 — business logic, APIs, etc.) and what known-vulnerability checks the fingerprinted versions warrant (2.10). See recon feeding the hunt.

⚠️ Common Mistakes

• Treating recon as a quick first step. In bug bounty, recon is the competitive edge — broad, thorough, continuous. Skimping on it means hunting crowded surface for duplicates.
• Only testing the obvious main application. That is where all the competition is. The overlooked subdomain and the new asset are where un-contested bugs live.
• Doing recon entirely by hand. Manual recon cannot achieve the breadth or the continuity that the advantage requires. Automate — your developer background makes this a strength.
• One-time recon. Attack surface changes constantly. Continuous monitoring catches new, un-tested assets — being early is a major edge.
• Disorganized recon. Re-discovering the same things and losing track of what you tested wastes the advantage. Maintain an organized recon database.
• Recon wandering out of scope. Discovering broadly makes it easy to drift onto out-of-scope assets. Recon must respect scope as strictly as testing does.
• Aggressive automated recon. Recon that hammers a target can violate program rules. Automate broadly but respectfully.

✅ Recap & What’s Next

• In bug bounty, recon is the competitive edge — the hunter with the broadest, freshest map of a target’s in-scope surface hunts where others do not, finding un-contested, un-duplicated bugs.
• It discovers the full in-scope surface (subdomains, assets, endpoints, technologies); automation makes it scale and continuous monitoring keeps you early to new assets — both areas where your developer background is a real advantage.
• It must be organized (a recon database), kept strictly in scope, and balanced with the depth of 5A.2 — recon feeds the hunt.

Next (5A.4): You have found a real, well-chained bug through good recon and deep exploitation. None of it earns anything until you communicate it well. Page 5A.4 is writing reports that get paid — because in bug bounty, the report is literally the product.