# Check For Malicious Cron Jobs 1. [Home](https://mysites.guru/) 2. [Tools](https://mysites.guru/tools/) 3. [Hacked site detection](https://mysites.guru/tools/hacked-site-detection/) 4. Check For Malicious Cron Jobs # Check For Malicious Cron Jobs ![Check For Malicious Cron Jobs](https://mysites.guru/_astro/malicious-cron-jobs.COEgksEk_Z1y7IM9.webp) A cron job that quietly re-downloads malware after every clean-up is why a hacked Joomla site keeps reinfecting itself. How to find one and remove it safely. Article Contents - [How the cron job check reads your crontab](#how-the-cron-job-check-reads-your-crontab) - [What turns a clean-up into a losing game](#what-turns-a-clean-up-into-a-losing-game) - [Every job accounted for, nothing hidden](#every-job-accounted-for-nothing-hidden) - [Auditing and removing a rogue cron job](#auditing-and-removing-a-rogue-cron-job) - [What the check can see on your hosting account](#what-the-check-can-see-on-your-hosting-account) - [Further Reading](#further-reading) - [Frequently Asked Questions](#faq) ## How the cron job check reads your crontab Cron is the task scheduler built into every hosting account. It runs a command on a timetable and has no opinion about what that command does, which makes it the most durable foothold an attacker can leave on a compromised Joomla site. This check reads the account’s own crontab, the system crontab at `/etc/crontab`, the drop-in directory at `/etc/cron.d/`, and the run-parts script directories (`/etc/cron.hourly/`, `/etc/cron.daily/`, `/etc/cron.weekly/`, `/etc/cron.monthly/`), and classifies whatever it can read. A job is only ever flagged as malicious on tells that have no innocent explanation in a website’s cron: downloading something and piping it straight into a shell, decoding an encoded blob and executing the result, fetching from a bare IP address instead of a hostname, running a program out of `/tmp` or `/dev/shm`, running a hidden dot-prefixed file, making a file executable from cron, or clearing shell history. Ordinary jobs, a CMS scheduler trigger, a backup tool, certbot, rsync, a database dump, are left alone because they read as exactly what they are. This only works where your hosting permits it Reading or changing cron needs the same access an attacker would need to plant a job. Plenty of hosts do not grant that, so a clean result on a locked-down host means “we could not look,” not “there is nothing there.” Treat this as one more place to check, not proof that cron is clean. ## What turns a clean-up into a losing game A cron job is what turns a one-off clean-up into a losing game, and [reinfected? check every crontab, not just yours](https://mysites.guru/blog/reinfected-check-every-crontab-not-just-yours/) is the fuller story of why. You can remove every malicious file from a site and, if a scheduled job is still set to fetch and rewrite them, they are back within the hour and the clean-up looks like it simply failed. We have seen a job running every five minutes whose only job was to check whether a hidden webshell was still in the web root and, if it had gone, copy a stashed spare back into place from a `.cache` directory. Removing the webshell without finding that job would have looked like a success right up until the next five-minute mark. The blind spot is that most site owners only ever look at their own account’s crontab. On one server we found a backdoor sitting in `/etc/cron.daily/`, disguised as a hosting-panel sync script, running as root every day and dropping a webshell into practically every site on the box. Its payload was a single line that downloaded a script from an IP address written in hexadecimal and piped it into a shell, so nothing was ever written to disk for a file scanner to catch. Because cron lives on the server rather than in a site’s files, neither a file scanner nor the CMS itself can see it. There are also two schedulers above the operating system that a server-side cron check does not cover: WordPress’s WP-Cron, stored in the `wp_options` table, and Joomla’s own Scheduled Tasks, stored in `#__scheduler_tasks`. Those are separate surfaces and need their own review. ## Every job accounted for, nothing hidden A clean crontab contains only jobs you or your host can account for: your CMS’s own scheduler, a backup tool, certbot renewal, a log rotation, a database dump. Every entry runs a recognisable command against a recognisable target, none of them download-and-execute, none of them run from a temporary directory, and nothing is hidden behind a dot-prefixed filename or an obfuscated one-liner. ## Auditing and removing a rogue cron job 1. **Get access to the crontab.** Run `crontab -l` over SSH, or use your host’s panel, cPanel’s Cron Jobs page or Plesk’s Scheduled Tasks. That only shows your account’s own jobs, so also ask your host, or use SSH access if you have it, to check `/etc/crontab`, `/etc/cron.d/` and the four run-parts directories. 2. **Read every line before touching anything.** Look for the tells above: a download piped into a shell, a decoded and executed blob, a bare-IP fetch, execution from `/tmp` or `/dev/shm`, a hidden dot-file, or a `chmod +x` on something that should not need it. 3. **Remove the malicious job first, then clean the files.** In that order. Clean the files while the job is still scheduled and it simply puts them back, often within minutes. 4. **Do not rely on a backup restore to fix this.** Restoring replaces your files and database. It does not touch the server’s crontab, so a scheduled reinfection survives the restore untouched and starts again. 5. **If you find anything under `/etc` owned by root, get your host involved.** Anything there was placed by something running as root, which means the compromise reaches beyond your hosting account and cannot be cleaned from inside it alone. 6. **Then find what installed it.** A malicious cron job is a symptom, not the whole story. Scan the site’s files for what dropped it, and check every other site you run on the same server or hosting account. ## What the check can see on your hosting account On every snapshot, twice a day, mySites.guru reads what your hosting account lets us see, in the same order and against the same tells described above, and flags any job that matches. We show you the exact line, why it was flagged and, where we can tell, whether it came from the system or from your own account, so you know whether it is yours to remove or your host’s. ## [Check For Malicious Cron Jobs](https://mysites.guru/free-audit/?check=joomla/hacked/cronjobs) mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site. [Check your site for free](https://mysites.guru/free-audit/?check=joomla/hacked/cronjobs) ## Further Reading - [Reinfected? Check Every Crontab, Not Just Yours](https://mysites.guru/blog/reinfected-check-every-crontab-not-just-yours/) ## Frequently Asked Questions Show all Why does my site keep getting reinfected after I clean it? The most common reason is a scheduled job on the server, not a file you missed. Cron runs on a timetable and does not care what the command is, so if an attacker has scheduled one to re-download or restore malware, cleaning the files without removing the job just resets the clock. Some jobs run every five minutes. Can my hosting control panel show me every cron job on the server? No. cPanel's Cron Jobs page and Plesk's Scheduled Tasks list only the crontab belonging to your account. The system crontab, the /etc/cron.d/ drop-in directory, and the run-parts script directories can all run something on a timetable, and none of them appear on your account's page. Is a malicious cron job something a file scanner will find? No. A file scanner reads files on disk. Cron entries live in the server's scheduler configuration, not in your site's files, so a clean file scan tells you nothing about what is scheduled to run. That is the gap this check exists to cover. [![EU icon: AI MODIFIED](https://mysites.guru/_astro/ai-modified.CaoawZEQ_1In0VX.webp)Written and edited by a human, with AI assistance. Our approach to AI](https://mysites.guru/ai-statement/) ### Article Contents - [How the cron job check reads your crontab](#how-the-cron-job-check-reads-your-crontab) - [What turns a clean-up into a losing game](#what-turns-a-clean-up-into-a-losing-game) - [Every job accounted for, nothing hidden](#every-job-accounted-for-nothing-hidden) - [Auditing and removing a rogue cron job](#auditing-and-removing-a-rogue-cron-job) - [What the check can see on your hosting account](#what-the-check-can-see-on-your-hosting-account) - [Further Reading](#further-reading) - [Frequently Asked Questions](#faq) - **Published** - 28 August 2026 - **Applies to** - Joomla - **One-click fix** - Manual fix Share [](https://x.com/intent/post?url=https%3A%2F%2Fmysites.guru%2Ftools%2Fhacked-site-detection%2Fmalicious-cron-jobs%2F&text=Check%20For%20Malicious%20Cron%20Jobs)[](https://bsky.app/intent/compose?text=Check%20For%20Malicious%20Cron%20Jobs%20https%3A%2F%2Fmysites.guru%2Ftools%2Fhacked-site-detection%2Fmalicious-cron-jobs%2F)[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysites.guru%2Ftools%2Fhacked-site-detection%2Fmalicious-cron-jobs%2F) Topics [Hacked site detection](https://mysites.guru/tools/hacked-site-detection/)Joomla ★★★★★ > "This [site / program](https://mysites.guru/features/) is just super." ![Mikael A - Webbkompass AB](https://mysites.guru/images/reviews/mikael-a-webbkompass-ab.webp) Mikael A - Webbkompass ABwebbkompass.se [](https://mysites.guru/reviews/) ## More checks in [Hacked site detection](https://mysites.guru/tools/hacked-site-detection/) - [ ### Helix Ultimate Mega Menu Hack A Helix Ultimate Joomla extension mega-menu setting can carry a stored XSS payload that never touches a file, so scanners miss it. How to check and clean it. ](https://mysites.guru/tools/hacked-site-detection/helix-ultimate-mega-menu-hack/) - [ ### Helix3 Custom Code Hack The Helix3 Joomla extension Custom Code template fields can carry a database-only defacement payload that file scanners never see. How to check and clean it. ](https://mysites.guru/tools/hacked-site-detection/helix3-custom-code-hack/) - [ ### Impostor Plugin Identities One malware family invents a plugin, an author and a vendor domain per site it breaks into, and the three agree in a way a real vendor identity rarely does. ](https://mysites.guru/tools/hacked-site-detection/impostor-plugin-identities/) - [ ### Check for JCE Rogue Profiles & Backdoors A rogue JCE editor profile lets an attacker re-upload a webshell after every clean-up. How to spot the fake profile and the files it plants on a Joomla site. ](https://mysites.guru/tools/hacked-site-detection/jce-rogue-profiles/) - [ ### Check For Malicious Scheduled Tasks Joomla has run a scheduler of its own since 4.1, in a database table that no crontab lists and no file scanner reads. How a planted task is found and removed. ](https://mysites.guru/tools/hacked-site-detection/malicious-joomla-scheduled-tasks/) - [ ### Check For Malicious WP-Cron Events WordPress runs its own scheduler out of one database row, where no server crontab and no file scanner can see it. How a planted event is found and removed. ](https://mysites.guru/tools/hacked-site-detection/malicious-wp-cron-events/) ## See where your own sites stand One free audit of one site · no card · about 2 minutes to connect [Get Your Free Site Audit](https://manage.mysites.guru/en/register) [How the cron job check reads your crontab](#how-the-cron-job-check-reads-your-crontab) [What turns a clean-up into a losing game](#what-turns-a-clean-up-into-a-losing-game) [Every job accounted for, nothing hidden](#every-job-accounted-for-nothing-hidden) [Auditing and removing a rogue cron job](#auditing-and-removing-a-rogue-cron-job) [What the check can see on your hosting account](#what-the-check-can-see-on-your-hosting-account) [Further Reading](#further-reading) [Frequently Asked Questions](#faq)