Most asset registers are honest about what procurement bought and silent about everything else. That gap is where the work sits: to find forgotten internet-facing assets, you have to look for the things that never passed through a change request, a purchase order or a CMDB form. A seasonal campaign site. A staging box named after the project that built it. A DNS zone still billing seven pounds a month to a card nobody recognises.
None of that requires a platform to uncover. A patient person with a spreadsheet, access to the registrar accounts and an afternoon can get surprisingly far. What follows is a repeatable hunt using free sources, plus an honest account of where those sources stop and what the law says about poking at whatever you find.
Where forgotten internet-facing assets actually come from
Five origins account for most of them. Marketing microsites built for a promotion that ended two years ago. Infrastructure inherited in an acquisition, where the previous owner’s cloud account came with the company. Developer sandboxes and staging environments stood up to test something and never torn down. Cloud resources half-decommissioned, where the compute went but the DNS record stayed. And domains or subdomains registered by staff who have left or by an agency on its own account.
An internal CMDB will not contain any of these, and not because the CMDB is badly run. Nothing in the procurement or change process ever touched them. A developer deploys a test service. A marketing manager pays for a domain with a company card. An agency adds a CNAME for a campaign. The register records what was formally requested; the internet records what was actually published.
The risk profile of an unowned asset is the uncomfortable part. No named patching owner, so updates stop. No certificate renewal, so TLS lapses or falls back to something self-signed. No log review, because nobody is watching a host they do not know exists. Often default or shared credentials, because it was only ever meant to be temporary. An attacker enumerating your domains does not care about any of that context. They see a reachable service running software from 2021 with an admin panel on the public internet, and they treat it as the softest entry point you own. That is what an unknown assets security risk looks like in practice: not an exotic zero-day, but ordinary neglect discovered by someone else first.
Start with the paper trail no scanner can see
Begin inside the business. External techniques expand outward from what is already visible; they cannot infer a domain registered on a supplier’s account or a cloud tenancy that arrived with an acquisition. Finance and procurement records are the most underused discovery source there is.
Work through four things:
- Registrar and DNS provider accounts. Export every zone, not just the primary domain. Then establish who actually holds the login, because the answer is sometimes a former employee’s personal email or an agency’s shared account. Count the zones. If the number surprises you, that is the finding.
- Cloud billing and card statements. A recurring charge of a few pounds a month frequently maps to a live VM, an object storage bucket, a hosted DNS zone or a certificate order. Pull twelve months of statements and chase anything nobody can explain in one sentence.
- Agency, reseller and supplier contracts. Look specifically for vanity CNAMEs, campaign domains and email-sending subdomains delegated to a third party. A marketing agency registering a seasonal domain on its own card is a routine arrangement until the contract ends and the hostname keeps resolving with nobody responsible for renewal or takedown.
- Ownership evidence scattered elsewhere. Google Search Console properties, CDN and WAF configurations, old TLS certificate orders, SPF and DMARC records listing senders you no longer use. Each is a claim of ownership written down somewhere other than the register.
This part is dull. It is also where the assets that no external method can reach are found, and it gives you something the scanning stage badly needs: a defensible list of what you genuinely own.
Free external discovery: from seed domain to candidate list
With apex domains in hand, look at your estate the way an attacker does: from the outside.
Certificate transparency logs
Certificate transparency is the strongest free source available. Publicly trusted certificate authorities log the certificates they issue to append-only public logs, and browsers including Chrome have required CT inclusion for publicly trusted certificates since 2018, so most of what is issued for your domains ends up searchable. Query each apex domain in a CT search service such as crt.sh and include expired certificates. A search against a mid-sized organisation’s main domain returning several hundred historic names is unremarkable, and the interesting ones are rarely the obvious ones: campaign microsites from closed promotions, staging hosts named after the project that created them, a VPN endpoint from a provider you stopped using.
Expired certificates deserve as much attention as live ones. The certificate lapsing does not remove the DNS record, and the hostname often still resolves long afterwards. We cover the structural limits of this source in more detail in the piece on the subdomain discovery gaps in certificate transparency, but the short form is that a wildcard certificate covers every subdomain while naming none of them, and anything issued by an internal CA or a non-logging issuer never appears at all.
Passive DNS and public record enumeration
Passive DNS services record observed resolutions over time, which lets you see names that answered historically even if they do not answer today. Pull the full record set for each zone you exported: CNAMEs pointing at cloud services, MX records aimed at a mail provider you migrated away from, TXT records authorising senders nobody can name, NS delegations handing a subdomain to a third party. SPF and DKIM entries are a particularly good map of forgotten SaaS relationships.
RDAP, WHOIS, ASN and reverse DNS
Registration data tells you who holds what. ICANN has moved gTLD registration data to RDAP, with the legacy port 43 WHOIS service for gTLDs retired in early 2025, so check what is currently available for the namespaces you care about. For IP space, look up the ASN associated with any address you control and walk the announced ranges, then run reverse DNS across them. If your organisation has its own allocation, this finds exposed services on public IP addresses that no hostname ever pointed at. If you sit on shared hosting, reverse DNS mostly finds your neighbours, which is a useful lesson in itself.
Search engines and public code
Site-scoped search operators still surface indexed pages on hostnames nobody documented. Public code repositories are worth a look too: hardcoded endpoints, config files and CI definitions pushed by a contractor years ago tend to name internal and staging hosts in plain text.
Why the output is a candidate list, not an inventory
Seed-domain expansion is indiscriminate by design. It will return shared hosting IPs where your site is one tenant of forty, SaaS vanity CNAMEs where the infrastructure belongs to the vendor, and lookalike domains that someone else registered to impersonate you. Confirm ownership against the registrar accounts and billing records before you touch anything. Claiming or testing an asset you do not own creates a real problem, and a typo-squatted domain in your candidate list is evidence of a brand abuse issue, not an asset to patch.
Passive observation also has a precision limit that is easy to forget. Banner and fingerprint data tells you a host is likely affected by something, not definitely. Several Linux distributions backport security fixes while leaving the version string unchanged, so a patched host can advertise a vulnerable build indefinitely. A reverse proxy can announce a version that is not what is actually serving the request. Raise a P1 off a version number alone and the team who has to patch it will, quite reasonably, trust you less next time. The distinction between likely and definitely is the whole difference between external observation and authenticated scanning.
Then there is the legal line, which matters more than people assume. Looking at what is published is not the same as testing it. Reading certificate transparency logs, resolving DNS and viewing a web page are passive. Running an active scanner, attempting a login or probing for a vulnerability is active testing, and the Computer Misuse Act 1990 turns on authorisation, not intent. If the asset turns out to belong to an agency, a supplier or a company you merely resemble, you need written authorisation from whoever is responsible for it before probing. Get the permission in an email. It costs nothing.
The two findings that usually justify the hunt on day one
Dangling DNS is the finding free methods are best at. A CNAME still pointing at a deleted object storage bucket or a decommissioned cloud app is visible from outside with no special access, often announcing itself with a provider error page such as NoSuchBucket. Anyone can then create a resource of the same name in the same region and serve content from your hostname, with a valid certificate, on a domain your users trust. The fix is deleting the stale record, not recreating the resource to make the error go away. And if you find one, check the entire zone, because these arrive in batches from the same decommissioning project. Our write-up on the dangling DNS problem goes through the provider-specific mechanics.
The second category is plain exposure: an admin interface reachable from the internet, a staging site with production data and no authentication, an expired or self-signed certificate on a public IP. Most of these are misconfigurations rather than CVEs, which makes them the easier win. There is no patch to schedule, no vendor advisory to wait for and no change window to negotiate. Someone closes a firewall rule or deletes a record, and the exposure is gone that afternoon.
Record what you found so the hunt is not wasted
A sweep that produces a one-off list of hostnames in somebody’s downloads folder has achieved very little. Record each confirmed asset with hostname, IP, service and port, named owner, business purpose, hosting provider and a review date. That minimum set is unpacked field by field in our guide to building an internet-facing asset inventory.
The owner field is the one people fudge. “IT”is not an owner. If nobody will claim an asset, that is a decommission decision, and it should be recorded so with a date. Anything unclaimed and unexplained after a fortnight of asking should be switched off, with the record kept.
Close the loop afterwards, or you will run the same hunt next year and find the same class of thing. Agree with procurement and marketing that campaign domains get registered on your account, not the agency’s, and that new hostnames land in the register at launch. Then set a cadence. A quarterly manual sweep is defensible for most mid-sized estates, with an out-of-cycle check triggered by an acquisition, a major campaign launch, a cloud migration or an NCSC advisory about something you might be exposed to. Cyber Essentials assessment expects you to be able to account for the devices and services you expose to the internet, and the NCSC’s asset management guidance treats knowing what you have as a foundation rather than an optional extra.
Where free methods run out and tooling starts paying
A manual hunt is a snapshot of a river. Accurate at the instant it was taken, drifting immediately. The exposure that matters most is often the one created on deployment day, three weeks after your quarterly sweep, which means change detection rather than discovery is the real gap in the free approach.
If you do go to market, judge products on data freshness, prioritisation logic and coverage beyond CVEs rather than counting features. How often is passive DNS refreshed? Does the tool explain why it believes something is yours? Can it tell a misconfiguration from a version string? Our practical checklist for choosing an EASM product sets out the questions worth asking in a demo.
One honest caveat. A noisy feed of low-value findings is worse than a quarterly manual hunt done properly, because people stop reading it and false confidence replaces absent confidence. External attack surface management, authenticated vulnerability scanning and internal asset tooling are complementary controls, not substitutes for each other. The free hunt is the right place to start, and it is also the thing that tells you whether paid discovery of the assets you forgot would actually earn its licence fee in your estate.
The Short Version
- Forgotten assets come from campaigns, acquisitions, sandboxes, half-finished decommissions and domains held by departed staff or agencies. Your CMDB never saw any of them.
- Start with the paper trail: registrar and DNS exports, cloud billing lines, card statements, agency contracts. No external technique can infer those.
- Then expand outward for free using certificate transparency (including expired certificates), passive DNS, full zone records, RDAP, ASN lookups and reverse DNS.
- The output is a candidate list. Confirm ownership before probing, and remember the Computer Misuse Act 1990 turns on authorisation.
- Dangling DNS and exposed admin interfaces are the findings free methods catch best. Delete the stale record rather than recreating the resource, and check the whole zone.
- Record owner, purpose and review date per asset, decommission what nobody claims, and repeat quarterly with triggers for acquisitions and launches.
Frequently Asked Questions
What counts as a forgotten internet-facing asset?
Any host, service, domain, subdomain or cloud resource that is reachable from the public internet and has no named owner inside your organisation. The test is not whether it is in use but whether anyone is responsible for patching it, renewing its certificate and reviewing its logs. If the answer to all three is nobody, it is forgotten regardless of what the register says.
Can I find forgotten internet-facing assets without buying a tool?
Yes, for a point-in-time sweep. Certificate transparency search, passive DNS, registration data and reverse DNS are free and will expand a handful of seed domains into a sizeable candidate list, and your own billing and contract records cover the ground those sources cannot. What free methods will not give you is continuous change detection, so new exposure created after the sweep stays invisible until the next one.
Is it legal to scan or probe an asset I think belongs to my organisation?
Passive observation of published data is a different activity from active testing, and the Computer Misuse Act 1990 depends on whether access was authorised. Confirm ownership through registrar or billing records first, and obtain written authorisation from the responsible party before running any active scan, particularly where hosting is shared or a supplier operates the asset. This is general information rather than legal advice; take your own if the ownership picture is unclear.
How often should a manual external discovery sweep be repeated?
Quarterly suits most mid-sized estates, with additional checks after an acquisition, a cloud migration, a large campaign launch or a significant NCSC advisory. Organisations that deploy frequently will find a quarterly cadence leaves long blind periods, which is usually the point at which continuous monitoring starts to look reasonable rather than indulgent.
Why do certificate transparency logs miss some subdomains?
A wildcard certificate secures every subdomain while listing none of them individually, so the names stay hidden. Certificates issued by an internal CA, or by any issuer that does not submit to public logs, never appear either. Hosts that have no certificate at all, including plain HTTP services and non-web ports, are outside the source entirely, which is why passive DNS and reverse DNS are needed alongside it.