Subdomain Takeover Attacks: What They Are and How to Stop Them

What is a subdomain takeover attack?

A subdomain takeover attack is a DNS-to-application lifecycle failure. The DNS record remains live (often a CNAME), but the cloud app, SaaS site, storage endpoint, or load balancer it points to has been deleted. If the target namespace can be re-claimed, an attacker can bind your subdomain to their infrastructure.

Why this risk is severe

• Brand trust abuse: victims see a legitimate company subdomain in the browser address bar.
• Credential phishing: attacker-controlled pages can mimic SSO, help desk, or HR workflows.
• Session and token theft: some ecosystems incorrectly trust sibling subdomains.
• Malware staging: trusted hostnames can help payload delivery bypass naive filters.

How subdomain takeovers happen

1. Teams create a subdomain for a temporary campaign, support portal, or dev environment.
2. The external service is removed or expires during cleanup.
3. The DNS record is never removed from the zone.
4. An attacker detects the dangling target and claims the reusable namespace.
5. The attacker serves content at your subdomain with your brand credibility.

Real-world signal: university websites serving malicious content

In April 2026, Ars Technica reported multiple top university websites serving pornographic content because of abandoned DNS/application mappings and weak housekeeping practices. Treat this as a governance and inventory problem, not just a DNS syntax problem.

Source: Ars Technica — Why are top university websites serving porn? It comes down to shoddy housekeeping.

How to detect takeover exposure

• Continuously inventory subdomains and CNAME chains.
• Look for provider error fingerprints (for example, unconfigured app or missing bucket banners).
• Cross-check DNS targets against currently provisioned assets in cloud/SaaS accounts.
• Prioritize externally reachable subdomains used in login, support, and partner workflows.
• Track ownership and expiry dates for third-party services tied to DNS aliases.

How to prevent subdomain takeover attacks

• Deprovisioning runbooks: deleting an app must include DNS cleanup as a required step.
• Automated drift checks: alert on records pointing to missing assets.
• DNS change ownership: assign service owners and review stale aliases monthly.
• Service templates: enforce one-click teardown that removes both app resources and DNS records.
• Incident SLAs: treat confirmed dangling takeover paths as critical security issues.

Operator checklist

• Export all CNAME records for each production zone.
• Verify each target still maps to an owned, active resource.
• Remove or replace stale aliases immediately.
• Re-test affected hostnames from multiple recursive resolvers after TTL expiry.
• Document root cause and patch lifecycle controls to prevent recurrence.