Cron jobs y tareas fantasma: el IoC que reinfecta tu web una y otra vez

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Hay un patrón que se repite en casi todos los casos de reinfección que investigamos: el cliente limpia el sitio a conciencia, borra el fichero sospechoso, cambia las contraseñas y respira tranquilo. Diez minutos después, el web shell ha vuelto. La responsable es, en la inmensa mayoría de las ocasiones, una tarea programada maliciosa en WordPress que actúa como reloj automático de la reinfección. Este mecanismo es una de las formas de persistencia más eficaces y baratas para un atacante, y entenderlo es imprescindible dentro del cuadro general que describimos en Anatomía del hackeo: persistencia, backdoors y SEO-spam.

Qué es una tarea programada maliciosa en WordPress y por qué es tan efectiva

Una tarea programada, o cron job, es simplemente una orden que el servidor ejecuta de forma automática cada cierto tiempo. En un entorno legítimo sirve para publicar entradas programadas, purgar caché o enviar correos. En manos de un atacante se convierte en un vigilante que comprueba, cada uno o cinco minutos, si su puerta trasera sigue en su sitio; si no la encuentra, la vuelve a escribir. El resultado es que la víctima está atrapada en un bucle: limpia el síntoma sin tocar el mecanismo que lo regenera.

La eficacia de esta técnica reside en que separa el arma del gatillo. El web shell visible es prescindible para el atacante; lo importante es el job que lo recrea. Por eso una limpieza que solo persigue ficheros ejecutables -sin auditar las tareas programadas- está condenada a fracasar. El propio MITRE ATT&CK, en su técnica de Web Shell (T1505.003), encuadra estas puertas traseras dentro de la persistencia precisamente porque suelen ir acompañadas de un mecanismo de reaparición.

Los dos escenarios: WP-Cron frente al cron del sistema

En WordPress la amenaza vive en dos planos distintos y hay que revisar los dos:

• WP-Cron: el planificador interno de WordPress. No es un cron real del sistema operativo; se dispara cuando alguien visita la web y ejecuta los hooks pendientes almacenados en la base de datos, en la opción cron de la tabla wp_options. Un atacante registra ahí un evento propio -por ejemplo, un hook con un nombre inocuo- que en cada disparo reescribe el backdoor o reinyecta el SEO-spam. Como vive en la base de datos, sobrevive a cualquier limpieza que se limite a los ficheros.
• Crontab del sistema: si el intruso ha conseguido acceso a nivel de usuario del hosting (por SSH o por un panel), puede añadir una entrada al crontab de Unix. Esto es más grave, porque se ejecuta con la periodicidad exacta que él decida, con total independencia de que alguien visite o no la web, y queda fuera del alcance de cualquier plugin de WordPress.

Cómo cazar la tarea fantasma

La investigación se aborda por capas. En el plano de WordPress, la lista real de tareas programadas se encuentra volcando el contenido de la opción cron de wp_options. Ahí aparecen todos los eventos con su próxima ejecución y el hook asociado. Un evento legítimo apunta a una función conocida del core o de un plugin instalado; un evento malicioso invoca un hook huérfano, sin código que lo respalde de forma visible, o cuyo callback esconde una llamada a eval, base64_decode o descarga remota. Cotejar cada entrada con los hooks que realmente registran tus plugins es lo que hace saltar a la falsa.

En el plano del sistema, con acceso por SSH se revisa el crontab -l del usuario y los directorios /etc/cron.* cuando hay privilegios para ello. Buscamos líneas que llamen a curl o wget hacia dominios desconocidos, que ejecuten PHP contra ficheros ocultos en uploads, o que canalicen texto directamente a un intérprete. Cualquier tarea que descargue y ejecute algo de un servidor externo cada pocos minutos es, salvo prueba en contrario, el motor de la reinfección.

Señales que delatan el job desde fuera

No siempre hace falta entrar al servidor para sospechar. Hay síntomas observables que orientan la investigación:

• Un fichero que borras y reaparece con fecha de modificación reciente cada pocos minutos (el cruce con los timestamps del sistema de ficheros confirma el patrón).
• Picos de carga o de CPU periódicos y regulares, coincidiendo con la frecuencia del job.
• Conexiones salientes recurrentes a la misma IP o dominio, visibles en los logs del servidor.
• SEO-spam que reaparece en el .htaccess o en la home justo después de haberlo limpiado, señal de que el contenido basura está siendo reinyectado de forma programada en contra de las políticas de spam de Google.

Erradicar el ciclo, no solo el fichero

Neutralizar una tarea fantasma exige orden. Primero se identifica y desactiva el job -eliminando la entrada de wp_options o del crontab-; solo entonces se borra el backdoor que regeneraba. Hacerlo al revés garantiza que el fichero vuelva antes de que termines. Después hay que cerrar la vía de entrada original, porque un atacante con acceso persistente volverá a plantar el cron en cuanto pueda. Y conviene revisar si el mismo cron alimenta a más de un artefacto: es frecuente que un único job mantenga vivos varios web shells repartidos por el sitio.

Cuando ni desactivando las tareas visibles se detiene la reinfección, el problema es una persistencia de nivel superior -un acceso que se revende y se reutiliza-, un fenómeno que analizamos en Backdoor-as-a-Service: el mercado negro que revende el acceso a tu web. En entornos exigentes como banca o comercios con datos de tarjeta, dejar un solo cron malicioso activo equivale a mantener la brecha abierta, por lo que la auditoría de tareas programadas es parte obligatoria de cualquier respuesta seria. Fuentes como el blog de Sucuri documentan campañas enteras sostenidas durante meses por un único job olvidado.

Si tu web se limpia y vuelve a infectarse en cuestión de minutos, casi con seguridad tienes una tarea programada trabajando en tu contra. Cuéntanos tu caso y localizamos el reloj que la regenera.