Open-source intelligence (OSINT) is the practice of gathering information from publicly available sources and turning it into something useful. Every attacker uses some form of OSINT before they touch your systems — your domain names, your employees on LinkedIn, your exposed S3 buckets, your code on GitHub, your job adverts naming internal tools. The good news is that defenders can use exactly the same techniques, in advance, to find and fix what attackers would otherwise exploit. Done well, OSINT is one of the cheapest, highest-leverage things a security team can do.
What counts as OSINT
OSINT is not a single tool or website; it is a discipline that pulls together many public sources. Common categories include:
- Domain and DNS data – WHOIS records, DNS history, certificate transparency logs (crt.sh), subdomain enumeration.
- Internet-wide scan data – Shodan, Censys, ZoomEye, and FOFA index services and devices reachable from the internet.
- Code and configuration leaks – GitHub, GitLab, Bitbucket, pastebins, and public S3/Azure/GCS buckets sometimes contain credentials, internal hostnames, or source code.
- People and organisations – LinkedIn, company websites, conference talks, press releases, regulatory filings, and breach data dumps.
- Social media and forums – Twitter/X, Reddit, Mastodon, Discord, and underground forums where leaks, exploits, and tooling are discussed.
- Geospatial and image data – Satellite imagery, Street View, EXIF metadata on photos.
Crucially, OSINT only uses information already public. Anything that requires breaking authentication, exploiting a flaw, or otherwise accessing non-public data is no longer OSINT — it is intrusion.
How attackers use OSINT against you
Most targeted attacks begin with a reconnaissance phase that is almost entirely OSINT, often before the target ever sees a single probe. Typical patterns:
- Mapping the attack surface – Enumerating subdomains, exposed services, cloud assets, and forgotten dev/staging environments through certificate transparency, DNS history, and Shodan.
- Profiling employees – LinkedIn to find names, roles, tech stack, and reporting lines; then crafting believable spear-phishing or vishing pretexts targeting finance, HR, or IT.
- Harvesting credentials – Searching breach data and combolists for company email addresses already exposed, then trying those passwords (or variants) against SSO and VPN portals.
- Finding leaked secrets – GitHub dorking for API keys, AWS access keys, internal hostnames, and config files committed in public repos by employees or third-party developers.
- Understanding the stack – Job adverts often disclose specific products, versions, and even cloud providers, which informs exploit selection and social-engineering scripts.
By the time an attacker sends their first phishing email or probes a service, they often know more about your environment than many of your own staff do.
Using OSINT to defend your organisation
The same techniques work in reverse. A small, disciplined OSINT routine often surfaces issues your scanners never will.
- External attack surface management – Regularly enumerate subdomains, certificates, and internet-exposed services for every domain you own. Tools like
amass,subfinder,httpx,nuclei, plus Shodan and Censys queries, are a good starting point. - Credential and leak monitoring – Check breach-data services (Have I Been Pwned, internal threat-intel feeds) for company email addresses and force resets where matches appear. Watch paste sites and known leak forums for mentions of your domains or products.
- Code leakage – Run GitHub searches for your domains, internal hostnames, and known repo names. Use secret-scanning tools (Gitleaks, TruffleHog) on your own org and, where permitted, on contractor repos.
- Brand and impersonation monitoring – Monitor newly registered lookalike domains (typosquats, homoglyphs) and certificate transparency feeds; report and take down phishing infrastructure early.
- Executive and high-risk staff exposure – Quietly check what is publicly known about senior staff and admins (home address, family members, personal email reused on breach lists) so you can advise them to lock things down.
Even a few hours a month spent on this surfaces real problems — forgotten dev portals, expired-but-still-pointing DNS records, hard-coded keys in old repos — that traditional vulnerability scans simply do not see.
Tooling and starting points
You do not need an expensive platform to start. A reasonable beginner toolkit might include amass and subfinder for subdomain enumeration, httpx and nuclei for probing, Sherlock or Maigret for username pivots, Shodan and Censys (free tiers are useful), crt.sh for certificate transparency, the Wayback Machine for historical content, and exiftool for metadata. The OSINT Framework website (osintframework.com) is a useful map of categories. For people-focused work, SpiderFoot and Maltego are commonly used. As the discipline matures, teams often consolidate into commercial attack surface management (ASM) and digital risk protection (DRP) platforms — but the manual workflow is still worth learning, because it teaches you what those tools are actually doing.
Ethics and the law
OSINT sits on a line that is easy to cross. Public does not always mean fair game, and several pitfalls are worth flagging. Computer misuse laws in the UK and elsewhere prohibit unauthorised access — passive observation of public data is fine, but probing authentication or exploiting weaknesses is not. Data protection laws (GDPR) apply when you collect and process information about identifiable people, especially employees of other organisations. Some sources (breach dumps, certain forums) carry legal and reputational risk; many organisations rely on reputable threat-intel providers rather than handling raw stolen data themselves. Document what you do, why, and under what authorisation. Treat OSINT as a craft: methodical, repeatable, ethically grounded, and tied back to concrete defensive actions. Done that way, it consistently pays for itself many times over.