Qué importa primero: La raíz index.php es pequeña y comúnmente monitoreada, por lo que los atacantes la utilizan como un punto de ejecución confiable. La modificación repetida demuestra que la limpieza no tuvo un cargador, credencial o compromiso vecino.
Qué indica realmente este síntoma
Fresh fecha y horas y hashes separan la reinfección real de la salida caché. Propiedad y auditoría logs ayudan a identificar web, SFTP o escribe a nivel de sistema.
Recopila pruebas antes de cambiar nada
- Preservar cada versión infectada, hash, fecha y hora y propietario.
- Monitoriza el archivo para la siguiente escritura y correlacionalo con el proceso y accede a logs.
- Buscar cron, mu-plugins, cargas, configuración de auto-prepensión y sitios de hermanos.
- Auditoría servidoring, SFTP y credenciales de administrador utilizadas cerca del tiempo de escritura.
Causas más habituales
- Cargador oculto: Otro archivo PHP reescribe index.php en solicitudes o cron.
- Credenciales comprometidas: Un atacante continúa cargando el archivo externamente.
- Lugar vecino: Una aplicación diferente bajo el mismo usuario escribe a través de directorios.
- Persistencia a nivel del servidor: auto_prepend_file o tareas programadas del sistema se ejecutan antes de WordPress.
Secuencia segura de diagnóstico y reparación
- Reemplazar index.php del paquete de núcleo limpio exacto después de preservar la evidencia.
- Quitar el mecanismo de persistencia y cerrar la ruta de escritura.
- Rotar todas las credenciales privilegiadas e invalidar sesiones.
- Separar o limpiar cada sitio compartiendo la cuenta y monitorear la integridad.
Cómo distinguir entre las causas probables
No trates Cargador oculto y Credenciales comprometidas como causas equivalentes. Otro archivo PHP reescribe index.php en solicitudes o cron. En cambio, un atacante continúa cargando el archivo externamente. Para distinguirlas, usa estas dos comprobaciones: Preservar cada versión infectada, hash, fecha y hora y propietario; y monitoriza el archivo para la siguiente escritura y correlacionalo con el proceso y accede a logs. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Reemplazar index.php del paquete de núcleo limpio exacto después de preservar la evidencia— 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 siga reemplazando index.php mientras el sitio permanece en línea y cambiando activamente. Preservar estado y contener acceso a escritura primero.
Cómo verificar la reparación
- index.php sigue siendo idéntico a través del tráfico, cron y reiniciar.
- Ningún proceso o cuenta desconocido puede escribir a la raíz de la web.
- Los sitios hermanos y la configuración a nivel de servidor están limpios.
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.