A forgotten asset is a finding until the first CVE: reconciling the declared and the actual perimeter

Last month we were asked to test the external perimeter of a mid-sized logistics company. The scope named three domains and two IP addresses. Two hours into the work it turned out that one of those IP addresses was running a web server that appears nowhere in the client's documentation, and that two further subdomains resolved to public addresses no one on the support team knew about.

That is not unusual. It is the normal situation in an external audit: the difference between what a client considers its perimeter and what is actually reachable from the internet is often larger than expected.

The first step of an external test is not vulnerability hunting

It is perimeter verification. Before any scanner runs or any injection is attempted, one plain question has to be answered: which resources actually belong to the client? If testing starts from the wrong asset list, everything downstream is distorted. Either a critical piece of attack surface is missed, or time goes into systems that are not part of the client's infrastructure at all — for example an IP address reassigned to another tenant after a migration.

MITRE ATT&CK describes this stage as T1590: Gather Victim Network Information. An attacker always begins with reconnaissance, collecting information about the target's network infrastructure to work out where the weakest point sits. A tester does the same thing, legally and for defensive purposes. The one difference is that the result of our reconnaissance is supposed to match the client's own understanding. When it does not, there is an asset visibility problem, and it needs resolving before anyone moves on to exploitation.

Why forgotten assets matter

Forgotten assets are the class of resource that most often becomes an entry point for compromise. They are abandoned, they run old software versions, their passwords have not been changed in years, and they do not go through regular patch management cycles. CISA's Binding Operational Directive 23-01 names improved asset visibility and vulnerability detection as a priority task, and the reason is simple: you cannot fix what you do not know exists.

How perimeter verification works in practice

We take the agreed asset list from the client — domains, IP addresses, services. Then we build an independent picture of what is really visible from outside, through several parallel channels:

1. DNS resolution of every known domain, plus a search for related zones.
2. Port scanning of the specified IP addresses.
3. Inspection of SSL/TLS certificates — the CN and SAN fields frequently reveal additional hostnames.
4. Analysis of WHOIS data and domain registration history.

The key move is the comparison of two lists: the one the client provided, and the one we found. Any mismatch is a signal. Say the client listed app.example.com on IP 1.2.3.4. During scanning we see that old-api.example.com also resolves to 1.2.3.4, with port 8080 open and an HTTP service that returns the application version in its headers. That resource was not in the scope. What happens next?

What happens when something outside the scope shows up

We are not entitled to start exploiting the newly found asset. The first step is to tell the client. It may be an old server that is scheduled for shutdown but still running. It may be a test environment that ended up publicly reachable by accident. It may be a legitimate microservice that was simply left out of the inventory. The decision is made together with the client: either it is brought into the current audit, or it is recorded as a security configuration finding.

Where automation shortens the first pass

Reconciling two lists by hand is slow and prone to human error, particularly when there are hundreds of domains involved. To cut the time spent on initial data collection, we use the forgotten-asset discovery function in SeguriScan. It produces an independent list of externally reachable domains, IP addresses and network devices from publicly available sources: DNS, WHOIS, certificates and port scan results.

That automated report becomes the baseline for comparison. Instead of collecting data domain by domain, we get a structured list: here are all the public IP addresses, here are all the related domains, here are the devices found. The task then reduces to a diff in both directions. What is in the report but missing from the client's list? And, the other way round, what did the client declare that is not reachable from outside — perhaps because a firewall already closed it?

The approach is particularly useful for MSPs (Managed Service Providers) serving dozens of clients. Every client has its own set of assets, and keeping all of them current from memory is not realistic. Pulling an independent perimeter list automatically before each audit reduces the risk of an overlooked surface.

Manual checks when specialist tooling is not available

Several checks are worth running even without dedicated tooling. They will not give the full picture that a systematic collection pass does, but each one tends to surface something.

Reverse DNS against the inventory

Start with a basic DNS reconciliation. Take the list of your public IP addresses and run a reverse lookup on each of them. Match the hostnames you get back against your internal inventory (CMDB). A hostname that is not in the database is a red flag: it may be a forgotten server, or an unauthorised record.

DNS history

Check DNS history as well. Services such as SecurityTrails or ViewDNS.info show which IP addresses were associated with your domains in the past. Old records sometimes linger in a cache or at the DNS provider even after the resource itself has been physically removed. The more serious case is different: sometimes the resource is not fully removed, and part of its functionality stays reachable over old IP addresses or subdomains.

TLS certificate SAN fields

Another check that pays off is TLS certificate analysis. Request the certificate for each of your public domains and read the SAN (Subject Alternative Name) field carefully. It can list hostnames that appear nowhere in your current documentation. If dev.internal.example.com suddenly shows up in the SAN field of a public certificate, either that host was reachable from outside at some point, or the certificate was issued incorrectly and carries extra names. Either way it is worth investigating — an internal service may have leaked out to the public side.

Make reconciliation recurring, not a pre-audit task

Perimeter reconciliation belongs in a regular monitoring cycle rather than in a one-off task before an audit. New services appear, old ones are switched off, IP addresses change during cloud migrations. If the perimeter is only checked ahead of an annual penetration test, a year's worth of forgotten assets can accumulate, each of them a possible entry point. Checking on a regular cadence — quarterly, or even monthly — keeps the inventory current and narrows the window in which such an asset stays unknown.