Mapping Infrastructure and Domains
Every company leaks its own attack surface through DNS and certs. Go read it.
What you will learn
- -Pull registration and DNS records for a target domain
- -Enumerate subdomains from certificate transparency logs
- -Use Shodan to see exposed hosts without touching them
The interesting stuff is almost never on www.company.com. It's on vpn.company.com, jira-dev.company.com, legacy-mail.company.com, the nobody remembered to lock down. Mapping infrastructure is the hunt for that forgotten attack surface, and most of it is sitting in public records the company published without thinking twice.
Start with WHOIS and DNS
WHOIS tells you who registered a , when, and through which registrar. Registration dates and shared registrant emails are how you tie a portfolio of domains back to one organization.
$whois company.com$dig company.com ANY +noall +answer$dig company.com TXT +shortRead the TXT records closely. An SPF record listing include:_spf.google.com and include:mailgun.org tells you they run Google Workspace for mail and Mailgun for transactional sending. That's two vendors and a phishing angle before you've scanned a single .
Certificate transparency is the subdomain gold mine
Every a public CA issues gets logged to certificate transparency, and those are searchable. When a company gets a cert for internal-portal.company.com, they announce that hostname's existence to the world whether they meant to or not.
$curl -s "https://crt.sh/?q=%25.company.com&output=json" | jq -r '.[].name_value' | sort -ucrt.sh often surfaces dev, staging, and admin subdomains that never appear in brute-forcing because they're internal-facing but still got a public cert. That's the whole reason it beats a wordlist for a first pass.
For the DNS-brute side, amass ties both approaches together.
$amass enum -passive -d company.comOnce you have candidate hostnames, resolve them to see which are live. A name in a cert log might point at a host that's been decommissioned.
$dnsx -l subdomains.txt -a -respShodan shows you the exposed hosts
Shodan scans the whole internet continuously and lets you query the results. You banners, open ports, and service versions for a host without ever connecting to it yourself, because Shodan already did the connecting.
$shodan search "org:\"Company Inc\" port:3389"Search by IP range, org name, or hostname. A single query like ssl:"company.com" http.title:"Login" can hand you every exposed login portal on their perimeter. Because Shodan is the one that scanned, your reconnaissance stays passive from the target's point of view.
Reading crt.sh, WHOIS, and Shodan never touches the target. The moment you resolve those subdomains, port-scan them, or hit a login page, you are active and in for their logs. Only do that against systems your engagement authorizes, and confirm every IP you scan actually belongs to the target before you send a .
Watch for the scoping trap
Shodan and cert logs will happily hand you hosts that a name but belong to a different company, or cloud that rotate to another tenant tomorrow. Before anything active, confirm ownership: does the IP fall in the ranges your rules of engagement list, does WHOIS on the netblock name your . Scanning the wrong host because a cert mentioned your target's brand is how people end up explaining themselves to someone's legal team.
You need every subdomain of target.com, including internal-facing dev and admin hosts. Why would certificate transparency (crt.sh) surface hosts that a DNS wordlist brute-force misses, and why might it also list hosts you cannot reach?
A target's SPF TXT record contains include:_spf.google.com and include:sendgrid.net. What does that tell you?