The hook
Subdomain takeover is the rare class of bug that costs zero dollars to find and zero dollars to exploit, and gives the attacker your domain's reputation. The pattern: a marketing campaign in 2022 used `promo-summer.yourdomain.com` pointing at a Heroku app. The campaign ended; someone deleted the Heroku app. Nobody deleted the DNS CNAME. Two years later, the CNAME still resolves — Heroku just returns a 404 'no such app' page. An attacker creates a new Heroku app named `promo-summer`, claims the dangling CNAME, and now serves any content they want from `promo-summer.yourdomain.com` with a valid TLS cert (Heroku auto-provisions one). Phishing pages, malware downloads, fake login portals — all hosted on your real domain.
Otú ọ si arụ ọrụ
Cloud services let you point a CNAME at them and serve content from a name they assign. When you delete the resource on the cloud side but leave the DNS record, the cloud responds with a recognizable error pattern (a 404 page, a 'no such app' message, an 'NoSuchBucket' XML response). The takeover candidate list includes most cloud and SaaS services that issue per-tenant subdomains: AWS S3 (`*.s3.amazonaws.com`), Heroku (`*.herokuapp.com`), Netlify (`*.netlify.app`), Vercel (`*.vercel.app`), GitHub Pages (`*.github.io`), Shopify (`*.myshopify.com`), Tumblr, Zendesk, Webflow, and dozens more. Each has a distinct error fingerprint when the underlying resource is gone — that's how scanners detect takeover candidates.
The variants
Cloud-provider takeover
CNAME points at AWS S3 / Heroku / Netlify / Vercel / GitHub Pages. Attacker provisions a new resource with the same name. Most common shape; trivial to exploit.
SaaS takeover
CNAME points at a SaaS support tool (Zendesk, Helpscout, Intercom). Attacker signs up for a free account with the same subdomain claim and serves their content.
Wildcard-cert takeover
Attacker who claims one subdomain on a domain with a wildcard TLS cert can sometimes intercept other subdomains via certificate-authority issuance abuse.
Lame-delegation takeover
DNS NS records delegate to a nameserver that no longer hosts the zone. Attacker registers the abandoned hosting account and answers queries.
The blast radius
Phishing pages on `yourdomain.com` — bypassing every browser warning, every URL-trust heuristic, every customer expectation that 'links from yourdomain.com are safe.' Eats your domain's deliverability reputation when phishing campaigns get reported. Cookie-scope abuse when the parent domain shares cookies (Domain=`.yourdomain.com`) with the takeover-candidate subdomain — attacker can read those cookies. Stored-XSS-style impact when attacker JavaScript on the subdomain has cookie access for the parent. Brand damage and customer trust loss compound the technical impact.
// what fixvibe checks
What FixVibe checks
FixVibe checks DNS and takeover risk with non-destructive ownership, resolution, and service-state signals. Reports show the risky host or record and the cleanup path. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
Delete DNS records when you decommission cloud resources. Make 'remove DNS' part of every decommission runbook. Audit subdomain DNS regularly — `dig` your full zone, list every CNAME, verify each target resolves to a resource you control. Tools like `subjack`, `subzy`, and `nuclei` automate the check; bake one into your security CI on a weekly cadence. For wildcard-cert risk, prefer per-subdomain certs over wildcards where possible (Let's Encrypt makes this cheap). Monitor certificate transparency logs for new certs issued for your domain — services like Cert Spotter or crt.sh's monitoring API alert on unexpected issuance. As a structural defense, prefer using your apex domain or a small set of canonical subdomains rather than spinning up per-campaign or per-environment subdomains; fewer DNS records means fewer abandoned ones to take over.