Return to the City of Cron – Malware Infections on Joomla and WordPress

Return to the City of Cron - Malware Infections on Joomla and WordPress

We recently had a client that had a persistent malware infection on their shared hosting environment that would re-infect the files quickly after we had cleaned them. The persistence was being created by a cron that was scheduled to download malware from a third party domain.

Persistent Malware Infection on WordPress and Joomla Websites

This persistent website malware infection made us remember a blog post we posted back in 2014. As it turns out, the malware operated almost identically — and in this more recent case, it was infecting a WordPress website. This malware has been configured to detect WordPress and Joomla based on their directory structures:

Malware used to detect Joomla and WordPress Websites
Malware Used to Detect Joomla and WordPress Websites

Once the malware has determined if the website is using Joomla or WordPress, it determines the method it will use to further infect the website files.

In this case, our client’s website was using WordPress. The malware proceeded to preserve the existing timestamps of the default WordPress plugin “Hello, Dolly”, then attempts to hide base64 encoded malware to the plugin file ./wp-content/plugins/hello.php:

Base64 Encoded Malware
Base64 Encoded Malware in the “Hello, Dolly” WordPress Plugin

Of course the backup backdoor cron job has been set up so that, in the event that the website owner were to clean their websites files or even restore from a backup, they would still be reinfected:

Cron Job in a Backdoor
Cron Job in a Backdoor

Over the past 5-8 years it looks like the malware operators have changed from distributing the malware from the old domain hestonsflorist[.]com to the current one at hestonsflorists[.]com. Other than this particular detail, their cron commands are almost identical to the same malicious cron we found back in 2014.

The attackers even assign the same fake timestamp (201104202045) using touch to try and trick webmasters — which nowadays would probably be even more suspicious, since the fake timestamp reflects a date over 8 years old.

Conclusion

In this particular infection, malicious files are served from the /tmp directory, which is rarely scanned or monitored and makes it difficult to detect.

Due to the fact that many website owners simply not being aware of the cron jobs that are set to run on their hosting account, this style of backdoor can be very persistent and prove frustrating as the websites will never be safe until the malicious cron is removed.

If you are looking for a malware removal solution, we would be happy to help you clean and protect your website.

 

You May Also Like