Subdomain takeover: cómo un CNAME olvidado acaba siendo tuyo

La historia es siempre la misma. Alguien montó blog.tuempresa.com apuntando con un CNAME a una app de Heroku, o a un bucket de S3, o a unas GitHub Pages. Meses después se da de baja el servicio… pero nadie borra el registro DNS. El destino queda vacío y reclamable. Un atacante registra ese mismo nombre en el proveedor, y de golpe blog.tuempresa.com —un subdominio legítimo, con tu marca y tu candado HTTPS— sirve su contenido.

Por qué duele más de lo que parece

• Phishing con dominio de verdad: el enlace es realmente tuempresa.com. Ni el usuario más avispado sospecha.
• Robo de cookies y sesiones: si hay cookies con alcance .tuempresa.com (Domain=), el subdominio secuestrado puede leerlas.
• Saltarse listas blancas: CSP, CORS o allowlists de OAuth que confían en *.tuempresa.com ahora confían en el atacante.
• Daño de marca y, si sirve JS, ejecución en el contexto de tu dominio.

La causa: registros DNS «colgando»

Un dangling record es un CNAME (o ALIAS/NS) que apunta a un recurso de terceros que ya no existe o ya no es tuyo. El proveedor devuelve una página de error reconocible —NoSuchBucket, There isn't a GitHub Pages site here, No such app— que es a la vez la señal del fallo y la invitación a reclamarlo. Servicios históricamente afectados: S3, GitHub Pages, Heroku, Azure (blob/cloudapp), Shopify, Fastly, Surge, Netlify, Zendesk… la lista es larga y viva.

Cómo se caza (recon)

1. Enumera subdominios del objetivo: Certificate Transparency, DNS pasivo, fuerza bruta con diccionario.
2. Resuelve cada uno y quédate con los que tienen CNAME hacia servicios de terceros.
3. Huella la respuesta: ¿devuelve una de esas páginas de error de servicio no reclamado?
4. Confirma sin explotar: en un pentest o bug bounty legítimo, basta demostrar que es reclamable; no publiques contenido en dominio ajeno más allá de una PoC acordada.

Cómo cerrarlo (lado defensa)

• ✅ Inventaría tu DNS: cada registro debe tener un dueño y un servicio vivo detrás.
• ✅ Orden de baja correcto: primero borra el registro DNS, luego libera el recurso —nunca al revés.
• ✅ Monitoriza Certificate Transparency y tus propias zonas; alerta ante CNAME que resuelvan a páginas de «no reclamado».
• ✅ Revisa periódicamente los subdominios olvidados (campañas, entornos de staging, adquisiciones).

Checklist

• ✅ ¿Tienes CNAMEs apuntando a servicios de terceros? Compruébalos.
• ✅ Al dar de baja algo: primero el DNS, después el recurso.
• ✅ Huella típica: NoSuchBucket, «There's nothing here», «No such app».
• ✅ Cuidado con cookies Domain=.tuempresa.com y allowlists *.tuempresa.com.
• ✅ Solo sobre dominios propios o con permiso.

Un subdominio takeover no explota ningún 0-day: explota el olvido. La superficie de ataque no es solo lo que despliegas, también es lo que dejas de desplegar y no limpias. Un inventario de DNS aburrido es la mejor defensa contra este fallo tan silencioso.

Sergio Belmonte Morales
Analista de Ciberseguridad · SOC · Especialista en Sentinel/KQL