Safeguard
Application Security•

Detecting and Mitigating Cron Job Abuse (T1053.003)

Cron is the default scheduler on Linux, macOS and ESXi, and a common persistence spot. See what MITRE says to monitor and how cron.allow and cron.deny help.

Safeguard Security Team
4 min read

Cron is the time based job scheduler on Unix like systems. A crontab file holds the schedule, listing what to run and when. MITRE tracks abuse of it as T1053.003 under Execution, Persistence and Privilege Escalation, on Linux, macOS and ESXi.

Cron is attractive because it is everywhere, it is quiet, and a single line is enough. It is also easy to inspect, which works in a defender's favor.

How attackers use it

MITRE says an adversary may use cron to execute programs at system startup or on a schedule for persistence. Crontab files are stored in operating system specific paths. On ESXi, MITRE notes that cron jobs must be created directly in the crontab file, for example /var/spool/cron/crontabs/root.

The MITRE page lists many procedure examples. Their behaviors fall into a few repeating patterns:

  • Adding an entry that runs at reboot, sometimes with a short delay.
  • Adding an entry that downloads and runs a script on a repeating interval, as often as every minute.
  • Falling back to crontab for persistence when the code lacks root privileges.
  • Editing a root crontab file directly.

The point is not any one family. It is that cron persistence is routine, and defenders should assume it will be tried.

How to detect it

MITRE's detection strategy, by platform:

  • Linux: creation or modification of crontab entries by non-root users or from abnormal parent processes, followed by execution of uncommon binaries at scheduled intervals.
  • macOS: crontab additions or modifications through the crontab utility or direct edits, especially by interactive users running hidden or renamed scripts.
  • ESXi: direct modification of crontab entries such as /var/spool/cron/crontabs/root, or of /etc/rc.local.d/local.sh, followed by execution of scripts tied to lateral movement or persistence.

Practical signals worth alerting on:

  1. A crontab file changed outside a change window.
  2. A new entry owned by a user who normally has no scheduled jobs.
  3. An entry that fetches something from the network and runs it.
  4. An entry pointing at a hidden file, a temp directory or a path an ordinary user can write.
  5. A @reboot entry you cannot account for.

MITRE also points to logs. Cron execution can be reviewed in the /var/log directory, and the location of the cron log file can be confirmed in the syslog configuration at /etc/rsyslog.conf or /etc/syslog.conf.

How to reduce the risk

MITRE lists two mitigations.

  1. User account management. Cron permissions are controlled by /etc/cron.allow and /etc/cron.deny. If a cron.allow file exists, only the users listed in it can use cron. The cron.deny file explicitly disallows users. If neither file exists, only the superuser can run cron.
  2. Audit. Review changes to the cron schedule, and use the logs under /var/log to review cron execution.

A cron.allow file with a short list is the stricter choice, because anything not named is blocked by default.

Check your own environment

Read-only commands on Linux or macOS:

  • crontab -l shows the current user's crontab.
  • sudo crontab -l -u root shows root's entries.
  • ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly lists system jobs.
  • ls -l /etc/cron.allow /etc/cron.deny shows which access control file is in use.
  • grep CRON /var/log/syslog on Debian style systems, or journalctl -u cron, shows recent cron activity. The log location varies, so confirm it from your syslog config.

Record a baseline of every entry, then compare it on a schedule. Cron jobs that fetch scripts or packages also depend on what they fetch. If your jobs install dependencies, the free scan at gold.safeguard.sh/scan can check a dependency file in your browser with no login, and the file does not leave your machine.

Monitoring that compares today against yesterday is what turns a baseline into a detection. The demo below walks through that idea for software supply chain changes.

Click through it at your own pace, or open it full screen.

Quick check

If neither cron.allow nor cron.deny exists, who can run cron?

Only the superuser, according to MITRE.

Which cron entry type survives a reboot?

A schedule based on startup, such as an @reboot line. It runs again each time the system starts.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.