Passive OSINT: Mapping the Target Without Touching It

Objective: Understand how authorized red teamers and defenders build a complete external attack-surface picture of an organization using only public, third-party data sources — generating zero packets to target systems — and how defenders run the same exercise against themselves to shrink that exposure.

1. What “Passive” Actually Means

Passive reconnaissance never interacts with the target’s own infrastructure. Every byte you read comes from a third-party aggregator — a registrar’s WHOIS server, a certificate transparency log, Shodan’s index, a breach database, a search-engine cache. The target’s web servers, DNS resolvers, and firewalls log nothing, because you never send them anything. That property is the entire point: passive OSINT leaves no forensic trail on the defender’s systems.

This contrasts directly with Active Scanning (T1595), where you resolve hostnames against the target’s authoritative nameservers, fingerprint services, or port-scan a CIDR. Active scanning touches the target and is logged. T1595 is explicitly out of scope here — it is the technique that begins the moment passive recon ends.

Authorization first. Run these techniques only against organizations you are contractually authorized to assess, within a signed Rules of Engagement (RoE) and defined scope. Querying public databases is legal in most jurisdictions, but acting on harvested credentials or accessing exposed services is not — that is active intrusion, governed by your authorization.

All techniques below map to MITRE ATT&CK Tactic: Reconnaissance (TA0043).

2. The OSINT Intelligence Cycle

Unstructured “Googling the company” wastes time and produces noise. Disciplined OSINT follows a repeatable cycle driven by intelligence requirements defined before any tool runs.

Below is the full passive source landscape this tutorial works through.

3. Domain & DNS Reconnaissance

Start with the apex domain. WHOIS/RDAP reveals registrar, registration dates, and (where not privacy-protected) ownership contacts. DNS record enumeration against public resolvers — not the target’s nameservers — exposes mail providers, CDN usage, and SPF/DMARC posture.

# Enumerate core DNS records via a public resolver (no packets to the target)
for rr in A MX NS TXT SOA; do
  echo "== $rr =="
  dig +short @1.1.1.1 example.com $rr
done

# MX reveals the mail provider; TXT reveals email-auth posture
dig +short example.com MX          # e.g. *.mail.protection.outlook.com -> M365
host -t TXT _dmarc.example.com      # p=none vs p=reject tells you spoofability

An MX pointing to mail.protection.outlook.com identifies Microsoft 365; an SPF record ending in ~all instead of -all, or a missing DMARC policy, flags mail-spoofing potential. This covers Domain Properties (T1590.001) and DNS (T1590.002).

4. Certificate Transparency & Subdomain Enumeration

Under RFC 6962, every publicly trusted CA logs each certificate it issues to append-only, monitorable CT logs. That means every SSL certificate ever issued for a domain is searchable — including certs for staging, dev, and legacy VPN subdomains defenders forgot existed.

# Pull every CT-logged cert for *.example.com and extract unique hostnames
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u

Aggregators wrap CT and dozens of other passive feeds. Run them in passive mode so they never resolve against the target:

# Passive mode: third-party data sources only, no resolution against the target
amass enum -passive -d example.com -o subs.txt

# Contrast: 'amass enum -active' resolves and brute-forces -> NOT passive, out of scope

Forgotten subdomains like legacy-vpn.example.com or jenkins-dev.example.com are gold: they often run unpatched software outside the patch-management lifecycle. This is Digital Certificates (T1596.003).

5. Internet-Wide Scan Databases: Shodan & Censys

Shodan and Censys continuously crawl the entire IPv4 space and index the banner metadata that devices return on open ports — web servers, routers, databases, ICS/OT, cloud instances. Querying their index is fully passive: they touched the target months ago; you only read the cache.

import shodan

api = shodan.Shodan("YOUR_API_KEY")          # querying Shodan's index, not the target
results = api.search('org:"Example Corp"')

print(f"Total results: {results['total']}")
for host in results["matches"][:25]:          # respect plan rate limits
    ip   = host["ip_str"]
    port = host["port"]
    prod = host.get("product", "")
    print(f"{ip}:{port}\t{prod}")

Pivot with filters: org:, asn:AS64500, port:3389, product:Elasticsearch. Exposed RDP (3389), unauthenticated Elasticsearch (9200), and VPN gateway banners directly enumerate Software (T1592.002), Hardware (T1592.001), and Network Security Appliances (T1590.006). Cross-reference Shodan IPs with your CT-derived subdomains to attach service data to named hosts. This is Scan Databases (T1596.005).

6. Search Engine Dorking (Google Hacking)

Search operators surface content the target inadvertently exposed and the engine indexed. The Google Hacking Database (GHDB) catalogs thousands of proven patterns. Use these manually in a browser — automated scraping violates ToS and risks blocking.

Combining site: with intitle:, inurl:, and filetype: is remarkably effective. Bing serves as a secondary index that sometimes retains content Google dropped. This covers Search Engines (T1593.002) and Search Victim-Owned Websites (T1594).

7. Code Repository Mining

Public repositories leak internal hostnames, tooling, and — too often — live secrets. Search GitHub/GitLab for the org name, email domains, and internal hostnames discovered earlier. For your own repositories, run secret scanners in CI:

# Audit your OWN org's repos for committed secrets (defensive use)
trufflehog github --org=example-corp --only-verified
gitleaks detect --source . --report-format sarif --report-path leaks.sarif

Commit history and job postings reveal the technology stack. This is Code Repositories (T1593.003).

8. Organizational & Personnel Intelligence

LinkedIn is the most complete public database of an organization’s employees — org structure, reporting lines, and the technology stack advertised in job postings. Combine with theHarvester and Hunter.io to derive the email-address convention (first.last@), feeding social-engineering target lists.

