Subdomain takeover: qué es, riesgos y prevención

Un subdomain takeover es el secuestro de un subdominio legítimo que se produce cuando un registro DNS (normalmente un CNAME) sigue apuntando a un servicio externo que ya se ha dado de baja, dejando el registro colgado y disponible para que un atacante reclame ese recurso y sirva contenido bajo tu dominio. El problema no está en un fallo de software concreto, sino en una descoordinación operativa: alguien elimina un bucket de Amazon S3, un sitio de GitHub Pages o un recurso de Azure, pero olvida borrar el registro DNS que lo referenciaba. Ese registro huérfano (dangling DNS) es la puerta.

Esta guía explica qué es un subdomain takeover, cómo se produce el dangling DNS, qué servicios cloud son los más afectados, los riesgos reales, el flujo de descubrimiento que usa un equipo ofensivo y la higiene DNS necesaria para prevenirlo.

Lo esencial sobre subdomain takeover

• Ocurre cuando un CNAME (o registro A/ALIAS) apunta a un servicio externo ya deprovisionado y reclamable.
• Servicios frecuentes: Amazon S3, GitHub Pages, Azure (App Service, CDN, Traffic Manager), Heroku, Fastly, Shopify, Zendesk.
• El impacto va más allá del defacement: phishing bajo dominio de confianza, robo de cookies de sesión, bypass de listas CORS y CSP, emisión de certificados TLS.
• Descubrimiento: subfinder, amass, dnsx, httpx y nuclei con plantillas de takeover, más la lista de fingerprints can-i-take-over-xyz.
• Prevención: borrar el registro DNS antes de deprovisionar el recurso, inventario de activos, monitorización continua y verificación de dominio en el proveedor.

Qué es un subdomain takeover

Un subdomain takeover es una clase de vulnerabilidad de configuración, no un fallo en el código de una aplicación. Por eso rara vez se le asigna un CVE: no es un defecto de un producto concreto, sino un estado inseguro de la infraestructura DNS de una organización. El estándar de pruebas de OWASP lo recoge como WSTG-CONF-10 (Test for Subdomain Takeover) y MITRE ATT&CK lo relaciona con la técnica T1584.001 (Compromise Infrastructure: Domains), porque un atacante que controla pagos.tuempresa.com no ha comprometido tu red, ha comprometido tu identidad.

El mecanismo es sencillo. El navegador de una víctima resuelve blog.tuempresa.com y sigue el CNAME hasta tuempresa.github.io (o un endpoint de S3 o Azure). Si ese recurso ya no existe pero cualquiera puede recrearlo con el mismo nombre, el atacante lo reclama y desde ese momento el proveedor sirve su contenido bajo tu subdominio, con tu marca, tu certificado y tu reputación.

Cómo se produce el dangling DNS

La secuencia que crea un takeover es casi siempre la misma error operativo:

1. Un equipo publica un microsite o una documentación en un servicio gestionado y crea el CNAME correspondiente.
2. Meses después el proyecto se archiva y alguien elimina el recurso en el proveedor (borra el bucket, desactiva Pages, tira la App Service).
3. Nadie elimina el CNAME: el registro DNS queda apuntando al vacío.
4. Un atacante que enumera subdominios detecta el registro colgado, identifica el proveedor por su página de error característica y reclama el recurso libre.

El orden importa: el fallo de fondo es deprovisionar el recurso antes de borrar el DNS. Invertir ese orden (borrar primero el registro) elimina la ventana de exposición por completo.

Servicios cloud típicamente afectados

No todos los servicios son vulnerables por igual: la condición es que el proveedor permita reclamar un nombre de recurso liberado sin verificar la propiedad del dominio. Los casos históricos más recurrentes:

• Amazon S3: un bucket borrado devuelve NoSuchBucket. Si el CNAME apunta al nombre del bucket y este queda libre, cualquiera lo re-registra.
• GitHub Pages: la página There isn't a GitHub Pages site here es la firma clásica. El atacante crea un repositorio con un CNAME hacia el subdominio y lo captura.
• Azure: App Service, Blob Storage, Traffic Manager y CDN han presentado variantes reclamables cuando el endpoint (*.azurewebsites.net, *.trafficmanager.net) queda huérfano.
• Heroku, Fastly, Shopify, Zendesk, Surge, Netlify, Read the Docs: todos aparecen en informes de bug bounty públicos (Uber, Starbucks y otros) con fingerprints conocidos.

