Managing subdomains is a normal part of modern IT and web infrastructure. But while subdomaining helps organize your services, misconfiguration or neglect can open serious security holes - even allowing attackers to take over parts of your domain.
The two main contexts of Subdomaining to understand are:
- Legitimate Subdomain Use
Creating subdomains like mail.example.com, shop.example.com,or dev.example.com is standard practice. It helps structure services under your main domain and improves manageability. This is normal and safe when managed properly.
- Subdomain Abuse or Misconfiguration (“Subdomain Takeover”)
This happens when a subdomain points to an external service (like AWS, GitHub Pages, or Azure) that no longer exists or isn’t under your control anymore. This is a serious security risk — attackers can seize control of that subdomain and use it to impersonate your brand.
When Subdomaining Becomes Risky
Subdomain takeover
DNS record (like a CNAME) points to a service that’s been deleted or isn’t owned anymore - attackers can claim it and host malicious content. 🔴 High Risk Level
Forgotten test/dev subdomains
Old development or staging environments left exposed with weak or default credentials. 🟠 Medium–High Risk Level
Wildcard subdomains (*.example.com)
Allowing automatic resolution of all subdomains can be abused for phishing or malware delivery. 🔴 High Risk Level
Unsecured or inconsistent SSL/TLS
A subdomain without HTTPS weakens your overall domain security posture. 🟠 Medium Risk Level
DNS sprawl / lack of inventory
Many subdomains spread across teams or services with no central control → increases attack surface. 🟠 Medium–High Risk Level
Third-party marketing or tracking subdomains
Delegated subdomains managed by vendors can be misused for spam or tracking. 🟠 Medium Risk Level
Real-World Example: A Subdomain Takeover in Action
Here’s a classic scenario:
1. You once hosted documentation at help.example.com using GitHub Pages.
2. Later, you delete the GitHub repo - but the DNS record help.example.com = example.github.io remains active.
3. An attacker creates a GitHub repo with the same name (example.github.io), and now your subdomain serves their content - under your brand and SSL certificate!
The result? Phishing, malware, or brand impersonation — all because of one forgotten DNS record.
How to Manage Subdomains Safely
Maintain an up-to-date inventory. Track every subdomain and its owner. Tools like amass, sublist3r, SecurityTrails, and Assetnote help automate discovery.
Scan regularly for orphaned DNS records. Find and remove CNAMEs pointing to decommissioned services.
Enforce DNS change control. Restrict who can create or modify DNS records. Implement approval workflows.
Use HTTPS everywhere. Ensure all subdomains have valid SSL/TLS certificates.
Apply CSP and HSTS policies. Mitigate injection and downgrade attacks.
Audit SaaS and third-party services. Remove unused integrations that generate subdomains.
Monitor DNS changes. Use monitoring tools (Detectify, Intrigue, or internal scripts) to detect unauthorised changes.
“Subdomaining” itself isn’t bad — in fact, it’s an essential part of organising digital infrastructure.
But uncontrolled or forgotten subdomains can become a major security risk, leading to:
- Subdomain takeovers
- Phishing and malware delivery
- Brand and trust damage
Regular audits, DNS hygiene, and centralised control are key to keeping your domain (and reputation) secure. Want to find out more or talk to people that 'get it'. Get in touch with us now!
