0

I am running a wordpress website and suddenly cpu usage spiked to 100%. When I tried to dig in, I found a binary in php/tmp folder which was running with configuration file-

{
    "algo": "cryptonight",
    "av": 0,
    "background": true,
    "donate-level": 1,
    "log-file": "/dev/null",
    "threads": "1",
    "pools": [
        {
            "url": "xmr.crypto-pool.fr:80/xmr",
            "user": "xyz",
        },
    ],
}

It seems to me that the server is involved in mining monero coin. As the location of folder is in tmp directory, I guess that the files were shipped there exploiting some insecure file upload kind of vulnerability, but I can't understand how the attacker made the system to execute the binary. As I can see the process in htop, I don't think attacker gained root access to system at any point of time, or he could have installed some root kit to hide the process at all.
The process is being run under daemon user and and PPid 1 and restarts itself after sometime if I try to kill it. I can't see any init file related to this binary.

I want to figure out exactly how the attacker managed to start it as daemon and how is it being controlled but I am stuck here. Any tips for further analysis will be very helpful.

EDIT: Php version is - 7.0.6 My wordpress is running using bitnami certified aws image. Php master process is running as root and children are running as daemon. As I checked php.ini file, there is nothing under disable_function configuration. This I guess is a bad practice as someone can exploit functions like exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source.
I am not sure about editing the configuration as I have never worked with wordpress or php and I am not sure if this will break the wordpress itself.
Even if I migrate my wordpress to a new instance, how can I make sure that it will not happen again ?

Krrish Raj
  • 109
  • 1
  • Did you disable exec() in your PHP? If not, he could do it using standard PHP shell. – Peter Harmann Apr 30 '18 at 14:09
  • What kind of server? Could you connect as *root* in a *shell* console? – F. Hauri - Give Up GitHub Apr 30 '18 at 14:45
  • Please add your PHP version and if possible the php.ini or the result of `phpinfo()` (of course without sensitive parts you want to hide like domain and user name etc.). Wild guessing atm but this incident can be the result of insecure configuration (disable_functions, allow_url_fopen, file_uploads and open_basedir may matter i.e.). –  Apr 30 '18 at 15:47
  • @PeterHarmann Can't you just use `eval()` even if `exec()` is disabled? – forest May 02 '18 at 09:44
  • @forest What what? Eval only evaluates PHP code. So it can do a lot of stuff but it can't for example execute binaries. exec() on the other hand uses shell code, so it can do stuff like execute binaries, disable firewall (if php process has privileges for that) etc. Anything you could do from the command line as the user running the PHP server. – Peter Harmann May 02 '18 at 09:54
  • That's true, but you can still get arbitrary code execution, even if you can't call external binaries. I had to re-read the question before I realized exactly what was being discussed. – forest May 02 '18 at 09:56
  • 4
    Sorry to hear that your server was compromised. Unfortunately, I dont think we will be able to figure this out. You need someone with access to a full image of the server that can do a forensic analysis. Also, you might want to have a look at [this](https://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server). – Anders May 02 '18 at 09:59

1 Answers1

1

This is really just a partial answer, so hopefully someone will come by with more details, but I wanted to give you something to get started.

https://www.wordfence.com/blog/2016/03/attackers-gain-access-wordpress-sites/

Wordpress hacks are a pain. We typically avoided wordpress altogether, but if we had a client that really wanted to run a wordpress site, we would put them on their own server for just this reason. How did they get in? That can be very hard to determine. Log files and lots of digging will be your friend. The core wordpress software itself is usually fairly secure these days, so long as your wordpress installation is up-to-date. However, you should audit your third-party modules with an extremely fine-toothed comb. When some of our wordpress-hosted sites were compromised in the past, it was almost always because of security weaknesses in third party modules that someone installed. Check for any security warnings related to any third party modules you have installed, especially the more popular ones.

It sounds like you caught it right after it happened. That is good because it will mean that you have far less logs to look through. Dig through them in detail until you find anything suspicious. It's hard to be much more specific then that. Once you figure out how they got in, Nuke it from orbit!, restore from a known-good configuration, and patch the issue that let them in in the first place.

Conor Mancone
  • 30,380
  • 13
  • 92
  • 98