Subdomain takeover: cómo un CNAME huérfano se convierte en un dominio hostil

Un patrón que detectamos en muchos clientes durante recon: subdominios huérfanos que apuntan a servicios SaaS retirados. El equipo de marketing creó promo2024.cliente.cl apuntando a un sitio de campaña en Heroku, terminó la campaña, alguien borró la app — pero nadie tocó el DNS.

Resultado: un atacante crea una cuenta en Heroku, reclama exactamente el mismo nombre que tenía la app borrada, y ahora promo2024.cliente.cl resuelve a un servidor controlado por él. Con TLS válido. En tu zona.

A esto se le llama subdomain takeover, y es una vulnerabilidad de impacto alto que vive en el espacio entre “responsabilidad de DevOps” y “responsabilidad del equipo que usa el SaaS”. Por eso suele quedar sin dueño.

El mecanismo, paso a paso

Tu zona DNS tiene un CNAME del tipo sub.cliente.cl. → algo.saas.com.
El recurso en el SaaS se borra o expira (la app de Heroku, el bucket de S3, el sitio de Netlify, el subdomain de Shopify, etc.). El CNAME en tu zona queda apuntando a un nombre que ya no existe en ese SaaS.
El SaaS permite “claim” del nombre: cualquier usuario puede crear un recurso nuevo con ese mismo subdomain interno. La mayoría de proveedores no valida que vos seas el dueño del CNAME que apunta hacia ahí.
El atacante reclama el nombre. Su recurso ahora responde cuando alguien resuelve sub.cliente.cl → CNAME a algo.saas.com → el contenido del atacante.
Heredás la URL completa: tu nombre, en tu dominio, con TLS válido (porque muchos SaaS proveen cert automático para el hostname configurado), con la confianza acumulada de la zona.

El atacante puede ahora:

Servir un sitio de phishing con tu marca y URL legítima.
Robar cookies con dominio .cliente.cl (si tu apex setea cookies sin Path estricto).
Ejecutar JS bajo el mismo origen que cualquier app que importe scripts desde ese subdomain.
Setear meta-tags arbitrarios y aparecer en SEO como tu sitio oficial.
Recibir emails enviados a *@sub.cliente.cl si setea MX (escenario más raro pero posible).

Dónde pasa más seguido

Cualquier SaaS que use CNAME a hostnames internos y permita claim libre. La lista cambia con el tiempo — muchos proveedores arreglaron el bug exigiendo verificación de ownership — pero a 2026 los patrones más comunes siguen siendo:

Heroku — *.herokuapp.com para apps borradas.
GitHub Pages — repos archivados o borrados sin quitar el CNAME del custom domain.
AWS S3 / CloudFront — buckets sin verificación de ownership.
Azure — App Service, Blob Storage, Traffic Manager, Front Door.
GCP — Cloud Storage, App Engine, Firebase Hosting, Cloud Run.
Vercel / Netlify — proyectos eliminados con CNAME residual.
Shopify, Webflow, Pantheon, Fastly, Tumblr, WordPress.com — el patrón se repite en hosting tipo SaaS.

Cada proveedor tiene un “fingerprint” — texto en la respuesta HTTP que indica “este nombre no está reclamado”. Por ejemplo, GitHub Pages devuelve "There isn't a GitHub Pages site here.", Heroku devuelve "No such app". Herramientas de detección como subjack y takeover usan exactamente esa lista.

Cómo verificás tu zona

Manual, para un subdominio puntual

# 1) ¿el sub tiene CNAME?
dig +short CNAME sub.cliente.cl

# 2) ¿resuelve a una IP?
dig +short A sub.cliente.cl

# 3) ¿qué responde el destino?
curl -sI https://sub.cliente.cl/
curl -s https://sub.cliente.cl/ | head -20

Las señales rojas:

Hay CNAME, pero dig A no resuelve a nada → posible NXDOMAIN del target.
El HTTP responde con uno de los strings conocidos del SaaS ("No such app", "There isn't a GitHub Pages site here", etc.).
El cert TLS no matchea el hostname (otro caso, llamado dangling IP recycled — un IP que era tuyo ahora es de otro tenant).

A escala, para todo el dominio

Inventario de subdominios desde CT logs:

curl -s 'https://crt.sh/?q=%25.cliente.cl&output=json' \
  | jq -r '.[].name_value' \
  | tr ',' '\n' | sort -u > subs.txt

Después corrés algo como subjack contra esa lista. Lo importante: el inventario debe rehacerse seguido, porque CT logs solo te dan dominios que tuvieron cert TLS en algún momento, y los CNAME a SaaS típicamente disparan eso (los SaaS auto-provisionan TLS).

La parte que más cuesta: prevención

La detección es relativamente fácil. Lo difícil es que el patrón no reaparezca, y eso requiere disciplina organizacional, no técnica.

Regla operativa: DNS first on creation, DNS last on retirement

Cuando creás un subdomain apuntando a un SaaS: documentá quién es el dueño, en qué proyecto vive, y cuándo se revisará.
Cuando vas a retirar un servicio: primero borrás el DNS, después borrás el recurso en el SaaS. Si lo hacés al revés (borrás el recurso, dejás el DNS), creás exactamente la ventana de oportunidad.

Inventario versionado

Tu zona DNS debería estar en git, o al menos exportarse periódicamente a un repo. Cualquier CNAME hacia un host externo necesita un comentario que diga para qué servicio es y quién lo creó. Si nadie reconoce el CNAME, candidato a borrar.

Verificación de ownership en el SaaS, cuando exista

Varios proveedores hoy permiten “domain verification” — un TXT record en tu zona que prueba que sos vos el dueño. Si el SaaS lo soporta, activalo. Eso bloquea el claim externo aunque el CNAME quede huérfano.

Monitoreo continuo, no auditoría puntual

Una auditoría manual cada 6 meses NO sirve. El CNAME huérfano puede aparecer mañana y ser reclamado pasado mañana. La detección efectiva es diaria, automatizada, con alerta al equipo de seguridad cuando aparece un nuevo huérfano.

Es exactamente el problema que nos llevó a construir el Dangling Monitor de Asentic — auto-descubre subdominios desde CT logs, clasifica cada uno en 5 estados (healthy, dangling-cname-nxdomain, dangling-cname-saas-claimable, dangling-ip-recycled, dangling-ns) y alerta cuando aparece uno nuevo o cuando uno existente cambia de estado. El servicio corre como monitoreo continuo con cadencia diaria y entrega los hallazgos por email.

Casos reales que vimos

Ofuscando contexto:

Cliente educacional — eventos2019.universidad.cl apuntaba a un Heroku que se borró en 2020. Detectado en 2026, reclamable. Reclamamos nosotros antes que cualquiera externo y lo entregamos al cliente para que limpie el DNS.
Retail — legacy-shop.retail.cl apuntaba a un Shopify retirado hacía 18 meses. El CNAME estaba documentado en una hoja Excel que nadie revisaba.
Pyme tecnológica — docs.empresa.cl → GitHub Pages, repo archivado por un ex-empleado. Cuenta personal, no organizacional. El nombre quedó claimable cuando GitHub borró el repo automáticamente por inactividad.

El patrón común: nadie sabía que el CNAME existía. No es un problema técnico, es un problema de inventario.

Cierre

Si tu zona DNS tiene más de 20 subdominios y nunca corriste un check de takeover, asumí que tenés al menos uno. La probabilidad sube con cada equipo que usa SaaS sin coordinación con seguridad — marketing, eventos, dev, customer success.

La detección manual te resuelve el problema de ahora. La detección continua te lo resuelve para siempre.