Reconocer tareas cron ocultas como puerta trasera

En resumen: Una tarea cron oculta es una de las puertas traseras más frecuentes en servidores Linux: descarga código malicioso con regularidad o reinicia procesos, también tras una actualización de PHP. Revise todos los lugares de tareas programadas, no solo crontab -l: crontabs de todos los usuarios, /etc/crontab, /etc/cron.d, las carpetas cron, temporizadores de systemd y trabajos at. Asegure los hallazgos antes de eliminarlos.

Por qué las tareas cron son tan apreciadas como puerta trasera

Tras una intrusión con éxito, un atacante tiene un problema: su acceso es frágil. Una actualización cierra la vulnerabilidad, un administrador borra la webshell, un reinicio termina el proceso. Una tarea cron resuelve ese problema. Inicia comandos a horas fijas sin que nadie intervenga y restablece así los accesos perdidos.

Para PHP2Shell no hay indicadores de compromiso confirmados. Pero, según los informes de que disponemos, las tareas cron nuevas figuran entre las señales de alerta generales tras intrusiones a través de aplicaciones web. Quien ya haya buscado webshells debería revisar de paso las tareas programadas. Los demás pasos de un seguimiento los recoge la lista de comprobación tras un hackeo.

Dónde pueden esconderse las tareas programadas

Linux conoce varios mecanismos para tareas programadas. Muchas revisiones fracasan porque solo se mira uno de ellos.

Importante para servidores web: el usuario del servidor web puede, por lo general, crear su propio crontab sin derechos de root. Un atacante con los derechos de www-data no necesita por tanto ninguna vulnerabilidad más. Las entradas en /etc/cron.d o unidades de systemd, en cambio, indican que ha obtenido derechos de root.

Los paneles de alojamiento como Plesk o cPanel ofrecen una interfaz propia para tareas programadas. Detrás suelen estar igualmente los crontabs de los usuarios del sistema correspondientes. Quien solo mira en la interfaz no reconoce por ello toda entrada creada directamente en el servidor. En caso de duda, revise ambos.

Cómo revisar todos los lugares por completo

Los siguientes comandos solo leen. Ejecútelos como root y asegure las salidas con la fecha.

# Mostrar los crontabs de todos los usuarios
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Entradas de todo el sistema y fechas de modificación
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# Temporizadores de systemd y trabajos at
systemctl list-timers --all
atq 2>/dev/null

# Buscar patrones típicos en todos los archivos cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null

Dos trucos merecen especial atención. Algunas entradas esconden comandos tras muchos espacios, de modo que en el editor se salen de la pantalla por la derecha. Otras usan caracteres de control que sobrescriben texto al mostrarlo. Con cat -A estos caracteres se hacen visibles:

cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less

Una segunda perspectiva son los registros del servicio cron. En muchos sistemas, cron anota cada ejecución con usuario y comando. Así ve también entradas que un atacante ha eliminado entretanto y reconoce desde cuándo se ejecuta un comando sospechoso:

# Comandos cron ejecutados por el usuario del servidor web (Debian/Ubuntu o journal de systemd)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100

Cómo reconocer una puerta trasera en cron

1. Descarga desde Internet: una descarga cuyo resultado se entrega directamente a una shell.
2. Contenidos codificados: cadenas largas que solo se decodifican en tiempo de ejecución.
3. Rutas inusuales: programas en /tmp, /dev/shm, carpetas ocultas o directorios de subida.
4. Usuario equivocado: tareas bajo el usuario del servidor web, aunque la aplicación no necesite ninguna.
5. Ritmo llamativo: ejecución cada minuto o en cada reinicio mediante @reboot.
6. Marcas de tiempo inadecuadas: archivo modificado en un período en el que nadie trabajó en el servidor, por ejemplo después del 17 de octubre.

No lo olvide: también las aplicaciones tienen sus propias programaciones. WordPress, por ejemplo, gestiona las tareas programadas en la base de datos. Cómo revisarlas allí lo describe Encontrar puertas traseras en WordPress.

Asegurar el hallazgo, entenderlo y después eliminarlo

Una tarea cron maliciosa es una valiosa prueba. Muestra la dirección de descarga, el momento de su creación y, a menudo, el usuario por el que entró el atacante. Asegure el archivo con suma de comprobación y marcas de tiempo antes de eliminarlo. La marca de tiempo ayuda después a reconstruir el desarrollo; cómo se hace lo muestra Crear la línea temporal de un incidente. También para una posible notificación a la autoridad de protección de datos o para la aseguradora, el hallazgo es una prueba importante de desde cuándo tuvo acceso un atacante.

Eliminar por sí solo no basta. Si aún se ejecuta un proceso que reescribe la entrada, estará de vuelta al minuto siguiente. Y mientras la vulnerabilidad original esté abierta, el atacante puede volver a empezar en cualquier momento. El orden es por tanto: asegurar, cerrar la causa, eliminar todos los componentes, cambiar los accesos, vigilar.

Proteger cron de forma preventiva

Para que una puerta trasera en cron ni siquiera pueda surgir o llame pronto la atención, ayudan tres medidas. Primero, se puede fijar qué usuarios pueden crear un crontab. Si existe el archivo /etc/cron.allow, solo los usuarios allí nombrados pueden usar crontab. Si su aplicación no necesita ninguna tarea cron bajo el usuario del servidor web, ese usuario no pertenece a la lista. Compruebe antes qué tareas necesita realmente la aplicación y créelas conscientemente bajo un usuario propio.

Segundo, merece la pena vigilar los archivos. Una herramienta de comprobación de integridad avisa en cuanto cambia un archivo en los directorios cron o bajo /var/spool/cron. Tercero, las tareas programadas pertenecen a la documentación del servidor: quien sabe qué entradas debe haber reconoce de inmediato una ajena.

¿Cómo ayuda PHP SOS en concreto?

• Revisar por completo: examinamos todos los mecanismos de tareas programadas, también temporizadores de systemd, trabajos at y programaciones de aplicaciones.
• Clasificar los hallazgos: analizamos las entradas sospechosas sin ejecutarlas y derivamos otras huellas.
• Limpiar con rigor: con la eliminación de malware eliminamos todos los componentes y cerramos la causa.
• Detectar la reaparición: configuramos una vigilancia que avisa de tareas programadas nuevas o modificadas.

Preguntas frecuentes

Fuentes

• BSI: Oficina Federal Alemana de Seguridad de la Información
• BSI IT-Grundschutz
• OWASP Cheat Sheet Series