El hack japonés en WordPress: cómo detectarlo y limpiarlo

Respuesta corta: el hack japonés crea en tu dominio miles de páginas en japonés (normalmente de marcas falsificadas) que Google indexa. Se detecta con una búsqueda site:tudominio.com y en Search Console. Para limpiarlo hay que quitar al atacante de Search Console, borrar el código que genera las páginas, hacer que esas URLs devuelvan 410 y pedir a Google que revise la web.

Es uno de los hackeos más comunes en WordPress y de los más molestos, porque puede generar decenas de miles de URLs en pocos días. Esta guía forma parte de nuestra guía general sobre qué hacer con un WordPress hackeado.

Qué es el hack japonés

El atacante entra por un plugin vulnerable, una contraseña filtrada o un tema pirata, y deja en el servidor un script que genera páginas al vuelo. Cada página tiene un título y un texto en japonés, casi siempre anunciando bolsos, relojes o ropa de marca a precios de saldo, y enlaces a tiendas falsas.

Lo que hace que sea tan dañino:

• Usa tu autoridad: Google indexa esas páginas porque confía en tu dominio.
• Se esconde: muchas veces las páginas solo se enseñan a Googlebot, o el visitante que llega desde Google acaba redirigido a la tienda falsa. Tú entras en tu web y la ves normal. Es una variante de cloaking.
• Se hace fuerte en Search Console: es habitual que el atacante se verifique como propietario de tu propiedad (con un fichero google….html o una metaetiqueta) y envíe sus propios sitemaps para que Google indexe más rápido.
• Vuelve: si solo borras las páginas visibles y no el generador, reaparecen.

Cómo saber si te pasa

1. Busca en Google site:tudominio.com japan y, simplemente, site:tudominio.com. Si ves títulos en japonés o chino que no has publicado, lo tienes.
2. En Search Console, mira «Problemas de seguridad», el informe «Páginas» (una subida repentina de páginas indexadas o descubiertas) y «Rendimiento» → consultas: búsquedas en japonés con impresiones en tu web son una señal clara.
3. En «Ajustes» → «Usuarios y permisos», busca propietarios que no conozcas. En «Sitemaps», sitemaps que no hayas enviado tú.
4. Copia una de las URLs que salen en Google y pídela como visitante y como Googlebot:

URL="https://tudominio.com/ruta-que-sale-en-google/"
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$URL"
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "$URL" | head -c 2000
curl -s -e "https://www.google.com/" -o /dev/null -w "%{http_code} %{redirect_url}\n" "$URL"

Si como Googlebot recibes texto en japonés y como visitante un 404 o una redirección, el generador está activo. El tercer comando simula una visita que llega desde Google, que es cuando muchas variantes redirigen.

Ojo: si el código malicioso comprueba que la petición viene de verdad de una IP de Google, el curl no lo destapa. En ese caso usa la inspección de URL de Search Console («Probar URL publicada» → «Ver página probada»), que pide la página desde los servidores de Google.

Cómo limpiar el hack japonés paso a paso

1. Lo básico de cualquier hackeo

Copia de cómo está la web, cambio de todas las contraseñas (WordPress, hosting, FTP/SFTP, base de datos) y cierre de sesiones con wp config shuffle-salts. Lo tienes detallado en la guía general. Google también publica su propia guía para corregir el hack japonés (en inglés), útil como referencia.

2. Echa al atacante de Search Console

En «Ajustes» → «Usuarios y permisos», localiza el propietario desconocido. Antes de quitarlo tienes que eliminar su método de verificación, o se volverá a verificar solo:

