Passive Reconnaissance: Building the Target Surface Without Touching It

Prerequisites

• PEN-K001: Methodology, Authorisation & Rules of Engagement

Why This Lesson Matters

The best recon leaves no footprint. Before sending a single packet to the target, a professional tester builds a comprehensive map of the attack surface using only publicly available information. Real attackers spend weeks here. Testers who skip recon miss the low-hanging fruit that a motivated adversary would find in hours.

1. What Passive Recon Gives You

Goal: build the fullest possible picture of the target
      without alerting them, triggering IDS, or touching their systems.

Output:
  - IP ranges and hosting infrastructure
  - Employee names, roles, email patterns
  - Technology stack (web server, CMS, frameworks)
  - Subdomains and forgotten assets
  - Leaked credentials and sensitive documents
  - Third-party relationships (vendors, cloud providers)

Analogy: Before a locksmith tests a door, they study the building plans, note the lock brand, and check if any keys have been copied at the hardware store nearby — all without touching the door.

2. DNS & Infrastructure Intelligence

2.1 WHOIS & Domain Registration

# Domain registration and registrant info
whois corp.local
whois 185.220.101.5   # reverse WHOIS on an IP

# Key fields: Registrar, creation date, nameservers, registrant contact
# A domain created last week is suspicious as a supplier; note for report

2.2 DNS Enumeration

# Basic records
dig A corp.local
dig MX corp.local        # mail servers
dig TXT corp.local       # SPF, DKIM, DMARC, verification tokens
dig NS corp.local        # nameservers

# Zone transfer attempt (often fails; noteworthy if it succeeds)
dig AXFR corp.local @ns1.corp.local

# Subdomain enumeration with wordlist
dnsx -d corp.local -w /wordlists/subdomains-top1m.txt -o subdomains.txt
subfinder -d corp.local -o subfinder_results.txt
amass enum -d corp.local -o amass_results.txt

2.3 Certificate Transparency Logs

Every TLS certificate issued is logged publicly. This reveals subdomains the target never intended to be public.

# Query Certificate Transparency logs
curl "https://crt.sh/?q=%.corp.local&output=json" | 
  jq '.[].name_value' | sort -u

# Common discoveries:
# dev.corp.local, staging.corp.local, vpn.corp.local
# internal-api.corp.local  ← should not be internet-facing

3. Technology Fingerprinting

Knowing what stack the target runs tells you which vulnerabilities to look for.

# HTTP headers (reveal server software, frameworks)
curl -sI https://app.corp.local | grep -iE "Server:|X-Powered-By:|X-AspNet-Version:|Via:"

# Wappalyzer (browser extension or CLI)
wappalyzer https://app.corp.local

# Shodan (what does the internet know about this IP?)
shodan host 185.220.101.5
# Shows: open ports, banners, running services, historical data, CVEs

Shodan one-liner for ASN enumeration:

shodan search "org:"Corp Ltd"" --fields ip_str,port,hostnames | head -50

4. Google Dorking

Google's search operators expose sensitive content inadvertently indexed.

Always test dorks in a browser, not automated tools — Google rate-limits and CAPTCHAs automated queries.

5. OSINT for People & Credentials

5.1 Employee Intelligence

# LinkedIn search (manual — no API needed)
# Search: company:"Corp Ltd" → build org chart, find IT/security staff names

# Email pattern inference
# Alice Martin at corp.local → try: alice.martin@, amartin@, alice@, a.martin@
# Verify with mail server response to VRFY or password reset response

5.2 Leaked Credentials

# HaveIBeenPwned API — check email addresses
curl "https://haveibeenpwned.com/api/v3/breachedaccount/[email protected]" 
  -H "hibp-api-key: YOUR_KEY"

# GitHub — search for accidentally committed secrets
# Search: "corp.local" org:corp-org
# Search: filename:.env "corp.local"
# Tools: TruffleHog, Gitleaks
trufflehog github --org=corp-org --only-verified

5.3 The Email Pattern Test

# Enumerate email format by testing password reset page
# Send reset for: [email protected] → "Email sent" = valid
#                 [email protected]       → "Email not found" = invalid
# (Only with explicit scope authorisation — this touches the target)

6. Passive Recon Output: The Target Summary

After passive recon, document your findings before moving to active recon:

TARGET SURFACE SUMMARY — corp.local

IP ranges:    185.220.101.0/24 (primary), 10.0.0.0/24 (VPN range, inferred)
Nameservers:  ns1.corp.local (185.220.101.5), ns2.corp.local (185.220.101.6)
Mail servers: mail.corp.local (MX 10), backup-mail.corp.local (MX 20)

Subdomains discovered:
  app.corp.local        → 185.220.101.10 (main web app)
  api.corp.local        → 185.220.101.11 (REST API)
  staging.corp.local    → 185.220.101.20 (non-prod — confirm scope)
  dev.corp.local        → 185.220.101.21 (dev environment — out of scope)
  vpn.corp.local        → 185.220.101.30 (Cisco ASA, version 9.8.2)

Technology:
  app.corp.local: Nginx 1.18, PHP 8.1, Laravel (X-Powered-By header)
  api.corp.local: Node.js, Express (Server header)

Notable findings:
  - TLS cert for *.corp.local reveals internal.corp.local
  - GitHub repo "corp-scripts" contains .env.example with DB_HOST=postgres.corp.local
  - 3 employee emails found in HaveIBeenPwned (2016 LinkedIn breach)
  - SPF: ~all (softfail) — phishing possible with low delivery risk

7. Common Mistakes

Mistake 1: Skipping passive recon to "save time." Passive recon reveals assets the client forgot to tell you about. A subdomain discovered via certificate transparency often leads to the most impactful finding.

Mistake 2: Testing subdomains before confirming they are in scope. staging.corp.local discovered via recon is not automatically in scope. Confirm with the client before testing.

Mistake 3: Not documenting the recon phase. Everything you found passively is evidence that the same information is available to a real attacker. Document it — it belongs in the report.

8. Practice Exercises

1. Using only passive techniques (no tools that touch the target), list five information sources you would check for target.com and what you expect to find from each.

2. Certificate transparency logs for corp.local reveal internal-payroll.corp.local. The original scope says "all subdomains of corp.local." Is this in scope? What do you do?

3. A GitHub search finds a file containing DB_PASSWORD=Sup3rS3cret for the target. This is passive recon. What three actions do you take before writing it up as a finding?

9. Lab

Assessment mode: quiz

6 questions: identify the correct passive recon technique for described intelligence goals, classify findings as in-scope / needs confirmation / out-of-scope, and complete a target surface summary from provided data.

10. Framework Alignment

11. Further Reading

• OSINT Framework — https://osintframework.com — Visual map of OSINT sources by category
• Subfinder — https://github.com/projectdiscovery/subfinder — Fast passive subdomain enumeration
• TruffleHog — https://github.com/trufflesecurity/trufflehog — Scans git history for secrets

["Build a target surface summary from passive recon using WHOIS, DNS enumeration, certificate transparency, and Google dorking", "Use subfinder and amass to enumerate subdomains passively and identify at least one non-obvious asset not listed in the scope document", "Explain why a subdomain discovered via certificate transparency is not automatically in scope, and describe the confirmation process before testing it"]

Prerequisites → Why this matters (locksmith analogy) → What passive recon gives you → DNS and infrastructure intelligence (WHOIS, dig, zone transfer, CT logs) → Technology fingerprinting (headers, Wappalyzer, Shodan) → Google dorking (table of dorks) → OSINT for people and credentials (LinkedIn, HIBP, GitHub) → Target surface summary template → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading