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

• What forgotten subdomains are

• Why teams lose track of them

• Why attackers care

• How attackers find them

• How to find them manually

• Free tools and automated methods

• Continuous monitoring

• Best practices

• Common mistakes

• Real-world scenarios

• Checklist

• Summary

• FAQ

• 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.

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

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.

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 | See Pricing

Most small and medium-sized businesses assume they are not interesting targets for hackers. They are wrong. Attackers don’t hand-pick victims based on company size or brand recognition — they run automated scanners across the entire internet, looking for anything exposed and exploitable. If your business has a public-facing server, a forgotten subdomain, an open cloud storage bucket, or an employee-facing login portal, those scanners will find it.

Attack Surface Management (ASM) addresses exactly this problem. It is one of the most practical security concepts to emerge in recent years. While ASM has historically been associated with large enterprises, the core idea applies just as much to a 20-person SaaS startup or a regional financial services firm. This article explains what ASM is, why SMBs are particularly vulnerable, what attackers are looking for, how ASM works in practice, and what SMBs can do today without needing a dedicated security team.

What is Attack Surface Management (ASM)?

ASM is the continuous process of discovering, inventorying, assessing, and monitoring everything about your organization that’s visible or accessible from the internet — and then prioritizing and remediating the most significant exposures. Key goals:

• Discover all external-facing assets (known and unknown).

• Continuously monitor for new exposures and configuration drift.

• Contextualize findings so you can prioritize real risks instead of noisy alerts.

• Provide remediation guidance and integrate with existing workflows (tickets, CI/CD, ITSM).

ASM is broader than a one-off vulnerability scan. It focuses on visibility and context across the external attack surface and keeps tracking it over time.

What Is an Attack Surface?

Your attack surface is everything about your organization that is visible and reachable from the internet. That includes assets you know about and — critically — assets you have forgotten or never knew existed. The external attack surface specifically refers to internet-facing components attackers can discover and interact with.

Common external attack surface components:

• Domain names and subdomains (active, abandoned, and wildcard entries)

• Web applications, admin panels, and APIs

• Cloud infrastructure (storage buckets, compute instances, IAM policies)

• Publicly exposed databases and services (e.g., misconfigured MongoDB, Redis)

• Certificates and certificate transparency/logs

• DNS records and email infrastructure (MX, SPF, DKIM)

• Source code and configuration files in public repositories

• CI/CD endpoints and build artifacts

• Third-party services, vendor integrations, and partner portals

• Remote access services (VPN, RDP, SSH) and exposed ports

• Shadow IT (employee-created SaaS accounts, forgotten VMs)

Why SMBs Are Particularly Vulnerable

• Limited security staff and expertise: SMBs often lack dedicated security teams and rely on general IT resources.

• Configuration and patching gaps: Lean teams and fast product cycles lead to misconfigurations and delayed patching.

• SaaS & cloud complexity: Using many SaaS vendors and cloud services increases the chance of overlooked settings or leaked credentials.

• Automated, opportunistic attackers: Attackers run broad scans and exploit the lowest-hanging fruit — size doesn’t matter.

• Third-party risk: Vulnerabilities in vendors and integrations can cascade to your environment.

• Credential reuse and weak controls: Reused passwords, missing MFA, and exposed API keys are easy entry points.

• Forgotten assets: Old domains, staging sites, and test buckets often remain exposed and unattended.

What Attackers Look For

• Exposed admin panels, dashboards, and debug endpoints

• Default or weak credentials and exposed SSH/RDP access

• Unpatched software with known CVEs

• Open cloud storage buckets and misconfigured object ACLs

• Public databases and management consoles

• API keys, secrets, or configuration files in public repos

• Misconfigured CORS or overly permissive cross-origin settings

• Duplicate or abandoned domains prone to subdomain takeover

• Expired or misissued TLS certificates

• Misconfigured DNS records that enable redirection or takeover

How ASM Works in Practice

ASM typically follows these phases:

1. Discovery

   • Passive discovery: certificate transparency logs, public datasets, DNS records, public code, certificate registries.

   • Active discovery: internet scans for open ports, services, and endpoints.

2. Fingerprinting and Classification

   • Identify asset types (web app, API, storage bucket), technologies, and ownership.

3. Risk Scoring and Prioritization

   • Assess exposure impact, exploitability, and business context to rank findings.

4. Validation and Enrichment

   • Reduce false positives with validation checks (active probes, HTTP responses, authentication requirements).

5. Alerting & Remediation Guidance

   • Provide clear remediation steps and integrate alerts into ticketing/ITSM workflows.

6. Continuous Monitoring

   • Track changes over time, detect new exposures, and alert on suspicious activity.

7. Integration

   • Feed ASM findings into vulnerability management, incident response, and developer workflows (CI/CD) for faster fixes.

ASM is complementary to vulnerability scanners, penetration testing, and endpoint defenses. ASM gives visibility and context for external exposure; other tools dig deeper into internal vulnerabilities and exploitability.

Practical Steps SMBs Can Take Today (No Dedicated Security Team Required)

Immediate (first 24–72 hours)

• Inventory domains and subdomains: audit DNS, registrar accounts, and internal records.

• Enable MFA on all admin, cloud, and critical accounts.

• Rotate and revoke exposed keys and credentials found in public repos.

• Check cloud storage buckets for public access and lock them down.

• Close unused ports and disable remote access protocols (RDP/SSH) that aren’t needed.

Short term (2–6 weeks)

• Run an external scan to discover internet-facing assets (use reputable free or low-cost tools).

• Audit SaaS and third-party vendor access; remove unused integrations and enforce least privilege.

• Harden publicly facing apps: apply security headers, rate limits, and basic WAF rules.

• Set up certificate monitoring (watch for new or expiring certs) and DNS monitoring.

• Establish a simple playbook for responding to exposed secrets or data leaks.

Medium term (3–6 months)

• Adopt a lightweight ASM or managed service (many offer SMB plans) to automate discovery and monitoring.

• Integrate ASM alerts into your existing ticketing or IT workflow.

• Start periodic external penetration tests or vulnerability assessments.

• Implement role-based access control and regular IAM reviews for cloud services.

• Establish logging and retention for critical services; centralize alerts.

Operational best practices (ongoing)

• Maintain an up-to-date external asset inventory.

• Use a password manager and enforce unique passwords and MFA for staff.

• Keep software and dependencies patched; subscribe to vendor security advisories.

• Train staff on phishing and basic security hygiene.

• Plan and test simple incident response steps (containment, communication, recovery).

Quick SMB ASM Checklist

• Audit DNS records, domains, and subdomains

• Lock down cloud buckets and storage permissions

• Enforce MFA across all admin and cloud accounts

• Revoke exposed API keys and rotate secrets

• Monitor certificate transparency logs and DNS changes

• Run external scans and validate findings

• Implement least privilege for SaaS and cloud services

• Subscribe to a lightweight ASM product or managed offering

• Integrate ASM findings into ticketing and remediation workflows

• Train staff and document basic incident response steps

Conclusion

ASM is not just for big enterprises. For SMBs, it’s a practical, cost-effective approach to reduce the most common and damaging exposures that automated attackers find first. Start small: inventory what you have, close obvious gaps, and adopt continuous monitoring. Over time, ASM will help you move from reactive firefighting to proactive risk reduction — with measurable benefits for security and business resilience.