🧪 Labs › Recon & Attack Surface

🛰️ Part of the Web & Bug Bounty path — module 1, Recon & Attack Surface

You cannot test what you never found. Build the inventory first.

What it is

Recon is not a phase you get through on the way to the interesting work — on a real programme it IS most of the interesting work. The hunters who get paid are usually the ones who tested an asset nobody else had looked at, running software nobody else had noticed.

An application tells you a great deal about itself for free: what it disallows in robots.txt, what it lists in a sitemap, what its headers and error pages reveal about the stack, what routes its own JavaScript has to know in order to work, and what generated API documentation describes. None of that is an attack; all of it narrows where you look.

The failure mode worth understanding is organisational rather than technical. Asset inventories are generated from whatever is currently managed. A host that stopped being managed stops appearing — while continuing to answer requests, on an old build, with old configuration. That gap between what a company believes it runs and what it actually runs is where a large share of real findings live.

How to approach it

• Start from one name and expand outward: enumerate hosts and subdomains, then confirm which actually answer.
• Read what each live host volunteers — robots.txt, sitemaps, security.txt, response headers, error pages, any generated documentation.
• Pull routes, hostnames and parameter names out of client-side bundles. A single-page app has to know where its backend is, and it ships that knowledge to you.
• Treat archived and leftover material as an intel source: old configuration describes the estate as it used to be, and companies shrink less tidily than their inventories claim.
• Keep a written inventory, and keep a column for what you have NOT tested yet. The point of recon is to know the size of the job.

How you'll recognise it

The tells that should make you slow down and test this class properly.

• References to hostnames, API bases and environments inside JavaScript bundles.
• robots.txt, sitemaps, security.txt and generated API docs that list more than the navigation does.
• Hosts or virtual hosts that answer differently to the same request — an older build, a different server header.
• An asset list or inventory that disagrees with what DNS or archived configuration says.

Proving it to a triager

On a real programme the report is what gets paid. What the evidence needs to show, and what usually gets it closed.

• Recon is rarely a finding on its own; it is the evidence trail behind one. Keep the chain: where you learned the host existed, and how.
• An exposed asset becomes reportable when it holds a vulnerability or sensitive data — report that, and cite the recon that found it.
• Check the programme's scope before touching any newly found host. Found is not the same as in scope.
• Common N/A: 'subdomain exists' or 'directory listing of public files' with no sensitive content.

How to prevent it

• Generate asset inventories from DNS and from the hosting platform, not only from what the current pipeline deploys — and reconcile the two.
• Give every asset an owner and a decommission date, and enforce the date.
• Treat pre-production environments as production for exposure purposes: same patching, same authentication, same review.
• Keep build-time files, archived configuration and directory listings off anything internet-facing.

More Recon & Attack Surface labs

• Debug & Development Surfaces — The tool the developer used to fix the app is now a tool for anyone to run it.

← All labs