Secuestro de subdominios: cómo un registro DNS olvidado se convierte en la web de otro

El secuestro de un subdominio (subdomain takeover) ocurre cuando un registro DNS de su dominio sigue apuntando a un servicio externo que ya no utiliza. Si ese servicio permite que cualquiera reclame el nombre que usted dejó libre, un desconocido puede registrarlo y empezar a servir su propio contenido en promo.yourcompany.com. Los visitantes ven su dominio en la barra de direcciones, así que no tienen motivo para desconfiar de la página.

La causa de fondo es casi siempre la misma: un registro DNS huérfano (en inglés, "dangling DNS"). Alguien lanzó una web de campaña, un centro de ayuda o una aplicación de prueba en una plataforma en la nube, apuntó un subdominio hacia ella y más tarde eliminó la aplicación, pero no el registro DNS. Microsoft describe exactamente esta secuencia para Azure, y el mismo patrón se da en muchas plataformas de alojamiento, almacenamiento y SaaS.

La buena noticia: es un problema de inventario, y puede comprobarlo usted mismo con unas pocas consultas DNS.

Cómo un registro huérfano acaba en secuestro

El problema suele seguir 3 pasos:

1. Creación. Un equipo crea yourcompany-promo.azurewebsites.net (o un bucket, un sitio de Pages, un endpoint de CDN) y añade un CNAME para que promo.yourcompany.com apunte a él.
2. Retirada. La campaña termina y la aplicación se elimina, pero nadie borra el CNAME. El subdominio apunta ahora a un nombre que ya no le pertenece.
3. Secuestro. Alguien detecta el nombre huérfano, crea un recurso con el mismo nombre en la misma plataforma y, desde ese momento, controla lo que muestra promo.yourcompany.com.

No todas las plataformas permiten el último paso. El proyecto comunitario can-i-take-over-xyz mantiene una lista de servicios, indica cuáles son vulnerables y recoge el texto de error que muestra cada uno para un nombre no reclamado, por ejemplo "The specified bucket does not exist" en Amazon S3.

Por qué importa más que una página desfigurada

Un subdominio secuestrado no es solo una página bochornosa. Según la guía de Microsoft, los riesgos incluyen:

• Robo de cookies. Muchas aplicaciones web asignan las cookies de sesión a *.yourcompany.com, de modo que cualquier subdominio puede leerlas.
• Un certificado válido para el atacante. Quien controla el subdominio puede obtener un certificado TLS para él, así que también aparece el candado.
• Phishing convincente. Una página de acceso en su dominio real es mucho más difícil de detectar que una en un dominio similar.
• Interceptación del correo. Un registro MX huérfano puede permitir que alguien reciba el correo enviado a ese subdominio.

La OWASP Web Security Testing Guide añade la variante más grave: un registro NS que delega un subdominio en servidores de nombres de un dominio que ya no está registrado. Quien registre ese dominio controla toda la zona delegada.

Cómo revisar su propio DNS

Empiece por una lista de todos sus subdominios. La exportación de la zona de su proveedor de DNS es la mejor fuente. El historial de certificados es una segunda fuente útil, porque casi todos los certificados emitidos para sus nombres quedan anotados en los registros de Certificate Transparency.

Para cada subdominio, mire adónde apunta:

dig +short CNAME promo.yourcompany.com
dig +short NS dev.yourcompany.com
dig +short MX shop.yourcompany.com

Después compruebe que cada destino sigue existiendo y sigue siendo suyo:

dig promo.yourcompany.com
curl -sI https://promo.yourcompany.com

Señales de alarma:

• el destino del CNAME devuelve NXDOMAIN (el nombre ya no existe),
• la página muestra un error de la plataforma como "No such app", "Repository not found" o "There isn't a GitHub Pages site here",
• un registro NS apunta a servidores de nombres de un dominio que no reconoce o que ha caducado,
• nadie en la empresa sabe para qué servía el subdominio.

Pruebe solo nombres de su propio dominio. No intente reclamar un recurso para "demostrar" el problema; basta con eliminar el registro.

Cómo corregirlo

1. Elimine el registro huérfano de su zona DNS. Esta es la solución tanto en la guía de Microsoft como en la de OWASP.
2. Si todavía necesita el subdominio, vuelva a crear el recurso en su propia cuenta antes de dirigir de nuevo el tráfico hacia él.
3. Compruebe si ocurrió algo mientras el registro estuvo huérfano: certificados inusuales para ese nombre, enlaces en su aplicación o en sus correos que todavía lo usen, URL de redirección OAuth que lo incluyan.
4. Use la verificación de titularidad cuando la plataforma la ofrezca. Azure App Service, por ejemplo, admite un registro TXT asuid.<subdomain> para que ninguna otra suscripción pueda validar el dominio personalizado.
5. Corrija el proceso, no solo el registro. Añada "eliminar la entrada DNS" a la lista de pasos para dar de baja cualquier servicio y mantenga un inventario sencillo de qué subdominio apunta a qué plataforma y quién es su responsable.

Lista de comprobación breve

• Exporte su zona DNS y enumere todos los registros CNAME, NS y MX.
• Para cada uno, confirme que el destino existe y pertenece a su empresa.
• Elimine los registros de servicios que se dieron de baja.
• Compare su zona con los nombres de los registros de Certificate Transparency para encontrar subdominios que nadie documentó.
• Revíselo de nuevo cada vez que termine una campaña, un producto o la relación con un proveedor.

Los registros huérfanos suelen convivir con otras piezas olvidadas, como los antiguos servidores de preproducción y de pruebas. Limpiar ambos a la vez suele ser la mejora más rápida.

Dónde encaja Datahorses

Datahorses vigila su empresa desde fuera todos los días: elabora la lista de sus subdominios, comprueba adónde apunta cada CNAME y señala los registros que llevan a servicios que ya no existen. No entramos en sus sistemas ni necesitamos ningún acceso, y cada hallazgo llega con los pasos exactos para su desarrollador. Puede ver la lista completa de lo que vigilamos o echar un vistazo al panel de ejemplo.