Hackeo de palabras clave japonesas: por qué tu plugin de seguridad no lo vio

#El escáner no te miente, le mienten a él

El 29 de julio de 2026, Joe Youngblood publicó un aviso de que el hackeo de palabras clave japonesas está corriendo por sitios WordPress a gran velocidad y, en sus palabras, “easily defeating WordFence, Securi, and Malcare along with other security methods / plugins.”

Esa última parte es la interesante, y no es un fallo de esos productos en el sentido que parece. El escaneo vuelve limpio porque la carga útil no está ahí en el momento en que el escáner la pide.

El contenido inyectado se sirve de forma condicional. El sitio mantiene un web shell, y el shell decide en tiempo de petición si inyecta o no. Si la petición parece un navegador, devuelve tu página de siempre. Si la petición parece Googlebot, devuelve una página llena de palabras clave japonesas de comercio electrónico que enlazan a productos falsificados. Tu plugin de seguridad pide la página como sí mismo, recibe la versión normal y no informa de nada.

Por eso el primer síntoma casi nunca aparece en el sitio. Aparece en Search Console, o en un resultado de Google para tu propia marca, o en una caída de tráfico que nadie sabe explicar.

#Demuéstralo con un comando antes de tocar nada

Antes de empezar a borrar archivos, establece a qué te enfrentas de verdad. Pide la misma URL dos veces desde la terminal:

curl -s https://example.com/some-page/ > browser.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/some-page/ > crawler.html
diff browser.html crawler.html

Si las dos difieren, y la versión del rastreador lleva enlaces o palabras clave que la del navegador no tiene, tienes cloaking y el diagnóstico está terminado. Sin escaneo de plugin, sin adivinar.

Haz lo mismo con tu sitemap. Un síntoma acompañante frecuente es que Search Console informe de que el sitemap “parece ser una página HTML” mientras el sitemap carga correctamente en tu navegador. Es el mismo mecanismo: algo intercepta la ruta del sitemap y le sirve otra cosa al rastreador.

Dos sitios más donde mirar, los dos fuera del sitio:

• Search Console, Problemas de seguridad. Si Google ya ha clasificado el sitio, el informe nombra el patrón y contiene la solicitud de revisión que necesitarás después.
• Search Console, Rendimiento, filtrado por consultas que no reconoces. Términos japoneses de comercio electrónico en una web en español no son ambiguos.

#Qué puede ver y qué no puede ver cada herramienta

Vale la pena ser preciso sobre por qué los escáneres vuelven limpios, porque “el plugin falló” lleva a la gente a comprar otro plugin en lugar de cambiar de método.

El patrón de esa tabla es todo el asunto. Cada método que inspecciona archivos responde a “hay algo en el sistema de archivos”, y cada método que inspecciona comportamiento responde a “está este sitio mintiendo ahora mismo a los rastreadores”. Necesitas los dos, y solo uno de ellos se vende como producto.

#Detectarlo pronto, y detectar una recaída

El hueco entre infección y descubrimiento es donde se produce el daño SEO. Hay tres señales que llegan antes que la caída de tráfico.

Impresiones para consultas que no tienen sentido para tu negocio. Search Console, Rendimiento, ordena por impresiones y busca cualquier cosa escrita en un sistema de escritura en el que tú no publicas. Suele ser la señal más temprana a tu alcance y cuesta un minuto a la semana.

Una página que se dispara de la nada. En la oleada actual, la primera página inyectada suele mostrar un salto repentino de impresiones antes de que la sigan las demás. Una página que no tocas desde hace un año y que de pronto rinde merece treinta segundos de curiosidad.

El favicon cambia en los resultados. Youngblood señala que esta oleada trae un favicon característico, visible en Search Console. Un favicon que tú no pusiste es un archivo que tú no escribiste.

Una vez limpiado, la misma prueba de doble petición sirve como monitor de recaídas aceptable. Esto se ejecuta desde cualquier máquina con curl, no desde el propio sitio, lo cual importa porque un sitio comprometido es mal juez de su propio estado:

