OSINT Fundamentals: Recon Before You Touch the Target

Every engagement starts before you send a single packet at the target. OSINT (Open-Source Intelligence) is the practice of gathering information from publicly available sources — DNS records, certificate logs, breach databases, social media, search engines — to build a picture of a target's attack surface before you touch it directly. It's the highest-leverage phase of a real engagement or bug bounty hunt that most beginners skip past to get to the "real" hacking, and it's usually where the most useful leads actually turn up: a forgotten subdomain, an employee's reused password from an old breach, a tech stack fingerprint that points straight at a known CVE.

Passive vs. active recon

This distinction matters more than any specific tool. Passive recon never sends traffic to the target itself — you're querying third parties (search engines, certificate transparency logs, WHOIS registries, breach databases) that already have the information. Active recon — port scanning, directory brute-forcing, even just visiting the target's website in a browser — touches the target directly and can be logged, alerted on, or rate-limited.

Do as much passive recon as possible before moving to active. It's quieter, it's usually faster, and on a real engagement it's often explicitly allowed even when the rest of the scope is tightly restricted. Everything in this guide is passive.

Domain and DNS enumeration

Start with what the domain itself tells you.

whois example.com

whois returns registration details: registrar, creation/expiration dates, and — depending on the TLD and whether privacy protection is enabled — registrant contact info. Registrar and creation date alone are useful for spotting recently-registered lookalike domains in a phishing investigation.

dig example.com ANY
dig example.com MX
dig example.com TXT

dig queries DNS records directly. MX records reveal what mail provider a company uses (Google Workspace, Microsoft 365, self-hosted), which matters for both phishing-simulation planning and understanding their infrastructure. TXT records often leak more than they should — SPF records list every mail-sending service authorized for the domain, and it's not unusual to find verification tokens for third-party SaaS tools a company uses, each one a small piece of the picture.

For subdomains, certificate transparency logs are the highest-signal free source available — every publicly trusted TLS certificate ever issued for a domain gets logged permanently, subdomains included:

curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u

This alone frequently turns up staging environments, old marketing microsites, and internal tools that were never meant to be public-facing but got a certificate anyway.

Search engines as a recon tool

Google (or any search engine) indexes far more than most organizations realize. Search operators let you narrow results to exactly what you're after:

site:example.com filetype:pdf
site:example.com inurl:admin
site:example.com -www

site: restricts to one domain, filetype: finds exposed documents (PDFs, spreadsheets, and configuration files all show up here more often than they should), and inurl: hunts for specific paths like login or admin panels. This technique has a name — "Google dorking" — and a maintained public archive of useful queries at the Google Hacking Database.

Breach and leak data

If part of an engagement's scope covers credential exposure, breach databases show whether an organization's employees have reused passwords that have already leaked elsewhere. Have I Been Pwned is the standard, well-maintained starting point — check your own accounts there before ever using it against a client's, so you understand what it actually returns.

This is also the area with the sharpest ethical and legal edges in OSINT. Checking whether an email address appears in a known breach is generally fine. Actually obtaining, storing, or using leaked passwords is a different matter entirely, and often outside what an engagement authorizes even when breach exposure is in scope — read the rules of engagement carefully before assuming "OSINT" covers it.

Username and social footprint

People reuse usernames across platforms far more than they reuse passwords. Given one confirmed username, tools like Sherlock check its existence across hundreds of sites in one pass, which is useful for building a picture of an individual's public footprint during an authorized social-engineering assessment or for de-anonymizing a threat actor's other accounts during an investigation.

Two dedicated tools are worth learning properly once you've got the fundamentals here down: theHarvester for pulling emails, subdomains, and names from a wide range of public sources in one run, and Shodan for finding internet-facing devices and services by fingerprint rather than by domain name at all.

Common mistakes

• Jumping straight to active scanning. Passive recon is free, quiet, and often turns up things a port scan never will — a leaked API key in a public GitHub repo tells you more than an open port does.
• Forgetting OSINT has scope too. "It's public information" is not the same as "it's in scope." A real engagement's rules of engagement define what OSINT is authorized to touch — company infrastructure and public-facing assets, usually; employees' personal social media and family members, usually not, even if it's technically public. Read the scope, don't assume it.
• Not rate-limiting or respecting platform terms of service. Automated queries against search engines, WHOIS servers, and third-party APIs can get your IP blocked fast, and some platforms' terms explicitly prohibit scraping regardless of rate. Tools like theHarvester handle this more gracefully than a naive script will.
• Treating OSINT as a one-time step. Certificate transparency logs and DNS records change. On a longer engagement, a second recon pass partway through sometimes turns up something new.

Next step

Once you've got a target's subdomains, tech stack, and exposed assets mapped out, Nmap is the natural next step for anything that needs active verification. For the tools that deserve deeper coverage on their own, see the theHarvester and Shodan cheatsheets.