الاستيلاء على نطاق فرعي

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.

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.

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.

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.