La referencia comunitaria es la lista can-i-take-over-xyz (mantenida por EdOverflow y colaboradores), que cataloga cada servicio, su fingerprint y si el takeover es explotable o ya está mitigado por el proveedor.

Riesgos reales de un subdomain takeover

El error más habitual es tratarlo como un defacement menor. El impacto real depende del contexto del subdominio y suele ser grave:

• Phishing bajo dominio de confianza. Una página de login clonada en acceso.tuempresa.com derrota cualquier formación anti-phishing basada en verificar el dominio: la URL es legítima y el candado TLS es verde.
• Robo de cookies de sesión. Si la aplicación fija cookies con Domain=.tuempresa.com, el subdominio secuestrado las recibe. Es un camino directo al robo de sesión sin necesidad de un XSS en la aplicación principal.
• Bypass de listas de confianza. Una política CORS que confía en *.tuempresa.com, o una CSP que permite scripts desde cualquier subdominio, se convierten en un agujero: el atacante sirve JavaScript desde el subdominio capturado y salta la restricción.
• Emisión de certificados TLS. Al controlar el subdominio, el atacante supera el reto ACME de Let's Encrypt y emite un certificado válido que hace el engaño indistinguible.
• Abuso de OAuth y reputación de correo. Un redirect_uri que confíe en el subdominio permite robo de tokens, y los registros de correo asociados facilitan suplantación con la reputación del dominio legítimo.

Descubrimiento: herramientas y flujo

Encontrar registros colgados es una tarea de reconocimiento. Forma parte del alcance de un pentesting de infraestructura externa y de cualquier ejercicio de OSINT sobre la superficie pública. El toolkit habitual:

• Enumeración de subdominios: subfinder, amass, assetfinder y findomain, más los logs de Certificate Transparency vía crt.sh, que revelan subdominios ausentes del DNS público.
• Resolución y cadena CNAME: dnsx para resolver en masa y seguir la cadena de CNAME hasta el destino final.
• Sondeo y fingerprinting: httpx para detectar qué subdominios responden, y nuclei con la etiqueta de takeovers (nuclei -tags takeover), que aplica cientos de fingerprints automáticamente.
• Detectores dedicados: subzy, subjack, tko-subs y dnsReaper (de Punk Security) confirman candidatos, y aquatone genera capturas de los subdominios vivos para revisión rápida.

Flujo de detección paso a paso

# 1. Enumerar subdominios de forma pasiva
subfinder -d tuempresa.com -all -silent -o subs.txt

# 2. Resolver y capturar registros CNAME
dnsx -l subs.txt -cname -resp -silent -o cnames.txt

# 3. Sondear los que responden por HTTP/HTTPS
httpx -l subs.txt -silent -o live.txt

# 4. Buscar fingerprints de takeover
nuclei -l live.txt -tags takeover

# 5. Confirmar candidatos con un detector dedicado
subzy run --targets subs.txt

La lógica de decisión es siempre la misma: se resuelve el subdominio, se sigue la cadena de CNAME, y si el destino final devuelve NXDOMAIN o responde con la página de error reclamable de un proveedor conocido, el subdominio es candidato a takeover. La confirmación real (reclamar el recurso) solo debe hacerse con autorización escrita, como parte de un ejercicio de Red Team o pentesting contratado.

Prevención e higiene DNS

La defensa combina proceso operativo y monitorización. Los controles que aplica un equipo maduro:

