cPanel Malware Persistence: Cron Jobs, Backdoors and Recurring Infections
A routine production cPanel security check uncovered persistence mechanisms and historical compromise across multiple isolated hosting accounts. Some malicious files had already been removed automatically, but cron entries and backdoor artifacts remained.
This case demonstrates why a successful malware cleanup does not necessarily mean that an incident is closed.
Incident context
The investigation began while verifying the automatic cPanel security update mechanism ahead of an announced critical security release. The update process was working correctly, but the cron logs exposed an unrelated hosting compromise.
A cPanel update check turned into an incident investigation
*/5 * * * * test -f /home/USER/public_html/.sys-mta-XXXX.php || cp /tmp/.cache/.sys_XXXX.php /home/USER/public_html/.sys-mta-XXXX.php 2>/dev/null # SYSCHKOn September 8, 2026, we were not originally investigating a malware incident. We were checking several production servers because of an announced critical cPanel & WHM security update and wanted to verify that the automatic security update mechanism was operating correctly.
On one CloudLinux-based cPanel server, the review of the hourly security update cron exposed user-level cron entries that clearly did not belong in a normal hosting account.
One of the entries repeatedly checked whether a hidden PHP file still existed inside the web root. If it had disappeared, the cron attempted to copy it back from another hidden location.
This was not simply a malicious file. It was a persistence mechanism designed to restore a component after cleanup.
Imunify had cleaned the malware, but the cron remained
We then inspected the files referenced by the cron job. Some of the hidden .sys-mta-*.php and .sys_*.php files had already been reduced to zero bytes, while others contained markers left behind by an earlier Imunify malware cleanup.
This indicated that the dangerous payload had already been removed or neutralized by the security system.
The persistence cron, however, was still present.
That distinction is important. Cleaning a malicious PHP file does not necessarily eliminate the compromise. If a cron job, secondary webshell or another persistence mechanism survives, malicious content may later return.
Multiple isolated cPanel accounts showed compromise indicators
grep -RniE \
'SYSCHK|defunct-kernel|/tmp/\.cache|\.sys-mta|\.sys_[A-Za-z0-9]+\.php' \
/var/spool/cron
find /home -xdev -type f \
\( -name '.sys-mta-*.php' -o -name '.sys_*.php' \) \
-lsAfter the first discovery, we stopped treating the event as an isolated website problem and searched the server for the same persistence indicators.
The search found compromise-related artifacts in several cPanel accounts that were separated at Unix user level.
This changes the scope of an investigation. When multiple isolated accounts are affected, administrators also need to consider shared causes such as reused credentials, compromised cPanel or FTP passwords, stored credentials on a developer workstation, or the same obsolete application components deployed on multiple websites.
At the same time, the available evidence did not demonstrate a root-level compromise of the server itself.
A second persistence pattern: defunct-kernel
# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
~/.config/htop/defunct
~/.config/htop/defunct.datA second persistence pattern appeared during the investigation. Several user crontabs contained a marker referring to defunct-kernel.
The corresponding user directories contained files named ~/.config/htop/defunct and ~/.config/htop/defunct.dat.
By the time we inspected the filesystem manually, the executable defunct file was already zero bytes.
The Imunify event history provided the missing forensic context: before cleanup, the file had been a multi-megabyte executable ELF backdoor.
In one affected account, Imunify had also removed a multi-megabyte ssh.php webshell during the same period.
That history made it clear that these were not harmless leftovers from an application.
Recurring infection was the strongest warning sign
/public_html/product/...One of the hosting accounts showed an even more serious pattern.
Imunify repeatedly detected phishing content in directories resembling product pages under /public_html/product/.
The malicious files were removed, but new ones appeared later. Then additional files appeared again.
This is one of the clearest warning signs in incident response. If a security scanner removes a malicious object and new malicious content is created hours or days later, repeatedly deleting the files is not enough.
The intrusion path or another persistence mechanism may still be available.
A cleanup_removed status confirms that a particular detected object was removed. It does not by itself prove that the root cause of the compromise has been eliminated.
Two obsolete Joomla installations were also involved
Joomla 3.10.12
filefuns.php
cache.php
wp-admin/
wp-content/Another affected hosting account contained two separate Joomla installations.
Both were running Joomla 3.10.12.
The website directories contained a large number of files that had previously been malicious or had already been cleaned. Repeated filenames included filefuns.php and cache.php, together with randomly named PHP files appearing in unexpected locations.
One Joomla installation even contained directories resembling a WordPress structure, including wp-admin and wp-content.
There was no actual WordPress installation and no wp-config.php file. The directories therefore did not represent a normal WordPress deployment.
When the malware no longer runs but the website no longer works either
administrator__52a63fd
components__52a63fd
configuration.php__52a63fd
PHP Fatal error: 'goto' to undefined label
HTTP 500A different domain in the same hosting account illustrated another consequence of automated cleanup.
Large parts of an old Joomla installation had been left with renamed files and directories carrying an additional suffix.
The active index.php was only a few hundred bytes long and contained part of an earlier obfuscated control-flow structure.
A goto instruction remained, but the destination label had disappeared when the malicious payload was removed.
PHP therefore generated a fatal error on every request and the website returned HTTP 500.
The malicious code could no longer operate, but the original application was no longer functional either.
This is why severe compromises may require application recovery in addition to malware removal.
We preserved evidence before removing the persistence
sha256sum \
/home/USER/.config/htop/defunct \
/home/USER/.config/htop/defunct.datWe did not immediately delete every suspicious object we found.
First, we preserved the relevant user crontabs, hidden files, timestamps, SHA-256 hashes and the associated Imunify event history.
Evidence preservation matters because blindly deleting suspicious files can destroy information needed to determine the type, timing or operating method of an intrusion.
Only after preserving that evidence did we remove the persistence artifacts.
Removing the identified persistence mechanisms
.sys-mta-*.php
.sys_*.php
.config/htop/defunct
.config/htop/defunct.datThe SYSCHK cron entries were removed together with the associated .sys-mta-* and .sys_* remnants.
For the defunct-kernel pattern, we removed the remaining cron marker and the defunct and defunct.dat files from the hidden htop configuration directory.
We then repeated the same server-wide searches.
The two persistence patterns no longer produced any matches.
High-risk hosting accounts were suspended
/scripts/suspendacct USER "Security incident - malware/backdoor detected"Two hosting accounts were considered unsafe to leave online based on their event history.
One had previously contained both a webshell and an ELF backdoor.
The other repeatedly generated new phishing content after earlier malicious files had already been removed.
Those cPanel accounts were suspended for security reasons.
Suspension also disabled outgoing mail for the affected accounts, reducing the risk that a compromised hosting environment could be used for spam or phishing delivery.
What we did not find
/etc/cron.d
/etc/cron.daily
/etc/cron.hourly
/etc/crontabAn incident report should document negative findings as carefully as positive ones.
The identified persistence signatures were not found in the system-level cron locations we checked.
At the time of the investigation we also found no active user processes associated with the identified persistence mechanisms.
The same targeted searches for SYSCHK, .sys-mta and defunct-kernel patterns were performed on two other cPanel servers and produced no matches.
Based on the evidence available at that stage, there was no indication that the entire server or the wider infrastructure had been compromised at root level.
A malware scanner does not replace incident response
Imunify360 performed a substantial amount of useful work in this incident.
It detected webshells, identified an ELF backdoor, removed phishing content and cleaned malicious PHP files.
Even so, the incident could not be considered closed based only on scanner results.
Cron persistence survived. Backdoor-related filesystem artifacts survived. Some websites were reinfected. Another website became unusable after malicious code was removed.
A malware scanner is therefore an important incident-response tool, but it is not incident response itself.
Filesystem state, user cron jobs, running processes, malware history, web server logs, CMS versions and access credentials need to be correlated to understand the full event.
A routine check became a multi-hour security incident
The investigation started with an entirely different task.
We were checking whether the hourly automatic security update mechanism was ready for an announced critical cPanel security release.
The cPanel update mechanism was operating correctly, while the expected security build had not yet reached the production RELEASE tier at that time.
The cron logs, however, exposed a completely different problem.
A few hours later, the investigation had uncovered compromise indicators across multiple isolated cPanel accounts, two different persistence mechanisms, historical webshells, an ELF backdoor and recurring phishing infections.
The incident is a useful reminder that during a security review, the most important finding is not always the one you originally started looking for.
Sometimes a single unusual cron entry reveals the larger incident.
Imunify cleanup documentation
CloudLinux documents why files may remain after Imunify360 or ImunifyAV has removed malicious code. The remaining file can contain artifacts from the earlier infection even though the dangerous payload has already been removed.