Subdomain takeover: cómo ocurre y cómo detectarlo

Un subdomain takeover empieza con un CNAME que apunta a un servicio dado de baja. Cómo se explotan los registros huérfanos y cómo auditar tu zona DNS.

Un subdomain takeover ocurre cuando un registro DNS, normalmente un CNAME, apunta a un recurso externo que ya no existe, y otra persona vuelve a crear ese recurso con el mismo nombre. Desde ese momento, tu subdominio sirve contenido que no controlas. El atacante consigue una página que vive bajo tu dominio, con tu reputación detrás: phishing convincente, distribución de malware y, en algunas configuraciones, acceso a cookies del dominio principal. El DNS nunca fue comprometido. Siguió diciendo la verdad sobre un destino que olvidaste limpiar. Este artículo cubre el mecanismo, los servicios donde suele pasar, cómo auditar tu propia zona y cómo prevenirlo.

El mecanismo: un registro huérfano

La vulnerabilidad sigue un ciclo de vida que le sonará a cualquiera que lleve unos años gestionando un sitio web:

Creas blog.ejemplo.com como CNAME apuntando a un servicio alojado, digamos tuempresa.una-plataforma.com.
El servicio funciona durante un tiempo. Todo va bien.
Cancelas la suscripción o borras el proyecto. La plataforma libera el nombre tuempresa.
Nadie borra el CNAME. Ahora apunta a un recurso que ya no existe. Eso es un registro huérfano ("dangling record").

Así se ve el antes y el después:

Antes (servicio activo):
blog.ejemplo.com.  CNAME  tuempresa.una-plataforma.com.
                          -> la plataforma sirve TU contenido

Después de la baja (huérfano):
blog.ejemplo.com.  CNAME  tuempresa.una-plataforma.com.
                          -> el nombre está libre en la plataforma

La resolución DNS sigue funcionando. El registro es válido y la infraestructura de la plataforma sigue respondiendo. Lo único que falta es el recurso detrás del nombre. Si la plataforma permite que cualquier cliente registre ese nombre liberado, quien lo reclame recibirá todo el tráfico dirigido a blog.ejemplo.com. Los visitantes ven tu URL en la barra de direcciones y una página válida detrás. Eso es lo que hace al ataque tan eficaz para el phishing: nada parece estar mal.

El CNAME es el vector más común porque delega un hostname completo a un tercero, pero los registros A huérfanos que apuntan a direcciones IP de nube liberadas causan el mismo problema. Si necesitas repasar cómo se comportan estos tipos de registro, consulta nuestra guía de tipos de registros DNS.

Los servicios donde suele ocurrir

Cualquier plataforma que asocie nombres elegidos por el cliente a hostnames puede verse afectada. Cuando el recurso detrás de un registro huérfano desaparece, la plataforma suele devolver un error reconocible. Estas señales son las que busca un defensor durante una auditoría:

Servicio	Señal de un recurso huérfano
GitHub Pages	"There isn't a GitHub Pages site here"
AWS S3	Página de error "NoSuchBucket"
Heroku	Página de error "No such app"
Azure (cloudapp, azurewebsites)	NXDOMAIN o error por defecto de Azure
Shopify	"Sorry, this shop is currently unavailable"
Vercel	404 con "DEPLOYMENT_NOT_FOUND"

Muchos proveedores han endurecido esto con los años. GitHub Pages y otros exigen ahora verificar la propiedad del dominio antes de asociar un dominio personalizado, lo que cierra el camino fácil. Pero la ventana se ha estrechado, no ha desaparecido: plataformas antiguas, proveedores regionales y servicios sin verificación siguen siendo reclamables, y la verificación no te protege si el registro huérfano apunta a un sitio que nunca la implementó.

Auditar tu propio dominio

Para una primera pasada no necesitas herramientas especiales. Tres pasos:

Exporta tu zona DNS desde tu proveedor (Cloudflare, Route 53, OVH, tu registrador) y lista todos los registros CNAME y A que apunten fuera de tu propia infraestructura.
Para cada uno, comprueba que el recurso de destino sigue respondiendo y sigue siendo tuyo. Abre el hostname en un navegador y confirma que el contenido es tuyo, no una página de error de la plataforma.
Borra todos los registros cuyo servicio hayas cancelado, migrado o no puedas identificar.

Para inspeccionar un registro concreto desde la terminal:

dig CNAME tienda.ejemplo.com +short

Si la respuesta apunta a una plataforma SaaS, solicita la página por HTTP y lee la respuesta. Un error de plataforma como los de la tabla anterior, en un hostname que todavía publicas en DNS, es exactamente la señal que busca un oportunista. Trátalo como urgente: borra el registro o recupera el recurso el mismo día.

Prevenirlo de forma duradera

La solución de fondo es de proceso, no técnica. Cuando canceles un servicio, borra el registro DNS en el mismo ticket, el mismo pull request o la misma ventana de cambio. Una baja solo está terminada cuando ambos lados han desaparecido. La mayoría de los takeovers se remontan a una cancelación que se saltó este paso años atrás.

Más allá de ese hábito, mantén un inventario vivo de cada subdominio que apunte a un servicio externo, con su responsable interno, y revisa esa lista con regularidad. Trimestral funciona para la mayoría de los equipos. Nuestro resumen sobre qué cubre la monitorización DNS explica dónde encajan los controles a nivel de registro en esa rutina.

Si usas Domain Sentinel, el campo Extra names de la monitorización DNS te permite añadir hasta diez subdominios críticos por dominio, cada uno vigilado como su propio hostname. Sus registros CNAME y A se capturan a diario y cualquier cambio genera una alerta por email. Diez son pocos, así que quédate con los subdominios que apuntan a un servicio externo. Eso mantiene tu inventario honesto: un registro que cambia o aparece sin un ticket de cambio asociado se detecta. Para ser claros sobre los límites: registra lo que responde tu DNS, no comprueba si el recurso de destino sigue existiendo en la plataforma. Borrar los registros obsoletos es la defensa; la monitorización es la red de seguridad que avisa cuando el conjunto de registros se desvía.

Empieza hoy con la exportación: descarga tu zona, lista los registros que apuntan a servicios externos, verifica cada uno y borra los muertos. La mayoría de las zonas con más de unos años contienen al menos una sorpresa. Y como los registros huérfanos son solo una de las formas en que un subdominio acaba sirviendo contenido ajeno, lee nuestro artículo sobre cómo detectar el DNS hijacking para el ataque emparentado, en el que se modifica la propia zona.