• Orden de baja correcto. Documentar y hacer cumplir que el registro DNS se elimina antes o a la vez que el recurso cloud, nunca después. Es el control que cierra la ventana de raiz.
• DNS como código. Gestionar las zonas con Terraform o herramientas equivalentes, de forma que cada registro tenga propietario, historial y pase por revisión. Un CNAME huérfano se detecta en el diff.
• Inventario de activos vivo. No se puede proteger lo que no se sabe que existe: un inventario de subdominios y su destino, revisado periódicamente, es la base.
• Verificación de dominio en el proveedor. GitHub, Azure y AWS ofrecen verificación de propiedad (registros TXT asuid, dominios de organización verificados, uso del dominio como nombre de bucket) que impide reclamar el recurso aunque el CNAME siga colgado.
• Monitorización continua. Ejecutar nuclei -tags takeover o dnsReaper de forma programada (idealmente en CI/CD) y vigilar los logs de Certificate Transparency (crt.sh, Cert Spotter) para detectar certificados inesperados sobre tus dominios.
• Evitar wildcards y delegaciones huérfanas. Un CNAME wildcard hacia un tercero amplía la superficie. Y una variante más grave, el NS takeover, aparece cuando una delegación (NS) apunta a una zona alojada que ya no controlas: revisa y retira delegaciones obsoletas.

Cuando el subdominio en riesgo apunta a infraestructura cloud, la revisión encaja de forma natural en una auditoría cloud de AWS, Azure o GCP, donde el inventario de recursos y sus registros DNS se cruzan de forma sistemática.

Preguntas frecuentes

¿Un subdomain takeover tiene CVE?

Normalmente no. Es una vulnerabilidad de configuración específica de cada organización, no un defecto de un producto de software, así que no recibe identificador CVE. Se documenta como hallazgo en pentesting y bug bounty, referenciada con el estándar OWASP WSTG-CONF-10.

¿Basta con borrar el recurso cloud para estar seguro?

No, es justo el error que provoca el problema. Si borras el bucket, la App Service o el sitio de Pages pero dejas el CNAME apuntando a él, creas el registro colgado que habilita el takeover. Hay que eliminar el registro DNS, no solo el recurso.

¿Cómo sé si un subdominio es vulnerable?

Se resuelve el subdominio, se sigue su cadena de CNAME y se comprueba el destino final. Si devuelve NXDOMAIN o muestra la página de error reclamable de un proveedor conocido (por ejemplo NoSuchBucket de S3 o There isn't a GitHub Pages site here), es candidato. Herramientas como nuclei, subzy o dnsReaper automatizan esa comprobación.

¿Qué diferencia hay entre subdomain takeover y NS takeover?

El subdomain takeover secuestra un subdominio concreto vía un CNAME colgado. El NS takeover secuestra una delegación de zona entera: si un registro NS apunta a nameservers que ya no controlas y son reclamables, el atacante toma el control de toda la zona delegada, un impacto mucho mayor.

¿Con qué frecuencia hay que revisar el DNS?

De forma continua para dominios grandes, y como mínimo en cada baja de proyecto o servicio. Integrar la comprobación de takeover en el pipeline de CI/CD y vigilar Certificate Transparency reduce la ventana de exposición a horas en lugar de meses.

Recursos relacionados

• Qué es OSINT: la disciplina de inteligencia abierta donde la enumeración de subdominios es un paso obligatorio.
• Google Dorks y footprinting: cómo descubrir subdominios y activos olvidados desde fuentes públicas.
• Pentesting de infraestructura externa: el ejercicio donde el reconocimiento de subdominios y el takeover forman parte del alcance.
• Pentesting cloud AWS, Azure y GCP: la auditoría que cruza recursos cloud con sus registros DNS.
• Qué es CORS y errores de configuración: por qué confiar en *.tudominio.com convierte un takeover en un compromiso de la API.

Subdomain takeover en Secra

En Secra la búsqueda de subdominios colgados forma parte del reconocimiento estándar de nuestros ejercicios de Red Team y del pentesting de infraestructura. Enumeramos tu superficie completa de subdominios, seguimos cada cadena de CNAME, identificamos registros colgados y recursos reclamables, y confirmamos los takeovers explotables con evidencia reproducible y sin impacto en producción. Si tu organización acumula proyectos archivados, migraciones cloud o subdominios que nadie recuerda, escríbenos a través de contacto o consulta nuestro servicio de Red Team.