Subdomains: the hidden attack surface
Every organization has more subdomains than it realizes. Beyond the classic www, mail, ftp, there are subdomains for development environments (dev, staging, test), APIs (api, api-v2), administration panels (admin, panel, cpanel), internal services (jira, confluence, gitlab), and cloud services (app, cdn, assets). Each of these represents a potential entry point for an attacker. The Subdomain Finder automates the discovery of these subdomains, providing a complete map of the domain's perimeter.
The subdomain security problem is worsened by "shadow IT": services created by different teams, often forgotten after the testing phase, that remain exposed on the Internet without security updates, without monitoring, and sometimes with default credentials. A forgotten subdomain like staging.example.com with a vulnerable version of the CMS is a gift to any attacker. The first defense is awareness: knowing which subdomains exist.
Subdomain enumeration techniques
The Subdomain Finder uses multiple sources: Certificate Transparency Logs (public registries of all issued SSL certificates, which contain the covered hostnames), DNS brute-force with wordlists (querying thousands of common names), analysis of existing DNS records (NS, MX, TXT often contain references to subdomains), and other OSINT sources. The combination of multiple techniques maximizes coverage.
What to do with discovered subdomains
Once you have the list, each subdomain should be analyzed. Check the SSL certificate with SSL Check — subdomains without HTTPS or with expired certificates are a red flag. Check security headers with Security Headers to identify weak configurations. Look for subdomains that resolve to private IPs (10.x, 172.16-31.x, 192.168.x) indicating misconfiguration, and orphaned CNAMEs pointing to decommissioned services (subdomain takeover risk).
Subdomain takeover is a particularly serious risk: if a CNAME points to a cloud service (e.g., something.azurewebsites.net) that is no longer active, an attacker can claim that hostname on the cloud provider and serve arbitrary content on your subdomain. This enables credible phishing, malware distribution, and domain reputation compromise. Prevention is simple: remove DNS records for subdomains no longer in use.
For a complete perimeter security audit, combine the Subdomain Finder with a systematic scan of every discovered subdomain. Document each subdomain with its purpose, responsible person, and date of last use. This continuous perimeter mapping is a fundamental component of any security program, and Domain Health can provide a consolidated report on the overall health of the domain and its dependencies.