Overview
Scheduled tasks (such as cron jobs) that run with elevated privileges are a classic Linux escalation vector when misconfigured. This lesson covers scheduled-task escalation, defensively.
Learning objectives
- Explain how privileged scheduled tasks enable escalation.
- Identify scheduled-task misconfigurations.
- Connect to hardening scheduled tasks.
Core concept
Linux scheduled tasks (e.g. cron jobs) run commands automatically at set times, often with elevated privileges (root). If a scheduled task, running as root, executes a script or binary that a low-privilege user can modify — or references paths/files the user controls — the user can influence what the privileged task does, escalating their access. The recurring nature makes this especially useful to attackers: modify the target file, and the next scheduled run executes it with elevated privilege. Misconfigurations here are a well-known escalation pattern.
How it works
A privileged scheduled task periodically runs a defined command. If the script/binary it runs is writable by a low-privilege user, or if it references a file/path the user can control, the user can alter what runs — and when the task next executes (as root), their changes run with root privilege (a boundary crossing). In authorized testing, enumeration examines scheduled tasks (what runs, as whom, and whether the referenced files are user-writable). Defensively, scheduled-task scripts/binaries must be owned and writable only by root, referenced by absolute, protected paths, and the tasks run with minimal necessary privilege. This is a permission misconfiguration expressed through scheduling.
Practical example
In an authorized Linux lab, the tester finds a root cron job that runs a script located in a directory where the low-privilege user can write. Because the user can modify (or replace) that script, the next scheduled run would execute the user's content as root — a clear escalation path. The fix: ensure the script and its directory are owned and writable only by root, and reference it by a protected absolute path. The path arose from a privileged scheduled task plus a writable target — a textbook pattern.
Cybersecurity relevance
Scheduled-task misconfigurations are a classic, well-documented Linux escalation vector (and also a persistence mechanism — see the persistence module). Defensively: ensure privileged scheduled tasks run scripts/binaries owned and writable only by root, use absolute protected paths, run tasks with minimal privilege, and monitor scheduled-task definitions and the files they run for unauthorized changes (a detection signal). In authorized testing, writable files referenced by privileged tasks are prime escalation findings. Understanding this pattern guides both offense (in labs) and the corresponding hardening/detection.
Common mistakes
- Privileged scheduled tasks running scripts/binaries writable by low-privilege users.
- Referencing tasks by user-controllable or relative paths instead of protected absolute ones.
- Not monitoring scheduled-task definitions/files for unauthorized changes.
Key takeaways
- Privileged scheduled tasks (e.g. root cron jobs) become escalation vectors when they run scripts/binaries a low-privilege user can modify, or reference user-controllable paths.
- The recurring execution means user-modified content runs with elevated privilege on the next run.
- Mitigate by making task scripts/binaries root-owned and root-writable-only, using protected absolute paths, running with minimal privilege, and monitoring task files (also a persistence mechanism).
Check your understanding
- How does a root cron job that runs a user-writable script enable privilege escalation?
- What hardening measures protect scheduled tasks from being abused for escalation?