La anatomía de un ataque de cloaking SEO en WordPress

No todo hackeo de WordPress es ruidoso. Algunos atacantes no quieren desfigurar tu sitio ni pedir un rescate. Quieren secuestrar discretamente la autoridad de búsqueda de tu dominio y usarla para posicionar su propio contenido en Google. Estos ataques se llaman ataques de cloaking SEO, y son algunos de los compromisos más dañinos que puede sufrir un sitio de empresa, porque a menudo el propietario ni siquiera sabe que están ocurriendo.

Este artículo recorre exactamente cómo funciona un ataque real de cloaking SEO, usando un caso reciente de una agencia de Sídney donde cada archivo y cada despachador se identificó durante una auditoría forense. Si gestionas un sitio WordPress, lo que sigue es el patrón que deberías saber reconocer.

Qué significa el cloaking

El cloaking es la práctica de servir contenido distinto a los buscadores que a los visitantes humanos. Una página puede mostrarle a Googlebot un artículo largo lleno de palabras clave de temas comerciales no relacionados, mientras le muestra a un visitante normal una página de aterrizaje genérica o una redirección. El objetivo es engañar a los buscadores para que posicionen el contenido encubierto bajo la autoridad de un dominio consolidado.

Google tiene reglas contra esto. El cloaking infringe las directrices para webmasters y puede acarrearle a un dominio penalizaciones por acción manual o un desplome total del posicionamiento si se detecta. Al atacante no le importa, porque el dominio no es suyo.

El patrón de los cinco directorios

El caso de Sídney usaba una versión particularmente limpia del ataque. El atacante había creado cinco directorios nuevos en la raíz del sitio, cada uno con un nombre que imitaba una página real de WordPress. En el disco aparecían carpetas con nombres como about, contact, good-to-know, services y work. Cada una contenía exactamente tres archivos. Un despachador index.php. Un archivo HTML user.php. Un archivo HTML wp-log.php.

La razón de nombrar las carpetas como páginas reales era sencilla. Cuando llegaba una petición de /about/ al sitio, el servidor web comprobaba primero el sistema de archivos. Existía una carpeta llamada about, con un index.php dentro. El servidor web resolvía ese archivo antes de que entrara en juego el propio enrutamiento de URL de WordPress. Cada petición a esas URL llegaba al código del atacante en lugar de a la página legítima de WordPress.

El despachador

El archivo index.php de cada carpeta era una pequeña pieza de PHP que hacía una sola cosa. Inspeccionaba la cabecera User-Agent de la petición entrante y enrutaba en consecuencia. Si el User-Agent contenía Googlebot, Googlebot-Mobile o Googlebot-News, servía el contenido de wp-log.php. En caso contrario, incluía user.php y salía.

El mismo archivo estaba desplegado en las cinco carpetas, idéntico byte a byte. El atacante usaba una sola carga útil y una sola regla de decisión. Todo lo demás eran datos.

La carga útil para Googlebot

Los archivos wp-log.php, a pesar de la extensión .php, contenían HTML puro. Eran enormes, de entre 1,3 MB y más de 4 MB. Cada uno era una página HTML completa en un idioma extranjero, en este caso indonesio, con contenido de spam sobre apuestas, comercio electrónico y seguimiento de productos Samsung. Las páginas estaban repletas de datos estructurados, scripts de seguimiento de terceros incrustados y enlaces diseñados para superar al contenido legítimo en las palabras clave a las que apuntaban.

¿Por qué llamarlo wp-log.php? Camuflaje. Para un propietario que echa un vistazo a la lista de archivos, parece un archivo de registro de WordPress, no una carga útil sospechosa.

La carga útil para humanos

Los archivos user.php eran páginas HTML más pequeñas que se servían a los visitantes humanos reales. Eran páginas puerta (doorway) de sitios de terceros no relacionados, también disfrazadas con una extensión .php pese a no contener nada de código PHP. Cualquiera que llegara a una de esas URL desde un resultado de búsqueda, o que navegara a /about/ en el sitio, vería contenido que no tenía nada que ver con la agencia.

