This guide shows you how to systematically map every asset exposed to the internet and then rank those assets by risk so you can focus your security efforts where they matter most. You’ll end up with a clear, prioritized list of what to patch, harden, or retire first.
What You’ll Need
- Access to your organization’s DNS provider or a DNS zone file export
- Network scanning tools (e.g., Nmap, Shodan, Censys)
- An asset inventory or CMDB (even a spreadsheet works)
- Credentials or access to your cloud provider console (AWS, Azure, GCP)
- Knowledge of your organization’s IP ranges (from your ISP or cloud provider)
- Approval from your security or IT leadership to run scans (important for legal and policy reasons)
Step-by-Step
- Start with your DNS records. Export all DNS records (A, AAAA, CNAME, MX, NS, TXT) from your public DNS zones. These are the easiest way to find subdomains and mail servers. Use a tool like
dnsreconor simply pull from your DNS provider’s API. - Enumerate subdomains. Use a subdomain discovery tool (e.g.,
subfinder,amass) to find subdomains that may not be in your DNS export. This catches shadow IT and forgotten test environments. - Identify your public IP ranges. Get the list of IP ranges you own from your ISP or cloud provider. Also check your ASN (Autonomous System Number) using a service like BGPView to see all ranges associated with your organization.
- Scan all IPs and hostnames. Run a port scan (e.g., Nmap with
-sVfor service version detection) on every IP and hostname you’ve discovered. Focus on common ports (80, 443, 22, 3389, 8080, 8443, etc.) but also scan the full range to find unexpected services. - Use external reconnaissance services. Query Shodan or Censys for your IP ranges and domains. These services have already scanned the internet and can reveal services you might have missed, like a database accidentally exposed on port 3306.
- Check cloud assets. If you use AWS, Azure, or GCP, list all public-facing resources: EC2 instances, S3 buckets, Azure Blob Storage, load balancers, and managed databases. Use the cloud provider’s console or CLI to get a complete list.
- Consolidate into a single inventory. Build a spreadsheet or use a CMDB. For each asset, record: hostname/IP, port, service, version, owner (if known), and whether it’s critical to business operations.
- Assess exposure and risk. For each asset, determine how sensitive the data is and how easy it is to exploit. A web application with customer data is higher risk than a public marketing page. Use a simple scoring system: 1-5 for data sensitivity, 1-5 for exploitability, and multiply them for a risk score.
- Prioritize by risk score. Sort your list by risk score, highest first. The top 10% are your immediate priorities. These are assets that are both critical and vulnerable.
- Create a remediation plan. For each high-risk asset, decide: patch it, isolate it, add a WAF (web application firewall), or decommission it if it’s no longer needed. Assign an owner and a deadline.
- Review and repeat. Attack surface mapping is not a one-time task. Re-run this process at least quarterly, or after any major infrastructure change.
Common Mistakes
- Only scanning your own IPs. This misses assets hosted on third-party infrastructure (e.g., a marketing site on a vendor’s CDN).
- Forgetting about IPv6. Many organizations have IPv6 enabled but don’t monitor it. Scan both IPv4 and IPv6.
- Ignoring cloud “shadow IT”. Developers may spin up a test server on a personal AWS account. Subdomain enumeration helps catch this.
- Not checking for dangling DNS records. A subdomain pointing to a decommissioned IP can be hijacked. Check for CNAMEs that point to domains you no longer own.
- Prioritizing only by port count. A single exposed database is more dangerous than ten web servers on port 443. Focus on data sensitivity, not just the number of open ports.
Tips
- Automate the discovery. Use a script to run subdomain enumeration and port scans on a schedule, and diff the results to spot new assets quickly.
- Tag assets by owner. If you don’t know who owns an asset, you can’t get it fixed. Use a naming convention that includes the team name (e.g.,
marketing-web-01). - Use a vulnerability scanner. Tools like Nessus or OpenVAS can automatically detect known CVEs on your discovered services, saving you time.
- Integrate with your ticketing system. When a new high-risk asset is found, automatically create a ticket for the owner.
- Start small. If you have thousands of assets, don’t try to scan everything at once. Start with your top 100 most critical domains and IPs.
Troubleshooting
- You find an asset you don’t recognize. Don’t panic. First, check if it’s a known third-party service (e.g., a payment gateway). If not, trace it back to a cloud account or developer. If you can’t identify it within 24 hours, take it offline or block it at the firewall.
- Your scan is blocked by a firewall. Some firewalls block ICMP (ping). Use TCP connect scans (
nmap -sT) instead of ping sweeps. Also, ensure you’re scanning from an allowed IP range. - Your DNS export is incomplete. Use a tool like
dnsreconto brute-force common subdomains (e.g.,test,dev,staging). Also check certificate transparency logs (crt.sh) for subdomains that appear in SSL certificates. - You find a service that’s not responding to scans. It might be behind a load balancer or CDN. Check the actual origin IP by looking at DNS history or using a tool like
fierce. - Your risk scores are all the same. You need more granularity. Add a third factor: whether the asset is internet-facing (vs. internal) and whether it has known vulnerabilities. Use a weighted formula.
Frequently Asked Questions
How often should I map my attack surface?
At least quarterly, but ideally monthly if you have a dynamic cloud environment. Continuous monitoring is best, but even a monthly manual scan is better than nothing.
What’s the difference between an attack surface and a vulnerability?
Your attack surface is the total set of all internet-exposed assets (hosts, ports, services). A vulnerability is a weakness in one of those assets that could be exploited. You must map the surface first, then find the vulnerabilities on it.
Do I need to scan every port?
Yes, at least once. Many attacks use non-standard ports (e.g., 8080, 8443, 3389). After the initial full scan, you can focus on common ports for daily monitoring.
Can I use free tools only?
Yes. Nmap, subfinder, and crt.sh are all free. Shodan has a free tier with limited results. You can build a solid process with free tools.
What should I do with the results?
Use them to drive your patching and hardening priorities. Share the top 10 risks with your security team and management. The list also helps you justify budget for security tools or additional staff.
How do I handle assets I can’t identify?
First, try to find the owner by asking your team or checking cloud provider logs. If you truly can’t identify it, treat it as a potential risk and restrict access to it until you can determine its purpose.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.
More cards in this drawer
- Server Repair Fails: Fix Restart Loops
- Plane Crazy Summer Event Schedule & Dates3 tier
- How to Choose a Secure IMAP Email Client
- Tower Defense RNG Codes: Active List & How to Redeem
- RCS Chats On or Off in Google Messages
- How to Choose a Phone That Supports VoLTE on Your Carrier