Threat analysis
Attack surface inventory: what you expose publicly
Most asset registers are written from the inside out: asset tags, machine names, owning department, which rack it sits in. An attack surface inventory asks a different question — seen from outside your company, which addresses, which names and which services answer? The two lists rarely match, and the gap almost always runs the same direction: the outside sees more than the inside remembers.
The gap is not anyone’s negligence. Requesting a certificate leaves a public record. A cloud test environment a department spins up never passes through IT. A vendor installing equipment opens a management port so they can maintain it remotely. Each decision is reasonable on its own; together they produce a public-facing list nobody owns.
This article covers how to get that list back: which public sources an attacker uses to derive your assets, which categories get missed, five steps you can run without buying anything, and what to do with each item once you have it.
- Public records, no contact with you
- Probing your addresses
- Usable target list
Text version of this diagram
Four stages from one public domain name to a list of usable targets; the first three run on public records alone and never touch the target.
Stage one — the starting point
- One domain name, which anybody can look up.
Stage two — four classes of public record
- Domain and ASN registration (ATT&CK T1590): the address ranges held in the organisation’s name.
- DNS records, reverse lookups (T1590.002): hostnames and the addresses behind them.
- Certificate transparency logs (T1596.003): every subdomain a certificate was ever issued for, including internal-sounding names.
- Public code and documents (T1593): system names and URLs from code hosting, slide decks and job ads.
Stage three — the candidate list
- The four sources merge into candidate address ranges, subdomains and hostnames.
- Not one packet has been sent to the target yet.
Stage four — actual probing
- A port scan establishes which of the candidate addresses answer.
- Each answer is fingerprinted for service and version, then matched against the known exploited vulnerabilities catalog to produce the usable list.
What to take from it
- The first three stages leave nothing in your logs; you will not know they happened.
- Only the last stage touches your systems, and it looks like an ordinary scan.
- The whole chain is automated and continuous, and it is not run for you alone.
How much an attacker derives from a single domain name
This stage is called reconnaissance (TA0043), and it happens before any connection is attempted. The attacker usually starts with a company name and one domain — enough to build a fairly complete asset list without ever touching your systems, which is also why you never learn that it happened.
| Public source | What it yields | Technique |
|---|---|---|
| Domain and ASN registration | Address ranges held by the company | T1590 |
| DNS records, reverse lookups | Hostnames and the addresses behind | T1590.002 |
| Certificate transparency | Every subdomain ever certified | T1596.003 |
| Public code and documents | System names, internal URLs, stack | T1593 |
Registration data is queried through RDAP, which reveals the autonomous system your ranges sit under. Anyone who finds your ASN has your entire public address space as a matter of public record — which is precisely what gathering victim network information (T1590) describes.
The most underestimated source is the certificate transparency log. Every publicly trusted TLS certificate is written to an append-only public log, and anyone can list every certificate ever issued for your domain. What surprises people is what those names give away: vpn-test.example.com or hr-uat.example.com became public knowledge the moment the certificate was requested. It is the most productive branch of searching open technical databases (T1596).
At this point the attacker holds a candidate list and has sent you nothing. Only now comes active scanning (T1595): a port scan over the candidates to see what answers, banner grabbing against whatever does, and a match of the resulting versions against the CISA Known Exploited Vulnerabilities catalog. This is the same opening move as the ransomware attack chain — the difference is that it now runs automatically, continuously, and not for you in particular.
The six exposed assets inventories usually miss
What gets missed follows a pattern. These six turn up in almost every first inventory, and they share one trait: IT did not put any of them there.
| Category | Typical case | Why it gets missed |
|---|---|---|
| Test and staging | uat, staging, demo subdomains | Nobody owns shutting it down |
| Department cloud | Hosts marketing or R&D spun up | Never went through procurement |
| Outsourced sites | Campaign sites, brochure sites | Nobody tracks it after handover |
| Vendor-managed devices | Monitoring hosts, door access, NAS | A port opened for remote upkeep |
| Management consoles | Firewall, hypervisor, remote desktop | ”Only we know the URL” |
| Stale DNS records | Pointing at released cloud resources | Service retired, record kept |
The first two are textbook shadow IT: they solve a real business need, they simply skipped the process — so they are on no register and in no patching schedule.
The last one deserves its own note. When a DNS record points at a cloud resource that has been released, someone else can claim that resource, and your subdomain starts serving their content with nothing visibly wrong to a browser or a visitor. This is subdomain takeover, and it is cheap precisely because nobody has looked at that record in years.
Five steps to a first attack surface inventory, with no tooling budget
A first attack surface inventory needs no purchase and no project budget. It needs an afternoon and a willingness to have the existing register proved wrong.
- List the starting points. Every domain the company holds (including retired ones still registered), public address ranges, cloud accounts, and any site an agency hosts for you.
- Expand from public sources. Pull subdomains from certificate transparency, add hostnames from DNS and reverse lookups, and merge the result into a candidate list. Nothing is touched at this step.
- Establish what answers. Port scan your own addresses and record open ports and services. Scan only what is yours — doing this to targets you have no authorisation for can be an offence in most jurisdictions, including Taiwan’s Criminal Code Article 358; when a third party runs it, the scope belongs in a signed authorisation.
- Tag three things per item. Who owns it, who uses it, what breaks if it is compromised. Any item where the first answer is missing is itself the most valuable finding of the exercise.
- Keep a snapshot. Store the list as a baseline so later rounds compare differences instead of starting over.
These five steps have a hard ceiling: they establish what answers, not whether it can actually be exploited. Answering that means trying it within an agreed scope, which is the job of a penetration test or red team engagement, not of an inventory.
Every item you find needs three questions answered
The list itself is worth nothing; what you do with it is worth something. Three questions per item: is anyone still using it, who owns it, and does it genuinely have to be reachable by the whole internet? The first two decide whether anyone is watching it. The third decides whether it should be visible at all.
- Stays public; harden and patch
- Needs an owner or a new reachability model
- Turn it off
Text version of this diagram
Every exposed asset lands in one of four cells: the horizontal axis is whether IT knows it exists, the vertical axis is whether it genuinely needs to be public. The cell is the decision.
Top left — known, and genuinely public
- Examples: website, mail, customer portal.
- State: it has an owner and a maintenance window.
- Action: harden it, keep patching it, leave it public.
Top right — unremembered, but genuinely in use
- Examples: outsourced sites, cloud services a department set up.
- State: people do use it; the inventory misses it.
- Action: find the owner and bring it into the inventory first.
Bottom left — known, but does not need to be public
- Examples: VPN gateway, management consoles, remote desktop.
- State: only staff and a few partners should use it.
- Action: make it reachable only after authorisation.
Bottom right — unremembered, and needed by nobody
- Examples: forgotten test sites, stale subdomains.
- State: nobody maintains it and nobody watches it.
- Action: turn it off.
- This is the highest-risk cell of the four.
Most companies find the distribution weighted heavily toward the bottom half. The services that genuinely need to be reachable by everyone are usually the website, mail, and a small number of customer portals. The rest is history: something was opened years ago so one person could work from home, and nobody closed it afterwards.
Why most of the list does not need to be visible to be usable
The bottom-left cell — known, but with no need to be public — is usually the largest group and the hardest to act on. Closing it draws complaints; leaving it open is attack surface.
The traditional compromise is source IP restriction. That works while everyone sits in fixed offices, but remote work, mobile networks and branch offices make source addresses unstable, the allow list grows, and eventually you are back where you started.
The other option changes the premise of reachability. The service listens on no public port; instead it dials outbound to a fabric, and only requests that have already passed authentication and authorisation are connected to it. A scanner does not get a refusal, it gets no answer at all — nothing is listening on that address, so it never enters anyone’s candidate list. The mechanics are in how a zero trust network works, and the differences between architectures on this specific point are in VPN, gateway ZTNA and SDP compared.
To be clear about the limit: this does not reduce the attack surface to zero. The website and mail still have to face the internet, and people still click links in email. What it does is shorten the list you have to defend to the things that genuinely need to be public, so that limited patching and monitoring effort lands on those.
Attack surface drifts, so an inventory is not a one-off project
An inventory starts losing accuracy the day it is delivered. A project ships, a vendor swaps hardware, a department opens a cloud service, a certificate adds two subdomains — each changes the attack surface without anyone telling IT.
- On the last inventory
- Added since, not yet tracked
Text version of this diagram
Two lanes against one timeline: above, the list the last inventory produced; below, the exposed items added afterwards without passing through IT.
Upper lane — the last inventory
- Website, mail, VPN gateway, customer portal, monitoring console: five items.
- The list stops changing the day it is written.
Lower lane — four items added since
- A campaign site, outsourced to an agency.
- A test environment, shipped with a project.
- Vendor equipment, for remote maintenance.
- A cloud service, set up by a department.
What to take from it
- None of the four passed through IT, so none appears on any list.
- Until the next inventory, every item in the lower lane is public and unwatched.
- The gap widens with time, which is why an inventory needs a fixed cycle.
A workable cadence is quarterly for the full sweep, plus four triggers in between: a new system going live, an acquisition or new site, a change of outsourcing vendor, and any change to a public-facing service. Because you kept a baseline snapshot, each round looks at the difference rather than the total, and costs a fraction of the first one.
None of this is optional extra credit in the major frameworks — it is control number one. CIS Control 1 is inventory and control of enterprise assets, and NIST CSF 2.0 puts asset management at the front of the Identify function. The ordering is deliberate: you cannot protect something you do not know exists.
Terms and further reading
| Term | In one sentence | Source |
|---|---|---|
| Attack surface | The sum of externally reachable entry points | Attack surface |
| Reconnaissance | Gathering target information before attack | MITRE ATT&CK TA0043 |
| RDAP | Protocol for querying registration data | RFC 9082 |
| Autonomous system (ASN) | Address ranges under one routing policy | Autonomous system |
| Gather victim network info | Recon of ranges, domains and DNS | MITRE ATT&CK T1590 |
| Certificate transparency | Public append-only log of issued certificates | RFC 6962 |
| Search open technical databases | Deriving assets from public records | MITRE ATT&CK T1596 |
| Active scanning | Sending probes directly to target addresses | MITRE ATT&CK T1595 |
| Port scan | Testing which ports answer | Port scanner |
| Banner grabbing | Identifying product and version from a reply | Banner grabbing |
| Known exploited vulnerabilities | Flaws confirmed as exploited in the wild | CISA KEV |
| Shadow IT | Systems and services IT does not track | Shadow IT |
| Subdomain takeover | Claiming a resource a stale DNS record points at | OWASP WSTG |
| Criminal Code Article 358 | Offence of unauthorised access in Taiwan | Criminal Code of Taiwan |
| Asset inventory control | Control requiring all assets be tracked | CIS Controls 1 |
| Cybersecurity Framework 2.0 | Framework organised by Identify, Protect, Detect | NIST CSF 2.0 |
| Zero trust architecture | Trust that does not follow network location | What zero trust is |
The four public sources and the five steps above work directly as the task list for a first inventory. The diagrams are simplified models; real environments add cloud and branch-office variations. If you finish and get stuck on the items that should be closed but cannot be, get in touch and we will look at the alternatives with you.