When we ask an organisation how many assets it has exposed to the internet, the answer is usually a round, low number. The corporate site, email, perhaps a client portal. Three or four things.
When we run the discovery, the real number is systematically higher. Not by two or three: by an order of magnitude, in mid-sized organisations.
The gap between those two figures is the practical definition of attack surface: it is not what you published, it is everything that stayed published.
Where the gap comes from
The assets that turn up and nobody remembers have fairly repeatable origins.
What survived a project. The test environment from a migration that finished two years ago. The subdomain from the 2023 marketing campaign. The supplier portal that stopped being used but was never taken down. They still respond, running the software from the day they were abandoned.
What a third party stood up. The agency that published a landing page on a subdomain delegated to it. The supplier that exposed an admin panel to provide support. The integrator that left a test endpoint open. They exist under the organisation’s domain and never passed through its IT function.
What was left in DNS. Records pointing at services that no longer exist or providers no longer used. When that destination is released, the orphaned record enables a subdomain takeover: someone claims the resource at the provider and takes control of content served from a subdomain carrying the company’s name. It is among the findings with the worst ratio of impact to effort of exploitation.
What left a trace in the past. Paths and parameters recorded in historical web archives that remain reachable even though nothing links to them any more.
The findings that repeat most
Without going into detail it would be wrong to publish, a handful of findings turn up again and again.
Administration panels reachable from anywhere. Management interfaces —for CMSs, network devices, databases, monitoring tools— reachable from the internet with no source restriction. In most cases there is no decision behind it: it has been that way since installation.
Badly managed TLS certificates. Expired, issued for a different name, or incomplete chains that only fail on some clients. It is rarely a serious security problem in itself, but it is a reliable indicator that nobody is watching that asset.
Exposed remote administration services. Remote access published directly, with no intermediate layer, no source restriction and sometimes no second factor.
Headers and responses that say too much. Exact versions of servers and frameworks, error messages with internal stack traces, file system paths. None of that is a vulnerability, but it saves reconnaissance time for anyone looking for one.
Unpatched software on forgotten assets. The server nobody maintains because nobody knows it exists is, almost by definition, the most out-of-date machine in the estate.
One pattern runs through the list: almost no serious finding turns up on the main asset. The corporate site is usually reasonably looked after. The problems are at the periphery, in what is not in the inventory.
Why an annual scan is not enough
Traditional vulnerability scanning runs against a defined scope: a list of IPs or domains someone prepared. It is useful and still necessary, but it has two structural limitations.
The first: it inherits the inventory’s error. If the forgotten asset is not on the list, it does not get scanned. And the forgotten asset is exactly where the problem is.
The second: it is a snapshot. Between two annual scans, the organisation publishes, migrates, contracts suppliers and closes projects. March’s exposure does not describe October’s.
Attack surface management inverts both: it discovers instead of starting from a list, and it monitors continuously instead of photographing. The question it answers is not “do these machines have vulnerabilities?” but “what is published under our name today, and what changed since yesterday?”.
What we do in SORT ASM
Our Attack Surface Management service continuously monitors up to two IPs or domains and feeds the findings into the ISMS risk cycle. The techniques it combines:
- Subdomain enumeration and DNS recon: discovery of the real namespace, beyond the declared inventory.
- Subdomain takeover: detection of orphaned records pointing at released resources.
- Historical URLs: paths and parameters recorded historically that remain reachable.
- HTTP probe: identifying what each asset responds with, on what technology, and what it exposes in its headers.
- Shodan / Censys: correlation with what device search engines have already indexed about the organisation.
- Port scan and SSL/TLS: accessible services and the real state of certificates and cryptographic configuration.
The deliverable is not a tool dump. It is a bounded set of findings prioritised by criticality, with context on why each one matters in that particular organisation, and with the change since the previous period.
Where to start
Before contracting anything, there is an exercise that organises the conversation and costs nothing: ask IT for the list of everything the organisation has published, and compare it against what shows up in public DNS.
The distance between those two lists is your unmanaged attack surface. In our experience, that distance is what most quickly convinces a board that the problem exists.
SORT ASM is part of the Advanced and Complete levels of our service model.