Subdomain Takeover: Guía de seguridad DNS 2025 | Prevención

Introducción

En el panorama en rápida evolución de la ciberseguridad, una vulnerabilidad sigue afectando a organizaciones de todos los tamaños: el takeover de subdominios. Mientras los equipos de seguridad se concentran en parchear vulnerabilidades de software y defenderse de ataques sofisticados, recursos en la nube abandonados y registros DNS olvidados crean puertas traseras invisibles que los atacantes pueden explotar en pocas horas. Los ciberdelincuentes pueden aprovechar un subdominio no utilizado para alojar sitios de phishing, distribuir malware y capturar datos sensibles de usuarios en horas, transformando tu dominio de confianza en un arma contra tus propios clientes.

Esta guía completa explora la mecánica del subdomain takeover, revela cómo los atacantes descubren y explotan estas vulnerabilidades, y ofrece estrategias prácticas para proteger tu infraestructura digital. Ya seas profesional de seguridad, desarrollador o propietario de negocio, entender esta amenaza es crucial para mantener la integridad de tu marca y proteger a tus usuarios.

¿Qué es el Subdomain Takeover?

Las vulnerabilidades de takeover de subdominios ocurren cuando uno de los subdominios de la empresa apunta a un servicio de terceros que ya no existe, permitiendo que un atacante reclame ese servicio y controle lo que aparece en el subdominio. Esta configuración errónea aparentemente simple crea un escenario peligroso donde los atacantes pueden servir contenido malicioso desde dominios en los que los usuarios confían inherentemente.

La anatomía de un subdominio vulnerable

La vulnerabilidad suele surgir a través de una secuencia predecible de eventos:

Provisionamiento del servicio: Tu equipo de desarrollo crea un subdominio (por ejemplo, marketing.tudominio.com) y lo apunta a un servicio de terceros como AWS S3, Azure, GitHub Pages o Heroku.
Configuración DNS: Se crea un registro DNS (usualmente un CNAME) para enrutar el tráfico desde tu subdominio al servicio externo.
Desmantelamiento del servicio: El proyecto termina, el recurso en la nube se elimina, pero el registro DNS permanece.
La ventana de vulnerabilidad: Estos registros DNS también se conocen como entradas “dangling DNS”, creando una oportunidad para que los atacantes reclamen el mismo nombre de recurso y controlen el contenido de tu subdominio.

Por qué esto importa para tu negocio

El takeover de subdominios representa riesgos de seguridad significativos: ataques de phishing — los atacantes pueden alojar contenido malicioso en el subdominio, aprovechando la confianza asociada con el dominio principal. Robo de datos — información sensible puede ser robada si los usuarios son engañados para interactuar con el subdominio comprometido. Las implicaciones van más allá de la seguridad técnica, afectando la reputación de la marca, la confianza del cliente y el cumplimiento regulatorio.

Impacto real: Ejemplos recientes

La amenaza del subdomain takeover no es teórica. Organizaciones en todo el mundo siguen siendo víctimas de estos ataques, con consecuencias devastadoras.

La campaña SubdoMailing

Recientemente, una masiva campaña de fraude publicitario llamada “SubdoMailing” utilizó más de 8,000 dominios legítimos para enviar correos fraudulentos a gran escala. Al explotar registros DNS dangling, los atacantes aprovecharon la reputación de dominios confiables para evadir filtros de seguridad de correo, demostrando cómo los takeovers de subdominios pueden habilitar ataques sofisticados y a gran escala.

Implicaciones en la cadena de suministro

En una investigación de octubre de 2024 a enero de 2025, los investigadores buscaron buckets de AWS S3 eliminados con referencias existentes que apuntaban a ellos, específicamente buscando buckets que pudieron haber sido usados en gestión de pipelines, desarrollo y despliegue de aplicaciones. Esta investigación destacó cómo los takeovers de subdominios pueden convertirse en ataques a la cadena de suministro, comprometiendo pipelines de desarrollo y mecanismos de distribución de software.

Incidentes de alto perfil

Sitios web gubernamentales, empresas Fortune 500 y plataformas populares han sufrido takeovers de subdominios. Es posible que hayas visto noticias sobre la defacement del sitio web de la administración Trump como ejemplo. Estos incidentes subrayan que ninguna organización está exenta de esta vulnerabilidad, sin importar su tamaño o madurez en seguridad.

Servicios y plataformas comúnmente vulnerables

Comprender qué servicios son comúnmente explotados ayuda a priorizar tus esfuerzos de seguridad. Aquí las plataformas más frecuentemente atacadas:

Servicios de almacenamiento en la nube

