Englishবাংলা
SubscribeWrite
Latest
Binary search: patterns, templates and common pitfallsDocker's $250 Cloud Sandboxes credit: what it covers and what it does notTwo pointers and sliding window: patterns with examplesArrays and hash maps: the interview patterns you must knowBig-O notation explained: time and space complexity for interviewsSoftware testing basics: the test pyramid and what to testClean code and code review habits that make you a better developerREST API design best practices: URLs, status codes and errors

Recon basics: mapping a target's assets without breaking the rules

Recon is how you find what is in scope and worth testing. Learn passive and active discovery, and how to do it politely and in bounds.

••2 min read
A magnifying glass over a map of connected hosts

Reconnaissance (recon) means learning what a target owns and exposes before you test anything. Good recon tells you where to spend your time. Bad recon wastes hours on assets that are out of scope.

Step zero: the scope

Everything starts with the program's policy. Write down:

  • The in-scope domains, apps and wildcards (for example *.example.com).
  • What is out of scope (third-party services, specific subdomains, certain bug types).
  • Limits on automation and request rates.

Anything you discover that is not clearly in scope is not yours to test, even if it looks related.

Passive vs active recon

Passive recon collects information without sending traffic to the target's servers. It is low risk and a good first step.

  • Certificate transparency logs: public logs of issued TLS certificates often list hostnames, including ones nobody advertises. Sites such as crt.sh let you search them.
  • Public DNS and search data: passive DNS datasets, search engines and public code repositories can reveal hostnames.
  • The company's own pages: documentation, job posts (which hint at technologies), mobile apps, and help centres.
  • Public archives of old pages (see the later part on archives).

Active recon sends requests to the target, for example resolving guessed hostnames or probing which hosts respond over HTTP. It must follow the program's rules on automation. Keep it slow and polite: low request rates, a clear user agent if allowed, and no aggressive scanning.

What you are trying to learn

  1. Which hostnames exist and which are alive.
  2. What each one is: a login app, an API, an admin tool, a marketing page.
  3. The technology (framework, server, third-party services), from headers and page content.
  4. What changed recently: new subdomains and new features are often the least tested.

Tools and judgement

Many open-source tools automate passive discovery and resolving results. Tools save time, but they also create noise and duplicates: every hunter running the same tool on the same program finds the same hosts. Use them to build a list, then read and think, because understanding one interesting application beats scanning a thousand dull ones.

Keep notes you can reuse

For each target keep a simple file: scope, hostnames found (with the date), technology, interesting features, and what you have already tested. Repeating recon later and comparing with your notes shows you what is new.

Be careful

  • Do not test hosts you cannot confirm are in scope.
  • Never access, download or change other people's data.
  • Respect rate limits. If a program asks you not to run scanners, do not.
  • Do not store or share sensitive data you stumble on. Report it instead.

Takeaway: start from the scope, use passive sources first, keep active steps gentle and in bounds, and turn what you find into notes that guide where you test.

Bug Bounty series, Part 2 (recon and tools): 1 of 5.

Keep reading