OSINT recon: notes from the field
Before an authorized engagement touches a single port, most of the useful signal is already public. A disciplined passive-recon pass keeps the later active testing focused instead of a blind scan of everything in scope.
What to collect
- Infrastructure: DNS records, subdomains, ASN/IP ranges, certificate transparency logs for name discovery.
- Technology footprint: what's visible from HTTP headers, JS bundles, job postings mentioning stack choices.
- People & process: public org charts, breach-corpus hits for reused credentials patterns (never the credentials themselves), naming conventions in email/usernames.
- History: old subdomains or endpoints that still resolve but were meant to be retired.
Keep it passive
The whole point of this phase is that it generates no traffic to the target beyond what's already public or intended for the public (search engines, registries, transparency logs). Save anything that touches the target directly โ even a "harmless" scan โ for the active phase once scope and rules of engagement are confirmed in writing.
Turning it into signal
Raw data is not a finding. Cluster what you gather into a short list of concrete hypotheses โ "this subdomain looks like a staging environment," "this stack version has known issues" โ and rank them by how much they'd matter if true. That list is what drives the next phase, not the recon dump itself.
All of this applies within the scope and authorization of an actual engagement or bug bounty program โ recon on a target you don't have permission to assess is not covered by "it's just public information".← back to posts