Malware WordPress que vuelve tras limpiarlo: los procesos que pueden reinfectar tu web

Borrar un archivo malicioso y descubrir que vuelve a aparecer poco después suele indicar un problema más serio que un único archivo infectado.

La pieza que ves puede ser solo el payload: el código que genera una redirección, spam SEO, una puerta trasera o un comportamiento anómalo. Pero el mecanismo que lo vuelve a crear puede estar en otro lugar y ejecutarse fuera del flujo normal de WordPress.

Eliminar el archivo visible no sirve de mucho si queda activo el proceso, la tarea o la configuración que lo vuelve a escribir.

El problema no siempre está dentro de WordPress

Cuando se habla de malware persistente, es fácil pensar solo en plugins, temas o archivos PHP de la instalación. Sin embargo, una reinfección puede mantenerse mediante componentes que no se ven al entrar en el administrador de WordPress.

Los análisis recientes de malware de tipo SC 4.0.3 describen precisamente varias vías de persistencia coordinadas: al eliminar una pieza, otra puede restaurarla cuando recibe una nueva petición PHP o de WordPress.[1]

Eso no significa que toda web que se reinfecta tenga esa familia concreta de malware. Sí explica un patrón importante: la web puede volver a infectarse porque todavía hay algo con capacidad de ejecutarse y escribir archivos.

Procesos y tareas que pueden volver a crear el malware

Una revisión debe buscar qué se ejecuta después de la limpieza y con qué permisos. Algunos puntos habituales son los siguientes.

Cron del servidor

Un cron del servidor puede lanzar comandos o scripts PHP cada pocos minutos, horas o días. Si contiene una ruta maliciosa o descarga un nuevo payload, el archivo eliminado puede reaparecer aunque WordPress esté aparentemente limpio.

No basta con revisar las tareas programadas dentro del panel de WordPress. También hay que comprobar los crontabs del usuario de hosting, las tareas definidas en el panel del servidor y cualquier automatización asociada a la cuenta.

WP-Cron y tareas de plugins

WordPress tiene su propio sistema de tareas programadas. Plugins, temas y código personalizado pueden registrar acciones que se ejecutan al recibir visitas o mediante un cron real del servidor.

Una tarea inesperada no demuestra por sí sola una infección, pero si llama a archivos desconocidos, descarga contenido o coincide con el momento en que reaparece el malware, debe investigarse. También conviene revisar los plugins desactivados y los MU plugins: estos últimos se cargan automáticamente y no se gestionan como un plugin normal desde el escritorio.

Configuraciones PHP que se ejecutan antes que WordPress

Archivos como .user.ini pueden incluir directivas de PHP que se aplican antes de cargar WordPress. Una directiva como auto_prepend_file, usada legítimamente en algunos entornos, puede obligar a PHP a cargar un archivo en cada petición.

Si esa configuración apunta a un loader malicioso, restaurar archivos de WordPress o cambiar el tema no resolverá la causa. Las investigaciones sobre SC 4.0.3 han documentado el uso de archivos .user.ini, drop-ins y otros cargadores PHP para mantener la ejecución del malware.[1][2]

Directorios temporales y scripts fuera de la instalación

El código que reconstruye una infección no tiene por qué vivir bajo public_html ni dentro de la carpeta de WordPress. Puede estar en directorios temporales, rutas auxiliares de la cuenta, archivos ZIP, copias antiguas accesibles o ubicaciones configuradas para ser cargadas por PHP.

Por eso una limpieza limitada a wp-content o a los archivos modificados recientemente puede dejar fuera justo el componente que conserva el acceso.

Servicios y procesos del servidor

En VPS o servidores administrados también conviene descartar procesos en ejecución, servicios modificados, tareas de despliegue o scripts de mantenimiento que no correspondan con la operativa del sitio.

No todos estos elementos estarán disponibles en un hosting compartido ni todos son responsabilidad del propietario de la web. Pero forman parte del alcance técnico que hay que valorar si el malware vuelve tras una limpieza.

Cómo reconocer que se está limpiando el síntoma, no el origen

Hay señales que justifican ampliar la investigación más allá de WordPress:

• El Mismo archivo vuelve a aparecer después de borrarlo.
• Aparecen archivos nuevos con nombres variables o en rutas distintas.
• La Reinfección coincide con una franja horaria o se produce de forma periódica.
• Un Archivo vuelve a cambiar tras recibir visitas o ejecutar una tarea programada.
• La web continúa enviando tráfico o realizando redirecciones sin que el código visible lo explique.
• El problema reaparece después de restaurar una copia de seguridad.
• Hay usuarios, claves, accesos SFTP, credenciales de hosting o reglas de servidor que no se han revisado.

Los escáneres y la comparación de archivos son herramientas útiles, pero no sustituyen la revisión de qué puede ejecutarse en la cuenta. En campañas analizadas recientemente, la persistencia se distribuía entre varias ubicaciones de WordPress y cargadores PHP, de modo que quitar un componente podía no ser suficiente.[1][2]

Qué debe incluir una limpieza bien planteada

Una desinfección no debería limitarse a borrar archivos detectados. El orden depende de cada caso, pero normalmente debe contemplar:

• Preservar la información útil del incidente antes de hacer cambios irreversibles.
• Revisar archivos de core, plugins, temas, MU plugins y drop-ins.
• Comprobar configuraciones PHP como .user.ini, php.ini y rutas de carga.
• Auditar WP-Cron, cron del servidor y automatizaciones del panel de hosting.
• Revisar directorios temporales, scripts auxiliares y procesos disponibles según el servidor.
• Examinar usuarios de WordPress, panel de hosting, SFTP, SSH y base de datos.
• Actualizar o sustituir componentes vulnerables y eliminar los que no se usan.
• Rotar todas las credenciales implicadas y validar las copias antes de restaurarlas.
• Reiniciar PHP-FPM o el servicio PHP equivalente y vaciar la caché de opcode cuando el servidor lo permita. OPcache conserva bytecode PHP precompilado en memoria y, aunque no puede recrear por sí solo un archivo borrado, puede hacer que se siga ejecutando código anterior o dificultar la validación de la limpieza.[3]
• Monitorizar la instalación después de la limpieza para comprobar que no reaparece actividad.

El objetivo es identificar el punto de entrada cuando sea posible, pero también eliminar cualquier mecanismo que pueda conservar o recuperar el acceso.

Por qué el mantenimiento importa después de una desinfección

Una vez recuperada la web, el riesgo no termina al desaparecer el último archivo malicioso. Sin revisiones periódicas, una vulnerabilidad sin parche, una cuenta comprometida o una tarea anómala pueden mantenerse activos durante semanas.

Un buen mantenimiento WordPress incluye actualizaciones revisadas, copias de seguridad verificables, control de accesos, revisión de alertas y seguimiento de cambios inesperados. Es la diferencia entre detectar una anomalía pronto y descubrirla cuando ya ha creado varias capas de persistencia.

Si tu WordPress se reinfecta después de limpiar archivos, no conviene encadenar borrados manuales. En WP Seguridad revisamos el entorno de forma completa para localizar persistencia y recuperar el control del sitio. Con un mantenimiento de seguridad WordPress también ayudamos a reducir la posibilidad de que el problema vuelva a aparecer.

Fuentes

[1] SC 4.0.3 Self-Healing WordPress Malware Research.

[2] SC WordPress Malware in functions.php, db.php & 1j2d192.php.

[3] PHP OPcache: introducción.