Esta es la parte del cloaking. Google ve el spam de apuestas en el contenido de wp-log.php, lo posiciona bajo la autoridad de dominio de la agencia y envía a los usuarios reales a user.php, que ofrece una experiencia de página puerta completamente distinta. El engaño funciona en ambos sentidos.

Cómo entró el atacante

La auditoría forense no pudo precisar el vector de entrada exacto con los datos disponibles, pero el principal sospechoso era un plugin de gestor de archivos desactualizado que seguía instalado y activo. La familia de plugins en cuestión tiene un largo historial de vulnerabilidades de ejecución remota de código, con varios avisos publicados en años anteriores. Con acceso de escritura a través de ese plugin, un atacante puede dejar archivos arbitrarios en cualquier parte de la raíz del documento.

Algo crucial: la auditoría confirmó que el núcleo de WordPress, wp-config.php, la base de datos y el tema activo estaban todos limpios. Ninguna puerta trasera en la aplicación, ningún usuario administrador fraudulento, ningún eval de PHP ofuscado. El compromiso estaba enteramente en esas cinco carpetas. Eso es lo que lo hacía tan silencioso. La mayoría de los escáneres de seguridad miran los archivos de WordPress, no la raíz del documento en busca de directorios inesperados.

Por qué este tipo de ataque es tan dañino

Los ataques de cloaking SEO hacen daño de tres maneras. Primero, el contenido de spam se indexa bajo tu dominio, empujando tus páginas reales hacia abajo o fuera de los resultados de búsqueda. Segundo, Google puede aplicar penalizaciones por acción manual o una degradación algorítmica cuando detecta el cloaking, de las que a menudo se tarda semanas o meses en recuperarse incluso después de eliminar los archivos maliciosos. Tercero, los scripts de terceros y los píxeles de seguimiento incrustados en las páginas de spam pueden poner a tus visitantes en riesgo de malware o phishing.

El propietario de un sitio con cloaking a menudo no nota nada hasta que el tráfico se desploma o un cliente menciona haber visto contenido extraño al hacer clic en un resultado de búsqueda. Para entonces, ya se han causado semanas o meses de daño.

Cómo detectarlo en tu propio sitio

Unas pocas comprobaciones rápidas detectan la mayoría de las variantes de este ataque. Visita tu página de inicio como un usuario normal. Luego lanza una petición curl desde un servidor con una cabecera User-Agent de Googlebot y compara. Si ves contenido distinto, algo va mal.

Revisa los informes de Cobertura y Rendimiento en Google Search Console por si hay URL indexadas que no reconozcas, sobre todo las que tienen consultas en idiomas extranjeros. Mira la raíz del documento por SFTP en busca de carpetas o archivos que no puedas justificar. Ejecuta un análisis completo de malware con un plugin de seguridad de confianza y lee el informe en lugar de limitarte a borrar las alertas.

Cómo prevenirlo

La prevención es el mismo conjunto de hábitos que evita la mayoría de los compromisos de WordPress. Mantén al día el núcleo, los temas, los plugins y PHP. Elimina los plugins que no uses activamente, sobre todo gestores de archivos y herramientas de acceso por shell. Bloquea la ejecución de PHP en directorios que nunca deberían contener PHP. Audita la raíz del documento cada mes. Usa un plugin de seguridad que vigile la aparición de archivos nuevos en ubicaciones inesperadas y avise cuando aparezca uno.

¿Necesitas ayuda?

Si te preocupa que tu sitio WordPress pueda estar alojando contenido encubierto sin tu conocimiento, Defyn puede ejecutar una auditoría forense y decirte exactamente qué hay en tu servidor. Ponte en contacto y nos aseguraremos de que tu dominio solo posicione por lo que debe.