Amazon S3: Si el desarrollador elimina el bucket pero olvida remover el registro DNS correspondiente, inadvertidamente introduce una nueva vulnerabilidad de takeover de subdominio. Un atacante puede crear un nuevo bucket en AWS S3 con el mismo nombre a través de la consola y tomar control de todo el contenido.

Azure Blob Storage: Similar a S3, cuando las cuentas de almacenamiento se eliminan pero los registros DNS persisten, los atacantes pueden recrear cuentas con nombres coincidentes.

Plataformas como servicio (PaaS)

Heroku: Las apps eliminadas dejan registros CNAME apuntando a herokuapp.com que pueden ser reclamados.
GitHub Pages: Repositorios eliminados sin remover las entradas DNS correspondientes crean oportunidades de takeover.
Shopify: Proyectos de comercio electrónico migrados o abandonados a menudo dejan configuraciones DNS vulnerables.
Fastly y CloudFront: Configuraciones CDN eliminadas mientras los registros DNS permanecen activos.

Plataformas de gestión de contenido y marketing

WordPress.com: Subdominios de blogs alojados que han sido desactivados.
HubSpot: Plataformas de automatización de marketing con páginas de destino abandonadas.
Zendesk: Subdominios de soporte al cliente que apuntan a centros de ayuda desactivados.

Guía paso a paso: Encontrando vulnerabilidades de takeover de subdominios

Los profesionales de seguridad y hackers éticos usan enfoques sistemáticos para identificar estas vulnerabilidades. Entender el proceso ayuda tanto a defensores como a testers autorizados.

Paso 1: Enumeración de subdominios

La primera fase implica descubrir todos los subdominios asociados a un dominio objetivo:

Métodos pasivos: - Registros de transparencia de certificados: Buscar en crt.sh todos los certificados emitidos para el dominio objetivo - Agregadores DNS: Usar servicios como SecurityTrails, DNSDumpster o VirusTotal - Reconocimiento en motores de búsqueda: Utilizar Google dorks (por ejemplo, site:*.ejemplo.com)

Métodos activos: - Fuerza bruta DNS: Usar herramientas como Sublist3r, Amass o Subfinder para probar nombres comunes de subdominios - Intentos de transferencia de zona: Verificar si los servidores DNS permiten transferencias de zona (configuración incorrecta)

Paso 2: Análisis de registros DNS

Una vez identificados los subdominios, analizar sus registros DNS:

# Verificar registros CNAME
dig marketing.ejemplo.com CNAME

# Buscar registros NS
dig dev.ejemplo.com NS

# Examinar registros A
dig blog.ejemplo.com A

Buscar respuestas que indiquen servicios externos, especialmente mensajes de error como “NXDOMAIN” o registros que apunten a plataformas de terceros.

Paso 3: Identificación de vulnerabilidades

Si el proceso de provisión o desprovisionamiento (eliminación) de un host virtual no se maneja correctamente, puede haber una oportunidad para que un atacante tome control de un subdominio. Indicadores clave de vulnerabilidad incluyen:

CNAME apuntando a recursos inexistentes: El registro DNS existe, pero el recurso objetivo no
Mensajes de error: “404 Not Found,” “NoSuchBucket,” “No hay un sitio de GitHub Pages aquí”
Nombres de usuario no reclamados: La plataforma permite reclamar el nombre exacto referenciado en el registro DNS

Paso 4: Pruebas de verificación

Antes de reportar una vulnerabilidad, verificar que sea explotable:

Reclamar el recurso: En la plataforma objetivo, crear una cuenta/recurso que coincida con el objetivo del registro DNS
Desplegar contenido de prueba: Colocar un identificador único e inofensivo (por ejemplo, “Prueba de concepto por [Tu Nombre]”)
Acceder vía subdominio: Visitar el subdominio vulnerable para confirmar que aparece tu contenido
Documentar minuciosamente: Tomar capturas de pantalla del proceso, registros DNS y la toma de control exitosa

Herramientas para detección automatizada

Varias herramientas especializadas facilitan la detección de takeover de subdominios:

SubOver: Herramienta en Python que verifica vulnerabilidades de takeover en múltiples servicios
subjack: Herramienta en Go con firmas extensas de servicios
Nuclei: Escáner de vulnerabilidades extensible con plantillas para takeover de subdominios
Can I Take Over XYZ: Base de datos completa de servicios vulnerables a takeover

El proceso de explotación (Perspectiva ética)

Comprender cómo los atacantes explotan los takeovers de subdominios ayuda a los equipos de seguridad a pensar como adversarios y fortalecer defensas.

Fase de reconocimiento

