How to Find Forgotten Subdomains Before Attackers Do (2026 Guide)
If you want to know how to find forgotten subdomains, start by assuming your current DNS inventory is incomplete. Most teams have more internet-facing assets than they think, and the ones nobody owns are usually the ones that cause trouble later.
Definition box
Forgotten subdomains are public hostnames that still resolve or still exist in historical records, but are no longer actively owned, maintained, or monitored.
Table of Contents
Key Takeaways
Forgotten subdomains expand your attack surface even when the underlying project is dead.
Attackers find them using certificate transparency logs, passive DNS, search, brute force, and historical records.
Manual discovery is useful, but automation is better once you have more than a few domains.
Continuous monitoring matters more than one-time scanning.
If nobody can explain why a subdomain exists, it should not stay public.
What forgotten subdomains are
Forgotten subdomains are subdomains that were created for a project, test environment, migration, campaign, partner integration, or internal workflow, then left behind after the work ended. They may still resolve, still serve content, or still show up in public records even though the business no longer needs them.
Common examples:
staging.example.com left behind after a release.
beta.example.com kept alive after launch.
promo.example.com created for a marketing page.
old-api.example.com pointing to a retired backend.
support.example.com mapped to a third-party service that was later removed.
These are often called abandoned subdomains, shadow assets, or stale dangling DNS records when the DNS entry still points somewhere that no longer exists. They matter because security teams usually focus on known apps, while forgotten subdomains quietly remain on the public internet.
Organizations often leave old subdomains publicly accessible.
Why teams lose track of them
Subdomains get forgotten because they are easy to create and hard to retire cleanly. A developer needs a quick staging hostname, marketing wants a campaign landing page, or a vendor integration needs a branded endpoint, and nobody owns the cleanup later.
The root causes are usually operational, not intentional:
No central subdomain inventory.
Weak ownership tracking.
Temporary projects that become permanent by accident.
Migrations that leave old DNS records in place.
Third-party services removed without DNS cleanup.
Multiple teams creating internet-facing assets independently.
That is why subdomain inventory belongs in external attack surface management, not just in deployment checklists.
Practical example
A startup launches launch.example.com for a product release, then moves the content to the root domain. Six months later, the old subdomain is still live, still indexed, and still part of the company's public footprint. Nobody remembers who owns it, but attackers can still find it.
Why attackers care
Attackers like forgotten subdomains because they often sit outside normal review and monitoring. These hosts may run older software, expose admin panels, or point to services nobody controls anymore.
The main risks are straightforward:
Subdomain takeover. A dangling CNAME can point to a removed cloud resource.
Phishing. A malicious page on a trusted subdomain can look legitimate.
Credential capture. Forgotten login pages can collect passwords or session tokens.
Information leakage. Old test systems may expose source maps, debug data, or internal docs.
Control gaps. Staging and beta systems often miss patching, MFA, logging, and access review.
Callout
If a forgotten subdomain still resolves, it is already part of your attack surface.
How attackers find them
Attackers do not rely on one technique. They build a picture from public records, brute force, and historical data until the missing hostnames start showing up.
Common discovery sources include:
Certificate transparency logs.
Passive DNS datasets.
Search engine indexes.
Historical DNS records.
Wordlist-based brute force.
Permutation-based enumeration of known names.
Recent subdomain enumeration workflows still center on the same basics: CT logs, passive data, active DNS checks, and validation of which hosts are live.
Typical attacker workflow
Pull subdomains from CT logs.
Cross-check passive DNS and archived records.
Brute-force common names like dev, test, staging, and backup.
Filter out wildcard DNS false positives.
Probe live hosts for takeover conditions or exposed services.
CT logs often expose subdomains that teams have forgotten.
How to find them manually
Manual subdomain discovery is slower, but it teaches you what to look for. If you are starting with a single domain or a small portfolio, this is the best place to begin.
Start with your own records
Export the assets you already control:
Then sort them into:
Check certificate transparency logs
CT logs are one of the best starting points because they reveal publicly issued certificates tied to your domain. Search your root domain and collect every hostname that appears.
Useful sources:
Review passive DNS and archives
Passive DNS can show older hostnames that no longer appear in your current records. Web archives and cached pages can also reveal old campaign pages, login portals, and forgotten docs.
Use search operators
Search engines can expose indexed subdomains and old content. Useful queries include:
site:example.com
site:*.example.com
inurl:example.com
These often surface old docs, beta pages, and campaign sites that were never removed.
Brute-force common names
Use a targeted wordlist, not random guessing. Common subdomain names include:
dev
test
staging
beta
old
legacy
admin
api
portal
backup
Then resolve the results and remove false positives caused by wildcard DNS.
Validate what still exists
For every discovered subdomain, ask:
If you cannot answer those questions quickly, the hostname needs review.
Manual work is fine for one domain. For multiple domains or frequent changes, automation is the practical choice.
| Method |
Best for |
Strengths |
Limits |
| CT log review |
Historical discovery |
Finds certificates tied to your domain |
Misses hosts without certs |
| Passive DNS |
Old and deleted records |
Good historical context |
Depends on source coverage |
| Search engine queries |
Publicly indexed hosts |
Simple and fast |
Incomplete coverage |
| DNS brute force |
Predictable naming patterns |
Finds hidden or guessed hosts |
Noisy and time-consuming |
| Permutation scanning |
Variants of known hosts |
Finds related hostnames |
Needs a baseline |
| Automated subdomain scanner |
Continuous inventory |
Fast, repeatable, scalable |
Needs tuning and validation |
Tools commonly used in subdomain enumeration workflows include Amass, Subfinder, Gobuster, Massdns, dnsx, and httpx. They are often used together: collect passive results, deduplicate, resolve live hosts, then compare the output against your approved inventory.
Step-by-step workflow
1. Run passive discovery first
Passive discovery gives you the broadest first pass without touching the target much. It is useful for building a baseline of what is publicly known.
2. Deduplicate the results
Multiple sources will return the same hostname. Clean the list before you spend time validating it.
3. Resolve live hosts
Look for names that resolve to current IPs or active HTTP services. This separates real hosts from stale records.
4. Detect wildcard DNS
Wildcard DNS can make every random label look valid. If you skip this step, your results will be noisy.
5. Run active brute force if authorized
Use a curated wordlist to find predictable names like dev, portal, or backup. Only do this on assets you own or are explicitly allowed to test.
6. Compare against the approved inventory
Anything not in the inventory becomes a review item.
7. Flag unknown or unmanaged hosts
Unknown does not always mean malicious, but it does mean untracked. That is the gap you need to close.
Example commands
subfinder -d example.com -silent -o subfinder.txt
amass enum -passive -d example.com -o amass-passive.txt
cat subfinder.txt amass-passive.txt | sort -u > all-passive.txt
Use commands like these only on domains you control or are authorized to assess.
Comparison of methods
| Approach |
Visibility |
Effort |
Best use case |
| Manual review |
Medium |
High |
Small environments, first audit |
| Free tools |
Medium to high |
Medium |
Budget-conscious teams |
| Automated scanner |
High |
Low after setup |
Ongoing discovery |
| Continuous monitoring |
Highest |
Lowest over time |
Mature attack surface management |
Continuous monitoring
One-time discovery is not enough. New subdomains appear when teams launch features, move vendors, or inherit assets through mergers and acquisitions. Continuous monitoring is what turns subdomain discovery into a real security process.
Monitor for:
New subdomains in CT logs.
DNS changes on existing records.
CNAME targets that stop resolving.
Certificates issued for unknown hosts.
Hosts that flip from live to dead.
Staging or beta domains that become public by accident.
A useful monitoring setup answers three questions:
If the answer is unclear, the change deserves review.
Monitoring turns discovery into an ongoing security process.
What good monitoring looks like
Good monitoring is not a pile of alerts. It is a lightweight pipeline that keeps your public asset inventory current and highlights real changes worth investigating.
A simple process looks like this:
Watch CT logs for new certificates tied to your domains.
Check DNS for new or changed records.
Compare new results with your asset inventory.
Route unknown hosts to the right owner.
Retire anything that no longer has a business purpose.
Best practices
If you want to reduce abandoned subdomains before they become a problem, make these habits part of your normal process:
Maintain a central subdomain inventory.
Assign an owner to every public hostname.
Remove DNS records when services are retired.
Separate production from test and staging domains.
Block indexing on non-production hosts.
Review CT logs on a schedule.
Monitor for dangling DNS records.
Include subdomains in change management.
Re-check old campaign and partner hostnames after projects end.
Tie new subdomain creation to a cleanup plan.
Rule of thumb
If nobody can explain why a subdomain exists, it should not stay public.
Example workflow for teams
A practical team workflow is simple:
A subdomain is created.
The owner is recorded.
The business purpose is documented.
The expected retirement date is added.
Cleanup is reviewed when the project ends.
That sounds basic, but most teams skip at least one of those steps.
Common mistakes
Teams usually make the same mistakes when handling forgotten subdomains:
Treating subdomains as low priority.
Assuming old DNS records are harmless.
Forgetting third-party decommissioning.
Ignoring wildcard DNS and false positives.
Scanning once and assuming the result is complete.
Leaving ownership unclear.
Not monitoring CT logs or DNS drift.
Keeping staging environments publicly exposed.
The biggest mistake is thinking a subdomain is safe just because it is old. Old does not mean inactive, and inactive does not mean unreachable.
Real-world scenarios
Scenario 1: Marketing campaign cleanup
A team launches promo.example.com for a product launch. The campaign ends, but the subdomain stays live with a form that still collects visitor data. That creates privacy and brand risk even if the page looks harmless.
Scenario 2: Retired third-party service
A company points support.example.com to a SaaS support platform. The platform is later canceled, but the DNS record remains. If the provider allows hostname reuse, that can become a takeover risk.
Scenario 3: Old staging environment
A staging.example.com host is left on an older stack with weak access controls. It may not contain production data, but it can still expose admin panels, internal notes, or debugging endpoints.
Scenario 4: Acquisition leftovers
After an acquisition, old subdomains from the acquired company remain online under the parent domain. Nobody tracks them because they were never folded into the main inventory. Attackers tend to look for exactly this kind of inherited exposure.
Practical examples
Example: Starting from one root domain
If you manage example.com, a simple first pass could look like this:
Review current DNS records.
Search CT logs for example.com.
Check historical DNS data.
Run passive subdomain enumeration.
Validate live hosts.
Compare results with your known inventory.
Investigate anything not owned by an active team.
Example: Cleaning up a campaign subdomain
A team creates summer2026.example.com for a seasonal campaign. When the campaign ends, the DNS record should either be removed or redirected to a permanent landing page. Leaving it live with no owner only increases the public footprint.
Checklist
Use this checklist during your next subdomain review:
Export all known DNS records.
Search CT logs for your root domain.
Query passive DNS sources.
Run search engine checks for indexed hostnames.
Brute-force common subdomain names.
Detect and filter wildcard DNS.
Validate every unknown hostname.
Identify dangling CNAMEs and stale A records.
Assign an owner to each public subdomain.
Remove records that no longer have a business purpose.
Add monitoring for new subdomains and DNS changes.
Re-scan after major releases, migrations, and acquisitions.
Summary
If you only scan for vulnerabilities on known apps, you will miss a lot of exposed infrastructure. The real first step is building a complete subdomain inventory, then keeping it current. That is the difference between a static list and a usable attack surface map.
FAQ
What is a forgotten subdomain?
A forgotten subdomain is a public hostname that still exists but no longer has active ownership or monitoring.
Why do companies forget subdomains?
They are often created quickly for projects, campaigns, tests, or integrations, then left behind when the work ends.
How do attackers discover abandoned subdomains?
They use certificate transparency logs, passive DNS, search engines, brute-force enumeration, and historical records.
What is the best way to find forgotten subdomains?
Use a combination of CT log review, passive DNS, search operators, DNS brute force, and continuous monitoring.
Which free tools help with subdomain discovery?
Common options include crt.sh, search engine operators, DNS lookup tools, and enumeration tools like Subfinder and Amass.
How often should subdomain enumeration be run?
For active environments, discovery should be continuous or scheduled regularly, not done only once a quarter.
What is the risk of a dangling DNS record?
A dangling DNS record can point to a removed service and create a subdomain takeover opportunity.
How does continuous monitoring help prevent subdomain takeover?
It alerts you when new hostnames appear or old ones stop resolving, so you can remove or reclaim them before they are abused.
Conclusion
To find forgotten subdomains, combine passive discovery, active enumeration, and continuous monitoring. That gives you the best chance of finding abandoned subdomains before they become takeover risks, phishing surfaces, or untracked internet-facing assets.
VeilScan can help you do that without living in spreadsheets or running one-off checks every month. Scan your domain, review your external attack surface, and keep monitoring for new subdomains before attackers find them first.
Try the Scanner | See Pricing
