Cron is one of the most useful automation mechanisms in Linux, but misconfiguration can turn it into a persistence and privilege-escalation vector. This guide covers practical usage, common attack paths, and defensive hardening patterns.
Why I still use Cron all the time
Cron is still one of the easiest ways to automate repetitive tasks in Linux.
Backups, cleanup jobs, report scripts, health checks — all of these can run quietly in the background and save a lot of manual work.
But this is also why attackers love it.
If permissions are weak or monitoring is missing, cron can become a clean persistence path or even a privilege-escalation path.
Understanding Cron basics
In Unix-like systems, cron is a time-based job scheduler daemon that runs commands and scripts at scheduled intervals.
Where cron jobs are defined
- System-wide crontabs:
/etc/crontaband/etc/cron.d/ - User-specific crontabs: managed with
crontab -e - User entries are stored under
/var/spool/cron/crontabs/
Crontab syntax
# ┌───────────── Minute (0 - 59)
# │ ┌───────────── Hour (0 - 23)
# │ │ ┌───────────── Day of month (1 - 31)
# │ │ │ ┌───────────── Month (1 - 12)
# │ │ │ │ ┌───────────── Day of week (0 - 7) (0 and 7 = Sunday)
# │ │ │ │ │
# * * * * * /path/to/command_or_script.shYou can also use shortcuts like @reboot, @daily, and @weekly when they fit.
Practical examples
Run backup every day at midnight:
0 0 * * * /home/user/scripts/backup.shRun cleanup every Monday at 03:30:
30 3 * * 1 /home/user/scripts/cleanup.shRun a script on reboot:
@reboot /home/user/scripts/on_boot.shOffensive Security Perspective
Privilege escalation via writable cron script
A common failure mode is a root-owned cron job that executes a script writable by non-privileged users.
ls -l /usr/local/bin/backup.shIf permissions are too broad, an attacker can replace the script payload and wait for scheduled execution.
Typical attack flow:
- Find a root cron job calling a writable script
- Replace script with malicious payload
- Wait for cron execution
- Gain elevated access
Other abuse patterns include:
- Persistence using malicious crontab entries
- Wildcard injection attacks in poorly designed backup scripts
- Misconfigured
systemdtimer/service equivalents
Other common abuse paths
Wildcard abuse in backup scripts
Poor command usage with wildcards can let attackers inject command-like arguments.
Cron entry persistence
If an attacker gets write access to a crontab, they can add recurring jobs that survive reboots and user logouts.
systemd timers as cron alternatives
A lot of modern environments use systemd timers.
Same risk model: bad permissions, bad ownership, no monitoring.
Defensive Hardening Checklist
1) Audit scheduled tasks regularly
crontab -l -u <username>
cat /etc/crontab
ls /etc/cron.d/Also review:
ls -la /var/spool/cron/crontabs/
systemctl list-timers --all2) Enforce least privilege
- Avoid running jobs as root when unnecessary
- Protect scripts with strict ownership and mode
chown root:root /path/to/script.sh
chmod 744 /path/to/script.shIf only root should run and modify it, consider:
chmod 700 /path/to/script.sh3) Monitor execution logs
/var/log/cron(RHEL-based)/var/log/syslog(Debian-based)journalctl -u cron
Look for:
- Unknown script names
- Unexpected execution times
- Jobs that suddenly start failing
4) Harden scripts
- Use absolute paths (
/bin/cpinstead ofcp) - Sanitize all external input
- Avoid unsafe wildcard usage in privileged scripts
- Log key actions for troubleshooting and audit
5) Restrict crontab access
Use /etc/cron.allow and /etc/cron.deny to control who can schedule jobs.
Simple rule:
- If
cron.allowexists, only listed users can use cron - If
cron.allowdoes not exist,cron.denyis used
Conclusion
Cron is still a great tool for Linux automation.
Used correctly, it saves time and keeps systems clean. Used carelessly, it can become an easy attack path.
Audit regularly, keep permissions tight, monitor logs, and treat scheduled jobs as part of your security surface.