Anatomía de una reinfección de WordPress: por qué volvió el hackeo

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Es una de las llamadas que más recibimos: «Ya limpiamos la web, pagamos a alguien para quitar el malware, y a los pocos días volvió el hackeo». Spam en Google, administradores rusos que aparecen solos, formularios que dejan de funcionar. La frustración es total, porque sobre el papel el trabajo se hizo: se borró el fichero malicioso, se cambió una contraseña, se reinstaló el tema. Y aun así, la infección regresa.

No es mala suerte ni «un virus muy resistente». Es un patrón que hemos reconstruido, con dump de base de datos y análisis forense en la mano, en varios incidentes distintos de e-commerce y pymes en España. La reinfección casi siempre obedece al mismo error: se limpió el síntoma, pero no se cerró el vector de entrada ni se eliminó la persistencia. Este artículo explica, sin tecnicismos innecesarios, por qué «vuelve» y cómo se erradica de verdad.

El vector raíz: una credencial robada que nadie rotó

En la mayoría de los casos que investigamos, el atacante no «revienta» nada. Entra con una llave legítima. Y esa llave, muy a menudo, no es del propio sitio: es una credencial de la agencia o del administrador que gestiona varias webs, robada por un infostealer (un programa que roba las contraseñas guardadas en el navegador de un equipo infectado).

Lo llamativo es la antigüedad. Hemos visto compromisos originados en un equipo infectado años atrás —a veces con más de 160 credenciales guardadas en un solo navegador— cuyas contraseñas nunca se rotaron. Esas credenciales se venden y se reutilizan en mercados clandestinos durante mucho tiempo. Como el correo y el trabajo de una agencia están presentes en muchas webs de clientes, una sola credencial robada se convierte en un caballo de Troya cross-site: la misma llave abre decenas de puertas.

Esta es la razón número uno por la que la reinfección es tan rápida. Si limpias la web pero la credencial que usó el atacante sigue siendo válida, puede volver a entrar por la puerta principal esa misma noche. No ha tenido que hackear nada de nuevo.

La persistencia: por qué reaparece aunque borres el fichero malicioso

El segundo motor de la reinfección es la persistencia: mecanismos que el atacante deja escondidos para que la infección se regenere sola. La limpieza superficial se centra en los ficheros PHP visibles, pero la persistencia más peligrosa no está en un fichero: está dentro de la base de datos.

1. Un disparador (trigger) en MySQL que recrea el administrador

El hallazgo que mejor explica las reinfecciones es un disparador SQL (un trigger) instalado sobre la tabla de comentarios. Es una pieza de código que vive en la propia base de datos y que se ejecuta automáticamente cada vez que se inserta un comentario que contiene cierta frase-marcador. ¿Qué hace? Recrea un usuario administrador oculto mediante inserciones directas en las tablas de usuarios.

Esto tiene una consecuencia demoledora: puedes borrar el administrador malicioso hoy, y mañana un simple comentario en cualquier entrada del blog lo vuelve a crear. El técnico que limpió la web ve la lista de usuarios limpia y da el trabajo por bueno. Pero el trigger sigue ahí, agazapado, esperando el próximo comentario. Es literalmente una máquina de resucitar al atacante.

2. Administradores ocultos que no aparecen en la lista de usuarios

Los administradores que crea el trigger no son visibles de forma normal. La familia de malware emplea una técnica que filtra esos usuarios de la lista del panel de WordPress y falsea el contador, de modo que un administrador legítimo mira «Usuarios» y no ve nada raro. La cuenta existe, tiene permisos totales, pero es invisible desde la interfaz. Solo aparece consultando la base de datos directamente.

3. El secuestro del correo

En paralelo, el atacante cambia las direcciones de correo del sitio: el correo de administración, el de las notificaciones de la tienda, el remitente de los pedidos, las direcciones de los formularios de contacto. El resultado es doble: por un lado, se lleva los leads y avisos del negocio a un buzón que controla; por otro —y esto es lo grave— si controla ese buzón, puede interceptar los correos de «restablecer contraseña». Cambiar la clave de administrador deja de servir de nada si el enlace de reseteo llega directo a manos del intruso.

4. Ficheros dropper

Por último están los ficheros: pequeñas puertas traseras en PHP camufladas dentro de plugins de aspecto inofensivo, o backups completos del sitio dejados accesibles por web (una fuga total, porque contienen la configuración y la base de datos). Estos son los que casi todo el mundo busca y borra. Son el síntoma más visible, pero el menos importante de toda la cadena.

La moraleja: limpiar el síntoma no cierra la herida

Cuando alguien «limpia» una web infectada de esta forma pero no cierra el vector ni retira la persistencia, el resultado es predecible: reinfección en días. Hemos documentado casos donde la primera limpieza eliminó el backdoor y revirtió el correo, pero dejó viva la cuenta de administrador comprometida y el secuestro del correo. Meses después, con esa cuenta todavía activa, el atacante volvió a plantar el trigger y a generar administradores ocultos con nombres nuevos. Mismo mecanismo, distinto disfraz.

Cómo se erradica de verdad

Una erradicación correcta no busca «quitar el virus»: busca cerrar las tres cosas a la vez —el vector de entrada, la persistencia y las llaves comprometidas—. Este es el orden que seguimos en nuestras respuestas a incidentes:

• Localizar y eliminar la persistencia de la base de datos. Ejecutar SHOW TRIGGERS para descubrir cualquier disparador oculto, confirmar su cuerpo y hacer DROP. Revisar también tareas programadas (cron/eventos) y opciones manipuladas.
• Neutralizar los administradores ocultos. No basta con la lista del panel: hay que auditar la tabla de usuarios en la base de datos para cazar las cuentas que se filtran de la vista.
• Revocar el privilegio de crear triggers al usuario de MySQL que emplea WordPress, para que no pueda volver a instalarse un disparador aunque el atacante recupere acceso.
• Rotar TODAS las credenciales, no una. Contraseñas de WordPress, FTP/SSH, panel de hosting, base de datos, SMTP y —crítico— el buzón de correo que el atacante pudo secuestrar. Si la credencial raíz vino de un equipo infectado, ese equipo debe formatearse y darse por comprometidas todas sus contraseñas guardadas.
• Activar la verificación en dos pasos (2FA) en el panel de administración y en el correo. Es lo que rompe la reutilización de credenciales robadas.
• Regenerar los salts y claves de autenticación en la configuración de WordPress. Esto invalida las cookies de sesión del atacante: aunque tuviera una sesión abierta, deja de servirle.
• Limpiar el secuestro del correo en todas sus ubicaciones: administración, tienda, remitente de pedidos y formularios.
• Vigilancia posterior. Una reinfección se detecta en horas si hay monitorización. Sin ella, te enteras cuando Google te penaliza.

Y una consideración que va más allá de una sola web: si el origen fue una credencial de agencia reutilizada, el problema es cross-site. No sirve de nada blindar un sitio y dejar los otros veinte con la misma llave robada. La auditoría tiene que ser del conjunto.

Si estás leyendo esto porque tu web ya ha vuelto a caer, no repitas la limpieza superficial que falló la primera vez. En nuestra guía me han hackeado te explicamos los primeros pasos para contener el daño sin destruir las pruebas forenses, y si quieres que lo revisemos nosotros, puedes escribirnos desde contacto. La diferencia entre una limpieza y una erradicación es, casi siempre, la diferencia entre volver a estar tranquilo y recibir esta misma llamada dentro de una semana.

PathSentinel · Jesús Macías Rubiales