~/tutorials / osint-fundamentals

OSINT Fundamentals

Map an organization's public footprint ethically, from domains and certificates to leaked code, and learn to audit your own exposure.

beginner30 min readupdated
  • osint
  • recon
  • privacy

Lab only. Practice these techniques on your own machines or on platforms that explicitly authorize testing. Informational and educational use only.

Open-source intelligence is the art of learning a great deal from information that is already public. It’s the first phase of almost every engagement, and it’s how real attackers choose their targets. Done well, it finds the forgotten server or leaked key before anyone else does.

OSINT is legal when it uses public sources, but it is not automatically ethical. Focus on organizations within an authorized scope. Do not compile profiles of private individuals, and never contact, impersonate, or harass anyone.

Start with yourself

The safest and most eye-opening first target is you. Search your own name, usernames, and email addresses. Check your email at Have I Been Pwned. Look at what your old forum posts, code commits, and photo metadata reveal. Fix what you find. You’ll learn the techniques and shrink your own attack surface at the same time.

The organizational footprint

For an authorized target, work from the root domain outward.

Certificate transparency. Every public TLS certificate is logged. Searching crt.sh for %.example.com lists subdomains the organization never meant to advertise:

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

DNS records. MX records reveal the email provider. TXT records reveal SaaS vendors through verification tokens. SPF records list every service allowed to send mail as the company.

dig +short MX example.com
dig +short TXT example.com

IP ownership. Look up the organization’s ASN on bgp.he.net to find IP ranges it owns, as opposed to cloud ranges it rents.

Historical data. The Wayback Machine shows old pages, forgotten endpoints, and JavaScript files that may still reference live APIs.

Code and documents

  • GitHub search for the company domain, internal hostnames, or product names often surfaces employee side projects, configuration files, and occasionally credentials. Report leaked secrets to the owner. Never use them.
  • Search engine operators narrow results fast: site:example.com filetype:pdf, site:example.com inurl:admin, "example.com" site:pastebin.com.
  • Document metadata. PDFs and Office files often contain author names, software versions, and internal paths. exiftool report.pdf shows it all.

Organize as you go

OSINT produces a lot of loose facts. Keep a simple structure from the first minute:

Asset Source Notes
vpn.example.com crt.sh Login portal, vendor branding visible
203.0.113.0/24 ASN lookup Owned range, in scope per RoE
Uses Google Workspace MX record Phishing tests would target Google sign-in

Tools like SpiderFoot and Maltego automate and visualize collection, but understand the manual steps first so you can judge what the tools give you.

What defenders should take from this

Everything above is visible to anyone. Organizations should run the same checks on themselves regularly: monitor certificate transparency for unexpected subdomains, scan public repositories for leaked secrets, and strip metadata from published documents.

Takeaway

The best OSINT finding is usually boring: an old subdomain still pointing at a forgotten server. Patience and good notes beat clever tools.