← All posts

Subdomain takeovers are embarrassing and also inevitable

The cleanest web attack you can run takes about fifteen minutes, requires zero skill, and uses your own DNS against you. Here is why it keeps happening to otherwise careful businesses, and how I find them during scope calls.

In June 2019, Check Point Research and CyberInt disclosed that Electronic Arts had a CNAME on eaplayinvite.ea.com pointing at ea-invite-reg.azurewebsites.net, an Azure web app EA had long stopped using. The researchers registered the abandoned Azure name on their own tenant, served whatever they wanted from eaplayinvite.ea.com, and chained it through EA's SSO flow into an account-takeover on up to 300 million Origin players. The cert was valid. The domain was EA's. The brand halo and the SSO trust were theirs for the asking until they reported it.

EA had budget and a security team. What they didn't have was anyone watching the CNAMEs for azurewebsites.net targets that had stopped resolving. If it can happen to them, it will happen to a small business the instant a marketing contractor cancels an Unbounce subscription.

This is a subdomain takeover. It's the closest thing web security has to a magic trick. No exploit. No brute force. You just sign up for a service that accepts the name you already own, and you own the subdomain.

Why this keeps happening

Every modern business shops at cloud and SaaS for convenience. Marketing spins up a landing page on Unbounce, points a CNAME, runs the campaign, gets busy with the next one. Six months later the Unbounce subscription lapses. The CNAME stays. Nobody thinks about DNS hygiene because it's not anybody's job.

The vulnerable services change every year as vendors tighten up. GitHub Pages used to be the poster child. Heroku cleaned theirs up around 2022. Elastic Beanstalk, S3 static sites with missing buckets, Shopify custom domains that were never claimed, Netlify sites whose team got deleted. There's always some new one. can-i-take-over-xyz on GitHub is the community bible. Check it against your own CNAMEs once a quarter.

How I find them

The recipe for anyone to do this on their own domain: pull every DNS record from every zone you control. Grep for CNAMEs. For each CNAME target, resolve it and look at what comes back. A target that doesn't resolve, or resolves to an error page from a known service, is suspect. Then check if the service lets anyone claim the hostname without DNS proof at sign-up time.

Tools make this faster. I use a combination of amass for enumeration, a script that pulls the CNAMEs, and dnsReaper or Nuclei's takeover templates for the detection. AttackEdge does this on every scan because the manual version gets tedious at scale. But the first time you run it against a domain you've owned for years, do it by hand. You'll learn more.

How to fix what you find

Delete the dangling record. That's the fix. If you still need the service, re-sign up with the same name immediately, but do not leave the DNS record pointing at an unclaimed target while you shop around.

And then do the preventative version. Add DNS cleanup to your off-boarding process every time you cancel a SaaS tool, retire a marketing campaign, or move hosting. A checkbox that says "did we remove the DNS record" on the cancellation ticket would have saved that healthcare company their embarrassment. Not my embarrassment. They kept me on.

If you haven't checked your DNS for this in the last six months, you almost certainly have at least one dangling record. The free check will surface the obvious ones. The weird ones need a paid scan and a human looking at the output, which is what AttackEdge is.