Public documents carry metadata that maps directly to usernames and software versions:

import subprocess, json

out = subprocess.run(
    ["exiftool", "-j", "report.pdf"], capture_output=True, text=True
).stdout
meta = json.loads(out)[0]

for f in ("Creator", "Author", "LastModifiedBy", "Producer"):
    if f in meta:
        print(f"{f}: {meta[f]}")   # e.g. Author: jsmith / Producer: Acrobat 15.0

This covers Determine Physical Locations (T1591.001), Identify Roles (T1591.004), Employee Names (T1589.003), and Email Addresses (T1589.002).

9. Breach Data & Credential Exposure

Have I Been Pwned, DeHashed, and credential-log collections reveal when employee credentials have been exposed in third-party breaches — frequently before those credentials are weaponized in credential-stuffing.

import requests

domain  = "example.com"
headers = {"hibp-api-key": "YOUR_API_KEY", "user-agent": "authorized-recon"}
url     = f"https://haveibeenpwned.com/api/v3/breacheddomain/{domain}"

for alias, breaches in requests.get(url, headers=headers).json().items():
    print(alias, "->", ", ".join(breaches))

Report the breach name, date, and exposed data classes (passwords, hashes, MFA seeds). Never reuse harvested credentials outside RoE scope — possession is recon; authentication is intrusion. This is Credentials (T1589.001).

10. BGP, ASN & IP Range Mapping

To bound the network footprint, resolve a known IP to its origin ASN, then enumerate every prefix that ASN announces. This delineates owned IP space, co-location, and cloud presence — without scanning a single host.

# 1. Resolve an IP to its origin ASN (Team Cymru WHOIS)
whois -h whois.cymru.com " -v 203.0.113.10"

# 2. Enumerate prefixes announced by that ASN
whois -h whois.radb.net -- '-i origin AS64500' | grep -E '^route:'

# 3. Or use the BGPView API for prefixes + upstreams
curl -s https://api.bgpview.io/asn/64500/prefixes | jq -r '.data.ipv4_prefixes[].prefix'

This maps Network Trust Dependencies (T1590.003), IP Addresses (T1590.005), and Network Topology (T1590.004).

11. Correlating the Picture: Building a Target Profile

The real power emerges when you correlate intelligence across platforms — joining a CT-derived subdomain to a Shodan banner to an ASN prefix to a breached employee account reveals patterns invisible in any single source. Document findings in a structured, repeatable report.

# OSINT Target Profile — <Engagement ID>
## 1. Scope & Authorization        # RoE ref, authorized domains/ASNs, date window
## 2. Domain & DNS                 # registrar/RDAP, NS, MX, SPF/DKIM/DMARC posture
## 3. Subdomains (CT + passive)    # host | source | state (live / parked / dev)
## 4. Exposed Services (Shodan)    # ip:port | product | version | notes
## 5. Network Footprint            # ASN | prefixes | hosting / cloud providers
## 6. Personnel & Org              # key roles | tech stack | SE surface
## 7. Credential Exposure          # breach | date | data classes | accounts
## 8. Risk Summary & Recommendations

12. Common Attacker Techniques

These feed downstream Initial Access — phishing the personnel map, password-spraying the breach list, or exploiting the exposed service — all of which occur after passive recon and are logged.

13. Defensive Strategies & Detection

Framing: True passive OSINT generates no logs on your systems — the adversary only queries third-party databases. Defense therefore shifts to attack-surface reduction and detecting downstream use of harvested intelligence, not the recon itself.

What Defenders Can Detect (Indirect Signals)

Sigma Sketch — Downstream Credential Use

title: Possible Use of OSINT-Harvested Credentials
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4625   # Failed logon (credential stuffing)
      - 4648   # Explicit credential logon (harvested creds / PtH)
      - 4768   # Kerberos AS-REQ with harvested identity
  timeframe: 10m
  condition: selection | count() by SourceIp > 20
level: high

(Add environment-specific thresholds and allow-lists before deployment.)

Hardening / Attack Surface Reduction

A defender running this exact exercise against their own organization has a structural advantage: OSINT needs no change-approval window because it touches no production systems, so perimeter assessment carries zero operational impact.

14. Tools for OSINT Analysis

15. MITRE ATT&CK Mapping

All techniques fall under Reconnaissance (TA0043). T1595 Active Scanning is out of scope.

Summary

• Passive OSINT maps an organization’s entire external attack surface using only third-party data, generating zero packets — and therefore zero logs — on the target.
• The disciplined intelligence cycle (plan → collect → process → analyze → disseminate → monitor) turns scattered searches into a correlated target profile across DNS, CT logs, scan databases, repos, personnel, and breach data.
• Correlation is the multiplier: joining a forgotten subdomain to a Shodan banner to a breached credential reveals reachable exposure invisible in any single source.
• Because passive recon is undetectable on your systems, defense means attack-surface reduction — CT monitoring, DMARC p=reject, secret scanning, metadata stripping — plus detecting downstream credential use via Windows EventID 4625/4648.
• All techniques map to ATT&CK Reconnaissance (TA0043); the boundary is T1595 Active Scanning, which begins the moment you touch the target directly.

Related Tutorials

• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Position-Independent Code: Writing PIC Shellcode Without Hardcoded Addresses

References

• Reconnaissance, Tactic TA0043 – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information, Technique T1589 – Enterprise | MITRE ATT&CK®
• Search Open Technical Databases, Technique T1596 – Enterprise | MITRE ATT&CK®
• Search Open Websites/Domains: Search Engines, Sub-technique T1593.002 – Enterprise | MITRE ATT&CK®
• Search Open Technical Databases: DNS/Passive DNS, Sub-technique T1596.001 – Enterprise | MITRE ATT&CK®
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment