# How to Find Forgotten Subdomains Before Attackers Do (2026 Guide)

# 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](#key-takeaways)
    
*   [What forgotten subdomains are](#what-forgotten-subdomains-are)
    
*   [Why teams lose track of them](#why-teams-lose-track-of-them)
    
*   [Why attackers care](#why-attackers-care)
    
*   [How attackers find them](#how-attackers-find-them)
    
*   [How to find them manually](#how-to-find-them-manually)
    
*   [Free tools and automated methods](#free-tools-and-automated-methods)
    
*   [Continuous monitoring](#continuous-monitoring)
    
*   [Best practices](#best-practices)
    
*   [Common mistakes](#common-mistakes)
    
*   [Real-world scenarios](#real-world-scenarios)
    
*   [Checklist](#checklist)
    
*   [Summary](#summary)
    
*   [FAQ](#faq)
    
*   [Conclusion](#conclusion)
    

## 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

1.  Pull subdomains from CT logs.
    
2.  Cross-check passive DNS and archived records.
    
3.  Brute-force common names like `dev`, `test`, `staging`, and `backup`.
    
4.  Filter out wildcard DNS false positives.
    
5.  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:

*   DNS zone files.
    
*   Cloud DNS records.
    
*   Certificates issued for your domain.
    
*   Internal asset lists.
    
*   Records inherited from acquisitions or older product lines.
    

Then sort them into:

*   Active production hosts.
    
*   Staging and test environments.
    
*   Vendor-owned subdomains.
    
*   Unknown entries.
    

### 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:

*   `crt.sh`
    
*   Cert Spotter
    
*   Security tools that surface CT data
    

### 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:

*   Does it resolve?
    
*   Who owns it?
    
*   Is it publicly reachable?
    
*   Is it still needed?
    
*   Does it point to a service you control?
    

If you cannot answer those questions quickly, the hostname needs review.

## Free tools and automated methods

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

```bash
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:

*   What changed?
    
*   Who owns it?
    
*   Is it supposed to be public?
    

If the answer is unclear, the change deserves review.

![Dashboard showing subdomain monitoring and DNS change alerts.](attack-surface-monitoring.webp align="center")

*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:

1.  Watch CT logs for new certificates tied to your domains.
    
2.  Check DNS for new or changed records.
    
3.  Compare new results with your asset inventory.
    
4.  Route unknown hosts to the right owner.
    
5.  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:

1.  Review current DNS records.
    
2.  Search CT logs for `example.com`.
    
3.  Check historical DNS data.
    
4.  Run passive subdomain enumeration.
    
5.  Validate live hosts.
    
6.  Compare results with your known inventory.
    
7.  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](https://veilscan.net) | [See Pricing](https://veilscan.net/pricing)