Cron Persistence: Hunting Scheduled Backdoors

You found the backdoor process, you killed it, the CPU graph went flat. Five minutes later it's back. You kill it again. It comes back again.

What you're fighting isn't the process — it's the schedule that keeps re-launching it. An attacker who wants to survive reboots and clean-up rarely relies on a single running program. Instead they plant a scheduled job: a line in cron, a systemd timer, an anacron entry — something the system itself faithfully re-runs on a clock. The malware doesn't have to stay alive. It just has to be re-spawned.

Think of a wind-up toy that rewinds itself. Knock it over and it stands back up, because the spring keeps turning. Stomping the toy (killing the process) does nothing while the spring (the schedule) is intact. To actually stop it you have to find and disarm the spring — and on Linux there are several springs, in several drawers, and a hunter who checks only one drawer declares the box clean while it's still compromised.

Each user account has its own personal crontab. You read your own with crontab -l, and you read someone else's with crontab -l -u <user>. The catch: an attacker who compromised the www-data account (or root) plants the job in that user's crontab — not yours.

These personal crontabs live as files under /var/spool/cron/ (the exact subpath varies by distro: /var/spool/cron/crontabs/ on Debian/Ubuntu, /var/spool/cron/ on RHEL). You should never edit those files directly, but as a hunter it's worth knowing they exist — a non-empty spool file for a service account that should never schedule anything is itself suspicious.

The move that separates a hunter from a beginner: loop over every account in `/etc/passwd` and dump each one's crontab.

Personal crontabs are only half the map. The system has its own scheduling locations, and they're a popular hiding spot precisely because hunters forget them:

• `/etc/crontab` — the master system crontab. Its lines have an extra field: a username to run as, between the time fields and the command.
• `/etc/cron.d/` — a drop-in directory. Any file dropped here is treated as a system crontab fragment (same 7-field format). Dropping a single file here is an attacker's clean way to add a job without editing any existing file.
• `/etc/cron.hourly/`, `/etc/cron.daily/`, `/etc/cron.weekly/`, `/etc/cron.monthly/` — directories of scripts. Anything executable here runs on that cadence. No cron syntax needed: just drop an executable script and it runs.

Grep them all at once and read every line with fresh suspicion.

Modern distros increasingly schedule work with systemd timers instead of cron — and so do modern attackers, because a hunter who only knows cron will never look here. A timer is two units working together (you met units in the systemctl lesson):

• a `.timer` unit that says when to fire (every 10 minutes, daily, 5 minutes after boot…)
• a `.service` unit it activates that says what to run.

Kill the service's process and the timer simply re-activates it on the next tick — the wind-up spring again, just in systemd's drawer. systemctl list-timers is the single command that lays them all out.

There's one more drawer, and it's the sneakiest. Plain cron assumes the machine is always on — if a job was scheduled for 3am and the box was powered off, that run is simply skipped. That's a problem for laptops and desktops, which is why anacron exists.

Anacron doesn't care about wall-clock time; it tracks how many days since each job last ran, and after a boot it runs anything that's overdue. Its config is `/etc/anacrontab`, with entries shaped like period delay job-id command.

For a hunter this matters enormously: a victim might reasonably think "my laptop was off all night, so the scheduled malware never ran." With anacron, the missed job simply runs when they next power on — the wind-up spring releases the moment the toy is picked back up. So your sweep is incomplete until you've read /etc/anacrontab too.

You have a real root shell. Run this sweep top to bottom — it's the exact checklist you'd run on a "this box keeps re-infecting itself" call. Every command here is read-only: you're enumerating schedules, not changing anything yet. There may be nothing malicious here; the goal is to make the moves reflexive, so on a real box you check every drawer, not just the first.