Passive reconnaissance and OSINT

The quietest, safest, and often most productive recon happens without your traffic ever reaching the target. Other people and systems have already collected information about the company, search engines, certificate authorities, code hosts, archives, and you can read what they collected. This is passive reconnaissance, and its close cousin OSINT (open-source intelligence): learning from public sources.

The line that matters: who feels your presence#

Draw this line in your head and keep it there for the rest of your career. Passive recon means you talk to third parties, Google, a certificate log, an archive, and never to the target's own servers. The target has no record you were ever interested in it. Active recon means a packet reaches the target: you loaded its home page, asked its DNS server a question, ran a scanner against it. That lands in a log with your IP.

Why care so much? Two reasons. On a real engagement, staying passive as long as possible means you learn the shape of the target before you make any noise. And on the wider internet, passive recon on a company is generally fine, you are only reading public data, whereas active recon on something you are not authorised to test can cross a legal line. Passive first is both good tradecraft and good conduct.

Sources that pay off#

Search engines, used properly. Not "search the company name" but targeted queries, sometimes called Google dorking. site:example.com shows what a search engine has indexed for that domain, including pages nobody links to any more. site:example.com ext:pdf finds documents. site:example.com inurl:admin or intitle:"index of" surfaces panels and open directory listings. You are reading the search engine's memory of the site, not the site.

Certificate transparency logs. Every time a company gets an HTTPS certificate, it is written to a public, append-only log. Those certificates name the hostnames they cover. So a public site like crt.sh will, for a query of example.com, hand you a list of subdomains the company has ever gotten certificates for, including internal-sounding ones like vpn., jira., staging. that were never meant to be found. This is one of the single best passive sources of subdomains, and the next lesson leans on it.

Code hosts. Developers push code to GitHub, GitLab and the like, and sometimes push things they should not: internal hostnames, API endpoints, and occasionally a hardcoded credential or key. Searching a code host for the company's domain, its unusual internal names, or strings like example.com next to password or api_key can hand you a live secret. Company repositories, and personal repositories of employees, are both worth a look.

Web archives. The Wayback Machine keeps old snapshots of pages. A page that used to expose an endpoint, a parameter, or a comment, and has since been cleaned up, may still be readable in the archive. Old JavaScript files in particular often list API routes that still exist on the live server.

The company's own footprint. Job listings name the technologies a team uses ("must know Laravel, Postgres, AWS"). Engineering blog posts describe the architecture. LinkedIn tells you who the developers and admins are, which matters for password-reset and social-engineering-flavoured findings. Status pages and documentation portals list services and endpoints.

Turning sources into a target list#

The goal of a passive pass is a written list you carry into the active phase:

• Hostnames, from certificate logs, search results, archived pages and code.
• Technologies, from job posts, blogs, and any headers already captured in archives.
• Endpoints and parameters, from archived JavaScript and indexed URLs.
• People, from LinkedIn and commit histories, for the human-facing parts of the app.
• Anything that looks forgotten: a subdomain with "old", "test", "dev", "legacy", or a year in it.

You have not touched the target yet, and you may already have forty hostnames and a dozen endpoints to check.

A word on OSINT and restraint#

OSINT can reach into people's lives quickly, and the fact that something is technically findable does not make collecting it appropriate. On an authorised engagement your scope tells you how far to go, and personal data about employees is usually off limits unless the engagement specifically covers social engineering. Keep your passive recon aimed at the application and its infrastructure, not at individuals, unless you have explicit permission and a reason. The bug is in the software.

Where this goes next#

You now have a way to build a target list without making noise. The next lesson takes the most valuable output of passive recon, hostnames, and turns it into a full picture of the target's domains, subdomains, and the IP space behind them, mixing in the first careful active steps.