Published: 2026-05-24

Bug bounty hunters who skip passive recon spend time attacking scope they don't understand and miss targets that aren't linked from the main domain. The most valuable findings in a program often live on forgotten subdomains running outdated software, development servers that slipped into production, or third-party integrations with weaker security than the primary application. None of these are discoverable by browsing the main site. All of them are discoverable through passive OSINT before you send a single active probe.

Passive means: no requests to target infrastructure. Everything in this guide touches only public data sources — DNS aggregators, certificate transparency logs, WHOIS registries, and search engine indexes. This matters for two reasons. First, some programs have rules against active scanning during recon. Second, active scanning generates noise. A well-executed passive recon phase builds the full target map silently, letting you choose exactly where to apply active techniques.

Start with certificate transparency. Every TLS certificate issued for target.com and its subdomains appears in public CT logs. Query crt.sh:

curl -s "https://crt.sh/?q=%25.target.com&output=json" \
  | jq -r '.[].name_value' \
  | sort -u \
  | grep -v '\*'

This returns every subdomain that ever received a TLS certificate, including decommissioned ones that may still be live. Unlike DNS brute-force, it produces no false positives — every result is a real certificate that was issued.

Follow with passive DNS aggregation. OpenOSINT's search_domain wraps sublist3r, which queries Google, Bing, DNSdumpster, VirusTotal, and several other sources:

openosint domain target.com

Cross-reference both lists. Subdomains appearing in CT logs but not DNS aggregators may be live but not indexed — more likely to host forgotten services. Subdomains appearing in both are confirmed active in recent history.

For each confirmed subdomain, record the A record IP. Group subdomains by IP range using ASN lookup. Subdomains on the same /24 as the main application are likely internally managed. Subdomains on entirely different ASNs often indicate third-party SaaS integrations or acquired infrastructure — frequently managed by a different team with different security posture.

WHOIS tells you who owns the target and when it was registered. For bug bounty, the more useful information is nameservers and registrar. Nameservers reveal the DNS provider: Route53, Cloudflare, custom nameservers. Custom nameservers often indicate self-managed DNS infrastructure; DNS provider nameservers indicate the program uses a managed service.

openosint whois target.com

Check the ASN for each IP in your subdomain inventory. If the main application is on AWS (AS16509) but a subdomain resolves to a different ASN, it may be old infrastructure or an acquisition. These are worth examining closely — infrastructure that predates the current security program often hasn't been through the same hardening process.

For corporate targets with large IP portfolios, Shodan queries against the ASN reveal everything the organization has publicly exposed on non-standard ports. org:"Target Corp" or asn:AS12345 returns the full port/service inventory. Admin panels, development servers, and monitoring interfaces exposed on unusual ports are common findings here.

Before touching any target system, search GitHub for leaked credentials. This is entirely passive and frequently produces critical findings:

# Search for secrets in public repos referencing the target domain
"target.com" "api_key" OR "secret" OR "password" site:github.com

# Search for the company name
"TargetCorp" "AWS_SECRET_ACCESS_KEY" site:github.com

# Search for internal hostnames
"internal.target.com" site:github.com

The Google dorks guide covers additional patterns. OpenOSINT's generate_dorks generates 12 ready-to-use search URLs for any target domain, including the GitHub patterns.

What to look for on GitHub: hardcoded API keys that appear in commit history even if removed from current HEAD (GitHub's search indexes history), internal hostname patterns that reveal the target's internal network topology, configuration files containing database connection strings, and employee personal repos that contain work-related credentials.

Any credential found through GitHub dorking should be tested for validity before reporting. An expired token is still a valid low/informational finding with historical exposure context. A live token is a critical.

After passive recon, you should have: a confirmed subdomain list with IPs and ASN annotations, WHOIS data for the primary domain and any interesting registrant patterns, a GitHub finding log, and a set of Google dork URLs to review manually.

Use OpenOSINT to run the IP reputation pass on each unique IP in the inventory:

openosint multi ips.txt --json > ip_results.json

IPs with high AbuseIPDB confidence scores on in-scope infrastructure are worth noting — either the program's infrastructure is being used maliciously (a valid finding category), or the IPs are shared hosting that also hosts abusive content.

This full passive recon pass takes 15–30 minutes on a typical program and produces a prioritized target list before a single probe is sent to the program's infrastructure. The subdomains with different ASNs, decommissioned CT-log entries still resolving, and GitHub credential hits are your first active investigation priorities. See the subdomain enumeration guide for deeper coverage of the enumeration phase, and the OSINT API automation guide for programmatic Shodan and Censys integration.

• Subdomain enumeration — passive CT logs, DNS aggregation, and tool comparison
• Google dorks for security researchers — target-specific recon patterns including GitHub secret search
• Automating OSINT with APIs — Shodan, Censys, and VirusTotal programmatic integration