Qué importa primero: Una entrada sospechosa de cron puede llamar a un gancho desconocido, ejecutar a menudo o ser registrado por código que ya no es visible en la lista plugin. El programa en sí es evidencia de persistencia.
Qué indica realmente este síntoma
Eliminar el evento puede detener un ciclo, pero el cargador que lo vuelva a registrar puede recrear la tarea en la siguiente solicitud.
Recopila pruebas antes de cambiar nada
- Exportar todos los eventos con ganchos, recurrencia, siguiente ejecución y argumentos.
- Cargue cada gancho desconocido al llamada de retorno PHP que lo registra o maneja.
- Compara los tiempos de creación y ejecución de eventos con cambios de archivo o reinfección.
- Inspecciona mu-plugins, plugins activo, temas y opciones de base de datos para el código de registro.
Causas más habituales
- Persistencia mediante puerta trasera: Un cargador oculto programa descargas remotas o escribe archivos.
- plugin comprometida: Se modificó el código legítimo para registrar la tarea.
- Residuo únicamente de base de datos: El evento permanece después de que el código original fue eliminado.
- Abuso de alta frecuencia: Una tarea se ejecuta cada minuto para preservar el acceso o enviar spam.
Secuencia segura de diagnóstico y reparación
- Preservar la lista de eventos y el código pertinente antes de la modificación.
- Eliminar el código de registro y la carga útil, a continuación, eliminar el evento huérfano.
- Ejecute los eventos debidos en un entorno controlado para identificar los efectos secundarios cuando sea seguro.
- Monitoriza la matriz cron a través de varios ciclos normales para recreación.
Cómo distinguir entre las causas probables
No trates Persistencia mediante puerta trasera y plugin comprometida como causas equivalentes. Un cargador oculto programa descargas remotas o escribe archivos. En cambio, se modificó el código legítimo para registrar la tarea. Para distinguirlas, usa estas dos comprobaciones: Exportar todos los eventos con ganchos, recurrencia, siguiente ejecución y argumentos; y cargue cada gancho desconocido al llamada de retorno PHP que lo registra o maneja. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Preservar la lista de eventos y el código pertinente antes de la modificación— 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 ejecute ganchos cron desconocidos en la producción simplemente para ver lo que sucede. Pueden enviar correo electrónico, reescribir archivos o contactar con la infraestructura del atacante.
Cómo verificar la reparación
- Se eliminan los ganchos sospechosos y el código de registro.
- Ningún archivo, usuario u opción se recrea después de los ciclos cron.
- Los trabajos programados legítimos continúan funcionando una vez.
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.