External attack surface: how to inventory yours in 30 minutes

Introduction

Ask an IT director how many assets their company exposes on the internet. You will get a number. Run the actual inventory two hours later and you will find more. This happens every time, and it is not a competence problem: it is the normal outcome of ten years of marketing campaigns, migrations, staging environments left online, and contractors who spun up a subdomain "just for a test".

That gap has a name in our field: the external attack surface. And the discipline of keeping it under control has an acronym, EASM (External Attack Surface Management). Before buying a platform that carries the acronym, you can do the exercise by hand. That is what this article is for: a five-pass method you can run on your own domain in about half an hour, with public and free tools.

What the external attack surface actually is

It is everything an attacker can reach from the internet without credentials and without an invitation. In practice: your domain names, your subdomains, your public IP addresses, the services listening on them, your web apps and APIs, your exposed buckets and cloud environments.

It is not your IT estate. It is not your ISO 27001 asset inventory either, which also covers internal assets. We wrote a separate guide on mapping your company's information system, which handles the broader exercise. Here we stay strictly on what is visible from outside, because that is the part an attacker sees before you do.

A working definition, more useful than the academic one: your external attack surface is everything that answers a request coming from the internet and that you cannot switch off without telling someone first.

The six families of assets that are always missing

Across the perimeters we map, the gap between the declared inventory and reality nearly always sits in the same categories. Roughly by frequency:

1. Campaign subdomains. promo-2023.example.com, webinar.example.com, created by marketing with an agency, never decommissioned.
2. Staging and UAT environments. preprod, staging, uat, demo. Often with production data and weaker authentication.
3. Merger and acquisition leftovers. A company acquired in 2021 whose domains still point at infrastructure nobody patches.
4. SaaS tools wired in through a CNAME. The subdomain is yours, the service is somewhere else, and nobody is quite sure who owns patching.
5. APIs and technical endpoints. api, ws, graphql, admin, vpn, rarely in the same inventory as the websites.
6. Dangling DNS records. A CNAME pointing at a bucket or an instance that has since been released. That is the subdomain takeover scenario, and it is trivial to exploit when it shows up.

Four of those six families are not created by the IT department. Which is exactly why the declared inventory never suffices.

The method, in five passes

Take your root domain. We will call it example.com in the commands below. Budget thirty minutes for a small or mid-sized single-brand perimeter, more if you run several brands.

Pass 1: the domains, not just the domain

Start by listing the names you actually own. The registry is your source of truth, and you query it over RDAP, the structured successor to WHOIS:

curl -s https://rdap.org/domain/example.com | jq '{
  registrar: .entities[]?.vcardArray,
  status: .status,
  events: [.events[] | {action: .eventAction, date: .eventDate}]
}'

Three things to look at in the response:

• The creation date. It tells you whether the domain belongs to the company's history or to a forgotten acquisition.
• The registrar. Several registrars for one brand is a symptom of purchases made outside the process.
• The status field. Look for clientTransferProhibited. If it is missing, the transfer lock is not set, and that is a real finding rather than an administrative detail: it is the front door for domain hijacking.

Go through your trademarks, your product names and the extensions you registered defensively. Plenty of companies rediscover at this point a .com bought eight years ago that still redirects somewhere.

Pass 2: subdomains, through certificates

This is the highest-yield pass. Every time someone in your company issued a TLS certificate, the certificate authority published it to the Certificate Transparency logs. Those logs are public and free to query:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | sed 's/^\*\.//' | sort -u > subdomains.txt

You will get a raw list, with duplicates and dead entries. That is expected, and it is already far more complete than your DNS zone, because the certificate was requested by the person building the service, not by the person maintaining the inventory.

Then check which ones still answer:

while read -r h; do
  ip=$(dig +short "$h" A | tail -1)
  [ -n "$ip" ] && echo "$h -> $ip"
done < subdomains.txt

One classic trap here: wildcard DNS. If *.example.com resolves, every test will answer and your list becomes useless. Test a name that cannot possibly exist before drawing any conclusion:

dig +short ff-nx-probe-7f3.example.com A

If that answers, you have a wildcard, and you will need to compare HTTP responses rather than plain DNS resolution.

Pass 3: what sits behind the addresses

