Shadow IT and Forgotten Subdomains: Your Hidden Attack Surface

How do subdomains get forgotten?

Subdomains accumulate through the normal course of business. The problem isn’t that they’re created - it’s that they’re never decommissioned:

Project subdomains. A team creates project-alpha.example.com for a client demo. The project ends. The subdomain persists.

Staging and development environments. staging.example.com, dev.example.com, test-v2.example.com. Developers create them for testing, then move on. The environments keep running with their original (often weak) configurations.

Acquisitions and mergers. When a company acquires another, it inherits all of the acquired company’s subdomains, DNS records, and infrastructure. Integration teams focus on critical systems; secondary subdomains get overlooked.

Contractor and vendor deployments. External parties create subdomains for specific projects or integrations. When the engagement ends, the subdomains and their infrastructure remain.

Marketing and campaign sites. summer-sale.example.com, event2024.example.com, promo.example.com. Marketing creates them for campaigns, often through third-party platforms. The campaigns end; the subdomains persist.

Why does shadow IT expand the attack surface?

Shadow IT isn’t malicious - it’s a natural consequence of teams solving problems quickly. When a developer needs a monitoring dashboard, they deploy Grafana on monitoring.dev.example.com. When marketing needs a landing page, they use a page builder on lp.example.com. When operations needs a wiki, they set up one on wiki.internal.example.com.

Each of these creates DNS records, exposes services, and expands the attack surface. None of them appear in the official asset inventory.

The challenge is structural: creating a subdomain requires only DNS access (often delegated broadly), while the security review process is designed for known, planned deployments. Shadow IT bypasses the process not by intent but by speed.

What makes forgotten subdomains dangerous?

A forgotten subdomain combines the worst properties from a security perspective:

No patching. If nobody knows a service exists, nobody patches it. Forgotten WordPress installations, outdated Jenkins servers, and unpatched development tools accumulate vulnerabilities over months and years.

No monitoring. Security monitoring only covers known assets. A compromised forgotten subdomain generates no alerts because no alerts are configured.

Weak authentication. Development and staging environments are typically configured with convenience in mind - default passwords, no MFA, relaxed access controls. These configurations persist when the environments are forgotten.

Production data. Staging environments frequently connect to production databases or contain production data copies. A compromised staging subdomain can be a path to production data.

Trust inheritance. A subdomain of example.com inherits the parent domain’s reputation. Browsers, email systems, and users trust it by association. An attacker who compromises forgotten.example.com operates under your domain’s authority.

How do you discover forgotten subdomains?

Finding your own forgotten subdomains uses the same techniques attackers use - the difference is doing it first:

Certificate transparency logs. Query CT logs (crt.sh, Certstream) for every certificate ever issued for your domains. This reveals subdomains that obtained certificates - including internal services that use public CAs.

Passive DNS databases. Services like SecurityTrails and VirusTotal aggregate historical DNS data. They reveal subdomains that resolved in the past, even if they’ve changed or been removed since.

DNS brute-forcing. Test common subdomain names (admin, dev, staging, test, old, backup, vpn, monitor, grafana, jenkins, etc.) against your domains. Fast tools like Subfinder and MassDNS make this practical for large domain portfolios.

Cloud provider inventories. AWS Route 53, Azure DNS, and Google Cloud DNS provide authoritative zone listings. If your DNS is managed in the cloud, query the API for a complete record list.

How do you build a subdomain cleanup program?

Discovery is the first step. A systematic cleanup program turns one-time findings into sustained improvement:

1. Enumerate and baseline. Run a thorough subdomain enumeration for every domain your organisation owns. Document what you find.

2. Assign ownership. Every discovered subdomain needs an owner. If no one claims it, that’s a strong signal it should be decommissioned.

3. Triage by risk. Prioritise based on: internet accessibility, service type (admin panels and databases are highest risk), authentication status, and patch level.

4. Decommission or secure. For each finding: either remove the subdomain and its infrastructure, or bring it into the security program (patch it, restrict access, add monitoring).

5. Continuous monitoring. New subdomains will continue to appear. Automated discovery on at least a weekly cadence ensures they’re caught early.

6. Process improvement. Address the root causes: require security review for new DNS records, automate decommissioning checklists, restrict DNS modification access to reduce shadow IT creation.

Why does the risk from forgotten subdomains compound over time?

Forgotten subdomains are not a one-time problem. They accumulate over time, and each one increases the likelihood that an attacker finds an entry point. An organisation that hasn’t cleaned up its subdomains in years may have dozens or hundreds of unknown assets - each a potential foothold.

The good news: the fix is systematic and achievable. Discovery tools exist, the techniques are well-understood, and the remediation actions (decommission, patch, restrict access) are straightforward. The hard part is starting.