Topic 25

Reconnaissance and OSINT

Recon

Before touching a target, an attacker learns everything reachable without touching it — employees, technologies, subdomains, leaked credentials, exposed services — because the more they know, the cheaper every later step. This is reconnaissance, and much of it is open-source intelligence gathered from public sources that no defender's IDS will ever see.

Understanding recon shows a defender how much they are giving away and how to shrink it. The highest-value defensive exercise in this whole topic is to run the same reconnaissance against Meridian that the intruder would — and fix what it finds before they use it.

Passive vs Active Recon

Passive recon touches nothing you own: public records, search engines, Certificate Transparency logs, breach dumps. It is invisible, so a defender cannot catch it — they can only reduce what is exposed. Active recon (scanning, the next topic) sends packets and can be detected. Attackers exhaust the passive path first precisely because it is silent, which is why a defender who only watches for scans misses the entire first phase of the campaign.

Mapping the Organization

Employees and roles come from LinkedIn, the email format from any single leaked address, technologies from job postings and HTTP headers. This is how a phishing campaign (Chapter 9) gets its targets and its pretext: the intruder learns who works at Meridian, what tools they use, and who to impersonate, all from public sources, before sending a single email.

Infrastructure Discovery

Subdomain enumeration, Certificate Transparency logs, DNS records, and cloud-asset discovery reveal the real attack surface — often including forgotten staging and admin hosts nobody remembers exposing. Certificate Transparency is the sharp one: every TLS certificate Meridian has ever issued is in a public log, so a certificate for staging-admin.meridian.example advertises that host to the world.

Recon Meridian the way the intruder would — passive, run against your own domain

# every certificate ever issued for the domain, from public CT logs
curl -s 'https://crt.sh/?q=%25.meridian.example&output=json' | jq -r '.[].name_value' | sort -u

# harvest subdomains, emails, and hosts from public sources
theHarvester -d meridian.example -b all

# scan your own repos for committed secrets before an attacker does
gitleaks detect --source ./meridian-app

These commands surface what an attacker sees for free: the forgotten subdomain in the CT log, the employee emails and technologies from public sources, and the API key a developer once committed. Run against your own organization, they are a defensive audit; the intruder runs the identical steps against you, so the only question is whether you find the exposure first.

Leaked Secrets and Breach Data

Credential dumps, public code repositories with committed keys, and exposed cloud buckets hand attackers footholds for free — no exploit required. A defender should be searching these continuously for their own exposure: monitoring breach-dump sites for company domains, scanning public repos for leaked secrets, and forcing resets on any credential that appears. Recon, done against yourself, is a control.

Passive vs Active Reconnaissance

Passive — uses third-party and public sources (CT logs, search, breach data), sends nothing to the target, and is undetectable; defenders cannot catch it, only reduce what is exposed.

Active — probes the target directly (scanning), and is detectable in logs, so it is where network detection starts. Attackers prefer passive first precisely because it is silent.

Common Mistakes

Assuming attackers start by scanning, when most start with silent OSINT — so a defender who only watches for scans misses the whole first phase.
Leaking infrastructure through Certificate Transparency, DNS, and forgotten staging hosts without realizing every issued certificate is publicly logged.
Committing secrets to public repos or leaving cloud buckets public, handing out free footholds recon will find.
Never running OSINT against yourself, so the organization has no idea what an attacker already knows.
Treating public employee and technology information as harmless, when it is exactly the fuel for targeted phishing.

Best Practices

Continuously run OSINT against your own organization — subdomains, CT logs, breach data, public repos — and remediate what you find.
Minimize public footprint: retire forgotten hosts, scrub secrets from repos, and lock down cloud-asset visibility.
Monitor breach-dump and paste sites for your domains and credentials, and force resets on exposed accounts.
Treat public employee and technology info as phishing fuel and factor it into awareness training (Chapter 9).
Review Certificate Transparency logs for hosts you did not intend to expose.

Comparable toolsOSINT theHarvester · Shodan/Censys · amass/subfinderExposure crt.sh (CT logs) · HaveIBeenPwnedSelf-audit gitleaks / truffleHog on your own repos

Knowledge Check

Why can't a defender detect an attacker's passive reconnaissance?

It uses public sources and never touches the target
It is always encrypted end to end
Defenders are legally barred from monitoring it
Firewalls silently drop reconnaissance packets

Why is Certificate Transparency a reconnaissance gift to attackers?

Issued certificates are publicly logged, exposing subdomains
It publishes the private keys of every logged certificate publicly
It lists the passwords used on each subdomain
It disables TLS on any logged host

What is the best defensive use of reconnaissance techniques?

Running them against your own org to fix exposure first
Running them against competitors to compare exposure
Blocking all Certificate Transparency logging for your domains
Waiting until an incident to see what was exposed

You got correct