Group the IPs you collected and look at who owns them. The real operator is readable from the ASN, and Team Cymru exposes it over DNS, with no key and no quota:

dig +short 1.0.0.127.origin.asn.cymru.com TXT

The format is unusual: you reverse the octets of the address before appending the suffix. So for 127.0.0.1 you query 1.0.0.127.origin.asn.cymru.com.

What you are looking for here is consistency. Three hosting providers for a company that declares one is a lead. An address at a cloud provider on an account nobody claims is a better one.

Pass 4: what is open

For each public address you want to know which ports answer and what versions run on them. You can scan yourself, but on shared hosting IPs that is a bad idea legally as much as technically. There is a passive route: Shodan publishes InternetDB, a keyless API that returns what it has already observed.

curl -s https://internetdb.shodan.io/1.1.1.1 | jq

You get the ports, the identified products with their versions, and the CVEs Shodan has correlated. Read those carefully: the CVEs are inferred from a version banner, not verified. A service can advertise a vulnerable version and have been patched through a distribution backport. Treat the list as a queue of things to investigate, not as a vulnerability report. We go into that difference in our comparison of vulnerability scan types.

Pass 5: the mail layer and the registry layer

This pass takes five minutes and often surfaces the most concrete risk, because a misconfigured domain can be spoofed without anyone touching your infrastructure.

dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com
dig +short MX example.com
dig +short CAA example.com

What to look at:

Run this on every domain from pass 1, not just the main one. Secondary domains, the ones that never send mail, are the ones people forget to protect, and therefore the ones that get spoofed.

What this method will not see

Worth stating plainly, because this is what separates an honest inventory from a false sense of coverage:

• Subdomains with no certificate. A plain HTTP service, or one behind a self-signed certificate, never appears in the CT logs. Finding it takes DNS wordlist enumeration.
• Anything published since your last pass. A point-in-time snapshot goes stale.
• Assets owned by subsidiaries and contractors that carry your brand without carrying your domain.
• Application vulnerabilities. None of this tests an injection, a broken access control or crooked business logic. You have an inventory, not an audit.

And above all: this method gives you a photograph. The surface moves. Between the moment you finish that spreadsheet and the moment your board reads it, someone has probably published a subdomain. We have watched carefully built inventories go stale in three weeks, not through negligence, but simply because the company kept working.

The shortcut

We wired the five passes above into a free preview available from the home page. You enter a domain, it queries public DNS, the RDAP registry, the ASN and InternetDB, then renders a readable report. No sign-up, and most of the analysis runs in your browser.

It is a preview, not the platform. The difference comes down to one word: recurrence. Flawfence redoes this mapping continuously, adds DNS wordlist enumeration on top, actually tests the vulnerabilities it finds instead of inferring them from a version string, and alerts you when something new shows up on your perimeter. Same exercise, but every day and without you.

FAQ

Is the external attack surface the same as mapping the information system?

No. Mapping the information system covers everything, including internal assets, flows and business applications. The external attack surface is only the part visible from the internet. It is narrower, but it is the one an attacker explores first, and the only one you can map without installing anything.

Am I allowed to run these queries on my own domain?

Yes. The five passes described here rely on public data (DNS, certificate transparency logs, the RDAP registry, Shodan observations). You never touch the target. The question is different for an active port scan, which does reach the server: on shared infrastructure, you are not alone on it.

How often should I repeat the exercise?

Quarterly is already good if you do it by hand. The theoretically correct cadence is continuous, because the risk appears when something goes live, not when you scan. A reasonable middle ground: redo pass 2 (certificates) monthly. It takes five minutes and it is the one that moves the most.

How many extra assets will I find?

Impossible to promise, it depends entirely on your history. Across our mapping exercises the gap commonly lands between 20 and 30% for a structured company, and climbs sharply after acquisitions. If you find no gap at all, check your method before celebrating.

Conclusion

An external surface inventory is not a project, it is an afternoon. The hard part is not doing it once, it is keeping it true. Start with the five passes, write down what you find, and above all write down who owns each asset you discover. That column, more than the list itself, is what will serve your next risk analysis.

And if you want the photograph before committing the half hour, enter your domain on the home page. You will know within a minute whether the exercise is worth it.