WHOIS, DNS, subdomain enumeration, and internet-wide scanning.
Behind every website, email server, and online service sits a layer of infrastructure — domains, DNS records, IP addresses, hosting providers — that leaves a much harder-to-fake trail than a social media bio ever will. This chapter is about reading that trail.
WHOIS is a query protocol that returns registration data for a domain: registrar, creation date, expiration date, and — depending on the domain's privacy settings and the registrar's jurisdiction — contact information for whoever registered it. Since GDPR came into force, most WHOIS records for domains tied to EU registrants are heavily redacted by default, showing only the registrar and generic proxy contact details rather than a real name or address. That doesn't make WHOIS useless — the registration date alone is one of the most reliable, hard-to-fake data points in this entire manual.
Registration-date analysis is a recurring pivot throughout this manual: a domain claiming to represent a company with "10+ years in business" but registered eight weeks ago is a direct, almost unfakeable contradiction (see the worked capstone example in Chapter 15, which hinges on exactly this kind of timeline mismatch). Beyond the live record, historical WHOIS lookup services let you see how a domain's registration details have changed over time — useful when a domain has been resold, or when you need to establish who controlled it at a specific point in the past.
To automate WHOIS lookups in Python:
import whois
whois_info = whois.whois('example.com')
print(whois_info["creation_date"])
DNS (Domain Name System) maps human-readable domain names to numerical IP addresses, and carries several other record types worth knowing:
To automate a DNS lookup in Python:
import dns.resolver
result = dns.resolver.resolve('example.com', 'A')
for ipval in result:
print('IP', ipval.to_text())
Organizations routinely spin up subdomains for staging environments, internal tools, and forgotten test deployments — and forget to lock them down as carefully as the main site. Finding them expands your attack surface for investigation considerably. Command-line tools like Subfinder and Sublist3r automate this by combining certificate-transparency logs, search-engine indexing, and DNS brute-forcing:
subfinder -d example.com -o example_subdomains.txt
No single tool finds everything — different tools pull from different data sources and consistently disagree on results, so if your goal is maximum coverage, run at least two or three in parallel rather than trusting one.
An IP address can be traced (roughly) to a hosting provider, a data center, and a country through IP geolocation databases and WHOIS-for-IPs (a separate registry system from domain WHOIS, run by regional bodies like ARIN, RIPE, and APNIC). This tells you who hosts the infrastructure, not necessarily who operates it — a huge share of the internet sits behind shared hosting, CDNs (Cloudflare being the most common), and cloud providers where thousands of unrelated sites share the same IP ranges. Treat an IP-to-location match as contextual support at best, never as a precise physical location for a person, exactly the same caution as the metadata-GPS warning in Chapter 6.
Censys and Shodan are the two major internet-wide scanning search engines — they continuously scan the public internet's IP space and let you search by open port, service banner, SSL certificate, or software version, which makes them the standard tool for finding exposed devices (webcams, industrial control systems, misconfigured databases) tied to a specific organization or IP range. Because these are active scanning services run by a third party rather than by you personally, using them to look up already-scanned results is a passive act from your side — you're querying a database, not scanning the target yourself (see the passive-vs-active distinction in Chapter 1, and the adversarial-mindset framing in Chapter 2).
Every publicly trusted SSL/TLS certificate issued today gets logged in a public, append-only Certificate Transparency (CT) log, by design — a security measure meant to catch fraudulently issued certificates, but a goldmine for investigators. Searching CT logs (via a tool like crt.sh) for a domain reveals every subdomain that's ever had a certificate issued for it, including internal or staging subdomains an organization never intended to publicize, often well before those subdomains show up anywhere else.
Start with WHOIS for the registration date and registrar. Pull DNS records to map mail infrastructure (MX), hosting (A/CNAME), and third-party service relationships (TXT/SPF). Search CT logs and run subdomain enumeration in parallel to build the widest possible map of the domain's footprint. Cross-reference any exposed subdomain or IP against Shodan/Censys for open ports and exposed services. At every step, pivot outward using the methodology from Chapter 3 (dork the domain for indexed files) and Chapter 4 (correlate any exposed contact email against the identity-investigation techniques there).
In exercise 2, a good sign you're reading the SPF record correctly is being able to name at least one specific third-party vendor (an email marketing platform, a help-desk tool) just from the domains listed in include: statements — that's a legitimate, and often underused, way to map an organization's vendor relationships without ever contacting them. In exercise 3, resist the urge to visit any suspicious-looking internal subdomain directly — noting its existence is the useful finding; actively probing it crosses from passive into active reconnaissance (Chapter 1) and needs its own authorization and threat model (Chapter 14).