Un subdomain takeover ocurre cuando un subdominio sigue apuntando mediante DNS a un recurso externo que ya no existe y ese recurso puede volver a ser reclamado por otra persona. El resultado puede ser el control de contenido servido bajo un subdominio legítimo de la organización. En esta guía veremos cómo detectar CNAME dangling, validar falsos positivos y revisar los patrones más habituales en Azure, GitHub Pages, AWS S3, Heroku, Vercel, Netlify y otros proveedores.
El objetivo de las técnicas descritas es la auditoría autorizada, bug bounty y validación defensiva. La disponibilidad de nombres, mecanismos de verificación y protecciones cambia con el tiempo, así que cualquier hallazgo debe confirmarse de forma controlada y dentro del alcance permitido.
¿Qué es un subdomain takeover?
Un subdomain takeover aparece cuando existe una desincronización entre el DNS de una organización y el ciclo de vida de un servicio externo. El equipo elimina una aplicación, bucket, CDN, página o servicio cloud, pero el registro DNS que apuntaba a ese recurso permanece activo.
El patrón típico es un registro CNAME:
# Estado normal
blog.victima.com → CNAME → proyecto.proveedor.example → Recurso activo
# Recurso eliminado, DNS intacto
blog.victima.com → CNAME → proyecto.proveedor.example → NXDOMAIN / error del proveedor
# Riesgo de takeover
Si el proveedor permite volver a registrar "proyecto", un tercero podría reclamarlo.
No debe confundirse con un DNS hijacking. En un takeover no es necesario comprometer el proveedor DNS ni modificar la zona. El problema está en que el DNS legítimo sigue confiando en un recurso externo que ya no está bajo control de la organización.
Señales que merecen revisión
- Un CNAME apunta a un hostname que devuelve
NXDOMAIN. - El proveedor devuelve una página de error característica de recurso inexistente.
- El nombre del recurso parece reutilizable en la plataforma externa.
- El subdominio sigue apareciendo en certificados, JavaScript, aplicaciones móviles o documentación antigua.
- El dominio era utilizado por una aplicación que fue retirada o migrada.
¿Qué impacto puede tener?
El impacto depende de cómo se utilizaba el subdominio y de la confianza que otras aplicaciones depositen en él. Controlar contenido bajo un dominio legítimo puede permitir escenarios como:
- Phishing de alta credibilidad: la URL pertenece realmente al dominio de la organización.
- Problemas con cookies: configuraciones demasiado amplias de
Domain=.example.compueden ampliar el impacto. - Bypass de allowlists CORS: si una aplicación confía en subdominios mediante reglas demasiado permisivas.
- Flujos OAuth/OIDC inseguros: cuando una
redirect_uripermite subdominios que ya no están controlados. - Supply chain: un recurso eliminado puede seguir referenciado desde scripts, assets o pipelines.
- Intercepción de tráfico de aplicaciones: si sistemas antiguos continúan conectándose al hostname retirado.
En una auditoría, el impacto no debe asumirse únicamente porque exista un CNAME roto. Hay que demostrar qué confianza mantiene la organización sobre ese subdominio y si el recurso es realmente reclamable.
Cómo detectar un subdomain takeover
Paso 1 — Enumerar subdominios
En un pentest o programa de bug bounty dentro de alcance, comienza construyendo un inventario de subdominios. Las fuentes pasivas reducen ruido y permiten localizar activos olvidados.
subfinder -d ejemplo.com -silent -o subs.txt
amass enum -passive -d ejemplo.com -o amass_subs.txt
assetfinder --subs-only ejemplo.com >> subs.txt
# Combinar y deduplicar
cat subs.txt amass_subs.txt | sort -u > all_subs.txt
Paso 2 — Revisar CNAME y resolución DNS
dig app.ejemplo.com CNAME +short
dig destino-del-cname.example-provider.com
Un destino que devuelve NXDOMAIN es una señal importante, pero no confirma por sí solo la vulnerabilidad. Algunos servicios pueden devolver errores similares aunque el nombre esté reservado, protegido o asociado internamente.
Paso 3 — Identificar el proveedor
El hostname del CNAME y la respuesta HTTP suelen revelar el servicio. Algunos ejemplos habituales:
| Servicio | Indicador habitual | Qué validar |
|---|---|---|
| GitHub Pages | There isn't a GitHub Pages site here. | Estado del dominio y verificación de organización |
| Azure App Service | 404 Web Site Not Found u otra respuesta de sitio inexistente | Disponibilidad real del nombre y custom domain |
| Azure Blob Storage | Errores de mapping o recurso inexistente | Disponibilidad de la Storage Account |
| AWS S3 | NoSuchBucket | Nombre, región y políticas actuales de AWS |
| Heroku | No such app | Asignación del dominio en la plataforma |
| Vercel | Deployment/domain no encontrado | Estado del dominio personalizado |
| Netlify | Respuesta de sitio no encontrado | Si el dominio puede asociarse a otro site |
| Fastly | unknown domain | Configuración de dominio en el servicio |
Repositorios como can-i-take-over-xyz son útiles para identificar fingerprints, pero no sustituyen la validación manual: los proveedores cambian protecciones, ownership checks y mensajes de error.
Falsos positivos: cuándo un CNAME dangling no implica takeover
Uno de los errores más comunes es reportar cualquier CNAME roto como takeover. Para que exista una vulnerabilidad real deben cumplirse, como mínimo, dos condiciones:
- El recurso al que apunta el DNS ya no debe estar controlado por la organización.
- Un tercero debe poder reclamar de forma efectiva el identificador o asociar el dominio al nuevo recurso.
Un NXDOMAIN, un 404 o un fingerprint conocido son evidencias de investigación, no una prueba definitiva. Entre los falsos positivos habituales están los nombres reservados, verificaciones de ownership obligatorias, recursos eliminados pero aún protegidos y servicios que devuelven NXDOMAIN en determinados estados internos.
Para un PoC responsable, demuestra el control con contenido inocuo, evita capturar datos reales y detén la prueba en cuanto quede validado el impacto.
Subdomain takeover en Azure
Azure presenta múltiples servicios que históricamente han utilizado nombres públicos controlados por el nombre del recurso. Por eso es frecuente encontrar CNAME antiguos apuntando a recursos que fueron eliminados durante migraciones o limpiezas de infraestructura.
Azure App Service
dig app.ejemplo.com CNAME +short
# proyecto.azurewebsites.net.
dig proyecto.azurewebsites.net
Si el hostname ya no existe, el siguiente paso es comprobar de forma autorizada si el nombre continúa protegido o si puede volver a registrarse. No basta con la respuesta HTTP del App Service: la posibilidad real de asociar el custom domain es la condición determinante.
Azure CDN (*.azureedge.net)
Los endpoints históricos de Azure CDN también aparecen con frecuencia en inventarios antiguos. Un CNAME hacia *.azureedge.net que ya no resuelve debe revisarse junto con el estado actual del endpoint y las protecciones del servicio.
dig cdn.ejemplo.com CNAME +short
dig nombre.azureedge.net
Azure Virtual Machine (*.[region].cloudapp.azure.com)
En máquinas virtuales con DNS label, la región forma parte del hostname y puede ser relevante para determinar si el identificador podría reutilizarse. No confundas estos endpoints con formatos legacy que pueden tener un comportamiento diferente.
Azure Traffic Manager (*.trafficmanager.net)
Traffic Manager merece especial atención porque un perfil sin endpoints puede producir respuestas DNS que se parecen a un recurso eliminado. Por eso es un buen ejemplo de por qué NXDOMAIN no equivale automáticamente a takeover.
Azure Blob Storage (*.blob.core.windows.net)
En Storage Accounts, el nombre de la cuenta controla el hostname público. Si un subdominio antiguo sigue apuntando a una cuenta eliminada, hay que comprobar si el nombre continúa protegido y si el proveedor exige validación del custom domain.
Otros servicios Azure a revisar
| Servicio | Dominio habitual | Riesgo a validar |
|---|---|---|
| Azure API Management | *.azure-api.net | Reutilización del nombre y custom domain |
| Azure SQL Server | *.database.windows.net | Reasignación del endpoint y conexiones residuales |
| Azure AI Search | *.search.windows.net | Disponibilidad del nombre |
| Azure Container Registry | *.azurecr.io | Reutilización del registry name |
| Azure Container Instance | *.azurecontainer.io | DNS label y scope de reutilización |
| Azure Redis Cache | *.redis.cache.windows.net | Reutilización del hostname y conexiones antiguas |
| Azure Service Bus | *.servicebus.windows.net | Reasignación del namespace y tráfico residual |
La revisión debe centrarse siempre en tres preguntas: si el hostname procede del identificador del recurso, si ese identificador puede volver a asignarse y si el proveedor exige una prueba de propiedad del dominio. Evito tratar el número de servicios como una cifra fija porque Azure cambia productos y controles con frecuencia.
Subdomain takeover en GitHub Pages
GitHub Pages es uno de los casos clásicos. El patrón suele ser un CNAME hacia un dominio de Pages cuyo repositorio o configuración ya no existe.
dig docs.ejemplo.com CNAME +short
# organizacion.github.io.
curl -I https://docs.ejemplo.com
Antes de concluir que existe takeover hay que tener en cuenta las protecciones de verificación de dominio. Si una organización ha verificado correctamente su dominio en GitHub, un usuario externo no debería poder reutilizarlo libremente.
En un entorno autorizado, el objetivo del PoC es demostrar que el mapping puede ser reclamado, no desplegar contenido dañino. Una página estática con el identificador del reporte es suficiente.
Subdomain takeover en AWS S3
Los buckets S3 eliminados son otro patrón muy conocido, especialmente cuando un subdominio apuntaba a un endpoint de static website hosting.
dig assets.ejemplo.com CNAME +short
# assets.ejemplo.com.s3-website-eu-west-1.amazonaws.com.
curl -I http://assets.ejemplo.com
Una respuesta como NoSuchBucket indica que el bucket de destino no existe, pero la explotación dependerá de la posibilidad actual de crear el nombre esperado y de las restricciones de AWS. La región codificada en algunos endpoints también puede ser relevante durante la validación.
Por qué S3 puede ampliar el impacto
Si el hostname antiguo sigue referenciado desde aplicaciones, scripts, documentación o pipelines, el problema puede trascender la simple modificación de una página. En una revisión defensiva conviene buscar todas las referencias al dominio afectado antes de cerrar el incidente.
Heroku, Vercel y Netlify
Heroku
Un dominio que continúa apuntando a una aplicación eliminada puede devolver mensajes de aplicación inexistente. La validación debe comprobar si el hostname personalizado puede asociarse realmente a una aplicación distinta.
Vercel
Las búsquedas de Vercel subdomain takeover son especialmente frecuentes. Un CNAME hacia infraestructura de Vercel combinado con un mensaje de deployment o dominio inexistente merece revisión, pero las verificaciones de dominio actuales deben formar parte del análisis.
dig preview.ejemplo.com CNAME +short
curl -I https://preview.ejemplo.com
Netlify
El patrón es similar: hostname externo, site eliminado y dominio personalizado todavía publicado en DNS. Como en los demás proveedores, la pregunta clave no es únicamente qué error devuelve, sino si la plataforma permite asociar el dominio a un recurso nuevo.
Otros servicios y fingerprints relevantes
También pueden aparecer configuraciones dangling en servicios SaaS, hosting y CDN. Algunos nombres que merece la pena reconocer durante el fingerprinting son los siguientes:
Shopify
Los dominios personalizados asociados a tiendas retiradas pueden quedar apuntando a infraestructura de Shopify. Una respuesta de tienda no disponible es solo una señal inicial: hay que comprobar si la plataforma permitiría realmente volver a asociar ese dominio.
Zendesk
Un antiguo Help Center puede dejar un CNAME residual hacia *.zendesk.com. Revisa tanto el estado del tenant como los mecanismos actuales de verificación del dominio.
HubSpot
Los dominios utilizados por landing pages y contenidos antiguos pueden seguir apuntando a infraestructura de HubSpot después de eliminar el recurso original.
Fastly
Mensajes como Fastly error: unknown domain son útiles para fingerprinting de configuraciones huérfanas, pero deben validarse contra la posibilidad real de registrar el dominio en un servicio controlado.
ReadMe y otras plataformas SaaS
Documentación, help centers, plataformas de marketing y otros servicios con custom domains siguen el mismo patrón general: DNS activo + recurso eliminado + posibilidad de reasignación.
El procedimiento de investigación es siempre el mismo:
- Identificar el registro DNS.
- Resolver el destino.
- Reconocer el proveedor.
- Comprobar si el recurso sigue existiendo.
- Validar si un tercero podría reclamar el identificador.
- Determinar el impacto real que mantiene el subdominio.
Los fingerprints son útiles para priorizar, pero una buena auditoría no basa el reporte únicamente en una cadena de error.
Automatización para detectar subdomain takeovers
En superficies grandes, la automatización ayuda a localizar candidatos que después deben revisarse manualmente.
Enumeración
Detección y fingerprints
- Nuclei con templates de takeover.
- Subzy.
- BadDNS.
- Subdominator.
# Pipeline de descubrimiento para activos autorizados
subfinder -d ejemplo.com -silent | \
httpx -silent | \
nuclei -t /nuclei-templates/http/takeovers/ -o candidatos.txt
La salida debe tratarse como una lista de candidatos. Revisa manualmente cada resultado para eliminar falsos positivos antes de reportar.
Si estás aprendiendo esta metodología, puedes ampliar la parte de reconocimiento y validación en nuestro curso de pentesting y practicar técnicas web en los CTF Labs de SixHack Academy.
Cómo prevenir un subdomain takeover
1. Eliminar primero el DNS
Cuando un recurso va a retirarse, elimina primero el registro DNS que apunta a él. Después espera a que expire el TTL y finalmente destruye el recurso externo. El orden contrario crea la ventana de exposición.
2. Inventariar CNAME y recursos externos
Mantén un inventario que relacione cada subdominio con su propietario interno, proveedor y recurso asociado. Los activos sin propietario son los que más fácilmente quedan abandonados.
3. Monitorizar DNS continuamente
Automatiza revisiones periódicas para localizar CNAME que empiezan a devolver NXDOMAIN o fingerprints de recursos eliminados. Puede integrarse en procesos de Attack Surface Management o CI/CD.
4. Activar verificaciones de dominio
Cuando el proveedor permita verificar la propiedad del dominio a nivel de organización, activa esa protección. Reduce la posibilidad de que un tercero asocie un subdominio corporativo a su propio recurso.
5. Revisar cookies, CORS y redirect URIs
Un takeover es mucho más grave cuando otras aplicaciones confían ampliamente en todos los subdominios. Evita cookies con scope innecesariamente amplio, allowlists CORS permisivas y patrones de redirect URI basados en comodines.
6. Revisar referencias antes de retirar un servicio
Busca el hostname en código, JavaScript, aplicaciones móviles, repositorios, pipelines, documentación y configuraciones antes de eliminar el recurso.
Para profundizar en estos vectores desde una perspectiva práctica, consulta nuestra guía de web hacking y el catálogo de cursos de ciberseguridad ofensiva.
Preguntas frecuentes sobre subdomain takeover
¿Qué es un subdomain takeover?
Es una vulnerabilidad en la que un subdominio legítimo sigue apuntando a un recurso externo eliminado y un tercero puede reclamar ese recurso, obteniendo capacidad para servir contenido bajo el subdominio afectado.
¿Un CNAME que devuelve NXDOMAIN confirma un takeover?
No. Es una señal de posible recurso dangling, pero hay que comprobar si el nombre puede reutilizarse y si el proveedor permite asociar el dominio. Muchos falsos positivos empiezan precisamente con un NXDOMAIN.
¿Qué servicios pueden verse afectados?
Cualquier servicio externo cuyo identificador forme parte del hostname o permita asociar dominios personalizados puede ser relevante. Entre los casos conocidos se encuentran servicios de Azure, AWS S3, GitHub Pages, Heroku, Vercel, Netlify y distintas plataformas SaaS/CDN.
¿Cuál es la diferencia entre subdomain takeover y DNS hijacking?
En DNS hijacking el atacante altera o compromete la resolución DNS. En un subdomain takeover el DNS legítimo no ha sido modificado: continúa apuntando a un recurso externo que la propia organización dejó de controlar.
¿Cómo se evita?
Elimina los registros DNS antes de destruir recursos externos, monitoriza CNAME dangling, activa verificaciones de dominio cuando estén disponibles y evita confiar de forma global en todos los subdominios mediante cookies, CORS o OAuth.
Referencias
- can-i-take-over-xyz — fingerprints y estado comunitario de servicios.
- Stratus Security — Azure Subdomain Takeover Guide.
- Stratus Security — AWS Subdomain Takeover Guide.
- 0xpatrik — Takeover Proofs.
- ProjectDiscovery — Nuclei takeover templates.