Los atacantes comienzan con un reconocimiento amplio, identificando organizaciones con huellas digitales grandes y numerosos subdominios. Se enfocan en: - Empresas en procesos de fusiones o adquisiciones (mayor probabilidad de recursos abandonados) - Organizaciones con campañas de marketing frecuentes (páginas de destino temporales) - Empresas tecnológicas con múltiples proyectos en desarrollo

Reclamar el recurso

Una vez identificado un subdominio vulnerable, la explotación suele ser sencilla:

Crear una cuenta en la plataforma identificada (AWS, Azure, GitHub, etc.)
Provisionar un recurso con el mismo nombre referenciado en el registro DNS
Desplegar contenido malicioso diseñado para explotar la confianza del usuario

Actividades maliciosas

Con control establecido, los atacantes pueden:

Operaciones de phishing: Los adversarios no necesitan forzar su entrada cuando pueden colarse a través de activos descuidados. Crean páginas de inicio de sesión convincentes en subdominios confiables para recolectar credenciales.

Distribución de malware: Servir kits de explotación o descargas maliciosas desde dominios en los que el software de seguridad confía.

Recolección de datos: Recopilar cookies, tokens de sesión y datos enviados por usuarios para servicios legítimos.

Daño a la reputación: Dañar subdominios con contenido embarazoso o inapropiado para perjudicar la reputación de la marca.

Manipulación SEO: Crear contenido spam en subdominios de alta autoridad para manipular rankings de búsqueda.

Estrategia de defensa integral

Protegerse contra el takeover de subdominios requiere un enfoque en capas que combine controles técnicos, mejoras en procesos y conciencia organizacional.

Acciones inmediatas

Auditoría de subdominios: Enumerar todos los subdominios de tu organización y documentar su propósito y propiedad.

Inventario de registros DNS: Crear un inventario completo de registros DNS, especialmente CNAMEs que apunten a servicios externos.

Identificar registros huérfanos: Los subdominios son vulnerables cuando los registros DNS apuntan a servicios desmantelados o recursos expirados. Por ejemplo, si tu equipo retira un proyecto alojado en Amazon S3 pero el registro DNS aún apunta a un bucket inexistente, los atacantes pueden reclamar y explotar ese bucket.

Eliminar referencias dangling: Borrar registros DNS que ya no sirven a recursos activos.

Mejoras en procesos y políticas

Establecer procedimientos de desmantelamiento: Crear procesos formales que aseguren la eliminación de registros DNS antes de eliminar recursos en la nube. Hacer la limpieza DNS un paso obligatorio en las listas de verificación de cierre de proyectos.

Implementar gestión de cambios: Requerir aprobación y documentación para todos los cambios DNS, con revisiones periódicas para validar la necesidad de registros.

Asignar propiedad: Designar propietarios claros para cada subdominio y registro DNS, asegurando responsabilidad en el mantenimiento.

Revisiones trimestrales: Programar auditorías regulares de registros DNS y recursos en la nube para identificar y corregir configuraciones incorrectas.

Controles técnicos

Monitoreo DNS: Implementar soluciones de monitoreo continuo que alerten sobre cambios DNS e identifiquen registros dangling.

Escaneo automatizado: Desplegar herramientas como SubOver o Nuclei en horarios regulares para detectar vulnerabilidades proactivamente.

Etiquetado de recursos en la nube: Etiquetar todos los recursos en la nube con información del proyecto y asociaciones DNS para facilitar el seguimiento.

Prevenir reutilización de recursos: Algunos proveedores en la nube ofrecen opciones para eliminar recursos de forma permanente, evitando la reutilización de nombres.

Precaución con registros comodín: Aunque los registros DNS comodín (*) pueden mitigar algunos riesgos de takeover, introducen otras preocupaciones de seguridad y deben evaluarse cuidadosamente.

Protecciones del proveedor de nube

Los principales proveedores de nube han implementado protecciones, pero entender sus limitaciones es crucial:

Azure: Los registros CNAME son especialmente vulnerables a esta amenaza, pero Azure ha implementado requisitos de verificación de dominio para ciertos servicios, requiriendo prueba de propiedad antes de agregar dominios personalizados.

AWS: Route 53 ofrece registros alias que se eliminan automáticamente cuando se eliminan los recursos objetivo, aunque los registros CNAME siguen siendo vulnerables.

Google Cloud: Los procesos de verificación de dominio para muchos servicios reducen pero no eliminan los riesgos de takeover.

Herramientas de seguridad y monitoreo

Integra la detección de takeover de subdominios en tu flujo de trabajo de seguridad:

Plataformas de monitoreo continuo: Servicios como SecurityTrails, DNSdumpster o Detectify monitorean continuamente cambios DNS y vulnerabilidades.

