Updated May 2026, by the Ransomnews Research Team.
An organisation’s external attack surface is the set of internet-reachable assets that an attacker can probe before gaining any foothold. In 2026 it’s larger than most security teams realise: forgotten subdomains from old marketing campaigns, legacy SSL VPNs nobody decommissioned, S3 buckets indexed by mistake, an exposed dev environment surfaced by a recent CVE-driven mass scan. Mapping that surface is also the first 30 minutes of work for any competent attacker.
This tutorial walks through the four-tool stack we use at Ransomnews to produce a defensive attack-surface map for any organisation, working only from public data. Treat it as offensive-style reconnaissance you run on yourself, on a schedule, before someone runs it on you for less friendly reasons.
Scope and authorisation
This is passive and lightly-active reconnaissance against your own assets, or assets you have written authorisation to test. None of the tools below require breaching any system, but several of them touch the target with traffic. Get authorisation in writing before you point them at someone else’s environment. UK CMA, US CFAA, and EU equivalents treat unauthorised scanning as a real risk; the line between “passive lookup” and “active scan” matters legally and you should know which side of it each tool sits on.
Step 1, Build the seed list
Start with what you know is yours. Apex domains, AS numbers, IP ranges declared in WHOIS or RIR records, GitHub organisations, public company registrations. The seed list grows through three pivots:
- Certificate transparency logs, every TLS certificate issued for any of your subdomains is publicly logged. crt.sh and Google’s CT report let you query by domain and surface every subdomain that ever had a certificate. This is the single highest-yield pivot, most organisations have hundreds of subdomains they’ve forgotten about.
- Reverse-DNS / passive DNS, services like SecurityTrails, RiskIQ, Validin, and Whoxy maintain historical DNS data. A passive-DNS query for your apex domain returns subdomains, related IPs, and historical resolutions that live DNS no longer shows.
- Open-source pivots, GitHub user/org search, Docker Hub, npm publisher pages, archive.org Wayback Machine. Engineers leak subdomains in commit messages and config files.
Capture results in a spreadsheet with columns: asset, type (domain / IP / cert / repo), source, first_seen, confidence. Keep the source attribution, when something looks suspicious during enrichment you’ll want to retrace where it came from.
Step 2, Enrich with internet-scan engines
Three commercial scan engines cover most of the internet daily. Each has a free tier sufficient for defensive scoping; full coverage requires paid plans. Use at least two, they catch different things.
- Shodan, the original. Best for quickly identifying services running on your IPs (port, banner, version) and for pivoting from a banner string (“show me every host running this same Confluence build”) into the wider exposure of an unpatched component.
- Censys, strongest TLS certificate index. Useful for finding all hosts presenting a certificate that contains your organisation’s name in the Subject or SAN, which often surfaces shadow-IT assets running on third-party hosting.
- FOFA, Chinese-built, broader coverage of Asian IP space than Shodan or Censys, and very strong at fingerprinting login pages and admin panels by HTML body hash. Useful as a third opinion.
Sample queries to run for each known IP range / ASN:
# Shodan, every host in your ASN with port 443 open
shodan search "asn:AS12345 port:443"
# Shodan, hosts presenting a cert with your org name
shodan search "ssl.cert.subject.cn:*.acme-corp.com"
# Censys, same idea via TLS
services.tls.certificates.leaf_data.subject.common_name:"acme-corp.com"
# FOFA, title fingerprinting for management UIs
title="Citrix Gateway" && org="acme-corp"Cross-reference results against your inventory. The two failure modes you’re looking for are known-unowned (something the scan engines say is yours but isn’t on your inventory, investigate) and owned-unscanned (something on your inventory but absent from scan results, possibly behind a firewall, possibly a stale record).
Step 3, Subdomain enumeration
For each apex domain you control, run the standard enumeration trio:
# Subfinder, passive aggregation across 30+ sources
subfinder -d acme-corp.com -all -silent | tee subdomains.txt
# Amass, active brute-forcing + passive sources
amass enum -d acme-corp.com -active -brute -o amass.txt
# CT logs direct
curl -s "https://crt.sh/?q=%25.acme-corp.com&output=json" \
| jq -r '.[].name_value' | sort -uDe-duplicate and resolve all results to live IPs:
# dnsx resolves and filters down to live hosts
sort -u subdomains.txt amass.txt | dnsx -silent -a -resp \
| tee live-hosts.txt
# httpx tags which are actually serving HTTP/S
httpx -l live-hosts.txt -title -tech-detect -status-code \
| tee web-surface.txtThe output of httpx is your web-facing surface. Read it line by line. Look for: legacy admin panels (/admin, /manager, /console), forgotten dev/staging environments (dev., staging., test., uat.), default vendor pages (Apache “It works!”, Tomcat manager, Confluence /login, Jenkins /jenkins), and anything reporting an old version banner.
Step 4, Templated vulnerability scanning with Nuclei
Nuclei is the differentiator at this stage. It runs lightweight templated checks, most are zero-click probes, no exploitation, against a target list and reports detections by CVE. The nuclei-templates repository is community-maintained and updated within hours of each new public CVE.
# Update templates and run a baseline scan
nuclei -ut
nuclei -l web-surface.txt \
-severity high,critical \
-exclude-tags intrusive \
-o findings.txt
# Run only the templates added in the last 14 days
nuclei -l web-surface.txt -nw 14d -o new-findings.txtThe -exclude-tags intrusive flag keeps you on the right side of “passive enough not to exploit.” For an internal exercise on your own assets, you can drop that flag, but for any external-targeting work, even your own organisation if you’re a contractor, keep it on without explicit written authorisation.
Each finding includes the matched template name, severity, and a description. Enrich with a CVSS lookup and assign owners.
Step 5, Continuous monitoring
One scan is a baseline. The value comes from running it weekly or daily and comparing diffs. Two specific monitoring streams pay outsize dividends:
- Certificate-transparency monitoring, subscribe via CertSpotter, crt.sh RSS, or your own CT log poller. Any new certificate issued for your domain is something you should be expecting; if you’re not, it’s a phishing-domain candidate or a shadow-IT asset.
- Nuclei diff over time, run nuclei daily, diff
findings.txtday-to-day. New findings are the signal; persistent findings need owners.
A 2026 attack-surface checklist
- All apex domains and their CT-log subdomains catalogued.
- All ASNs and IP ranges enumerated, cross-referenced to inventory.
- Cloud accounts inventoried for public S3 / R2 / GCS buckets, public-IP load balancers, and exposed managed databases.
- SaaS tenant subdomains catalogued (yourcompany.atlassian.net, .okta.com, .auth0.com, .salesforce.com).
- Public GitHub / GitLab repositories scanned for credentials with TruffleHog and Gitleaks.
- Acquisition / divestiture inventory current, newly-acquired subsidiaries are a recurring blind spot.
- Continuous CT log monitoring active, with alerts.
- Nuclei scans running weekly; new findings triaged within 48 hours.
A note on third-party services
Commercial attack-surface management (ASM) products, Microsoft Defender EASM, Palo Alto Cortex Xpanse, Bishop Fox CAST, IONIX, runZero, automate everything above with prettier UIs and continuous coverage. Worth the spend for organisations larger than ~500 employees. For everyone smaller, the open-source stack above plus a $20/month Shodan plan covers ~80% of the same ground at a fraction of the cost.
Further reading
- MITRE ATT&CK, Reconnaissance tactic for the full attacker playbook your scan should be defending against.
- CISA KEV catalog, prioritise nuclei findings against this list first.
- OWASP Attack Surface Detector, methodology framework.
- Our own multi-tool OSINT tutorial for the human-target equivalent of this asset-target workflow.
The principle to take away: an attacker doesn’t know what you own; they know what they can see from the internet. Run the same scan on yourself, on a schedule, and act on the diff. Most breaches in 2026 started with an asset the victim’s security team didn’t know existed.