Your Forgotten Subdomain Is Someone Else's Phishing Page
Delete the service, keep the DNS record, and anyone can register the target and serve content on your domain. One record, full brand trust.
Enumerate every CNAME, resolve each, and check for provider-specific responses like NXDOMAIN or NoSuchBucket. A dangling record to S3, CloudFront, Heroku or GitHub Pages means anyone can claim your subdomain and serve content under your name.
A team deploys staging on Heroku, creates staging.company.com pointing at the app, then decommissions the app. The DNS record stays. Heroku frees the app name. An attacker registers the same app name on Heroku, and now staging.company.com serves their content, with a certificate Heroku issues for your domain.
In This Guide
The mechanism
The check
If it stays
Get the skill
4 Tips to Get Started
crt.sh lists every certificate ever issued for your domain: that is your subdomain map.
S3 returns NoSuchBucket, Azure returns 404 with a specific body, GitHub Pages returns 404 with its footer. Each is a fingerprint.
The fix is one DNS deletion. The risk is that the record is in Terraform nobody owns anymore.
Check after every service decommission. The record outlives the service by default.
Ready to Stop Worrying About Infra?
Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.
Related Guides
Is My S3 Bucket Public? How to Check in One Command
One command tells you if your S3 bucket is public, and one curl proves it. The policy check shows intent, the anonymous request shows reality.
The Most Common AWS Misconfiguration (It Is One Line of Config)
Public buckets and Principal * policies cause most disclosed AWS incidents. Each is one line of config with account-wide blast radius. Here is the pattern.
Terraform State File Leak: Every Secret in Plaintext
terraform.tfstate stores database passwords, IAM keys and TLS private keys in plaintext. sensitive=true hides nothing. Here is how leaks happen and the check.
Docker Socket Mounted in a Container: Root on the Host, No Exploit Needed
A container with /var/run/docker.sock mounted controls the host daemon and can mount your entire filesystem. No kernel exploit required. Here is the mechanism and the check.
Ron Cohen — DevOps engineer & founder, roqy.io
Content reviewed by the roqy.io team. Our guides are based on publicly available data.
Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.
Frequently Asked Questions
What is a dangling CNAME and subdomain takeover?
A DNS record pointing to a service that was deleted. Anyone can register that service name and serve content on your subdomain, with your brand and your cookies. Attackers use it for phishing that passes every trust check, because the page really is on your domain.
How do I check for subdomain takeover?
Enumerate subdomains from crt.sh and DNS, resolve every CNAME, and check the target's response. S3 answers NoSuchBucket, Heroku answers no-such-app, GitHub Pages answers with a 404 page. Each fingerprint means the record is claimable. The fix is deleting the DNS record.
Why is subdomain takeover dangerous?
The attacker serves content on your actual domain, with a valid TLS certificate for it. Phishing from your domain bypasses brand trust, email filters and user suspicion. It can also set cookies on your parent domain, which turns takeover into session theft.
Get the DevOps Ecosystem Behind You
One accountable engineer. Full platform behind him. Month-to-month, no lock-in.