Joomla Site Hacked, keeps adding a Cron job


#1

Our site was hacked and so interesting things happened. As I was cleaning out the files (a whole lot injected PHP and edited HTML) I found that there were 4 files that kept returning after being deleted.
They are wprx, cloki, xm, and config.json. Two look to be compiled code and the others had IP addresses.

I did some research and found some items in /home//Maildir/new with recent dates

When I opened one, I found an email that contained the below (I masked the user for security purposes)

From: root@ontario.dreamhost.com (Cron Daemon)
**To: ***@ontario.dreamhost.com
Subject: Cron *****@ontario pidof cloki || exec /dev/shm/cloki >/dev/null 2>&1 &

Notice that it looks for cloki, one of the files that won’t go away, and executes some code in /dev. It appears that a hack is being done by email to trigger Cron jobs.


#2

Sorry to read this! It’s unfortunate that this happened to you. I have checked with my colleagues and your ticket has been addressed. Once the dust settles, if you’ve learned more about how the vandals managed to violate your site, could you please share your findings here, too?


#3

Thanks. I don’t think I’ll find out exactly how they did it, but the Cron job was not showing in the DreamHost Panel for Cron Jobs. The response from support (thanks for the help in getting some to look at it), just said they deleted the job, but didn’t say from where.

I just recently took over managing the site again. Since then it has had a couple of different webmasters. Some novices. One might have FTP’d instead of SFTP. The first thing I did was change the password.

One thing I did notice is that the .htaccess file was missing. When I managed the site a few years back I had built a pretty list of IP’s to Deny. Some of the bad files were referencing IPs that would have been blocked.

Anyway, if I do find out more, I’ll share.


#4

Are you running Joomla on your server?

Unfortunately I am unable to make anymore posts on this topic to give more details on what I have found, because I’m a new user and no one “liked” any of my posts. I can only edit previous posts which hopefully people will go back and review to find the information.


#5

Hi Mike

Yes, we are running Joomla for the website.


#6

Seems to be some security flaw in Joomla they are using, I am dealing with the same thing past 2 days.


#7

I’ve provided everything I could to DreamHost, but no response what so ever. And since the cron jobs are being set by root, I’m starting to think that DreamHost has been infected and not telling anyone.

I’ve done some research and it might be Mumblehard.C backdoor.


#8

I don’t think so, as there is no info on the files dropped anywhere, plus they are not detected by any virus scanners. I think this is a new hack that’s being tested on our servers.

somehow files got put in /cache, and there are 5 IPs so
far constantly trying to hit those php files to re-infect. Guessing that
there is some exploit in joomla that allows a hacker to put files into
that directory.


#9

It is almost impossible that root is compromised. How do you know that the cron jobs are set by root?


#10

The cron job did not appear on Cron Jobs Panel.

From DreamHost on 2/8:
“There was a crontab setup here which I’ve just deleted:
root@ontario:/home/<owner># crontab -l -u <owner> */4 * * * * pidof cloki || exec removed script

And with response to my thinking it was a data miner.
From DreamHost on 2/10:
“I have deleted the miner and the shared memory process that was reinstalling it.”


#11

that doesn’t mean much. You removed the <owner> from crontab -l -u <owner> which is the relevant information. Is owner root? if not, cron job is owned by an unprivileged user.

Unfortunately these sorts of hacks are hard to clean up and you will need lots of patience, lots of expertise while getting all the help possible from DreamHost support.


#12

@KFilby I have recently also been affected by this malware. May I ask, do you use Akeeba Kickstart?


#13

Yes, Akeeba is the backup we use. Is that infected for you?

Just checked the site and it is back. Another ticket opened at Dreamhost.


#14

The is the user under which our site runs. The -u tells it to “edit some other user’s crontab” in this case our user.

And unfortunately, whatever shared memory process that they found that was doing this is back. :frowning:

Another ticket has been opened #8103429.


#15

That pretty much excludes root being the cause of the returning hack…

Maybe you’re restoring a backup version that is already infected. I’ve seen cases where the corrupting code was stored in the database, thus the hack came back after each restore. You’ll have to look at the content of the tables… it’s a hard and painful process.

I’ve cleaned up my WordPress site from such pest a long time ago. I downloaded the most recent database dumps I had and inspected them one by one for suspect base64-encoded strings. I found the culprit by comparing older (clean) versions of the database with the latest (infected) ones. I then removed the offending rows in the database, restored it and hardened WordPress after that.

I’m not familiar with Akeeba, not sure how it stores the backups. Can inspect the database files from the Akeeba backup file?


#16

Akeeba seems to be the source of infection. I recommend updating or removing it.

In Joomla, you’ll want to look in your index and theme files for the code that executes the infected files. If you remove that you should get visible errors telling you where the infections are.

In Wordpress, you’ll want to look in your index, wp-settings and wp-config files.

Also remove the cron task and file it’s executing as discussed in the original post.

Also other infected sites will try to run infected dormant files. So try to remove them all. I found using cPanel’s File Manager and looking at the “Last Modified” date will lead you to the infected files.

Good luck


#17

Looks like this is becoming a well know problem here is an article I found.
https://www.idlwebgroup.com/cloki-malware-slowing-wordpress-joomla-websites-removal-fix.html


#18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.