The forgotten VPN: enumerating shadow IT from the outside

Every organisation has an asset it does not know about. Usually several. A VPN appliance stood up for a project that ended, a staging environment that was never torn down, a marketing subdomain pointed at a platform someone stopped paying for, a device that a supplier installed and nobody inherited. None of it appears in the CMDB, because the CMDB records what was requested rather than what exists.

The asset nobody owns is the one nobody patches. That is the whole reason this pass is worth running, and worth running on a schedule rather than once.

Start from what is provably yours

The temptation is to begin with a subdomain wordlist. Resist it — brute force finds what you thought to guess, and the interesting assets are the ones nobody would guess. Start instead from records that exist because somebody had to register something.

Certificate transparency logs are the most productive single source available. Any publicly trusted certificate issued for a hostname is logged, permanently and searchably, which means every host that has ever had TLS terminated in front of it has left a record. That includes the internal-sounding names people assume are private: vpn-test, jira-staging, old-mail. The logs do not care what you intended.

# Hostnames from certificate transparency
curl -s 'https://crt.sh/?q=%25.acme.local&output=json' \
  | jq -r '.[].name_value' \
  | tr '[:upper:]' '[:lower:]' | sed 's/^\*\.//' | sort -u

Registration data is the second pillar. Work outward from the domains you know to the organisation's ASN and the netblocks announced under it, then to the reverse DNS of those ranges. This finds infrastructure that has no relationship to any hostname you started with — which is exactly the category you are looking for.

Third, historical DNS. Records that used to exist tell you what used to be deployed, and a surprising proportion of it is still listening on the address it was pointed at. A hostname removed from DNS is not a decommissioned host; it is an undocumented one.

The dangling record problem

Two failure modes recur often enough to check for specifically, and both come from the same root cause: a DNS record outliving the thing it points at.

A CNAME aimed at a cloud service that has since been released means the name can be claimed by whoever registers that service name next. The organisation's own DNS then authoritatively points visitors — and any cookie scoped to the parent domain — at infrastructure it does not control. This is cheap to check and easy to miss, because the record looks perfectly healthy in the zone file.

An A record aimed at an address released back into a provider's pool has the same shape with different mechanics. Both are found by resolving every record you have collected and asking whether the target is claimed, unclaimed, or serving something unexpected.

• Resolve everything, and record what does not resolve rather than discarding it. A non-resolving name is a finding, not a dead end.
• For every CNAME, check whether the target is currently registered.
• For every address, confirm it is inside a range the organisation actually controls. Addresses outside the known netblocks are either third-party hosting nobody documented or no longer yours at all.

Fingerprinting, and knowing when to stop

Now you have a host list. What matters is what is on it, and the answer should be gathered in the order of least intrusive first — an external recon pass on a live estate is not the place to be careless with a target you have not yet confirmed belongs to your client.

Service and version identification comes first, from banners and response characteristics. Then the technology behind any web service. Then whether an authentication surface is present, because appliances with a login page are the single most valuable category here: they are internet-facing by design, frequently unpatched, and the ones nobody owns are unpatched by definition.

# Which of the collected hosts actually answer
httpx -l hosts.txt -sc -title -tech-detect -o live.txt

# Fingerprint without touching anything
nuclei -l live.txt -tags tech,detect -severity info

Two disciplines apply. Confirm ownership before you probe anything — a certificate transparency search for a common brand name returns hosts belonging to entirely unrelated companies, and testing one of those is somebody else's incident. And keep the passive and active phases separate in your notes, because the client will ask which of your findings required touching their infrastructure and which came from public records.

The asset nobody owns is the one nobody patches. That is not a coincidence — it is the same fact stated twice.

Prioritising what comes back

A first pass against a mid-sized estate returns more than anyone will act on. Ranking it is the part that determines whether the exercise changes anything.

Sort by a single question: if this host were compromised, what would it reach? That produces a very different ordering than severity scores do.

• Remote access surfaces first — VPN concentrators, remote desktop gateways, management interfaces. They are network entry points by function, so a weakness in one is a weakness in the perimeter itself.
• Then anything holding an authentication surface tied to the corporate directory. A forgotten application that federates to the main identity provider is a credential-harvesting position.
• Then non-production environments carrying production data, which is most of them.
• Then everything else, which is mostly abandoned marketing infrastructure and matters mainly for domain reputation.

Report the ownership gap alongside the technical findings. "This host is running an unpatched appliance" produces a patch. "No team in the organisation claims this host, and we found four more like it" produces a process change, and the process change is what stops the next four appearing.

Make it recur

A one-off external assessment describes a day. The estate changes weekly: someone stands up a subdomain, a supplier deploys an appliance, a project ends without a decommissioning step.

The collection stages here are all automatable and cheap. Run them on a schedule, store the results, and diff. A new host appearing in certificate transparency for your domain, with no corresponding change ticket, is worth an email the same week rather than a finding in next year's report. The value is not in the individual scan — it is in being the first party to notice each change.