Map Your External Attack Surface: A Recon Playbook You Can Run Today

You cannot defend what you cannot see. Most organizations are exposing more to the internet than they think, a forgotten staging server, an expired-but-live subdomain, an S3 bucket someone made public two years ago. Attackers map this surface continuously; defenders usually do it once a year, if at all. This is a practical recon playbook you can run against your own domains today, with the same tools we use on an engagement.
Rules of engagement: only run these commands against assets your organization owns or is explicitly authorized to test. Passive discovery is low-impact; active scanning should be scoped and, in shared or cloud environments, permitted by your provider terms.
Step 1: enumerate your domains and subdomains
Start passively, from public sources, so you find assets you forgot you had. Certificate transparency logs are a goldmine because every TLS certificate you have ever issued is public record.
bash
# Passive subdomain discovery from many sources
subfinder -d example.com -all -silent | tee subs.txt
# Certificate transparency logs often reveal forgotten hosts
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sed 's/^*.//' | sort -u | tee -a subs.txt
sort -u subs.txt -o subs.txt
wc -l subs.txt
Step 2: find what is actually live
A list of names is not a list of exposure. Resolve them and probe for live web services to see what is really reachable, and grab titles and technologies while you are at it.
bash
# Resolve names to live hosts
dnsx -l subs.txt -silent -a -resp | tee resolved.txt
# Probe for live HTTP(S) services with metadata
cat subs.txt | httpx -silent -status-code -title -tech-detect -web-server | tee live.txt
Read live.txt critically. Anything with dev, test, staging, uat, old, or admin in the name deserves a hard look, those are the assets most likely to be under-maintained and over-exposed.
Step 3: map ports and services
Now look beyond the web. On the IP ranges you own, discover open ports and identify the services behind them. A fast port sweep followed by targeted version detection keeps it efficient.
bash
# Fast port discovery across your owned range
naabu -host resolved.txt -top-ports 1000 -silent | tee ports.txt
# Service/version detection on the open ports found
nmap -sV -Pn -iL resolved.txt -oA surface-scan
You are hunting for things that should not face the internet: database ports, RDP, SMB, exposed management interfaces, and old services with known vulnerabilities.
Step 4: check TLS and security headers
Misconfigured TLS and missing headers are easy wins for an attacker and easy fixes for you. Check both on your live hosts.
bash
# TLS configuration: protocols, ciphers, expiry, known flaws
testssl.sh --quiet --sneaky https://www.example.com
# Quick security-header look
curl -sI https://www.example.com | grep -Ei 'strict-transport|content-security|x-frame|x-content-type'
Step 5: hunt for forgotten cloud assets
Shadow IT and old cloud resources are where breaches love to start. Look for storage buckets and endpoints tied to your brand that nobody is watching. Check the ownership and access of anything you find, a public bucket with your data in it is a quiet, common, and avoidable breach.
Step 6: turn a scan into a monitored inventory
The real value is not a one-off scan, it is noticing when your surface changes. Save today's baseline, then diff against it on a schedule so a new, unexpected host lights up the moment it appears.
bash
# Snapshot today, then diff on a schedule (cron) to catch new exposure
subfinder -d example.com -silent | httpx -silent | sort -u > surface-$(date +%F).txt
diff surface-last.txt surface-$(date +%F).txt && cp surface-$(date +%F).txt surface-last.txt
# Example: run weekly via cron and email the diff
# 0 7 * * 1 /opt/recon/surface-diff.sh | mail -s 'Attack surface changes' soc@example.com
Blue-team tip: a new host appearing in your diff that no ticket explains is worth a same-day investigation. Most breaches start on an asset the security team did not know existed.
From visibility to assurance
This playbook shows you what you expose; it does not tell you how deep each weakness goes, that is where hands-on testing comes in. Knowing a login panel is live is different from knowing it accepts default credentials or is vulnerable to a chained exploit. Our network and web application penetration testing services take the surface you have mapped and prove exactly how far an attacker could get. Want a professional attack-surface review and a prioritized fix list? Talk to our team.
