Every assessment begins with reconnaissance — and the most disciplined testers start without sending a single packet to the target. Passive reconnaissance builds a picture of an organisation's attack surface entirely from data that already lives in third-party sources: certificate-transparency logs, public DNS, search-engine indexes, internet-wide scanners, and public code repositories. It is quiet, fast, and zero-footprint — and it routinely surfaces the forgotten subdomain, the exposed admin panel, or the indexed backup file that becomes the way in.
This lesson introduces the quiet phase that comes before hands-on active recon — techniques such as browser inspection ([browser-recon](browser-recon)) and content discovery ([content-discovery-enumeration](content-discovery-enumeration)) — by mapping the whole external attack surface from the outside, so that by the time you touch the target you already know what to touch.
Scope and authorisation come first
Passive recon feels harmless because you are querying Google, crt.sh, and Shodan rather than the target's own servers. The data-gathering is low-risk, but the engagement is still scoped:
- Only act on assets you are authorised to test. Discovering a subdomain is not permission to scan or exploit it — confirm every host is inside the agreed scope before doing anything active against it.
- The embedded practice application is not a valid OSINT subject. A localhost app has no certificates in CT logs, no search-engine presence, and no internet exposure. The practical here must target a domain you own or are explicitly authorised to assess — your own domain, a bug-bounty program's in-scope domains, or a lab.
If there is any doubt, re-read [hacking-ethics-and-authorization](hacking-ethics-and-authorization). Scope is a written boundary, not a judgement call.
In this lesson you will
- See the line between passive recon (querying third parties) and active recon (touching the target), and why passive comes first.
- Enumerate subdomains passively from certificate-transparency logs (crt.sh,
subfinder/amass). - Fingerprint a target's technology stack from headers and
whatweb/Wappalyzer. - Craft Google dorks to surface exposed files and login pages, and query Shodan/Censys for internet-facing services.
- Compile the findings into an attack-surface map — the target list every later phase depends on.
Prerequisite: The techniques step uses DNS record types (A, CNAME, MX, TXT, NS) without defining them. If these are unfamiliar, complete [networking-dns-tls](networking-dns-tls) first — the hands-on exercise will not make sense without that background.
Target: a domain you own or are explicitly authorised to test, plus read-only third-party sources (crt.sh, Shodan/Censys, Google). Never the embedded localhost app. If you do not yet own a domain, suitable options include a bug-bounty programme's explicitly in-scope training targets, a domain your instructor provides for the exercise, or a free subdomain from a course lab environment.
Estimated time: twelve to fifteen minutes.
When you are ready, send the Continue signal.