Subdomain takeover is one of the most underestimated SSL security risks organizations face today. While most teams focus on certificate expiration alerts and HTTPS configuration, forgotten or misconfigured subdomains can quietly become entry points for attackers – complete with valid SSL certificates that make them look entirely legitimate.
What Subdomain Takeover Actually Means
A subdomain takeover happens when an attacker gains control of a DNS subdomain that still points to an external service you no longer use. Common examples include old staging environments pointing to cloud services, marketing microsites pointing to decommissioned CDN endpoints, or feature branches pointing to platforms like Heroku, GitHub Pages, or AWS S3 buckets that have since been deleted.
The subdomain itself remains in DNS. The external service slot becomes available. An attacker registers that slot, claims the subdomain, and suddenly controls traffic meant for your organization.
Why SSL Makes the Threat Far More Dangerous
Once an attacker controls a subdomain, nothing stops them from obtaining a valid DV (domain-validated) SSL certificate for it. Certificate Authorities issue DV certificates to anyone who can demonstrate control over a domain – and an attacker who has taken over staging.yourdomain.com can pass that validation check without difficulty.
The result is a subdomain with a valid HTTPS padlock, a certificate signed by a trusted CA, and no visible browser warnings. Visitors – or automated API clients – have no obvious signal that something is wrong. Phishing pages, credential harvesting forms, and API interception endpoints can all operate under a certificate that looks entirely legitimate.
Recognizing the Attack Surface
The typical attack surface is larger than most teams expect. A mid-sized organization that has been running for several years might have dozens of subdomains pointing at services that were provisioned, used briefly, and forgotten. Marketing campaigns, A/B testing tools, third-party integrations, developer playgrounds – each one is a potential dangling DNS record.
The risk compounds in organizations where DNS changes don’t require the same review cycle as application deployments. A developer spins up a preview environment, finishes the project, deletes the cloud resource – but the DNS record stays because DNS cleanup is nobody’s explicit responsibility. Three months later, the subdomain is available for anyone to claim.
The Misconception That Browsers Will Warn Users
Many security teams assume that a subdomain takeover will trigger browser warnings or SSL errors that alert visitors. This is wrong. An attacker who obtains a fresh DV certificate for the hijacked subdomain presents a fully valid TLS handshake. The certificate is signed by a legitimate CA. The browser shows a padlock. No warnings appear.
The misconception stems from conflating certificate errors – expired cert, mismatched domain, self-signed – with certificate legitimacy. A certificate can be technically valid while being issued to the wrong party entirely. This distinction is critical, and it is why monitoring Certificate Transparency logs matters: CT logs record every certificate issued for a domain, and an unexpected new certificate for a subdomain is a reliable early-warning signal.
How Certificate Transparency Exposes Takeovers Early
Every trusted SSL certificate is logged in public Certificate Transparency (CT) ledgers. These logs are append-only and publicly queryable. When an attacker issues a certificate for a hijacked subdomain, that issuance appears in CT logs within minutes of the request being processed.
Monitoring CT logs for unexpected certificate issuance across your subdomain space is one of the most effective detection mechanisms available. An alert on a new certificate issued for a subdomain you don’t recognize – especially from a CA you haven’t previously used – gives you a window to act before the attacker’s infrastructure is fully operational. Tracking certificate issuer changes closes this gap directly: if staging.yourdomain.com has always used one CA and suddenly a certificate from a different issuer appears, that is a flag worth investigating immediately.
Practical Steps to Reduce Your Exposure
Audit your DNS records regularly. Export your full DNS zone and compare every record against services you actively maintain. Pay particular attention to CNAME records pointing at third-party platforms – these are the most common source of dangling DNS entries.
Delete DNS records before decommissioning services. The order matters: remove the DNS entry first, then delete the cloud resource. Doing it in reverse leaves a window – sometimes hours, sometimes longer – where the subdomain is live but the backing service is gone.
Monitor certificate issuance across all your subdomains. Automated SSL monitoring that watches CT logs and alerts on new or unexpected certificate issuance covers this without manual overhead. Checking only your known active certificates is not enough.
Review wildcard certificate scope carefully. Wildcard certificates covering *.yourdomain.com don’t directly cause subdomain takeover, but they can obscure which subdomains are in active use. A subdomain inventory is harder to maintain when everything is covered under one certificate.
Apply HSTS subdomain policies deliberately. Including subdomains via the includeSubDomains directive reduces some attack vectors but means any subdomain issue can affect the entire domain. This trade-off deserves deliberate evaluation rather than a blanket policy.
If you discover a certificate was already issued during a takeover window, having a clear response process is essential. Understanding certificate revocation options helps teams respond quickly and limit the damage after unauthorized issuance is confirmed.
Frequently Asked Questions
Can subdomain takeover happen even if I enforce HTTPS across my site?
Yes. HTTPS enforcement on your main site doesn’t prevent an attacker from obtaining their own valid certificate for a dangling subdomain. Each subdomain can have its own certificate issued independently, and DV certificates require only DNS or HTTP control to obtain – no relationship to your existing certificate setup is needed.
How quickly can an attacker get an SSL certificate after taking over a subdomain?
With ACME-based automation, an attacker can obtain a valid DV certificate within minutes of claiming a cloud resource slot that your DNS still points to. Let’s Encrypt and other free CAs support fully automated issuance with no human review. The window between takeover and a fully operational HTTPS site can be under 30 minutes in practice.
Does removing the dangling DNS record fully resolve the problem?
It removes the attack surface going forward, but it doesn’t revoke any certificate already issued during the window. If an attacker obtained a certificate while the subdomain was hijacked, that certificate remains valid until it expires or is explicitly revoked. This is why monitoring certificate issuance matters even after remediation – you need to know whether a certificate was issued before you reclaimed control.
Treating Subdomain Hygiene as Part of SSL Security
Subdomain takeover sits at the intersection of DNS hygiene and SSL security – two areas that are often managed by different teams, with gaps between them. The combination of forgotten DNS records and freely available DV certificates turns what looks like a minor cleanup task into a genuine phishing and interception risk.
The defense is not complex. A disciplined DNS record lifecycle, regular subdomain audits, and automated monitoring of Certificate Transparency logs provide visibility before an attacker can establish a foothold. Treating SSL monitoring as covering only your known active certificates misses the threat entirely; watching for unexpected certificate issuance across your full subdomain space is where the real protection lives.