Reconnaissance & OSINT

Passive recon gathers data from third parties and public sources without sending packets directly to the target’s infrastructure. Active recon probes the target (DNS queries to their servers, HTTP requests, port scans). In practice the line can blur (e.g., DNS to authoritative servers), so judge by intent, policy, and what the RoE allows.

Start passive when you need breadth with less noise: forgotten subdomains, old staging names, leaked documents, employee naming patterns, technology hints. Move active when passive inventory is organized and you have written authorization for the addresses and names you will touch.

Authorization still applies. Querying public CT logs for a domain in a bug bounty program may be fine; bulk scraping personal data, harassing individuals, or using breach datasets against people without a lawful professional purpose is not “just OSINT.” Stay mission-focused and minimize sensitive personal data in notes.

Certificate Transparency (crt.sh and similar) logs certificates issued for names under a domain. Subdomains appear because operators requested certs — including staging, VPN, and legacy systems. Query, deduplicate, and mark which names still resolve.

WHOIS and RDAP give registration metadata, name servers, and sometimes contacts. Privacy redaction is common; still record registrar and NS for attack-surface and phishing-resistance discussions. dig/nslookup against public resolvers maps what the world sees for A/AAAA/MX/TXT/CNAME.

Subdomain enumeration tools (subfinder, Amass in passive modes, theHarvester) automate multi-source collection. Prefer passive/source modes first; understand each tool’s configuration so you do not accidentally enable aggressive active modes against out-of-scope infrastructure.

Search engines still reward skilled operators: site:, filetype:, inurl:, and careful phrases surface exposed indexes, docs, and login portals. Google dorking is not magic — it is disciplined querying plus note-taking. Respect robots and legal boundaries; do not automate abusive scraping of search engines.

Web archives (Wayback and similar) preserve old paths, parameters, and JS endpoints that modern SPAs still honor. waybackurls and related tooling help extract historical URLs for later content discovery. Filter for admin, api, backup, .git, and auth-related paths — always against in-scope hosts only when you move to active checks.

Public code hosts, paste sites, and cloud buckets sometimes leak secrets. If you find live credentials during authorized testing, handle as sensitive loot: notify per RoE, do not reuse outside the engagement, and never dump findings on social media for clout.

Shodan, Censys, and similar engines show banners and services already observed by third parties. They are excellent for scope discussions (“this management port is already public”) and for prioritizing hardening. Using them to attack random hosts remains unauthorized activity.

Interpret results with humility: banners lag, CDN front-ends confuse ownership, and shared hosting may show neighbors. Cross-check with DNS and the client’s asset list before treating an IP as in scope.

Record the query, date, and screenshot or export. Recon claims in reports should be reproducible. If a port was open on Shodan but closed during your test, that historical exposure can still be a useful narrative for risk and monitoring gaps.

Raw tool output is not inventory. Normalize into fields: name, IP(s), source (CT, search, client list), resolves? (yes/no), in-scope? (yes/no/unknown), notes. Unknown scope items become questions for the client, not silent additions to your scan list.

Assign confidence and priority: production marketing site vs forgotten Jenkins on a weird subdomain. Passive recon often finds the weird ones — those drive high-value paths later.

Stop conditions matter. Infinite OSINT is a real failure mode. Define “done enough for this phase”: core domains covered, major sources queried, inventory reviewed, open questions listed. Then proceed to pipelines and scanning under RoE.

A modern recon pipeline is a staged factory: (1) discover names, (2) resolve to IPs, (3) optional port foreshadowing, (4) HTTP probe for live web, (5) light fingerprint or safe template checks, (6) manual triage. Each stage has inputs, outputs, and failure modes.

Example flow (authorized targets only): subfinder → resolve (dnsx/puredns/massdns style tooling as available) → httpx → optional katana crawl on approved hosts → selective nuclei with safe tags → notes. Adjust for RoE: some programs forbid automated vulnerability scanning entirely.

Never let a wildcard mental model send traffic out of scope. Physical files win: scope.txt, oos.txt, roots.txt. Feed tools explicit lists. If a new name appears mid-pipeline, gate it through scope review before active stages.

Combine passive sources first, then consider permitted active DNS brute force only if RoE allows and rate is sane. Wordlists should match the environment (corp naming vs product SaaS). Longer lists are not automatically better if they burn time and trigger defenses.

Resolution must handle wildcards. Some domains resolve every label; without wildcard detection you invent infinite fake hosts. Record both names and IPs; CDNs may map many names to shared edges — ownership still follows the name and client asset rules.

Deduplicate with sort -u and tools like anew so daily runs only add deltas. Recon is iterative across days of an engagement; deltas are where new staging systems appear.

httpx (and similar) confirms which hosts speak HTTP(S), captures status, title, tech hints, and TLS info. Tune threads and rate. Production marketing sites and fragile appliances are not CTF boxes — start slow, increase only if stable.

Crawlers (katana, browser-based tools) expand paths on live apps. Stay on in-scope hosts, respect authentication boundaries, and avoid destructive methods. Save URL lists for content discovery later; do not weaponize every path immediately.

Titles and status codes feed prioritization: “Jenkins”, “login”, “phpmyadmin”, default framework pages, and error banners often beat generic marketing sites for early attention — after scope confirmation.

Nuclei and similar template engines are powerful and easy to misconfigure. Use only with authorization, against in-scope assets, with templates appropriate to the engagement (often “safe” or informational first). Aggressive CVE spray can DoS or violate bounty rules.

Automation without notes is noise. For every automated alert you pursue, capture the request/response evidence and a human hypothesis. False positives are common; your reputation depends on verification.

naabu and other port foreshadowing tools may sit between resolve and full Nmap. Keep methodology staged: do not confuse a quick top-ports peek with full enumeration (Module 4). Document what each stage was meant to answer.

Save raw outputs with timestamps: scans/recon/2026-08-10_subfinder.txt, httpx.json, etc. Prefer machine-readable exports when available and use jq to build clean lists (live-hosts.txt, titles.txt, techs.txt).

A teammate should be able to re-run or continue from your folder. Include tool versions (subfinder -version) in notes. Pipelines evolve; reproducibility prevents “it found it yesterday” mystery.

Know when to stop automating. If httpx shows three interesting apps, deep manual mapping may beat another hour of template spam. Experts schedule thinking time; beginners hide in tools.

Even authorized tests can harm availability. Use rate flags, avoid business-critical windows if RoE says so, and coordinate with the client when automation must be louder. Bug bounties often ban automated scanning or limit it — read the policy again before pipelines.

Third-party SaaS in the inventory may be out of scope for active probing even if DNS points at them. Separate “client-controlled” from “vendor-controlled” assets.

Your pipeline is part of your professional brand. Clean inventories, low collateral noise, and clear handoff to scanning/exploitation phases mark operator maturity more than a huge raw subdomain count.