OSINT — Concepts
OSINT — Open Source Intelligence. Intelligence gathered from public sources. All the research you can do without sending a single packet to the target. No one will know you are looking. This is where half of an engagement is decided — before you even plug in Nmap.
The sources are public; looking at them is not a crime. But two limits exist: (1) some jurisdictions treat the mass collection of personal data as processing subject to GDPR / Law 25 even when the data is public; (2) many OSINT tools send active requests without you realizing it. Check what each tool does before you run it.
What you will be able to do after this lesson
- Tell passive reconnaissance apart from active reconnaissance — the red line.
- Name the six families of OSINT sources and know what each one gives you.
- Build a clean, version-controlled target sheet that you can use in the active phase.
- Spot the tools called OSINT that actually touch the target (and therefore change the legal nature of your action).
- Leave an OSINT session with three things: an attack plan, a list of key people, and a first batch of weaknesses to confirm.
1. The red line: passive vs active
This is the only distinction that matters, and 90% of beginners get it wrong.
| Phase | What you do | What the target sees |
|---|---|---|
| Passive | Query third parties (Google, crt.sh, shodan.io, LinkedIn). | Nothing. No packet reaches it. |
| Active | Send a direct packet (nmap, curl, ping, a scan). | An entry in its logs. |
Two examples to burn this in:
- You check
crt.shto list the subdomains ofclient.com→ passive.crt.shlooks into public certificate logs; the target has no idea you exist. - You run
dig ANY client.com @ns1.client.com→ active (a rare case). The client's DNS server receives your query. It can show up in its logs.
The simple rule: if my packet reaches the target, I am active. Otherwise, passive.
OSINT lives in the passive. It is even its definition.
2. Why it matters more than people think
A poorly prepared black-box pentest is a month of failure. A pentest preceded by two days of serious OSINT is sometimes the whole engagement finished in a week.
What OSINT gives you:
- The real perimeter, not the announced one. A client tells you about
client.com. You discover it also runsclient.io,mieux-que-client.ca,client-store.myshopify.com, and a poorly hiddenvpn.client.corp. - The technologies in use. Nginx 1.14, Django 3.1, Cloudflare in front of some subdomains and not others. Every technology has its known flaws.
- The human org chart. Who decides, who administers, who might click a booby-trapped email.
- Past leaks. HaveIBeenPwned, dumps on pastebin, the Collection #1 database — passwords of employees that are already known.
- Exposed misconfigurations. A public
.git, an open S3 bucket, an/actuator/envendpoint on a poorly secured Spring Boot.
All of this without running a scan. Quiet. Defensible. Often decisive.
3. The six families of sources
3.1. DNS — the infrastructure told through its addressing
DNS is the map of the public infrastructure. Every record tells you something.
| Type | What it reveals |
|---|---|
| A / AAAA | The public IP. Often a CDN (Cloudflare, Akamai) that hides the real server, sometimes not. |
| MX | The mail provider (Google Workspace, Microsoft 365, MailerLite…). |
| TXT (SPF) | The servers allowed to send mail on behalf of the domain — often a very telling list of SaaS services. |
| TXT (DMARC) | The anti-spoofing policy. Missing or p=none = open to phishing. |
| TXT (others) | Ownership verifications for Google, Microsoft, Slack, Facebook — shows who uses what. |
| NS | The DNS provider. A bad choice (registrar without MFA) is already a weakness. |
| CNAME | Often the real destination (heroku, netlify, github pages). |
3.2. WHOIS / RDAP — the administrative identity
Who bought the domain, when, at which registrar, with which email. These days often masked by a privacy proxy service, but sometimes not. A contact email admin@client.com visible in WHOIS = an email pattern for the whole company.
3.3. Certificate Transparency (crt.sh, Censys)
Every certificate authority publishes the certificates it issues, in public, auditable logs. The result: every certificate obtained for a subdomain is knowable, even if that subdomain is never listed anywhere.
This is the number one source for finding subdomains. One curl 'https://crt.sh/?q=%25.client.com&output=json' and you have everything that has been certified since 2013.
3.4. Search engines and Dorks
Google, Bing, DuckDuckGo index everything that is not protected. Dorks are targeted searches:
site:client.com filetype:sql
site:client.com filetype:env
site:client.com filetype:log
site:client.com intitle:"index of"
site:client.com inurl:admin
site:client.com "internal use only"
site:*.client.com -site:www.client.com
site:pastebin.com "client.com"
site:github.com "client.com" password
Each line can find a treasure. The Google Hacking Database (GHDB) lists thousands of patterns. Go look at it.
3.5. Specialized services
- Shodan: a search engine for services exposed on the Internet. Query
hostname:client.com= a list of public IPs and services. Careful: Shodan queries the targets to build its index, but you, by consulting Shodan, stay passive. - Censys: an equivalent, often more complete on certificates.
- GreyNoise: tells you about the IPs that constantly scan the Internet — useful to tell a targeted attacker apart from background noise.
- HaveIBeenPwned: do your targets' emails show up in public leaks?
- LinkedIn: the org chart, the tech stack in job postings, the employees to target with phishing.
- GitHub: the client's code, or that of its employees. You find API keys, configs, and hardcoded passwords there — more often than you would imagine.
3.6. Archives and historical sources
- Wayback Machine: the version of the site 3 years ago. It can contain endpoints removed since but still live on the server.
- GitHub Search: the public commits of former employees. A
git rmdoes not remove anything from history. - Regional archives (BAnQ, Quebec Enterprise Register): legal structure, officers, shareholders — useful for context.
4. The OSINT tools that really are not
A classic trap. Some tools sold as OSINT trigger active requests. You think you are being passive, you are active. Check every tool.
| Tool | Actual action |
|---|---|
amass enum -passive | Passive. amass enum (without -passive) does active DNS scans. |
theHarvester | Passive (queries third-party APIs). |
subfinder | Passive (by default). |
assetfinder | Passive. |
nuclei | Active. Sends probes to the target. |
httpx | Active. Checks who answers over HTTP. |
dnsx with -resolvers | Active — it uses a public resolver, but each A resolution can land at the client's NS if you force +trace. |
masscan, nmap | Active, no ambiguity. |
wappalyzer (CLI) | Active. Loads the page. |
wappalyzer (browser extension) | Active. You are the one loading the page in your browser; the target sees the request. |
In short: when you send something, you are active. It can be legitimate, but knowing it keeps you from cheating on the RoE.
5. The target sheet — the deliverable of the OSINT phase
By the end of week 3, you must have one file, version-controlled (Git), that answers the questions below. Without this file, the active phase will scatter in every direction.
# Target sheet — client.com (as of 2026-04-10)
## 1. Confirmed perimeter
- Root domains: client.com, client.io
- Subdomains (sources: crt.sh + passive subfinder):
- www.client.com Cloudflare
- api.client.com Cloudflare
- api-dev.client.com AWS ELB (ca-central-1) — out of scope? to confirm
- vpn.client.com Fortinet (public login page)
- jira.client.com Atlassian Cloud
- status.client.com StatusPage.io
- old-shop.client.com WooCommerce, last certificate 2022 — abandoned?
- Suspicious subdomains (to check against RoE):
- internal.client.com does not exist but a certificate was issued in 2024
## 2. Addressing
- Observed AS block: 203.0.113.0/28 (5 IPs)
- Providers: Cloudflare (front), AWS (backend), OVH (email marketing)
## 3. Technologies
- Front: Next.js 13.x (X-Powered-By)
- API: Django 3.2 (hint: X-Framework header)
- Forgotten files:
- /robots.txt reveals /admin and /old-panel
- /.git/config exposed on old-shop.client.com — TO CONFIRM WEEK 4
## 4. Email
- MX: mx1.google.com, mx2.google.com → Google Workspace
- SPF: v=spf1 include:_spf.google.com include:mailchimp.com -all
- DMARC: v=DMARC1; p=none; rua=mailto:dmarc@client.com → weak
- DKIM: present (selector: google)
## 5. Key people (public LinkedIn)
- CIO: Marie Tremblay (marie.tremblay@client.com)
- System admin: Etienne Roy (etienne.roy@client.com)
- 24 employees identified in total — see personnes.csv
## 6. Public leaks
- HIBP: 12 @client.com accounts appear in Collection #1 (2019)
- Pastebin: nothing so far
- GitHub: 2 personal repos of E. Roy contain scripts named
"client-backup.sh" — to examine week 4.
## 7. Attack hypotheses
- The api-dev.client.com subdomain seems to be outside the CDN. Priority target.
- .git exposed on old-shop: potential jackpot.
- DMARC at p=none: spoofed phishing possible (module 6).
- 12 HIBP leaks: password spraying likely.
This file is your mission map. Every following module will build on it.
6. The mistakes that ruin an OSINT phase
- Searching for everything, organizing nothing. Without the sheet, your two days of collection turn into a folder of unreadable screenshots.
- Confusing passive and active. You think you are quiet, the target sees everything in its logs.
- Limiting yourself to the main domain. The real flaw is almost always on
admin-old.client.com, not onwww.client.com. - Forgetting LinkedIn. The
personnes.csvfile will feed the phishing of module 6. Without it, phishing is a gamble. - Getting lost on Twitter/Reddit. Lots of noise for little signal. Spend 30 minutes there, no more.
7. What to remember
- Passive = third parties, active = target. A red line never to blur.
- Six families of sources: DNS, WHOIS, Certificate Transparency, search engines, specialized services, archives.
- Many OSINT tools are in fact active — check before you launch.
- The week 3 deliverable is a target sheet, not a pile of screenshots.
- OSINT is the best return on investment in the whole pentest.
Next lesson: we take a real target (a public bug bounty, hackerone.com/programs) and run everything above in 90 minutes.