#!/usr/bin/env bash
# cloaking-watch.sh - avisa si la vista del rastreador diverge de la del navegador
URL="https://example.com/"
UA_BOT="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

a=$(curl -s --max-time 20 "$URL" | md5sum | cut -d' ' -f1)
b=$(curl -s --max-time 20 -A "$UA_BOT" "$URL" | md5sum | cut -d' ' -f1)

if [ "$a" != "$b" ]; then
  echo "DIVERGENCE on $URL at $(date -u +%FT%TZ)"
  exit 1
fi

Dos advertencias antes de meterlo en un cron. Las páginas con contenido rotativo, tests A/B o bloques personalizados van a diferir de forma legítima, así que apúntalo a una página estable, como un artículo perenne o el sitemap. Y un shell decidido puede tomar huellas de más cosas además del user agent, incluido el rango de IP que solicita la página, así que un resultado limpio aquí es un indicio, no una prueba. Aun así detecta el caso común, y lo detecta en un día en lugar de en un trimestre.

#Cómo distinguirlo de las otras variantes de spam

Hay tres infecciones a las que se llama “spam SEO” y cada una pide un primer movimiento distinto, así que vale la pena dedicar un minuto a averiguar cuál tienes.

El spam farmacéutico mete palabras clave de medicamentos en títulos, extractos y contenido de las entradas. Vive en la base de datos, es visible para cualquier visitante y lo encuentras buscando en wp_posts y wp_options los términos que Google está mostrando. Si un SELECT encuentra esas palabras, estás en este caso y no en el japonés.

El spam de casinos y apuestas está a medio camino entre los dos. A menudo hace cloaking igual que la variante japonesa, pero suele llegar con bloques hreflang inyectados y versiones de idioma inventadas de tus páginas, porque los operadores quieren varios mercados a la vez. Si la vista del rastreador muestra enlaces a idiomas alternativos que tú nunca creaste, mira por ahí.

El hackeo de palabras clave japonesas deja la base de datos intacta. La carga útil está en archivos, se genera en tiempo de petición y solo para rastreadores, que es justo la combinación que derrota a la vez a la búsqueda en la base de datos y al escaneo del plugin.

Existe además una variante de redirección solo para móviles que se dispara con el user agent igual que esta, salvo que comprueba si es un teléfono en lugar de si es Googlebot. Si tus visitantes cuentan que acaban en otro sitio y tus propias pruebas desde el escritorio siguen saliendo limpias, repite la prueba de doble petición con una cadena de user agent móvil en lugar de la de Googlebot. El mecanismo es idéntico, lo único que cambia es la condición.

#Verifica archivos de forma determinista, luego mira las fechas

El texto de Youngblood sugiere buscar base64 por todo el sistema de archivos y pedirle a un modelo de IA que revise la lista. Funciona, pero es el segundo paso, no el primero, porque le pide a un modelo que adivine qué archivos pertenecen a WordPress. WordPress ya lo sabe:

wp core verify-checksums
wp plugin verify-checksums --all

Esto compara cada archivo del core y de los plugins con los checksums oficiales de WordPress.org y nombra todo lo modificado o añadido. Es determinista, tarda segundos y produce una lista mucho más corta sobre la que razonar que un grep de base64 por todo el árbol.

Lo que los checksums no pueden verificar: tu tema, cualquier cosa premium, wp-content/uploads y mu-plugins. Ahí es donde entra la pasada manual:

grep -rl --include="*.php" -E "base64_decode|eval\(|gzinflate|str_rot13" wp-content/ | head -50
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins/

Un archivo PHP dentro de uploads no tiene ninguna razón legítima para existir. Tampoco un archivo en mu-plugins que tú no escribiste, y ese directorio merece atención especial porque se carga automáticamente y nunca aparece en la lista de plugins.

