The riskiest server is the one nobody remembers

Attackers rarely start with your main website. It is patched, monitored and behind a WAF. They start with everything around it: the staging subdomain from a project that ended two years ago, the test VM someone opened "just for a demo", the marketing microsite an agency still hosts for you.

These assets have one thing in common: they are not on anyone's list. No owner, no patching, no monitoring. That makes them the easiest way in.

Here is a practical checklist to find them before someone else does. Everything below uses public information or tools you probably already have.

Only scan and test assets you own or have written permission to test.

1. Start from what you know you own

Before discovering anything new, write down the starting points:

• Every domain registered by the company (check your registrar account, not your memory)
• Cloud accounts and subscriptions, including the ones opened with a personal card
• Public IP ranges assigned to you by your ISP or hosting provider

This list is your "seed". Most forgotten assets hang off one of these.

2. Find subdomains through Certificate Transparency

Every publicly trusted TLS certificate is written to public Certificate Transparency logs. If someone ever requested a certificate for oldstaging.example.com, that name is recorded forever.

You can search these logs for free on crt.sh:

https://crt.sh/?q=%25.example.com

The %25 is a wildcard, so this returns every certificate issued for any subdomain of example.com. Expect names you have never seen: dev, test, vpn2, jira, grafana, names of past projects and old campaigns.

3. Look for dangling DNS records

A dangling record is a DNS entry that still points to a resource that no longer exists. The classic example is a CNAME pointing to a cloud storage bucket or a hosted app that was deleted.

If an attacker can create a resource with that same name on the same provider, your subdomain now serves their content. This is called subdomain takeover, and it is one of the most common findings on bug bounty programs.

For every subdomain you found in step 2:

• Resolve it and note where it points
• If it is a CNAME to a cloud service, check that the target still exists and still belongs to you
• Delete records you no longer need instead of leaving them "just in case"

4. See what is actually listening

A hostname tells you something exists. Open ports tell you what it exposes. Pay special attention to services that should almost never face the internet:

A database or an admin panel reachable from the whole internet is rarely intentional. It is usually a temporary rule that became permanent.

5. Check certificates, not just whether they exist

For each HTTPS service, look at:

• Expired certificates (users learn to click through warnings, which is worse than the warning itself)
• Self signed certificates on public services
• Certificates expiring in the next 30 days

Expired certificates are also a strong hint that nobody is maintaining that asset anymore. Treat them as a signal to ask "who owns this?"

6. Do not forget your supply chain

Some of your exposure does not run on your infrastructure at all:

• SaaS tools mapped to your subdomains (help desk, status page, docs)
• Websites hosted by agencies or former vendors
• Integrations that hold API keys to your systems

You cannot patch these yourself, but you can know they exist, ask vendors the right questions and remove the ones you no longer use.

7. Search for leaked credentials

An exposed asset is dangerous. An exposed asset plus a valid password is an incident. Check:

• Public code repositories for committed secrets (GitHub secret scanning helps here)
• Breach notification services for company email addresses
• Paste sites and dark web sources, if you have access to that kind of monitoring

8. Prioritize instead of drowning

By now you may have hundreds of findings. Fixing them in the order they appear is how teams burn out. A simple order that works:

1. Actively exploited: Anything matching a vulnerability in the CISA Known Exploited Vulnerabilities catalog
2. Directly reachable and sensitive: Exposed databases, admin panels, remote access
3. Takeover risk: Dangling DNS records
4. Hygiene: Expired certificates, outdated software versions with no known exploit

And for each finding, write down who owns it. A finding without an owner will still be open next quarter.

9. Make it continuous

The biggest mistake is doing all of this once, usually right before a pentest or an audit. New subdomains appear every week. Developers spin up test servers. Marketing launches a campaign site.

Some practical rules:

• Rescan critical assets more often than everything else, not everything on the same schedule
• Alert on new assets, not only on new vulnerabilities
• Review the list of assets without an owner once a month

Wrapping up

None of these steps require expensive tools. The hard part is doing them every week, for every asset, and turning the results into a short list of fixes someone will actually make.

Disclosure: I work at Cylana, where we automate this process: you enter a domain, the platform discovers your internet facing assets, monitors leaks and returns a prioritized list of fixes written step by step. But the checklist above works on its own, and I'd love to hear in the comments what you would add to it.