Un patrón recurrente en zonas DNS de organizaciones medianas y grandes: subdominios huérfanos que apuntan a servicios SaaS retirados. El equipo de marketing crea promo2024.organizacion-ejemplo.cl apuntando a un sitio de campaña en un hosting SaaS, termina la campaña, alguien borra la app — pero nadie toca el DNS.
Resultado: un atacante crea una cuenta en ese mismo proveedor SaaS, reclama exactamente el mismo nombre que tenía la app borrada, y ahora promo2024.organizacion-ejemplo.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.organizacion-ejemplo.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 tú seas el dueño del CNAME que apunta hacia ahí.
- El atacante reclama el nombre. Su recurso ahora responde cuando alguien resuelve
sub.organizacion-ejemplo.cl→ CNAME aalgo.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
.organizacion-ejemplo.cl(si tu apex setea cookies sinPathestricto). - 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.organizacion-ejemplo.clsi 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.compara 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 verificas tu zona
Manual, para un subdominio puntual
# 1) ¿el sub tiene CNAME?
dig +short CNAME sub.organizacion-ejemplo.cl
# 2) ¿resuelve a una IP?
dig +short A sub.organizacion-ejemplo.cl
# 3) ¿qué responde el destino?
curl -sI https://sub.organizacion-ejemplo.cl/
curl -s https://sub.organizacion-ejemplo.cl/ | head -20
Las señales rojas:
- Hay CNAME, pero
dig Ano 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.organizacion-ejemplo.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 creas un subdomain apuntando a un SaaS: documenta quién es el dueño, en qué proyecto vive, y cuándo se revisará.
- Cuando vas a retirar un servicio: primero borras el DNS, después borras el recurso en el SaaS. Si lo haces al revés (borras el recurso, dejas el DNS), creas 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 tú eres el dueño. Si el SaaS lo soporta, actívalo. 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.
Los patrones más comunes en la industria
Las publicaciones de hallazgos en programas de bug bounty y los reportes de la industria muestran que los takeovers documentados siguen unos pocos patrones recurrentes, independientes del sector de la organización afectada:
- Microsites de campaña sobre hostings SaaS de corta vida. Subdominios tipo
evento-2019.organizacion-ejemplo.clopromo-fin-de-anio.organizacion-ejemplo.clapuntando a un hosting tipo Heroku, Netlify o Vercel. La app se borra cuando termina la campaña; el CNAME permanece. Años después el nombre interno queda disponible para que cualquier cuenta lo reclame. - Storefronts retirados sobre plataformas de e-commerce. CNAMEs hacia tiendas que se desactivaron al consolidar el catálogo en un dominio principal. El proveedor permite que otro merchant active el mismo subdominio si nadie verificó el ownership.
- Documentación técnica sobre GitHub Pages. Repos archivados por ex-colaboradores en cuentas personales (no organizacionales), que el proveedor termina eliminando por inactividad. El CNAME custom domain en la zona corporativa sobrevive al repo.
El denominador común en todos los casos: nadie en la organización tenía registro de que ese CNAME existía. No es un problema técnico — es un problema de inventario y trazabilidad.
Cierre
Si tu zona DNS tiene más de 20 subdominios y nunca corriste un check de takeover, asume que tienes 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.
