Subdomain takeover: el subdominio olvidado que se vuelve puerta de entrada

promo.yourcompany.com was spun up in 2022 for a Black Friday campaign. Deployed to Heroku, ran for a month, then everyone forgot about it. In 2023, the team killed the Heroku app — but nobody removed the CNAME in DNS.

Today, the DNS record still says "promo.yourcompany.com → yourcompany-promo.herokuapp.com". Except that Heroku name is available again. Anyone can create an app with that exact name and, within seconds, promo.yourcompany.com serves their content.

That's a subdomain takeover. Cheap to pull off, devastating to suffer.

Why this works

DNS points to cloud services by name, not IP. When you create a Heroku app, it gives you my-cool-app.herokuapp.com. You add a CNAME promo.yourcompany.com → my-cool-app.herokuapp.com. Everything works.

When you delete the app, the name my-cool-app.herokuapp.com returns to the available pool. Whoever registers first owns it. The CNAME in your DNS keeps pointing there — now out of your control.

Same pattern in:

• AWS S3 (bucket-name.s3.amazonaws.com)
• GitHub Pages (user.github.io)
• Azure (*.azurewebsites.net, *.cloudapp.net)
• Vercel (*.vercel.app)
• Netlify (*.netlify.app)
• Fastly, Surge, Bitbucket, Tumblr, Shopify, Zendesk, Statuspage, Helpscout, Mailgun...

The list is huge. Every "pick a unique name" service plus DNS-by-name is vulnerable.

What the attacker does next

It's not just "embarrassing site online". It's much worse:

1. Phishing signed with your brand. Customer gets an email "update your password", link points to promo.yourcompany.com/login, looks legit (valid HTTPS, your domain). Phishing conversion spikes.
2. Cookie theft. If the parent domain yourcompany.com sets cookies with Domain=.yourcompany.com, the compromised subdomain reads those cookies. Customer sessions leak.
3. CORS bypass. Your API allows CORS for *.yourcompany.com. Now the attacker has a whitelisted origin to call your API straight from the victim's browser.
4. SEO abuse. Attacker hosts malicious content, builds backlinks in forums, pollutes your brand search ranking.
5. Malware distribution. A domain with positive reputation delivers payloads that corporate filters wave through.

How to find out if you have it

Manually

1. List every subdomain your company has. Active lookup:

   dig +short any yourcompany.com
   

   Passive discovery via Certificate Transparency:

   https://crt.sh/?q=%25.yourcompany.com
   

   crt.sh shows every SSL certificate ever issued under your tree — including forgotten subdomains you didn't know existed.

2. For each one, check the CNAME:

   dig CNAME promo.yourcompany.com
   

3. Visit the destination. If the response is "No such app", "There isn't a GitHub Pages site here", "Repository not found", "NoSuchBucket", "404 Not Found · The requested URL was not found on this server", you have a takeover candidate.

Classic fingerprints by provider

Spotted one on your domain? Delete the CNAME today.

The fix is free and simple

Not a patch. Not a WAF. Not a firewall. Just removing the orphan DNS record.

• Subdomain no longer used: delete the CNAME.
• Still used: make sure the destination is yours again (reactivate the Heroku app, recreate the S3 bucket, etc.).
• Set a process: service decommissioning must include "remove DNS" in the checklist. Almost nobody does this.

The problem is nobody's looking

The average mid-size company has 50–300 subdomains. Nobody maintains an up-to-date inventory. Marketing spawns promo, lp, quiz, events. Product spawns staging, qa, legacy. HR spawns careers. All scattered.

Real defense is continuous discovery + fingerprint monitoring:

1. List new subdomains every night (DNS + CT logs).
2. For each one, send a HEAD/GET request and classify the response.
3. When a takeover fingerprint shows up ("No such app", etc.), critical alert.

Where Sentinela fits

We monitor your domain tree and:

• Discover new subdomains via DNS and Certificate Transparency
• Resolve each one and classify the destination
• Flag potential takeover when we see abandoned-provider fingerprints
• Alert before it becomes an incident

This is the kind of finding annual pentests almost never catch (because the subdomain is born and dies between two pentests) and that continuous auditing solves by design.

The simple rule

A subdomain is like a house key. You don't leave a key in a public lobby because "no one will take it". But in DNS you do — because it's invisible. The difference is that the attacker sees the keys hanging on your wall better than you do.

Map. Clean up. Monitor. It's the cheapest defense there is.