Después ordena lo que has encontrado por fecha de modificación. El grueso de los archivos inyectados suele compartir una misma marca de tiempo, que es el momento del ataque visible. La excepción es lo que Youngblood llama la semilla: un único archivo plantado semanas, meses o a veces años antes, con una marca de tiempo que no coincide con nada más. Si lo limpias todo menos la semilla, la infección vuelve, y vuelve en silencio.

La prueba práctica para saber si lo has cogido: restaura un index.php limpio, espera dos minutos y vuelve a leer el archivo. Si ha revertido, algo sigue ejecutándose y lo ha reescrito, y no has terminado.

#El orden importa

El orden de la limpieza es donde se tuercen las recuperaciones, y la secuencia no es intuitiva.

Copia antes de limpiar. Haz primero una copia completa de archivos y una exportación de la base de datos del estado comprometido. Restaurar un backup por encima destruye la única evidencia de cómo se produjo la entrada, y si el propio backup ya está infectado, te quedas sin nada con lo que comparar. Aquí la retención es el detalle que se pasa por alto: en el mercado español lo habitual en alojamiento compartido son copias diarias con siete días de retención, y los planes gestionados que llegan a treinta días suelen guardar solo la última de cada semana en las semanas antiguas. Con una semilla que puede preceder al ataque visible en varios meses, la ventana útil se agota mucho antes de que aparezca el primer síntoma. Comprueba en el panel de tu proveedor cuántos días tienes de verdad y descarga una copia a tu propia máquina antes de tocar nada; trata “restauro el backup del mes pasado” como una suposición, no como una solución.

Limpia, después rota, después ocúpate de los buscadores. En ese orden. Rotar credenciales antes de eliminar el shell es simplemente entregarle las nuevas.

Rota más que contraseñas. Este es el paso en el que casi todas las guías se quedan cortas:

• Las contraseñas de aplicación, en cada perfil bajo Usuarios, sobreviven a un cambio de contraseña y conservan acceso completo a la REST API. Son por usuario, son fáciles de crear mediante programación en cuanto un atacante tiene admin, y la mayoría de la gente no sabe que la función existe. Enuméralas y bórralas.
• Los propietarios delegados en Search Console, en Configuración, Usuarios y permisos, viven totalmente fuera de tu sitio. Nada de lo que hagas en WordPress los elimina. Revisa también la verificación de propiedad, por si quedan archivos HTML sueltos o registros TXT en el DNS.
• Las credenciales de base de datos y de FTP o SSH, porque si la entrada fue credential stuffing contra wp-admin, todo lo demás que compartiera esa contraseña también está expuesto.

Y entonces los buscadores. Regenera el sitemap, confirma con una prueba de URL en directo en la Inspección de URL de Search Console que Googlebot ya recibe la página real, y solicita una revisión en el informe de Problemas de seguridad. Reenviar un sitemap no levanta una acción manual; la solicitud de revisión sí.

#Dos consejos habituales con los que merece la pena discutir

El aviso que dio pie a este artículo es un buen trabajo de campo, y dos de sus recomendaciones merecen réplica.

“Immediately request to remove your full website via Search Console.” Solicitar de inmediato la retirada de toda la web es un instrumento más pesado de lo que la situación suele necesitar. La herramienta de Retirada oculta URL de los resultados durante unos seis meses; no cambia nada de la infección ni de cómo Google reevalúa el sitio más adelante. Retirar los patrones de URL inyectados con una retirada por prefijo es proporcionado. Retirar el sitio entero retira también las páginas que siguen trayendo consultas, y cada una de ellas tiene que volver pasando por una cancelación y un nuevo rastreo que tú no controlas. Recurre a la versión completa cuando las páginas inyectadas superen de verdad en número a las reales, no como primer paso.

“Find any excuse imaginable to run a press release to drive fresh interest from Googlebot.” El rastreo se impulsa con cosas sobre las que sí puedes influir: valores lastmod correctos en el sitemap, enlaces internos desde páginas que se rastrean con frecuencia y solicitudes de Inspección de URL sobre las páginas que importan. Una nota de prensa es una forma cara de comprar unas cuantas visitas de rastreador.

