Workshop › Cybercom Ch.1

Passive Reconnaissance

Beginner  ·  Objective: Build a complete passive profile of a domain using only public sources and OSINT tools.  ·  Tools: whois, nslookup, theHarvester, Shodan, Google Dorks

Objective

Build a complete passive profile of a domain using only public sources and OSINT tools.

Passive Reconnaissance

In Cybercom Chapter 1, we saw that ARPANET was designed with openness as a feature. That openness means information leaks — constantly, in every direction.

Passive reconnaissance is the art of collecting that leaked information without ever touching the target directly.

No packets sent. No logs created. No alerts triggered.


Before You Begin

Important: Only perform reconnaissance on systems you own or have explicit written permission to test. This workshop uses example domains for illustration only.

You will need: - A terminal (Linux or macOS, or WSL on Windows) - An internet connection - A free Shodan account (shodan.io)


Step 1 — WHOIS: Who Registered This Domain?

Every domain registration is public record. WHOIS databases store the registrant's name, organisation, registrar, and registration dates.

whois example.com

What to look for: - Registrant organisation and contact email - Registration date (how old is this domain?) - Name servers (which DNS provider do they use?) - Registrar (can reveal patterns if they own multiple domains)

Some organisations use WHOIS privacy protection — but even then, the registrar, nameservers, and dates are visible.


Step 2 — DNS Enumeration

DNS records are a goldmap of infrastructure.

# Basic lookup
nslookup example.com

# Mail servers
nslookup -type=MX example.com

# All records
nslookup -type=ANY example.com

# Or using dig (more detailed)
dig example.com ANY
dig example.com MX
dig example.com TXT

What each record tells you:

Record Tells you
A IPv4 address of the server
MX Which mail server handles email (often reveals providers)
TXT SPF/DKIM policies, sometimes domain verification tokens
CNAME Aliases — reveals CDN providers, SaaS services
NS Name servers — who manages their DNS

TXT records are often goldmines. SPF records list every service authorised to send email on behalf of the domain — each one is a third-party vendor the target uses.


Step 3 — Email Harvesting with theHarvester

theHarvester aggregates public sources to find email addresses and subdomains associated with a domain.

# Install (Kali has it pre-installed)
pip install theHarvester

# Run against a domain
theHarvester -d example.com -b google,bing,linkedin -l 200

What it finds: - Employee email addresses (format tells you the naming convention) - Subdomains (each one is potentially another attack surface) - Associated IPs


Step 4 — Google Dorks

Google indexes things organisations didn't intend to be public. Search operators let you query that index precisely.

site:example.com filetype:pdf
site:example.com inurl:admin
site:example.com "internal use only"
"@example.com" filetype:xls

Interpret your findings: - PDF files may contain author metadata, internal system names, or employee names - inurl:admin finds admin panels that were indexed - Spreadsheets with email addresses are common credential enumeration targets


Step 5 — Shodan: The Search Engine for Internet-Connected Devices

Shodan continuously scans the internet and indexes what it finds — open ports, banners, service versions, certificates.

Search for a domain or IP at shodan.io:

hostname:example.com
org:"Example Corp"

What to look for: - Open ports and what services are running - Software versions (are they patched?) - SSL certificate details (may reveal additional hostnames) - Geographic distribution of servers


Review: What You Now Know

After these five steps, without sending a single packet to the target, you have:

  1. Who registered the domain and when
  2. Where their infrastructure lives (IPs, hosting providers)
  3. What services they use (mail providers, CDN, SaaS tools)
  4. Who works there (email addresses, naming convention)
  5. What is publicly indexed that shouldn't be

This is the foundation of every penetration test. The more you know before you touch anything, the more targeted — and less detectable — your subsequent steps will be.


Going Further

Read the Cybercom chapter on The Morris Worm to see how the trust relationships baked into ARPANET (the same ones passive recon exploits today) made the first major internet attack possible.

The infrastructure you just mapped is a direct descendant of the design choices made in 1971.

← All Workshops