Sitio WordPress hackeado con spam de casino: cómo identificamos y eliminamos el malware en TourReview
Spam de casino en francés inyectado por una base de datos comprometida, no un plugin desactualizado. Reparación completa en 5 fases.
La alerta
Si tu sitio WordPress empezó a mostrar bloques de texto en francés promocionando casinos online — o Google Search Console te alertó sobre contenido sospechoso indexado — el primer instinto es sospechar de un plugin desactualizado. No siempre es ahí donde está el problema. Fue lo que encontramos al investigar el sitio de TourReview, SaaS B2B de gestión de reputación online para operadores turísticos, cliente vía Workana: el sitio mostraba spam de un casino (mystakecasinobet.com) repetido en múltiples páginas. La causa raíz no estaba en ningún plugin — estaba directamente en la base de datos, comprometida por un usuario backdoor creado a partir de una credencial filtrada.
Regla del proyecto: nunca actualizar con malware activo
Actualizar los plugins antes de identificar y eliminar el vector de infección puede ocultar cómo entró el atacante, dificultando después una limpieza completa. La investigación fue primero: la inyección estaba en las tablas `wpuw_posts` y `wpuw_postmeta`, sin ningún archivo PHP comprometido. El vector fue un usuario backdoor (`Af17lN8wTX`) creado mediante acceso a la base de datos o una credencial filtrada — eliminado de forma permanente tras la confirmación.
Después del malware: reinstalación limpia
Tras la eliminación, se actualizaron WordPress y 21 plugins, incluyendo un Elementor Pro nulled (pirata, versión 3.8.0) que fue removido y sustituido por una licencia legítima. La instalación antigua fue descartada y una reinstalación limpia se estableció como el único WordPress activo en la cuenta, con los archivos subidos (325MB) restaurados desde el backup previo a la limpieza.
Control de calidad con metodología contra el ruido
Las pruebas de Lighthouse en hosting compartido mostraban una variación de 14 a 23 puntos entre ejecuciones idénticas de la misma prueba — ruido del servidor de origen, no de las optimizaciones aplicadas. La solución fue medir por la mediana de 5 ejecuciones por página, en lugar de confiar en un único resultado, para no tomar decisiones técnicas basadas en una medición que en realidad era solo imprecisión estadística.
Resultado
23 páginas y alrededor de 70 publicaciones de blog verificadas, todas con respuesta 200 OK. Escaneo completo de Wordfence sin ninguna ocurrencia maliciosa restante. Hardening aplicado: xmlrpc.php bloqueado, protección contra fuerza bruta, cuenta de administrador propia de Crazy Diamond creada para mantenimiento futuro. Ningún punto técnico bloquea la entrega — lo que queda depende únicamente de decisiones de la propia clienta (reconexión del feed de Instagram, clave de Akismet), sin impacto en el alcance principal ya concluido.