El malware de WordPress que se cura solo cada hora

A principios de septiembre, la empresa de seguridad Monarx destapó una campaña de malware en WordPress con un comportamiento que hasta ahora era raro ver fuera de un laboratorio: se reconstruye solo.

El vector de entrada es un falso plugin llamado wp-cron, colocado en wp-content/plugins/, con nombres de función y comentarios que imitan al WordPress real. Desde ahí, el código se inyecta en el index.php de la raíz — el fichero que se ejecuta en cada visita — y crea una cuenta de administrador con usuario fijo y privilegios de Super Admin si el sitio es multisite. También toca el wp-config.php para desactivar caché y constantes de seguridad, y fuerza el vaciado de caché de plugins como WP Rocket o LiteSpeed.

Hasta aquí, un ataque más. Lo que lo hace distinto es lo que pasa después de que alguien lo detecta y lo limpia.

Monarx cuenta al menos cinco capas de persistencia trabajando a la vez: un plugin mu (de los que WordPress carga siempre, sin poder desactivarlos desde el panel), una copia del payload guardada en la base de datos, un capturador de credenciales inyectado en wp-login.php, un dropper inyectado en functions.php, y varios backdoors sueltos por el sistema de ficheros.

La pieza que lo ata todo es una tarea de wp-cron que se ejecuta cada hora: repone la cuenta de administrador si la has borrado, restaura el capturador de credenciales y el dropper si los has limpiado, vuelve a vaciar la caché y borra los registros.

Borrar el fichero infectado no arregla nada. A la hora siguiente vuelve, porque la copia de verdad no estaba en el fichero: estaba en la base de datos, y WordPress mismo es quien la trae de vuelta.

No es un ataque sofisticado en el sentido de cifrado exótico u ofuscación imposible de leer. Aprovecha dos piezas que WordPress tiene por diseño, en cualquier instalación: una base de datos donde escribir, y una tarea programada que corre sola en cada visita sin que nadie la vea.

Es la misma dependencia que ya comentamos al hablar de los plugins que WordPress se está inventando para dejar de ejecutarse: mientras haya PHP corriendo en cada petición y una base de datos con permiso de escritura, hay un sitio donde un atacante puede guardar su copia de seguridad. No hace falta que el atacante sea brillante. Le basta con que la web tenga, por defecto, las dos piezas que necesita.

En Forja lo publicado es HTML y nada más: no hay PHP corriendo en el servidor de la web, no hay base de datos que consultar en cada visita, no hay wp-cron ni ninguna tarea que se ejecute sola. El contenido se escribe en el CMS, se compila y se despliega — no hay un proceso vivo en el que un atacante pueda dejar algo que se auto-restaure.

Si alguien consiguiera modificar un fichero servido, no volvería solo: no hay ninguna tarea programada corriendo en el hosting que vaya a traerlo de vuelta. La próxima publicación desde el origen lo sobrescribe, y punto. El «self-healing» de este malware no es magia: es una consecuencia directa de tener algo ejecutándose. Quítale eso, y no queda mecanismo que pueda usar.

No todo el mundo puede migrar mañana. Si tu web sigue en WordPress, lo mínimo razonable después de esto: revisa la lista de plugins buscando nombres que imiten al core (wp-cron, wp-security, variaciones así), audita las cuentas de administrador una por una, y no des por buena una limpieza sin comprobar la base de datos además de los ficheros.

Y ten los backups fuera del propio hosting — si el malware vive en la base de datos, una copia guardada en el mismo servidor no sirve de mucho. De eso habla la deuda invisible del mantenimiento: la vigilancia continua no es un extra, es la mitad del coste real de seguir en WordPress.