passive OSINT: mapping an attack surface before you touch anything
How passive reconnaissance using open source intelligence reveals more than most people expect, without sending a single packet.
There is a meaningful gap between what an organization thinks is exposed and what is actually visible from the internet. Passive OSINT, open source intelligence gathered without ever touching a target’s systems directly, exists in that gap. It is legal, it is quiet, and in the right hands it paints a surprisingly complete picture.
This is worth understanding from both sides. As a defender, knowing what an adversary can learn about you without triggering a single alert should inform how you harden your perimeter. As someone doing a reconnaissance exercise, passive OSINT is where any serious engagement starts.
/ what counts as passive /
The distinction matters. Active reconnaissance involves sending packets to a target: scanning ports, probing services, triggering server responses. This leaves traces and in most contexts requires explicit authorization.
Passive reconnaissance means gathering information that is already publicly available. You are reading, not touching. DNS records, certificate transparency logs, WHOIS data, archived web content, search engine caches, social media, job postings; none of these require you to make any contact with the target’s infrastructure.
The line gets blurry in a few places (querying a third-party service that then queries the target on your behalf, for instance), but the core principle holds: if it’s public, reading it is passive.
/ DNS and certificate intelligence /
DNS is remarkably chatty for something most people treat as invisible infrastructure.
Certificate transparency logs are public by design. Every certificate issued by a trusted CA is logged, and those logs are searchable. Tools like crt.sh let you enumerate subdomains simply by searching for certificates issued to a domain. Internal staging environments, developer portals, and forgotten legacy services all show up here if they’ve ever had a certificate.
WHOIS records often reveal registration dates, registrars, and sometimes contact information. Older registrations are particularly interesting, as they can indicate infrastructure that predates the organization’s current security posture.
DNS history services (SecurityTrails, DNSDumpster, and similar) maintain historical records. IP addresses that were once associated with a domain, MX records that have since changed, nameserver transitions; this history can reveal infrastructure relationships the current DNS record doesn’t show.
/ the job posting problem /
Job postings are underrated as an intelligence source. A posting for a “Senior Engineer, AWS infrastructure (EKS, RDS, Terraform)” tells you the cloud provider, the orchestration layer, the database type, and the IaC tooling. A posting for a SOC analyst that requires “experience with CrowdStrike and Splunk” tells you the endpoint detection and SIEM stack.
Organizations are essentially advertising their technology stack to the world, and most don’t think about it from a security standpoint. Defenders should periodically review their own job listings with this lens.
/ what this looked like in practice /
On a recent exercise targeting my own infrastructure:
- crt.sh returned several subdomains I had set up and half-forgotten, including an old dev instance
- Shodan (passive, queries previously-indexed data) showed my external IP associated with open ports 22 and 443, correct
- DNS history via SecurityTrails revealed a previous hosting provider I’d migrated away from, and that transition window was visible
- GitHub (searching the organization name) turned up a public repository from two years prior with a hardcoded staging domain in a config file, since removed but indexed
None of this required touching anything. All of it would be useful to someone planning a targeted attack.
/ the defender’s takeaway /
Passive OSINT is not a niche skill. It is the starting point for any serious threat intelligence or red team exercise, and the information it surfaces is available to anyone. Running this kind of exercise against your own footprint is one of the higher-leverage things a security-conscious individual or small team can do.
The questions to ask are simple: what do your job postings reveal, what’s in your certificate logs, what does your DNS history look like, and is there anything in public repositories that should not be there?
The answers are usually more interesting than expected.
Tools used (passive): crt.sh, DNSDumpster, SecurityTrails (free tier), Shodan (previously-indexed data), GitHub search, Google dorks.