Qué importa primero: Una herramienta de monitoreo informa que los archivos fueron añadidos, modificados o eliminados. La alerta es una evidencia valiosa solo cuando se compara con una implementación esperada y una liberación de confianza.
Qué indica realmente este síntoma
Restaurar cada archivo cambiado puede borrar la evidencia de trabajo legítimo o atacante. Rutas, hashes, propietario y historial de procesos ayudan a separar los cambios de rutina de las escrituras no autorizadas.
Recopila pruebas antes de cambiar nada
- Exportar el conjunto de cambios completo con hashes antiguos/nuevos y fecha y horas.
- Compáralo con la actividad de implementación, actualización y administrador.
- Verifica los archivos núcleo, plugin y tema contra paquetes de confianza exactos.
- Priorizar archivos ejecutablas en subidas, root, mu-plugins y rutas de escritura reciente.
Causas más habituales
- Actualización legítima: Una versión controlada del componente cambió los archivos esperados.
- Hotfix manual: Una edición autorizada ocurrió fuera del control de la versión.
- Desplazamiento fallido: Sólo una parte de una versión fue copiada.
- Compromiso: Código desconocido o cambios aparecen sin un actor legítimo.
Secuencia segura de diagnóstico y reparación
- Preservar archivos sospechosos y registros relevantess antes de su reemplazo.
- Restaurar de versiones de confianza solo después de clasificar los cambios personalizados.
- Cierre la ruta de escritura, gire las credenciales e Inspecciona la persistencia si no está autorizada.
- Establacer una línea de base limpia y monitorizar la recurrencia.
Cómo distinguir entre las causas probables
No trates Actualización legítima y Hotfix manual como causas equivalentes. Una versión controlada del componente cambió los archivos esperados. En cambio, una edición autorizada ocurrió fuera del control de la versión. Para distinguirlas, usa estas dos comprobaciones: Exportar el conjunto de cambios completo con hashes antiguos/nuevos y fecha y horas; y compáralo con la actividad de implementación, actualización y administrador. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Preservar archivos sospechosos y registros relevantess antes de su reemplazo— o si debes conservar el estado actual y ampliar la investigación.
En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No apruebe una nueva línea de base de integridad mientras que los cambios inexplicables permanecen. Eso convierte los archivos atacantes en “bien conocido”.
Cómo verificar la reparación
- Cada archivo cambiado tiene una fuente documentada o se elimina.
- Los comprobaciones de confianza y los manifiestos de despliegue coinciden.
- No se produce ningúna escritura inexplicable después de la nueva línea de base limpia.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.