Un subdomain takeover ocurre cuando un atacante secuestra un subdominio legítimo de tu organización porque apunta a un servicio que ya no existe. Ese subdominio abandonado — el típico blog.tuempresa.com que montaste en 2019 y olvidaste — se convierte en una puerta abierta para phishing, robo de cookies y destrucción de reputación. El secuestro de subdominio explota un fallo conocido como DNS dangling: registros DNS huérfanos que apuntan a la nada. Y esa nada, cualquiera puede reclamarla. El takeover de dominio parcial es uno de los vectores más subestimados en seguridad web, y lleva años apareciendo en programas de bug bounty con recompensas que superan los 10.000 dólares.
Si te suena a problema de "empresas grandes", espera. Cualquier organización con un dominio y tres subdominios olvidados es candidata.
Cómo funciona el secuestro de subdominio paso a paso
El mecanismo es brutalmente simple. Imagina que tu empresa creó landing.tuempresa.com con un CNAME apuntando a tuempresa.herokuapp.com. La campaña terminó, alguien borró la app de Heroku, pero nadie tocó el DNS. Ese registro CNAME sigue ahí, apuntando a un recurso que ya no existe.
Ahora llega un atacante. Escanea subdominios con herramientas como Sublist3r, Amass o subfinder. Encuentra landing.tuempresa.com. Comprueba que el CNAME apunta a Heroku y que el nombre está libre. Crea una cuenta en Heroku, reclama ese nombre, sube su propio contenido. Listo: landing.tuempresa.com ahora sirve lo que el atacante quiera, con el certificado SSL de tu dominio.
El DNS dangling es el corazón del problema. Un registro DNS que apunta a un recurso inexistente es como dejar las llaves puestas en una puerta que da a la calle. Los servicios más afectados históricamente:
- GitHub Pages — si borras el repo pero mantienes el CNAME
- Heroku — nombres de app reutilizables tras eliminación
- AWS S3 — buckets con nombre específico que cualquiera puede recrear
- Azure — subdominios de
cloudapp.azure.comyazurewebsites.net - Shopify, Fastly, Pantheon, Surge.sh — y la lista sigue
Microsoft documentó en 2020 que detectó más de 600 subdominios propios vulnerables a subdomain takeover. Si le pasa a Microsoft, le pasa a cualquiera.
Qué puede hacer un atacante con tu subdominio
Aquí la cosa se pone fea. Un subdominio abandonado bajo control del atacante hereda la confianza del dominio principal. Los navegadores, los filtros de correo y los usuarios lo tratan como legítimo. Las posibilidades:
Phishing de alta credibilidad. Una página de login en portal.tuempresa.com que pide credenciales corporativas. El dominio es real, el certificado es válido, el usuario no tiene motivo para sospechar. Esto conecta directamente con técnicas avanzadas de suplantación como las que explicamos en nuestro artículo sobre deepfake y phishing con suplantación de vídeo.
Robo de cookies. Si el dominio principal usa cookies con scope amplio (establecidas para .tuempresa.com), el subdominio secuestrado puede leerlas. Tokens de sesión, cookies de autenticación — todo accesible. Esto puede combinarse con ataques CSRF para ejecutar acciones en nombre del usuario sin que lo sepa.
Distribución de malware. El atacante sube un ejecutable o un script malicioso. Lo enlaza desde foros, emails o redes sociales. La URL pertenece a tu dominio — los filtros de seguridad y los antivirus lo dejan pasar.
SEO spam. Montar una granja de enlaces o contenido basura bajo tu dominio para explotar tu autoridad de dominio. Google penaliza el dominio completo, no solo el subdominio.
| Vector de ataque | Impacto | Dificultad para el atacante |
|---|---|---|
| Phishing en subdominio | Robo de credenciales | Baja |
| Cookie hijacking | Secuestro de sesión | Media |
| Distribución de malware | Infección de usuarios | Baja |
| SEO poisoning | Penalización de dominio | Baja |
| Email spoofing (si SPF incluye subdominio) | Suplantación de correo | Media-Alta |
Casos reales: esto no es teoría
En 2020, investigadores de seguridad descubrieron que Starbucks tenía un subdominio vulnerable que permitía takeover de dominio a través de Azure. El subdominio legítimo podía servir cualquier contenido, incluidas páginas de phishing perfectas. Recompensa del bug bounty: premio de cuatro cifras.
Uber sufrió un caso similar con un subdominio que apuntaba a un bucket S3 eliminado. Un investigador lo reclamó, subió una prueba de concepto, y demostró que podía servir contenido bajo el dominio de Uber. Uber lo clasificó como vulnerabilidad de severidad alta.
El NCSC del Reino Unido publicó en 2021 una guía específica sobre DNS dangling y secuestro de subdominio tras detectar el problema en múltiples departamentos gubernamentales. No era un fallo técnico complejo — era simplemente que nadie llevaba un inventario de subdominios.
En el ámbito académico, un estudio de la Universidad Técnica de Múnich (2021) escaneó los 50.000 dominios más visitados del mundo y encontró que aproximadamente 1 de cada 50 tenía al menos un subdominio potencialmente vulnerable a takeover. La cifra exacta varía según la metodología, pero el orden de magnitud es consistente en varias investigaciones independientes.
Cómo detectar y prevenir el subdomain takeover
La prevención se resume en una frase: no dejes registros DNS apuntando a servicios que ya no usas. Pero la ejecución requiere disciplina.
Auditoría de subdominios. Usa herramientas como Amass (OWASP), subfinder (ProjectDiscovery) o dnsrecon para enumerar todos tus subdominios. Compara con tu inventario interno. Todo lo que no reconozcas, investígalo.
- Enumera todos los registros CNAME, A y AAAA de tu zona DNS
- Verifica que cada recurso destino existe y está bajo tu control
- Elimina registros que apunten a servicios dados de baja
- Documenta cada subdominio activo con su propósito y responsable
- Programa revisiones trimestrales (mínimo)
Herramientas específicas de detección. can-i-take-over-xyz es un repositorio de GitHub mantenido por la comunidad que lista qué servicios son vulnerables a subdomain takeover y cómo verificarlo. Nuclei de ProjectDiscovery tiene templates específicos para detectar takeovers. subjack y tko-subs automatizan la comprobación.
Medidas preventivas en DNS:
- Elimina el CNAME antes de dar de baja el servicio, no después
- Usa registros CAA (Certificate Authority Authorization) para limitar quién puede emitir certificados para tu dominio
- Configura SPF, DKIM y DMARC correctamente para evitar que un subdominio secuestrado envíe correo en tu nombre
- Limita el scope de las cookies al dominio exacto — evita
.tuempresa.comcuando puedas usarwww.tuempresa.com - Si usas WordPress profesional con subdominios para staging o desarrollo, revisa que no queden entornos huérfanos tras el lanzamiento
Para equipos con infraestructura compleja, conviene integrar la monitorización de subdominios en el pipeline de seguridad automatizada. Un script que compruebe la resolución DNS de todos tus subdominios cada semana cuesta poco y ahorra disgustos.
Preguntas frecuentes
¿Cómo sé si alguno de mis subdominios es vulnerable a takeover?
Ejecuta un escaneo con subfinder o Amass para listar todos tus subdominios. Luego usa Nuclei con los templates de subdomain takeover o comprueba manualmente si los destinos CNAME devuelven errores tipo "404 — There isn't a GitHub Pages site here" o "No such app" de Heroku. Cualquier respuesta de "recurso no encontrado" del proveedor de hosting es una señal de alarma.
¿Un subdomain takeover afecta al dominio principal en Google?
Sí. Google puede penalizar la autoridad del dominio completo si detecta contenido spam o malicioso en un subdominio. Además, si el atacante monta una campaña de phishing y tu dominio acaba en listas negras como Google Safe Browsing, el impacto se extiende a todos los subdominios y al dominio raíz.
¿Es legal reclamar un subdominio abandonado de otra empresa?
Depende de la jurisdicción y la intención. En programas de bug bounty, los investigadores reportan la vulnerabilidad sin explotarla. Reclamar el recurso para montar contenido propio sin autorización puede constituir acceso no autorizado bajo legislación como el Computer Fraud and Abuse Act (EE.UU.) o el artículo 197 bis del Código Penal español. La línea entre investigación legítima y abuso la marca la intención y el consentimiento.
¿Los certificados SSL protegen contra el subdomain takeover?
No. De hecho, empeoran el problema. Servicios como Let's Encrypt emiten certificados automáticamente a quien controle el contenido del dominio. Si un atacante reclama tu subdominio en Heroku o GitHub Pages, puede obtener un certificado SSL válido en minutos. El candado verde aparecerá en el navegador, dando falsa sensación de seguridad al usuario. Los registros CAA en DNS pueden mitigar esto parcialmente.
El siguiente paso
Abre la consola DNS de tu proveedor ahora mismo y revisa todos los registros CNAME. Cada uno que apunte a un servicio externo — Heroku, GitHub Pages, Azure, S3, cualquiera — comprueba que el recurso destino sigue existiendo y bajo tu control. Si encuentras un CNAME huérfano, elimínalo. Toda la operación lleva menos de quince minutos y puede ahorrarte un incidente de seguridad serio. Si quieres profundizar en la seguridad de tu infraestructura, echa un vistazo a nuestra guía de seguridad WiFi para asegurar también la capa de red.
