Why recon comes first

There is a habit that separates people who find bugs from people who bounce off targets, and it has nothing to do with knowing more payloads. It is this: before touching anything, they find out what "anything" even is. They map the target first. This lesson is about why that map is the actual work, and how to think about building it.

You cannot test what you have not found#

Imagine you are handed a single address, shop.example.com, and told "find bugs." The tempting move is to open it, see a login form, and start trying things on that form. And you might get lucky. But look at what you just did: out of everything the company runs, you picked the one page that was easiest to see, and you tested that.

Meanwhile the interesting things were somewhere else. An api.example.com that speaks JSON and trusts its callers more than the website does. A dev.example.com that a developer stood up two years ago and forgot, running an old version of everything. An /admin panel that is not linked from anywhere but answers if you ask for it directly. A backup.zip sitting in the web root. None of these are on the login page, and none of them will find themselves.

The size of what you find is capped by the size of what you looked at. Recon is how you make what you looked at as large as possible.

Recon is a loop, not a step you finish#

Beginners treat recon as a box to tick: "did the recon, now the real work." It is not like that. Every new thing you discover gives you new things to look at, which gives you more to discover.

You observe what is in front of you, enumerate to turn one host into many and one page into many endpoints, map what you found into a picture of the application, and prioritise where to spend your limited attention. Then the host you just prioritised becomes the next thing you observe, and around you go. You stop when the surface stops growing, not when a timer goes off.

The map you are building#

By the end of a good recon pass you should be able to answer, on paper or in your notes:

• What hosts and subdomains belong to this target? Not just the one you were given.
• What runs on each? A web app, an API, a login portal, an admin panel, a file server.
• What technology is under it? Web server, language, framework, and ideally versions.
• What does each app do, and for whom? Where are the roles? Where is money, or personal data, or a file upload?
• What is the attack surface? Every place that takes input from you: forms, URL parameters, headers, cookies, uploads, API endpoints.

That last picture is the whole point. A finding almost always lives at a point where the application takes something you control and does something trusting with it. Recon is how you build the complete list of those points, so that when you start testing you are working through a map instead of poking at whatever is nearest.

Passive first, then active, and always in scope#

Some recon never touches the target at all. You can learn a company's subdomains from public certificate logs, its code from public repositories, its old pages from web archives, and the target's servers see none of it. That is passive recon, and it is free and safe to do on anything.

Other recon does touch the target: asking a server which HTTP methods it allows, throwing a wordlist of paths at it to find unlinked pages, reading its error messages. That is active recon, and every request lands in someone's logs with your IP on it. The next lesson goes deep on this line, and a whole later lesson is devoted to it, because it is the difference between research and trespass: you run active recon only against targets you are authorised to test: your own labs, a bug bounty program's in-scope assets, or a client who signed an engagement. On the labs in this Academy, you are always in scope. On the wider internet, you are not, until someone says so.

What good recon feels like#

It feels slow at first and then suddenly fast. You spend an hour finding forty subdomains and it seems like nothing is happening. Then you notice that thirty-nine of them are the polished production site and one is a staging box with debug mode on, and the next hour finds three bugs there because the map told you exactly where the soft ground was.

The rest of this path is the how: passive sources, subdomains and DNS, the files a site hands out, fingerprinting the stack, finding hidden content, and probing HTTP methods. Do them in order. Each one adds a layer to the map, and the map is the work.