$ cat osint.md

How attackers map your attack surface

OSINT - open-source intelligence - is information anyone can collect from public sources. For an attacker it's step one: build a map of your attack surface before touching your app.

It works because a lot of what you publish says something about how you're built: certificates, DNS records, job ads, old web pages, public code. None of it is a vulnerability on its own. Put together, it tells an attacker which doors exist and which ones are probably weak.

⚠ Recon your own assets, or targets you have written permission to test. Passive OSINT reads public data, but using it to target someone else's systems can still be illegal or against their terms. Examples on this site use example.com placeholders.

## passive vs active

passive recon

Reading data held by someone else: certificate logs, archives, search engines, Shodan. You never send a packet to the target, so the target can't see you.

active recon

Talking to the target directly: probing hosts, scanning ports, requesting files. Visible in their logs - and needs permission.

That's why OSINT is so dangerous for defenders: the passive phase leaves no trace in your logs. By the time you see the first request, the attacker already has a plan.

## what each public source reveals

source	what it reveals	leads to
Certificate transparency crt.name	Every subdomain you ever got a TLS certificate for - staging., admin., old-api.	A02
DNS & subdomain datasets subfinder, Amass	Forgotten hosts and dangling CNAMEs pointing at deleted cloud resources (subdomain takeover).	A02
Internet scanners Shodan, Censys	Open ports, admin panels, default pages and version banners - already indexed.	A02, A03
HTTP headers & error pages curl, httpx	Server: nginx/1.18.0, X-Powered-By, stack traces with paths and versions.	A02, A10
Web archives Wayback Machine	Old endpoints, old JavaScript, URLs with parameters - often still live.	A01, A05
JavaScript bundles & source maps browser dev tools	Internal API routes, hidden admin features, API keys, library versions.	A01, A04
Public code GitHub, GitLab, gists	Leaked secrets (even in old commits), internal hostnames, dependency lists, internal package names.	A03, A04
Exposed files /.git, /.env, /swagger	Source code, credentials and a full map of your API.	A02
Job postings LinkedIn, careers page	"Angular 12, .NET 6, Elasticsearch 7" - your stack, and how outdated it is.	A03
People LinkedIn, company site, theHarvester	Employee names → email/username format → targets for phishing and password spraying.	A07
Breach data public breach notifications	Passwords your users and staff reused on other sites.	A07

## one fact leads to the next

Real recon is a chain. A typical one, all from public data:

crt.name shows a certificate for staging-api.example.com.
A job ad says the team uses .NET 6 - out of support since November 2024.
The Wayback Machine has staging-api.example.com/swagger/index.html from last year.
A developer's public repo contains appsettings.Development.json with a connection string.
LinkedIn gives 40 employee names; the company site shows emails are first.last@.

No request has touched the target yet - and the attacker already knows where to start: an unpatched staging API with documented endpoints, a possible credential, and a list of usernames.

## turn it around

Everything above works just as well for you. Running the same recon on your own domain is the fastest way to find your forgotten and unknown attack surface.

./lookup - click-through, no install ./recon-yourself - command-line checklist ./recon.sh - one line or full report

Further reading: Web Attack Surface and Bug Hunting Methodology on InternalAllTheThings by Swissky.