9

I'm on a shared hosting plan (I know, I know) on GoDaddy and all the files in it have been hacked. There are multiple sites in the plan, each of them has a folder. The folders and sub-folders of each site are full of hacked files, and so are the folders above public_html.

I've deleted tons of files with malicious code and I feel I have deleted everything except that there's a xm1rpc.php file that shows up again 10 seconds after I delete it. .htaccess, configuration.php and index.php, all in the root of one of the sites, seem to get infected very fast as well.

How do they manage to do that? I've searched for crons in the control panel, changed passwords (FTP, admin, etc), what should I check for next? So that you know, the sites are Joomla and WordPress.

GAD3R
  • 2,211
  • 3
  • 15
  • 38
Victoria Ruiz
  • 191
  • 1
  • 3
  • 5
    You're treating the symptoms, not the cause. They have a consistent backdoor somehow, whether it be through compromised admin credentials, plugins, or forms on your site. There's no way to know for sure how they're getting in without extensive code review or packet capture but I'd start filling the gaps by disabling any "snazzy" plugins that aren't 1000% necessary. – Ivan Nov 03 '16 at 19:40
  • 1
    Also, you may be deleting the files the malware creates, but have you checked ALL of the core files for code modifications? Just because you deleted all the new, obviously bogus files doesn't mean they didn't modify wp-config or some other core file during the initial infection. – Ivan Nov 03 '16 at 19:47
  • Thanks for the info, Johnny. I am going to try to disable plugins. I got rid of a few old things already, and I have checked for many backdoors in files like the wp-config and restored them to the original files. The fact that it only takes 10 seconds to get the infected file back leads me to think that they're either bombing the site or have a cron every 10 seconds, would that make sense? Or is there any other way for the hack to get back so quickly? – Victoria Ruiz Nov 03 '16 at 19:59
  • The steps you've taken are good ones. Is there any way for you to completely shut down the site - turn off public access, temporarily delete joomla and wordpress, that sort of thing? – Xiong Chiamiov Nov 03 '16 at 20:07
  • 4
    The traditional advice is to kill an infected machine and slowly start restoring backups on a new one as you verify your backups are clean. I don't know how easy that would be for you to do, but that's the safest option. – Xiong Chiamiov Nov 03 '16 at 20:08
  • 2
    @vic3685 Yep. You're still missing something. If you're getting reinfected that quickly then there is something persisting on your system, calling home for another payload. It's highly unlikely you're getting attacked every 10 seconds (are you running RevSlider by chance? There's a current exploit out for it). Plus, if you have two different CMSes running on the same instance, that's 2x the attack surface. It's not an optimal setup at all... – Ivan Nov 03 '16 at 20:09
  • 1
    i would backup the whole site, change the password, and delete all the contents. if the files still re-appear, you should get your money back from the host and find something more reliable. – dandavis Nov 03 '16 at 20:22
  • Thank you all for your input. It seems that it will take a while for me to figure out what the real cause was, and I will start separating the hosting accounts for all sites. Hopefully they won't get reinfected, and if they do, I hope it's just one of them! – Victoria Ruiz Nov 04 '16 at 19:48
  • Your local machine might be infected, so when You connect via FTP it upload that `xm1rpc.php` and other junks. – PeterM Nov 07 '16 at 16:21
  • 1
    Possible duplicate of [How do I deal with a compromised server?](http://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server) – Matthew Nov 07 '16 at 17:23
  • Possible duplicate of [Recent hack appends to all javascript files](http://security.stackexchange.com/questions/121137/recent-hack-appends-to-all-javascript-files) – Anders Nov 08 '16 at 12:01
  • Do you have WHM access or Cpanel access? – Lester T. Nov 15 '16 at 14:30

5 Answers5

3

You might have some backdoor in the database as inline HTML or Javascript.

If you are sure that you have removed everything from the files, look into the database.

Also, make sure you upgrade both CMSes to latest versions and disable / remove all unused modules in both so that they won't hack you again in the same way.

Also look in the WWW server access and error logs if someone is really bombing you.

user129555
  • 31
  • 1
3

First, check the access logs of your sites to prove to yourself that you're not getting reinfected through the same attack vector that got you infected. If you don't see requests coming in every ten seconds, that should be enough for now.

You said there are no suspicious cronjobs. How did you check this? Are you sure that cronjobs all show up on the control panel you mentioned, even if they weren't created through the control panel?

If there really aren't any cron jobs, the next likely cause of reinfection is a malicious process that is still running on the server and keeps sleeping for ten seconds, then checking for the existence of the files and recreating them if they're not there any more.

If thats whats happening, then its also likely that you still have a copy of the malicious files on the server somewhere (either that, or they're being downloaded from a remote source). Don't forget to check the /tmp directory for hidden subdirectories. /tmp is a likely place for malware to reside on because its usually world writeable.

Some malware uses a neat trick on unix systems to hide their files: the running process opens the files and then unlinks them, which makes them invisible to command such as ls and find, but because they're open, they're still there (until the process that keeps them open terminates). The good thing is that since they're open, they will show up under /proc.

You need to find this process and kill it. I don't know anything about GoDaddy, do you have shell access? If so, you can use the ps command to list active processes running under your user name.

However, this is all pointless unless you find the infection vector. Check your access logs for very long URLs containing random looking strings first. This is fairly easy if you know how to use grep and regular expressions. If you find something that looks suspicious, google the URL; this might provide you with a description of the security hole that made the initial breach possible and thats what you need to know in order to secure your system.

Out of Band
  • 9,150
  • 1
  • 21
  • 30
  • Thanks for your input, Pascal! How else can I check for cron jobs? – Victoria Ruiz Nov 04 '16 at 19:49
  • if you don't have shell access, it's really complicated and involves writing a php script that runs local system commands and pipes the result into the script output. With shell access, use "crontab -l" and check the /etc/cron.d directories (may be located somewhere else, too, depending on your server configuration). – Out of Band Nov 04 '16 at 21:07
3

How can a file be added over and over to my site?

Exploiting the "Privilege Escalation flaw" on the system/programs

A user with a low-privileged account can get the root privilege by exploiting the Privilege Escalation flaw , the malicious user( with a root access) will take the full control over the database by adding, deleting files ....

Example : the new vulnerability discovered on LAMP (Linux-Apache-MySQL-PHP) 01.11.2016 CVE-2016-6664 ( MySQL and MariaDB)

Description

MySQL-based databases including MySQL, MariaDB and PerconaDB are affected by a privilege escalation vulnerability which can let attackers who have gained access to mysql system user to further escalate their privileges to root user allowing them to fully compromise the system. The vulnerability stems from unsafe file handling of error logs and other files.

GAD3R
  • 2,211
  • 3
  • 15
  • 38
  • i guess if that was the case, they wont need adding further malicious files. Why would they need to? If they already compromised the system using any SQL DB vulnerability, no further actions would be required for any other purpose. – KanekiDev Nov 10 '16 at 14:59
3

It's pretty hard to answer by just the information you give.

Some mates said that your problem may be a SQL Database Vulnerability, but i don't think so (i still can be wrong). As if that was the case, no further file injection would be necessary to gain access to your system.

It is pretty right that there's a chance somebody is trying to exploit any of the current vulnerabilities in your page to gain access.

So, the most i can say is:

  • The most probably cause (i guess) is a RFI vulnerability (Remote File Inclussion), in PHP dynamic webpages is pretty common.
  • Joomla as many of CMS motors (as @user129555 said) are pretty vulnerable, and new bugs/vulnerabilities are found so fast.
  • The BEST you can do is:

    1. Check your web files and the permissions(some CMS require some files to be deleted, or changing the permissions after the first setting-up for security).
    2. Check for possible vulnerabilities by googling (or using pages or public databases as CVE).
    3. Use any kind of motor to find some vulnerabilities (there are tons for CMS).
    4. Update everything (Joomla) to the last versions, to fix most of vulnerabilities.

Good luck!

KanekiDev
  • 1,039
  • 6
  • 9
3

Your xm1rpc.php came from wordpress. Follow these steps, it will solve your issue. Go straight to the point and follow the below steps to fix it. This is a script kiddie kind of work, don't over complicate it by going all over the place

  1. Go to every wordpress you have access to. Download this plugin in every wordpress and use this to scan and remove the malware.
  2. Update wordpress to the latest version for every site.
  3. Change password to all wordpress site, cpanel and whm(if you have)

How it works? Your /wp-includes/load.php is infected. This will keep creating the malicious php file which will infect your .htaccess, .configuration.php and index.php

Lester T.
  • 1,263
  • 1
  • 9
  • 21