Exposed Subdomains: How to Find and Fix Them

Most organisations have more subdomains than their security team can name. Marketing spins up a campaign microsite, a developer publishes a staging environment, a vendor hosts a portal on your domain, and each one quietly becomes part of your attack surface. Attackers know this, and subdomain enumeration is almost always the first step in external reconnaissance.

This guide explains why exposed subdomains are dangerous, how to find the ones you have forgotten, and what to do about them.

Why exposed subdomains are a problem

A subdomain is exposed when it is reachable from the internet but no longer properly maintained, monitored, or secured. The risks fall into a few categories:

• Subdomain takeover. When a subdomain points (via a CNAME) to a third-party service that has been de-provisioned, an attacker can claim that service and serve content from your domain. This is devastating for phishing because the URL is genuinely yours.
• Forgotten applications. Old staging sites and legacy apps run outdated software with unpatched vulnerabilities. They rarely get the same scrutiny as production.
• Information disclosure. Development environments leak API keys, internal hostnames, and debug endpoints that help an attacker map the rest of your estate.

How attackers find your subdomains

Adversaries combine several techniques: certificate transparency logs (every TLS certificate you issue is publicly logged), passive DNS datasets, search engine scraping, and brute-force resolution against common names like `dev`, `staging`, `vpn`, and `mail`. None of this touches your infrastructure in a way you would notice, which is exactly why it is so effective.

How to discover your own subdomains

To defend the surface, you have to see it the way an attacker does:

1. Enumerate from public sources first. Certificate transparency, passive DNS, and search indexes give you a baseline without sending a single packet to your own servers.
2. Resolve and probe. For each candidate, check whether it resolves, what it points to, and what is listening.
3. Flag dangling records. Any CNAME pointing to an unclaimed third-party service is an immediate takeover risk.
4. Do it continuously. A one-off scan is out of date the moment a new subdomain appears. New assets are created every week.

How to fix exposed subdomains

• Remove dangling DNS records the moment a service is decommissioned. This single habit eliminates most takeover risk.
• Decommission forgotten apps or move them behind authentication and patch them like production.
• Centralise DNS ownership so subdomains cannot be created without security visibility.
• Monitor certificate transparency so you learn about new subdomains as certificates are issued, not months later.

Where ScruteX fits

ScruteX continuously discovers the subdomains attributable to your domain, fingerprints what is running on each, and flags dangling records and takeover-prone configurations before someone else finds them. It is the discovery and prioritisation half of a CTEM programme, running from the outside-in with no agents to deploy.

You can see your own exposed subdomains in minutes — add your domain and the first findings appear in your free dashboard.