ls -la google*.html
grep -il "google-site-verification" wp-content/themes/*/header.php

Borra los ficheros google….html que no sean tuyos, quita la metaetiqueta si la han metido en el tema y revisa los registros TXT del DNS. Después elimina al usuario en Search Console y borra los sitemaps que no hayas enviado tú.

3. Encuentra el generador

El generador suele estar en uno de estos sitios:

• Reglas nuevas en .htaccess que mandan rutas inventadas a un PHP concreto.
• Un index.php modificado o ficheros PHP con nombres raros en la raíz.
• PHP dentro de wp-content/uploads, donde nunca debería haberlo.
• Código añadido al functions.php del tema o en mu-plugins.

find . -name ".htaccess" -exec grep -l "RewriteRule" {} \;
find . -maxdepth 1 -name "*.php" -newer wp-config.php
find wp-content/uploads -name "*.php"
grep -rlP "[\x{3040}-\x{30FF}\x{4E00}-\x{9FFF}]" --include=*.php . | head
wp core verify-checksums

El grep -P busca caracteres japoneses o chinos dentro de ficheros PHP; un plugin con traducciones puede dar algún positivo legítimo, pero un PHP suelto con plantillas en japonés no lo es. Si el texto viene de la base de datos, búscalo también ahí:

wp post list --post_type=any --post_status=any --fields=ID,post_title,post_date --orderby=date --order=DESC --posts_per_page=50
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_title REGEXP '[ぁ-んァ-ヶ]' LIMIT 50"

La consulta con REGEXP funciona en MySQL 8 y en MariaDB recientes. Cambia wp_ por tu prefijo (wp db prefix).

4. Reinstala lo que no puedas revisar

Reinstala el núcleo y los plugins del repositorio con --force, y los de pago desde la web del fabricante. Si el tema viene de una descarga «nulled», cámbialo: no hay forma razonable de confiar en él.

5. Cierra la puerta de entrada

Revisa si alguno de tus plugins tiene una vulnerabilidad conocida en la versión instalada y si queda algún administrador que no reconoces. Sin esto, vuelve.

6. Haz que las URLs de spam desaparezcan

Una vez quitado el generador, esas URLs ya deberían dar 404. Si siguen un patrón (una carpeta inventada, un parámetro fijo), es mejor devolver un 410, que le dice a Google que no van a volver:

# Apache (.htaccess)
RedirectMatch 410 ^/carpeta-inventada/

# nginx
location ^~ /carpeta-inventada/ { return 410; }

No las redirijas todas a la portada: Google las trata como errores suaves y tarda más en olvidarlas. Si son muchas y te urge que dejen de salir, usa además la herramienta «Retiradas» de Search Console con el prefijo. Después vuelve a enviar tu sitemap real.

7. Pide la revisión

En «Problemas de seguridad», marca el problema como corregido y explica qué has hecho. Google revisa y, si todo está bien, retira el aviso. Las URLs indexadas irán cayendo según vuelva a rastrearlas.

Errores habituales

• Borrar los resultados de Google y no el generador. Las páginas vuelven en días.
• Quitar al propietario de Search Console sin quitar su fichero. Se vuelve a verificar automáticamente.
• Redirigir miles de URLs a la portada. Mejor 410.
• Restaurar una copia sin actualizar el plugin vulnerable. Mismo hackeo, otra semana.
• Mirar solo desde tu navegador con sesión iniciada. Muchas variantes no se enseñan a usuarios conectados.

Para agencias: enterarte antes de que Google lo indexe todo

Con decenas de webs, el hack japonés se suele descubrir cuando el cliente busca su marca y ve resultados en japonés. Con Jeffrey, una vez al día se descarga la portada de cada web como visitante y como Googlebot. Si aparece un bloque grande de texto japonés o chino (más de 200 caracteres y una parte relevante del texto) en una web que no está en esos idiomas, abre un aviso crítico y te avisa al momento, incluido el caso en que solo lo recibe Googlebot.

Para ser honestos: muchas variantes del hack japonés no tocan la portada y solo crean páginas nuevas. Esas las verás antes en site: y en Search Console. Lo que sí hace Jeffrey, con el plugin instalado, es vigilar las puertas de entrada habituales: avisa al momento si aparece un administrador nuevo o alguien sube a administrador, y avisa de plugins, temas o núcleo con vulnerabilidades conocidas. Jeffrey no analiza los ficheros del servidor en busca de malware.

Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Preguntas frecuentes