WordPress XML-RPC Attack

This week, one of my sites, sptr.net, has been under a co-ordinated and sustained attack from what appears to be a botnet – a collective of several hundred virus-infected computers running Microsoft Windows. The attack comprises attempts to use the remote procedure call methods built into WordPress to post unauthorised content.

Detection

I was notified by one of my independent monitoring services that the site was having trouble some time after the attack began. It appears that once triggered by the attacker, it takes a while for the command to spread to a significant number of infected machines – this is reasonable if you assume the greatest number of infected PCs is in the USA. The attack peaked around the middle of the day in Scotland, coincident with the switching on of computers as the sun moved East to West across the continental US. Although the server remained operational, it was struggling to continue to respond to requests in a reasonable time as the CPU usage soared way above 1000% of nominal maximum. A look at the top processes on the server showed that it was trying to keep things together:

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
12345 xxxxxxx    20   0 55992 36080  7128 R 49.0  6.9  0:15.73 [see below]
12346 xxxxxxx    20   0 56036 36124  7188 R 46.0  6.9  0:04.96 [see below]
12347 xxxxxxx    20   0 55940 36076  7128 R 46.0  6.9  0:03.82 [see below]
12349 xxxxxxx    20   0 55912 35908  6984 R 46.0  6.8  0:07.88 [see below]
12340 xxxxxxx    20   0 55976 36116  7180 R 46.0  6.9  0:03.59 [see below]
12342 xxxxxxx    20   0 55940 36064  7128 R 44.0  6.9  0:07.21 [see below]
12341 xxxxxxx    20   0 55948 36140  7196 R 44.0  6.9  0:34.79 [see below]
12343 xxxxxxx    20   0 55972 36248  7276 R 44.0  6.9  2:20.11 [see below]

The command attempted showed that it was an attack on a php script:

/usr/bin/php-cgi -c /var/www/vhosts/sptr.net/etc/php.ini

Further investigation

Looking at the server access logs identified the specific script targeted by the attacker, the machines and methodology involved. The range of IP addresses showed that the infected PCs were world-wide (in the sample below, India, Poland, Egypt, Thailand, Algeria, Brazil and Pakistan).

106.76.44.110 - - [10/Jul/2014:14:03:19 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
194.50.157.187 - - [10/Jul/2014:14:03:34 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
41.235.83.103 - - [10/Jul/2014:14:03:43 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
171.6.204.105 - - [10/Jul/2014:14:03:54 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
41.107.87.186 - - [10/Jul/2014:14:04:04 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
179.186.51.47 - - [10/Jul/2014:14:04:06 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
39.44.61.247 - - [10/Jul/2014:14:04:14 +0000] "POST /xmlrpc.php HTTP/1.1" 200 159 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"

Mitigation

Restarting the VPS container made no difference. CPU usage remained very high. Installing a plugin to disable XML-RPC in WordPress seemed to make things better, probably because of the response time improvement but as the day progressed, the attack seemed to abate and the server was coping better with CPU usage falling below 100% nominal maximum. The log sample above is from today, when the attacks have fallen to a few per minute instead of the hundreds per second on Tuesday. It looks like the botnet is learning that there are robust passwords on the system that will take too long to guess and is giving up.

Brute force solution

I’m not happy with this constant knocking at my door, however, so have decided that I don’t need a door there at all. Removing the target script doesn’t directly affect the rate of attack, it changes the 200 response to a 404 (page not found), which is quickly delivered.

94.55.132.13 - - [10/Jul/2014:14:09:13 +0000] "POST /xmlrpc.php HTTP/1.1" 404 430 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"

6 Replies to “WordPress XML-RPC Attack”

  1. Hello 🙂

    Great article as we have been experiencing attacks of this nature.

    When you say remove this script, did you remove this line of code?

    “94.55.132.13 – – [10/Jul/2014:14:09:13 +0000] “POST /xmlrpc.php HTTP/1.1” 404 430 “-” “Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)”

    If so, where does it live?

    Thank you,

    SINDEEZ

    1. Hi @disqus_Va5S7LHDej:disqus, thanks for the comment. The line you quote is from the server logs and it shows the WordPress script that is being accessed in the attack is /xmlrpc.php. I didn’t actually remove the script, I renamed it. In your WordPress installation folder, find the file xmlrpc.php and rename it – for example, to xmlrpcphp.bak. Any attacker (or user) trying to access xmlrpc.php will get a “not found” or 404 response. This is much quicker for the server. You will lose rpc funtionality on your site but, like me, you don’t use it anyway, so nothing is lost. You will have to do it again if you upgrade or re-install WordPress, as this will install a fresh xmlrpc.php.

      Hope this helps.

      1. Nick, thank you for the prompt response! I understand now what you did and it makes sense. Thank you.

        I have a question. It is my client who is experiencing these attacks.
        How do I know if they do not need to utilize this function?

        Your help is greatly appreciated. I’m happy to provide you with the URL and information about what plugins are used.

        1. Hello again, SINDEEZ. You only need xmlrpc if you are using remote access – if your client just wants a normal website accessed with a browser, you can safely disable it.

          When xmlrpc is removed, there are almost 80 functions that are removed with it, most of which are never used by “regular” WP sites. Pingbacks won’t work, nor will remote publishing, nor the WP mobile apps that allow you to write new posts. I personally think leaving xmlrpc working when you don’t need it is an unnecessary security risk – I have disabled it on sptr.net.

          There’s a great intro here, written by Ryan Dewhurst (@ethicalhack3r):
          http://www.ethicalhack3r.co.uk/introduction-to-the-wordpress-xml-rpc-api/

  2. I was contact by Andrijana from WHGeeks who said, “I would like to introduce you to our latest complete guide on how to start a web hosting company, where we tried to explain the advanced technology in ordinary language, and where we’ve also talked about benefits and downsides of VPS hosting.”

    Having taken a look at the WHGeeks guide, I’m impressed with how useful it is for people who are interested in setting up their own hosting business. You can see it here: https://webhostinggeeks.com/guides/hosting-business/

Comments are closed.