Comprender las adquisiciones de subdominios: Guía práctica para SEO

El secuestro de subdominios no es un tema común en las discusiones de SEO, sin embargo, puede tener un efecto directo y perjudicial en los rankings. Este artículo comparte mi propia experiencia con el tema, junto con el proceso que sigo ahora para comprobar subdominios vulnerables durante las auditorías técnicas.

Antecedentes

Poco después de pasar de un puesto de SEO general a uno puramente técnico, recibí una temida notificación en Search Console:

«Acción manual aplicada – contenido hackeado detectado»

La URL marcada era una promoción navideña olvidada alojada en christmas.client.co.uk. Mi jefe no tenía ni idea de lo que era, y yo tampoco. Después de indagar un poco (y de googlear frenéticamente), me di cuenta de que se trataba de un subdominio de una antigua campaña. Alguien lo había reutilizado para difundir contenido spam.

Afortunadamente, el cliente era receptivo y tenía conocimientos técnicos, y pudimos solucionar el problema en cuestión de horas. Pero el incidente me hizo preguntarme: ¿cuántos otros subdominios descuidados podrían estar al acecho sin que nos diéramos cuenta, listos para ser tomados?

Lo que ocurrió en realidad

Una toma de control de subdominio se produce cuando el registro DNS apunta a un servicio de terceros (por ejemplo, GitHub Pages, Heroku, AWS, etc.) y ese servicio ya no está en uso, pero la entrada DNS sigue existiendo.

Un atacante puede reclamar el recurso abandonado en esa plataforma y servir instantáneamente su propio contenido bajo tu subdominio.

En mi caso, el antiguo micrositio del «calendario de adviento» había sido muy promocionado años atrás. Cuando se abandonó, el DNS permaneció activo, creando una oportunidad de explotación. El secuestrador aprovechó la autoridad y los vínculos de retroceso existentes en el subdominio y lo utilizó para promocionar un sitio de casinos.

Esto no es raro. Incidentes similares han afectado a portales gubernamentales, grandes marcas e incluso sitios de gran autoridad en los que los modelos de IA suelen confiar ciegamente.

Por qué los SEO deben preocuparse

No se espera que seas un especialista en ciberseguridad. Pero los subdominios comprometidos pueden desencadenar acciones manuales, pasar autoridad a sitios maliciosos y deshacer meses o años de trabajo de optimización. Muchas vulnerabilidades provienen de proyectos heredados que nadie recuerda haber configurado.

Google trata los subdominios como propiedades independientes en muchos aspectos, pero los enlaces entre ellos pueden transferir autoridad. Si un subdominio descuidado es pirateado y tu sitio principal enlaza con él, básicamente estás avalando el contenido del atacante. Esta es la razón por la que las comprobaciones periódicas de subdominios deben formar parte de su rutina de auditoría técnica.

Proceso de investigación

Descubra los subdominios existentes

Utilice herramientas como ViewDNS o DNSDumpster. Tenga en cuenta los límites de búsqueda; si un cliente tiene docenas o cientos de subdominios, vale la pena señalar la posibilidad de activos heredados o no utilizados.

Identificar plataformas de alojamiento

Compruebe el alojamiento con herramientas como WhatCMS o el comando dig de Google. Además, evite visitar directamente un enlace comprometido.

Evalúe la vulnerabilidad

Compare las plataformas de alojamiento con servicios conocidos como AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com y JetBrains. Utiliza ViewDNS para encontrar subdominios, Wappalyzer para perfilarlos y compara los resultados con las listas de vulnerabilidades disponibles públicamente.

Si encuentra un subdominio vulnerable

Si está vinculado a una de las plataformas de alto riesgo y no se utiliza (o está previsto que se cierre), coordínese con quien gestione los DNS para eliminar o reorientar el registro. Aunque los SEO no son directamente responsables de la configuración de los servidores, concienciar a las partes interesadas de las implicaciones tanto de seguridad como de SEO suele ayudar a priorizar el problema.

No soy un experto en pruebas de penetración, sólo un SEO técnico que se ha encontrado con esto suficientes veces como para ver el valor de las comprobaciones proactivas. Incluir este paso en las auditorías puede ahorrar dolores de cabeza más adelante.

Ejemplo real: EY.com

Un ejemplo reciente, compartido por Michael Curtis en LinkedIn, se refería a un subdominio de EY alojado a través de Microsoft Azure. El recurso de Azure se eliminó, pero la entrada DNS permaneció.

Un atacante registró una nueva aplicación Azure con el mismo nombre de host utilizado anteriormente por el subdominio de EY. Como el DNS seguía apuntando allí, pudieron servir contenido explícito bajo el dominio de confianza de EY.

No se trata de un «hackeo» en el sentido tradicional, sino de un uso oportunista de entradas DNS abandonadas. El atacante no violó los sistemas internos; simplemente reclamó un nombre no protegido y heredó el tráfico y la confianza que conllevaba.