Passive Recon for Bug Bounty: How Vexta Pulls From 40+ Sources Before Sending a Packet

What does passive recon for bug bounty work actually mean, and why start there? Passive reconnaissance means building a picture of a target's attack surface entirely from data other services already collected, certificate logs, DNS history, web archives, so a hunter learns the scope before a single packet reaches the target itself. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, runs this as the first stage of every scan: its reconnaissance engine queries more than 40 passive sources, 26 of them requiring no API key at all, before any active discovery begins.

Which passive sources does Vexta query without an API key?

Twenty-six sources fire with no credentials required at all. Certificate transparency logs come from crt.sh, CertSpotter's free tier, and Digitorus, each surfacing subdomains the moment a TLS certificate gets issued for them. DNS aggregators and passive-DNS providers include HackerTarget, AlienVault OTX, AnubisDB, ThreatCrowd, RapidDNS, Mnemonic, ThreatMiner, DNSRepo, and DNS History. Web archive sources pull historical URLs out of the Wayback Machine's CDX API, CommonCrawl's index, and the Portuguese Arquivo.pt archive, which often surface old parameters and endpoints long removed from the live site. A handful of HTML-scraping sources, DNSDumpster, SiteDossier, Riddler, and NetCraft, round out the aggregator list, and six general search engines, DuckDuckGo, Bing, Yahoo, Yandex, Baidu, and Ask, get scraped directly for indexed pages the aggregators miss.

None of this touches the target's infrastructure. Every one of those 26 sources is a third party that already crawled, logged, or indexed the target's public footprint, so the recon phase can build a substantial subdomain and endpoint list before Vexta's own traffic ever reaches the target's servers.

What do API keys add to the source list?

A further 25 sources are available when a hunter supplies their own API keys, expanding the same passive model with paid or registration-gated data: Shodan and Censys for internet-wide scan data, VirusTotal and SecurityTrails for domain intelligence, BinaryEdge, FullHunt, URLScan, and Netlas for exposure data, and specialist feeds like DNSDB, IntelX, ONYPHE, Quake, ZoomEye, WhoisXMLAPI, LeakIX, PassiveTotal, Hunter, Chaos, FOFA, CIRCL, and C99. Each source authenticates the way its provider expects, whether that is a query parameter, a bearer token, or basic auth, and Vexta simply adds its results into the same aggregated recon output as the free sources. None of these are required to get useful recon; they extend coverage for a hunter who already has accounts with some of these providers.

How does code search fit into passive recon?

Recon also reaches into source code hosting. Vexta's GitHub dorking runs REST API code searches for leaked secrets, exposed configuration files, and internal endpoint references, using configurable dork patterns that automatically search for terms like password, api_key, and JWT alongside common configuration file names. When a GitLab key is supplied, the same dorking runs against GitLab's search API as well. For a hunter, this is often where the highest-value finds show up early: a leaked credential or an internal API path committed by mistake tells you more about the real attack surface than a subdomain list alone.

This is also passive in the sense that matters for scope: querying a code-hosting platform's own search API for text a developer already committed in public is not sending traffic to the target's infrastructure at all. A secret or endpoint surfaced this way still needs the same verification discipline as anything else in the report, confirming it is live, in scope, and reported through the program's own disclosure process, but finding it costs nothing in terms of noise against the target itself.

How does this look on an actual target?

In practice, the 26 free sources run in parallel as soon as a scan starts, and each returns a slightly different slice of the same picture: crt.sh and CertSpotter surface subdomains the moment a certificate is issued for them, even for hosts nobody linked to from the main site; the Wayback Machine's CDX API and CommonCrawl turn up parameter names and endpoint paths from years-old snapshots that the current site no longer links to but the server may still accept; DNSDumpster and NetCraft fill in infrastructure details like mail and hosting providers. None of these results depend on each other, so a source going stale or rate-limiting for the day does not stall the rest of the pass, and the aggregated output ends up broader than any single tool's view of the same target.

For a hunter working a program with a wide wildcard scope, that combined output is often the difference between testing a handful of subdomains anyone would find with a quick lookup and testing the long tail of forgotten staging hosts, old API versions, and archived endpoints that never got decommissioned. Those forgotten assets are disproportionately where bugs survive, precisely because nobody is actively maintaining or monitoring them.

Why does starting passive matter for a bug bounty hunter?

Most bug bounty programs put limits on active scanning, whether that is a rate cap, a list of excluded subdomains, or a blanket rule against noisy brute-forcing before scope is understood. Running through 40-plus passive sources first means a hunter walks into active testing already knowing a large share of the target's real subdomains, historical endpoints, and technology footprint, which makes every active probe that follows more targeted and less likely to trip a program's own monitoring before it needs to. It also means recon keeps producing results even against a target that is otherwise well-defended against active scanning, since none of these 40-plus sources requires the target to respond to anything at all.

Key takeaways