Todo empezó con una reunión que no tenía nada que ver con esto.
Un cliente me había llamado para hablar de un nuevo proyecto web. Casi de pasada, antes de entrar en materia, me comentó algo que le había llamado la atención: el favicon de su web había cambiado solo. Y que al buscar su sitio en Google, entre las sugerencias aparecía una página con una descripción en italiano.
Eso no suena a gran cosa. Podría ser un error, un fallo puntual, algo sin importancia. Pero a mí me encendió todas las alarmas.
Lo que encontramos al investigar fue mucho peor de lo que cualquiera de los dos esperaba.
El primer síntoma: algo no cuadra en el panel de WordPress
Al entrar al wp-admin, lo primero que me llamó la atención fue que no aparecía el botón de «Añadir plugin», y tampoco podía actualizar los que ya tenía instalados. Un administrador de WordPress siempre tiene esas opciones. Si no están, alguien las ha bloqueado.
Fui directo al wp-config.php y encontré esto:
define('DISALLOW_FILE_MODS', true);
define('DISALLOW_FILE_EDIT', true);Estas líneas no vienen por defecto en WordPress. Alguien las había añadido manualmente, y lo había hecho después del require_once final, lo que técnicamente es incorrecto y delataba que se habían insertado con prisa, sin conocimiento real del sistema.
El efecto práctico era brutal: el administrador no podía instalar plugins de seguridad ni detectar el problema desde el panel. El atacante se había asegurado de que fuera difícil reaccionar.
El sitemap lo confirmó todo
Al abrir webafectada/sitemap_index.xml el panorama fue inmediato: miles de URLs con nombres de productos en italiano.
/Adesivo-Teschio-Diametro-65-Mm-Decorativi-E-Protettivi-Per-Le-c-545095
/Bracciale-Fai-Da-Te-Donna-In-Argento-925-Con-Zirconi-Elegante-c-959575
/Olio-Keroscene-Vetro-Trasparente-Nuovo-3-X-8-1-4-Pollici-c-653854Todas con fecha de modificación reciente. Todas siguiendo el mismo patrón: palabras en italiano separadas por guiones, terminando en -c- seguido de un número.
La web de un cliente (un dominio con años de historia y buena autoridad en Google) estaba sirviendo miles de fichas de productos de una tienda online falsa en italiano. Un problema de visibilidad que cualquier propietario de negocio querría evitar a toda costa.
Qué es el Italian SEO Spam Hack
Este tipo de ataque tiene nombre: Italian SEO Spam Hack o WordPress Italian Spam Hack, y en su variante italiana es especialmente frecuente en Europa. Si has llegado hasta aquí porque has visto URLs con el patrón -c-XXXXX en tu Search Console, o páginas en italiano indexadas en Google que no reconoces, es muy probable que estés ante este mismo ataque.
El objetivo no es robar datos ni romper la web. El objetivo es el posicionamiento.
Los atacantes inyectan miles de páginas de productos falsos en dominios con autoridad (webs con años de historia, backlinks, reputación acumulada) para aprovechar esa autoridad y posicionar sus tiendas fraudulentas en Google.
Los atacantes no eligen sus víctimas al azar. Buscan dominios con autoridad: webs con años de antigüedad, backlinks naturales acumulados y buena reputación ante Google. Esa autoridad es exactamente lo que necesitan para posicionar sus productos falsos rápidamente. Cuanto más ha trabajado el propietario su SEO a lo largo del tiempo, más valioso es su dominio para un atacante.
Lo que hace especialmente peligroso este ataque es el cloaking: las páginas falsas solo se muestran a los buscadores. Si tú visitas la URL directamente, ves la web normal. Si la visita el Googlebot, ve el producto italiano. Por eso puede estar activo durante semanas sin que el propietario note nada.
En este caso, el hackeo se había producido el 25 de febrero. El cliente lo detectó el 4 de marzo y me lo comunicó el día 6: nueve días activo, nueve días generando páginas falsas que Google fue indexando sin parar.
El backdoor: elegante y peligroso
Al revisar los archivos del servidor encontré en wp-includes/Requests/ un archivo llamado Cookie-handler.php. El nombre es deliberadamente inocente, parece parte del núcleo de WordPress.
Su contenido era una clase PHP llamada NightJarEncryptHelper. Código aparentemente sofisticado, con métodos con nombres técnicos creíbles. La clave no estaba en una línea concreta sino en el enfoque: todo el código malicioso viajaba cifrado con AES-256, completamente ilegible. Un escáner de malware convencional no encuentra nada sospechoso porque lo que analiza es texto cifrado sin ningún patrón reconocible.
Sin embargo, una inspección humana lo delata: cifrar código en un archivo de WordPress no es una práctica legítima. Ningún plugin ni tema serio lo hace. Si ves algo así en tus archivos, es una señal de alarma inmediata.
Ese era el motor de las 20.000 páginas. No estaban en la base de datos, se generaban dinámicamente al vuelo, solo cuando las pedía un rastreador.
El proceso de limpieza
Una vez identificado el problema, el proceso fue metódico. Estos son los cuatro pasos que seguimos:
1. Desactivar el backdoor
Renombré Cookie-handler.php a Cookie-handler.php.bak para desactivarlo sin borrarlo, conservándolo como evidencia por si hacía falta analizarlo después.
2. Bloquear las URLs falsas
Todas las URLs del hackeo seguían el patrón -c-XXXXXX al final. Añadí una regla en el .htaccess antes del bloque de WordPress para devolver 410 Gone a todas ellas:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^.*-c-[0-9]+$ - [R=410,L]
</IfModule>
El 410 es preferible al 404 para este caso: le indica a Google que el recurso ha desaparecido permanentemente, acelerando la desindexación. Si no tienes claro cómo funciona el rastreo de tu web, revisar tu archivo robots.txt también forma parte de la higiene básica de cualquier sitio.
3. Limpiar y asegurar WordPress
Reinstalé el núcleo de WordPress para sobrescribir cualquier archivo del core que pudiera estar comprometido, actualicé todos los plugins, instalé Wordfence y cambié todas las contraseñas: WordPress, base de datos y FTP.
4. Notificar a Google
Reenviamos el sitemap limpio desde Search Console para que Google rastreara el sitio de nuevo y empezara a procesar las respuestas 410.
El daño real
A pesar de actuar rápido, Google ya había indexado más de 20.000 páginas falsas. Y lo más frustrante: el número siguió subiendo varios días después de la limpieza, porque Google tenía en cola miles de URLs del sitemap infectado que ya había rastreado cuando el backdoor estaba activo, y que estaban pendientes de indexar.
El daño no es solo estético. Un dominio con miles de páginas de spam puede recibir una penalización manual de Google (similar en impacto a lo que ocurre tras una Core Update), perder posiciones en sus rankings reales y ver su reputación de marca afectada si usuarios llegan a esas páginas.
La recuperación completa del índice lleva semanas. El 410 y el sitemap limpio aceleran el proceso, pero no hay atajos.
Por qué ocurre esto… y cómo evitarlo
En la mayoría de casos el vector de entrada es uno de estos tres:
- Plugin o tema desactualizado con una vulnerabilidad conocida y pública
- Contraseña comprometida por fuerza bruta o filtración
- Falta de revisión periódica que permite al atacante trabajar durante días o semanas sin ser detectado
Este último punto es el más importante. El hackeo llevaba nueve días activo cuando se detectó, y se detectó por casualidad, porque el cliente notó que el favicon había cambiado. Con una revisión periódica del sitio y de Search Console, el problema se podría haber detectado antes y el daño habría sido mucho menor.
Pero más importante aún: con los plugins actualizados, es posible que el hackeo nunca hubiera ocurrido. No es una certeza (nunca lo es), pero la mayoría de ataques a WordPress explotan vulnerabilidades conocidas en plugins desactualizados. Si quieres partir de una base sólida, aprender a gestionar correctamente tu WordPress con un Child Theme es el primer paso.
El mantenimiento web no es un gasto, es un seguro
Muchos ven el mantenimiento web como un gasto innecesario, o lo van postergando indefinidamente. Pero en la mayoría de casos, si la web está bien construida y tiene tema hijo, con mantener los plugins y el tema actualizados es suficiente para cerrar la puerta a la mayoría de ataques. No hace falta ser técnico ni dedicarle horas pero sí hacerlo de forma regular.
Una web descuidada es como cualquier otro activo abandonado: se deteriora por dentro mucho antes de que se note por fuera.
¿Necesito un plugin de seguridad?
Es la pregunta que más me hacen. La respuesta honesta es: depende.
La versión gratuita de Wordfence o Defender añade una capa extra sin coste y no está de más tenerla. Pero hay un matiz importante que pocos mencionan: este tipo de plugins pueden ralentizar la web, especialmente en hostings compartidos o con recursos limitados. El escaneo de archivos consume CPU y memoria, y en hostings modestos se nota.
Para la mayoría de webs de negocio, no es imprescindible pagar por la versión premium si se hacen bien las cosas básicas. La alternativa más eficiente es hacer la seguridad a nivel de servidor (desde el panel de hosting directamente) en lugar de a nivel de plugin. Muchos hostings ya incluyen escaneo de malware y firewall propio, que es mucho más eficiente que hacerlo desde WordPress.
Si tienes una web y no tienes un plan de mantenimiento activo, este artículo es para ti.
