Limpias un archivo PHP y reaparece cuando se guardan los ajustes de un plugin o se ejecuta una tarea. El payload puede estar almacenado en una opción, plantilla, snippet o tabla propia mientras el plugin escribe esos datos en una caché o archivo generado.
Limpiar solo el sistema de archivos deja intacta la fuente. Borrar filas de la base sin identificar su función puede destruir una configuración legítima.
Construye una cronología del desencadenante
Registra qué acción precede a la reescritura: guardar ajustes, regenerar caché, ejecutar cron, compilar un constructor visual o recibir una visita. Anota ruta y hash del archivo antes y después.
Conserva un volcado de la base y el directorio del plugin antes de repetir el desencadenante en una copia aislada. No continúes generando archivos maliciosos en producción.
Alinea las marcas de tiempo de PHP, base de datos y logs de acceso en la misma zona horaria.
Identifica el componente que escribe
Busca el nombre y directorio del archivo generado dentro del código verificado del plugin o tema. Determina qué callback lo escribe y qué valor de la base suministra el contenido.
Plugins legítimos de caché o minificación generan derivados PHP o JavaScript, por lo que escribir archivos no es malicioso por sí mismo. Compara el valor almacenado con los ajustes esperados e investiga cómo entró en la base.
No ejecutes la salida generada durante el análisis.
Localiza de forma segura la fuente en la base
Utiliza consultas de solo lectura o herramientas que entiendan WordPress para buscar una cadena distintiva del payload, un dominio externo o el nombre de la opción. Evita búsquedas genéricas que devuelvan contenido de clientes.
Inspecciona opciones, entradas, widgets, bloques reutilizables, tablas de plugins de snippets y argumentos de acciones programadas. Protege los volcados porque pueden contener datos personales y credenciales.
Exporta la fila concreta antes de cambiarla, conservando serialización y codificación.
Determina si el escritor está comprometido
Compara el plugin con su paquete verificado. Un plugin limpio puede compilar fielmente una plantilla maliciosa guardada en la base; uno modificado puede inyectar código aunque los ajustes almacenados sean correctos.
Revisa versión, origen de la actualización, acciones administrativas e historial de vulnerabilidades. Comprueba si el formulario de ajustes carecía de control de capacidades, nonce o validación de entrada.
Corrige tanto los datos como la ruta de código. Eliminar solo una parte permite que la infección vuelva.
Correlaciona escrituras cuando existan registros
Los logs de auditoría administrados o el registro binario de MySQL pueden mostrar cuándo cambió un valor y qué usuario de base lo hizo. Consulta al proveedor antes de activar trazas detalladas: pueden afectar al rendimiento y capturar consultas sensibles.
WordPress suele conectarse con un solo usuario de aplicación, así que ese nombre no identifica necesariamente a una persona. Correlaciona la hora con logs web y administrativos y con los callbacks de la aplicación.
Conserva únicamente los eventos relevantes y evita incluir datos de clientes en el informe.
Limpia sin corromper la configuración
Usa el método de ajustes o restablecimiento admitido por el plugin cuando exista. Para modificar un valor concreto, trabaja con copia previa y preserva las estructuras serializadas mediante las API de WordPress.
Elimina solo campos o filas confirmados como maliciosos. Reconstruye los archivos generados desde datos revisados o reinstala el plugin desde un paquete verificado.
Nunca ejecutes un REPLACE SQL masivo sobre opciones serializadas: cambiar la longitud de una cadena puede impedir su deserialización.
Revisa cuentas y otras persistencias
Inspecciona administradores, contraseñas de aplicación, cron, acceso SFTP o al panel y webs vecinas. Una sesión administrativa robada puede volver a insertar el valor en la base.
Rota las credenciales afectadas después de asegurar los dispositivos. Revisa los logs para atribuir el cambio de ajustes y elimina automatizaciones desconocidas.
Comprueba usuarios y acceso remoto de MySQL si es posible un compromiso directo de la base.
Verifica el ciclo completo
Pon en cuarentena el archivo generado, limpia la fuente en la base y activa la regeneración legítima en un staging aislado. Confirma que la salida coincide con el código esperado y revisado.
Repite ejecuciones programadas y guardados de ajustes. Después monitoriza hashes y valores de la base en producción durante más tiempo que el antiguo intervalo de retorno.
Cuándo se necesita ayuda especializada
Solicita una evaluación cuando haya opciones serializadas, plugins de snippets o PHP generado. Comparte nombres de opciones o tablas y hashes, pero censura los valores.
La reparación debe limpiar almacenamiento y escritor, conservar la configuración legítima y demostrar que la regeneración normal ya no puede recrear el malware.