El resto de ese texto, en particular la observación sobre la marca de tiempo única del archivo semilla y el aviso de volver a comprobar index.php después de restaurarlo, coincide con lo que se ve en estas limpiezas en la práctica.

#Cerrar la puerta que el ataque usó de verdad

La cadena de entrada reportada en esta oleada es concreta: credential stuffing contra wp-admin con listas filtradas de correos y contraseñas, después instalar un plugin para conseguir acceso al sistema de archivos, después subir un único archivo con la carga útil. Cada uno de esos pasos tiene un control que lo detiene.

Autenticación en dos factores en todos los administradores. El credential stuffing funciona porque la contraseña ya se conoce. El segundo factor hace que una contraseña correcta no baste, que es el ataque entero.

DISALLOW_FILE_MODS. En wp-config.php:

define( 'DISALLOW_FILE_MODS', true );

Esto bloquea por completo la instalación de plugins y temas desde el escritorio. En la cadena reportada, ese es el paso dos. Un atacante con una sesión de administrador válida no puede instalar el plugin de gestor de archivos que le da el sistema de archivos. La contrapartida es real y conviene conocerla: las actualizaciones automáticas también se detienen, así que las actualizaciones pasan a hacerse por WP-CLI o por una tubería de despliegue. En un sitio que se despliega desde un repositorio, así es como debería funcionar de todos modos.

Sin ejecución de PHP en uploads. En el servidor web, no en un plugin. Esto degrada el camino más común de “el atacante subió un archivo” a “el atacante ejecuta código”.

Menos administradores. El personal de la agencia, un desarrollador que ayudó una vez, un contratista de soporte de hace dos años. Cada uno de ellos es una credencial que se puede probar en un ataque de listas. Baja de rol lo que no necesita ese rol.

Vigila Search Console antes que el escritorio. El escritorio es justo donde este ataque es invisible por diseño. Un vistazo semanal a Rendimiento buscando consultas que no reconoces lo detecta antes que cualquier escaneo.

#Qué contarle al cliente o a tu jefe

Si estás limpiando esto para otra persona, la parte difícil de la conversación no es técnica, es la del tiempo. La limpieza se mide en horas y la recuperación en semanas, y esas dos cosas se funden con facilidad en una única expectativa: arréglalo esta noche y mañana vuelve el tráfico. No va a volver, porque Google tiene que revisitar páginas que ya había clasificado como spam, y esa cola depende de con qué frecuencia rastreaba el sitio antes.

Lo segundo que conviene decir con claridad: no puedes responder con honestidad a “se llevaron datos de clientes” cuando los logs del servidor tienen siete días de retención y el archivo semilla es de febrero. La respuesta es “no lo sabemos y no lo vamos a averiguar”, y eso es información, no una evasiva. En una tienda que guarda datos personales, ese vacío decide si se activa la obligación de notificar una brecha, y el RGPD da 72 horas desde que se tiene conocimiento de ella, así que el tema tiene que estar sobre la mesa desde el primer día y no una semana después.

Lo tercero: el coste de esta infección rara vez es la limpieza. Es el tráfico que no llegó durante esas semanas, y esa cifra merece calcularse juntos a partir de los datos anteriores a la infección, en lugar de dejarla en la sensación vaga de que las cosas bajaron.

#Si estás en medio de uno ahora mismo

La versión corta: demuestra el cloaking con la prueba de doble petición, verifica core y plugins con checksums, caza la semilla por marca de tiempo, copia todo antes de restaurar nada, y recuerda que las contraseñas de aplicación y los propietarios delegados de Search Console sobreviven al cambio de contraseñas que estás a punto de hacer.

Ejecutamos esta secuencia como parte de una auditoría de seguridad WordPress, y el proceso de limpieza más amplio, incluido el trabajo sobre la base de datos y la revisión de logs, está en nuestra guía para limpiar un sitio WordPress hackeado.

Última actualización: 30 de julio de 2026, tras el aviso de la oleada actual.