Toma de control de subdominios, explicada — y cómo detectarla | Scanthra

Scanthra · 7 min de lectura · Actualizado Mayo de 2026

El mecanismo, en un párrafo

Hace tres años alguien de tu equipo creó eventos.tuempresa.com como un CNAME apuntando a tu-pagina-evento.herokuapp.com. La campaña de marketing terminó, la app de Heroku fue eliminada, el CNAME en DNS quedó olvidado. Hoy, cualquiera puede registrarse en Heroku, reclamar el nombre tu-pagina-evento.herokuapp.com, y servir cualquier HTML que quiera. Los navegadores que visiten eventos.tuempresa.com recibirán su página, con tu dominio en la barra de direcciones, con la confianza de tu marca. TLS funciona porque servicios como Heroku emiten certificados automáticamente. Desde el punto de vista del navegador, es una visita perfectamente legítima a tu sitio real.

Por qué esto importa

Ataques reales observados en la práctica:

• Phishing. «Inicia sesión en tu-banco.ejemplo.com» lleva a la página del atacante con el candado TLS perfecto.
• Robo de cookies. Si tu dominio padre establece cookies en .ejemplo.com, el subdominio tomado puede leerlas simplemente estando bajo el mismo padre.
• Envenenamiento de SEO. Los atacantes redirigen desde tu subdominio a hosts de fraude publicitario o malware. Google a veces pone en lista negra todo ejemplo.com como resultado.
• Daño de marca. Una historia filtrada como «el propio subdominio de Acme Corp sirve páginas de estafa cripto» es difícil de limpiar.

Los servicios vulnerables

La toma de control de subdominios es una clase de vulnerabilidad contra cualquier SaaS que: (1) permite a los usuarios reclamar un subdominio arbitrario en la plataforma, y (2) no verifica que el reclamante también sea propietario del dominio original. Entre las plataformas históricamente vulnerables se encuentran:

• Heroku, buckets de AWS S3 (alojamiento web estático), Azure Cloud Apps / Traffic Manager / CDN, GitHub Pages, GitLab Pages, Shopify, Squarespace, Tumblr, Webflow, Netlify, Vercel, Fastly, Pantheon, Zendesk, Statuspage, SendGrid, Mailgun, Tilda, Strikingly, Surge.sh, Ghost.io, Cargo, Read the Docs.

El indicador de toma de control de cada plataforma es ligeramente diferente — la mayoría muestran una huella característica de «no such app» / «bucket does not exist» / «404 Not Found» cuando el nombre no está reclamado. El repositorio mantenido por la comunidad EdOverflow/can-i-take-over-xyz en GitHub mantiene la lista actualizada.

Cómo detectar registros colgantes tú mismo

Paso 1 — Enumera tus subdominios

No puedes corregir lo que no conoces. Fuentes para un inventario completo:

• El archivo de zona de tu proveedor DNS — exporta cada registro A, AAAA y CNAME.
• Registros de Transparencia de Certificados mediante crt.sh — cada certificado TLS emitido para tu dominio es público.
• Escaneos pasados, entradas del gestor de contraseñas, wikis internas — cualquier lugar donde alguien haya podido añadir un subdominio que nadie eliminó.

Paso 2 — Resuelve cada uno

Para cada registro:

• Si es un A/AAAA apuntando a una IP que ya no posees — elimínalo.
• Si es un CNAME apuntando a un servicio de terceros, visita la URL y observa la respuesta. «No such app», «There isn't a GitHub Pages site here», «NoSuchBucket» o «Repository not found» son señales de toma de control.
• Si dig +short cname.subdominio devuelve NXDOMAIN para el destino — es una señal fuerte de toma de control.

Paso 3 — Elimina o reclama

Si no necesitas el subdominio, elimina el registro DNS. Si aún lo necesitas, apúntalo a un activo actual. Evita apuntar a apps cloud «de marcador de posición» — tienden a derivar a un estado vulnerable.

Cómo prevenir el próximo

• Propietario DNS por registro. Cada registro de subdominio en tu zona debe tener un propietario documentado en las notas de tu proveedor DNS o en una hoja de cálculo interna.
• Lista de verificación de desprovisión. «Cierra el sitio de la campaña» debe incluir «elimina el CNAME DNS que apunta al host de la campaña».
• Revisión DNS trimestral. 30 minutos por trimestre evitan un incidente que daña la marca.
• Comodines con cuidado. Un CNAME comodín *.ejemplo.com a un servicio de terceros es una invitación permanente a la toma de control para cualquier nombre no reclamado.

Cómo Scanthra detecta esto

Nuestro módulo Reconocimiento DNS consulta los registros públicos de Transparencia de Certificados (de forma pasiva, sin fuerza bruta DNS) y señala cada subdominio que alguna vez tuvo un certificado real. Mostramos subdominios de desarrollo, staging y de aspecto administrativo como problemas detectados — los candidatos clásicos a registros olvidados y colgantes. La detección de toma de control de subdominios en sí (verificar si cada destino CNAME no está reclamado en un proveedor vulnerable conocido) está en nuestra hoja de ruta y beneficia primero a los usuarios de pago.