Un subdominio abandonado, una puerta abierta
Tu empresa tiene blog.example.com apuntando a una aplicacion en Heroku que se dejo de usar hace seis meses. Nadie se acordo de eliminar el registro DNS. Un atacante registra una nueva aplicacion en Heroku con el mismo nombre y, sin tocar tu infraestructura, ahora controla tu subdominio. Puede servir paginas de phishing, robar cookies del dominio principal y evadir politicas de seguridad como CSP.
Esto es subdomain takeover, y es mucho mas frecuente de lo que parece.
Como funciona el ataque
El subdomain takeover explota una desconexion entre la configuracion DNS de una organizacion y los servicios externos a los que apunta. El flujo tipico es el siguiente:
1. La empresa crea un registro CNAME:
blog.example.com --> CNAME --> myapp.herokuapp.com
2. La empresa elimina la aplicacion de Heroku,
pero NO elimina el registro DNS.
3. El atacante crea una nueva aplicacion en Heroku
con el nombre "myapp".
4. blog.example.com ahora resuelve al servidor del atacante.
5. El atacante controla un subdominio legitimo
de la organizacion.
El punto critico es el paso 2. Cuando el servicio en la nube se da de baja pero el registro DNS permanece, se crea lo que se denomina un dangling record (registro colgante). Ese registro apunta a un recurso que ya no existe y que cualquier tercero puede reclamar.
El atacante no necesita comprometer ningun servidor. No necesita explotar una vulnerabilidad de software. Solo necesita detectar un registro DNS que apunta al vacio y reclamar el recurso en el servicio correspondiente.
Servicios vulnerables
No todos los servicios en la nube son susceptibles, pero la lista de los que si lo son es extensa:
- GitHub Pages: registros CNAME apuntando a
usuario.github.io - Heroku: subdominios apuntando a
app.herokuapp.com - AWS S3: registros apuntando a
bucket.s3.amazonaws.com - Azure: subdominios apuntando a
app.azurewebsites.net - Shopify: dominios personalizados configurados en tiendas eliminadas
- Zendesk: subdominios de soporte desvinculados
- Fastly, Netlify, Vercel: configuraciones de CDN abandonadas
- Surge.sh, Fly.io, Pantheon: plataformas de hosting con namespaces reutilizables
El patron comun es claro: cualquier servicio donde el nombre del recurso puede ser reclamado por un tercero despues de ser liberado es potencialmente vulnerable. Si la plataforma no reserva los nombres de recursos eliminados, un atacante puede apropiarselos.
El peligro real
El subdomain takeover no es una curiosidad tecnica. Sus consecuencias son severas y directas:
Robo de cookies. Si el dominio principal establece cookies con el atributo Domain=.example.com, el subdominio controlado por el atacante puede leerlas. Esto incluye tokens de sesion, preferencias de usuario y cualquier otro dato almacenado en cookies del dominio padre.
Phishing de alta credibilidad. Una pagina de phishing servida desde soporte.example.com es ordenes de magnitud mas convincente que una servida desde un dominio aleatorio. El certificado TLS sera valido (muchos servicios emiten certificados automaticamente), la URL pertenece a la organizacion legitima, y ningun filtro de correo ni navegador la marcara como sospechosa.
Evasion de CSP. Si la politica Content-Security-Policy de tu sitio principal permite *.example.com como origen de scripts, el atacante puede inyectar JavaScript desde el subdominio tomado. CSP, disenada para prevenir XSS, se convierte en un coladero.
Recepcion de correo electronico. Los registros MX tambien pueden ser victimas de dangling records. Si un registro MX apunta a un servicio de correo desmantelado, un atacante puede reclamar ese endpoint y recibir emails destinados al subdominio, incluyendo posibles tokens de restablecimiento de contrasena.
Robo de tokens OAuth. Si las URIs de redireccion de un flujo OAuth incluyen el subdominio vulnerable, el atacante puede interceptar los tokens de autorizacion durante el proceso de autenticacion.
Como detectarlo
La deteccion proactiva es la unica defensa efectiva. Cuando un atacante toma control de un subdominio, el registro DNS funciona correctamente desde el punto de vista tecnico: resuelve, el servicio responde, el certificado es valido. No hay alertas de monitoring convencional.
Auditar todos los registros DNS periodicamente. No solo los registros A. Los registros CNAME, MX, NS y SRV pueden apuntar a servicios externos y son igualmente vulnerables. Exporta la zona DNS completa y revisa cada entrada.
Buscar respuestas NXDOMAIN o SERVFAIL. Si un subdominio configurado en tu zona DNS devuelve NXDOMAIN (dominio no encontrado) al resolver el destino del CNAME, es un indicador claro de dangling record. El registro apunta a un recurso que no existe.
Verificar que los servicios asociados siguen activos. Para cada registro CNAME, confirma que la aplicacion, bucket o proyecto sigue existiendo en la plataforma correspondiente. Si fue eliminado, elimina tambien el registro DNS inmediatamente.
Usar herramientas automatizadas. La base de datos del proyecto can-i-take-over-xyz cataloga que servicios son susceptibles de takeover y como verificarlo. Herramientas como subjack, nuclei o dnsx permiten escanear a escala.
UareSafe incluye deteccion de dangling records en su escaner DNS. El analisis identifica registros CNAME que apuntan a recursos inexistentes y los marca como hallazgos criticos. Esto se ejecuta automaticamente como parte de la dimension de Seguridad Tecnica.
Como prevenirlo
La prevencion se reduce a una disciplina operativa: gestion rigurosa del ciclo de vida del DNS.
Eliminar el registro DNS antes de dar de baja el servicio. El orden importa. Primero se elimina el registro CNAME, despues se desactiva el servicio. Si se hace al reves, existe una ventana de exposicion durante la cual el registro apunta a un recurso que cualquiera puede reclamar. DNS primero, servicio despues.
Mantener un inventario de DNS y revisarlo trimestralmente. Cada registro CNAME que apunte a un servicio externo debe estar documentado con el propietario, la fecha de creacion y el proposito. Una revision trimestral permite detectar registros huerfanos antes de que se conviertan en un riesgo.
Implementar DNSSEC. Aunque DNSSEC no previene directamente el subdomain takeover, anade autenticacion a las respuestas DNS, dificultando ataques de envenenamiento de cache que podrian combinarse con un takeover para amplificar el impacto.
Usar herramientas de gestion de activos cloud. En organizaciones con multiples equipos desplegando en diversas plataformas, una herramienta centralizada de inventario de activos cloud ayuda a detectar recursos huerfanos que todavia tienen registros DNS asociados.
Configurar alertas de cambios en resolucion DNS. Si un subdominio que resolvia a una IP especifica empieza a resolver a otra diferente, algo ha cambiado. Ese cambio puede ser legitimo o puede indicar un takeover. Un sistema de monitoring que detecte variaciones en la resolucion DNS permite actuar antes de que el dano se materialice.
Casos reales
Las plataformas de bug bounty como HackerOne y Bugcrowd reciben informes de subdomain takeover de forma constante. Es una de las categorias mas reportadas, y las organizaciones afectadas incluyen grandes corporaciones tecnologicas, bancos, organismos gubernamentales y universidades. Las organizaciones con cientos o miles de subdominios son especialmente vulnerables porque la superficie de ataque crece con cada registro, y la probabilidad de que alguno quede huerfano tras una reorganizacion, migracion o decommissioning es alta.
En muchos casos documentados publicamente, los subdominios tomados se mantuvieron bajo control del atacante durante semanas o meses antes de ser detectados, precisamente porque ningun sistema de monitoring convencional genera alertas para un subdominio que tecnicamente "funciona".
Que evalua UareSafe
La dimension DNS de UareSafe incluye tres controles directamente relacionados con este vector de ataque:
- Deteccion de dangling records (
dns-dangling): identifica registros CNAME, MX y NS que apuntan a recursos inexistentes o reclamables por terceros. Cualquier hallazgo se clasifica como critico. - Validacion de registros MX (
dns-mx): verifica que los servidores de correo configurados son legitimos y estan operativos, previniendo la recepcion no autorizada de email. - Cumplimiento de DNSSEC (
dnssec): comprueba que la zona DNS tiene firmas validas, anadiendo una capa de autenticacion a las respuestas DNS.
Estos controles se ejecutan automaticamente como parte de la certificacion UareSafe y se reevaluan en cada ciclo de monitoring.
Conclusion
La higiene del DNS es tan importante como parchear servidores. Cada registro colgante es una puerta abierta que un atacante puede cruzar sin necesidad de explotar una sola vulnerabilidad de software. Y la solucion es simple: audita tu DNS, elimina lo que no uses, y establece un proceso para que los registros se gestionen con el mismo rigor que el codigo en produccion.
Tu zona DNS no es un archivo estatico que se configura una vez y se olvida. Es superficie de ataque viva que requiere mantenimiento continuo. Tratar cada registro como un activo con ciclo de vida propio es la diferencia entre una organizacion que controla su perimetro y una que tiene puertas abiertas sin saberlo.