Programas de bug bounty: Incentivar a investigadores externos a identificar y reportar vulnerabilidades de takeover mediante plataformas como HackerOne o Bugcrowd. El feed de Hacktivity de HackerOne — una recopilación curada de informes divulgados públicamente — ha visto varias reportes de takeover de subdominios.

Integración SIEM: Configurar tu sistema de gestión de información y eventos de seguridad para alertar sobre cambios DNS y actividad inusual en subdominios.

Respuesta ante un takeover de subdominio

Si descubres un takeover activo, responde rápidamente:

Respuesta inmediata

Verificar el takeover: Confirmar que el subdominio está comprometido y documentar el contenido malicioso.
Eliminar registros DNS: Borrar inmediatamente el registro DNS que apunta al recurso comprometido. Esto detiene el tráfico hacia el contenido del atacante.
Notificar a las partes interesadas: Informar a los equipos de seguridad, asesoría legal y unidades de negocio afectadas.
Evaluar impacto: Determinar qué contenido se sirvió, cuánto tiempo existió el takeover y el posible número de víctimas.

Fase de investigación

Revisar logs de acceso: Si están disponibles, analizar los logs de consultas DNS para entender el alcance de la exposición.
Verificar compromiso de datos: Investigar si se recopilaron datos de usuarios o se phishingearon credenciales.
Análisis forense: Documentar la metodología del ataque para futuras prevenciones.

Acciones post-incidente

Implementar controles preventivos: Abordar la causa raíz y aplicar las lecciones aprendidas en toda la infraestructura.
Notificación a usuarios: Si se comprometieron datos de usuarios, cumplir con los requisitos de notificación de brechas.
Reportar a reguladores: Informar a las autoridades pertinentes según las regulaciones aplicables.

Mejores prácticas para protección a largo plazo

La seguridad sostenible requiere integrar la prevención de takeover de subdominios en la cultura organizacional:

Educación del equipo de desarrollo

Capacitar a los desarrolladores sobre riesgos de takeover de subdominios, enfatizando: - La importancia de la higiene DNS - Procedimientos adecuados de desmantelamiento - Gestión segura de recursos en la nube

Infraestructura como código (IaC)

Gestionar registros DNS mediante infraestructura como código versionada: - Rastrear todos los cambios DNS en repositorios Git - Implementar validaciones automáticas para detectar registros dangling - Usar Terraform, CloudFormation u otras herramientas similares para gestión DNS

Conciencia de seguridad

Incluir el temática de takeover de subdominios en programas de concienciación de seguridad: - Explicar el impacto en el negocio a stakeholders no técnicos - Demostrar cómo pequeñas omisiones crean vulnerabilidades mayores - Fomentar una cultura donde la seguridad sea responsabilidad de todos

Gestión de proveedores

Al trabajar con servicios de terceros: - Documentar qué servicios tienen registros DNS apuntando a ellos - Revisar contratos de proveedores por cláusulas sobre desmantelamiento de recursos - Establecer canales de comunicación para notificar a proveedores sobre preocupaciones de seguridad

Conclusión

El takeover de subdominios representa una tormenta perfecta de infraestructura olvidada, adopción rápida de la nube y procesos de desmantelamiento inadecuados. Los adversarios no necesitan forzar su entrada cuando pueden colarse a través de activos descuidados de una organización. Los takeovers de subdominios son un ejemplo claro de cómo los atacantes explotan configuraciones menores para lograr un impacto significativo.

La buena noticia es que el takeover de subdominios es completamente prevenible mediante una gestión diligente de DNS, procedimientos adecuados de desmantelamiento y monitoreo continuo. Implementando las estrategias de esta guía — desde auditorías inmediatas hasta mejoras en procesos a largo plazo — las organizaciones pueden eliminar esta vulnerabilidad de su superficie de ataque.

Recuerda que la seguridad no es un destino, sino un camino. Auditorías regulares, monitoreo automatizado y conciencia organizacional transforman el takeover de subdominios de una amenaza invisible en un riesgo gestionado. Toma acción hoy: inventaría tus subdominios, limpia registros DNS dangling e implementa procesos que prevengan futuras vulnerabilidades.

La reputación de tu marca y la confianza de tus usuarios dependen de la infraestructura invisible de registros DNS. No permitas que configuraciones olvidadas se conviertan en la puerta trasera que socava tu inversión en seguridad. Comienza tu auditoría de subdominios hoy, porque los atacantes ya están buscando tus entradas DNS dangling.

Sobre el autor: Este artículo fue investigado y redactado con las mejores prácticas de ciberseguridad vigentes a octubre de 2025, basándose en fuentes líderes de la industria como Microsoft Azure Security, CrowdStrike, OWASP, HackerOne y recientes informes de inteligencia de amenazas sobre campañas de takeover de subdominios.