Linux Cron Job Security Audit: Persistence Backdoor Detection and Hardening

Cron is the persistence foothold attackers use most. Full Linux cron audit: user- and system-level inventory, systemd timers, download-and-execute indicators, cron.allow whitelist, chattr lock, auditd monitoring. Commands are copy-paste ready. Covers self-respawning backdoors and whitelist false positives.

Applicable Scenarios

First case for a Linux cron security audit is IR after confirmed or suspected compromise: once an attacker has root or an application account, the usual persistence is a cron job that re-runs a malicious script every few minutes and self-revives. Second is routine security baseline inspection—periodic review of scheduled jobs to catch leftover high-risk scripts, weakly permissioned writable jobs, and unexplained entries. Third is ops handover: on an unfamiliar host, inventory every scheduled job before deciding what is business-required vs. a security risk.

Prerequisites

• A CentOS 7+/RHEL/Ubuntu/Debian server. Run audit commands as root or with sudo.
• cronie (RHEL family) or cron (Debian family) installed. On systemd hosts, also inspect systemd timers.
• Optional: auditd for long-term monitoring of cron file changes.

How It Works

Linux cron is driven by the crond daemon. Config is scattered: user jobs in /var/spool/cron/<username> (Debian: /var/spool/cron/crontabs/), system jobs in /etc/crontab and /etc/cron.d/, periodic script dirs /etc/cron.hourly, cron.daily, etc. crond rereads these files every minute and runs them on schedule. Attackers prefer cron for persistence for three reasons: a file write takes effect with no service restart; the job runs as a specified user with stable privilege inheritance; more stealthy than startup items—admins rarely inspect cron. Typical backdoor signatures: a remote download-and-execute chain (curl/wget fetch then run), a reverse shell as the job script, or a self-daemonizing job that deletes then rewrites itself so miner processes come back after the admin kills them.

Procedure

Step 1: Inventory all cron jobs

Run these in order. Collect jobs from every location:

`# All user-level jobs
for user in $(cut -f1 -d: /etc/passwd); do
  echo "== $user =="; crontab -l -u $user 2>/dev/null;
done

# System-level jobs
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

# systemd timers (often-overlooked second persistence point)
systemctl list-timers --all`

Step 2: Identify suspicious job signatures

Triage anything that hits these high-risk patterns:

• Download-and-execute chains combining curl, wget, base64, python -c
• Jobs pointing at scripts in writable dirs: /tmp, /dev/shm, /var/tmp
• Abnormal owner or mode on the job script (777, owned by a web app account)
• High frequency with no business justification (e.g. */1 every minute)

`# Find scripts created or modified in the last 7 days under the directories above
find /etc/cron* /var/spool/cron -type f -mtime -7 -ls

# Check writable directories for suspicious scripts
ls -la /tmp /dev/shm /var/tmp | grep -v drwx------`

Step 3: Harden cron write access

Whitelist who can create jobs. Lock critical files against overwrite:

`# Allow only root and ops accounts to use crontab
echo root > /etc/cron.allow
echo opsuser >> /etc/cron.allow
rm -f /etc/cron.deny
chmod 600 /etc/cron.allow

# Set the immutable attribute on critical system job files
chattr +i /etc/crontab

# Monitor scheduled-job config changes with auditd
cat >> /etc/audit/rules.d/cron.rules <<'EOF'
-w /etc/cron.d/ -p wa -k cron_change
-w /var/spool/cron/ -p wa -k cron_change
-w /etc/crontab -p wa -k cron_change
EOF
augenrules --load`

Verification

Whitelist: as an account not in cron.allow, `crontab -e` should print you (xxx) are not allowed to use this program. auditd: edit a file under /etc/cron.d/, then `ausearch -k cron_change -i` should show a full record (time, account, process). crond: `systemctl status crond` should remain active (running).

FAQ

FAQ 1: Deleted a suspicious job; it came back in minutes? Self-daemonization. Clear three sources together: the job rewrites its own crontab—kill derived processes after deleting the job; a separate daemon script in another job or a startup item—`grep -r "crontab" /etc/cron* /var/spool/cron` to find who writes crontab; malware resident in memory that reinstalls—locate the binary with `ls -l /proc/<PID>/exe` and wipe it, or it revives no matter how many times you delete the job.

FAQ 2: crontab edit fails with Operation not permitted after chattr +i? Expected. The immutable bit also blocks legitimate edits. Unlock with `chattr -i /etc/crontab`, change, re-lock. Root-only; xfs/ext4 only. In containers chattr often does nothing—use a read-only mount or tighter file perms instead.

Summary

Cron persistence is the most common and most overlooked post-compromise foothold. Audit is three moves: collect, identify, harden. List user jobs, system jobs, and systemd timers with one command set. Filter on download-and-execute chains, suspicious paths, and abnormal frequency. Close the write path with cron.allow, chattr, and auditd. Fold these inspection commands into the weekly security baseline and keep verifying so cron stays under control.