Home > Website Security, WordPress Tips and Tricks > My WordPress site was hacked: When Looking for Zebras like SoakSoak, Don’t Forget About the Horse

My WordPress site was hacked: When Looking for Zebras like SoakSoak, Don’t Forget About the Horse

December 22, 2014

Last week a large malware campaign targeted and compromised over 100,000 WordPress sites.  As most probably know by now the attack was named SoakSoak due to the first domain used in the malware redirection path (soaksoak . ru). Google has already blacklisted, by some estimates, over 11,000 domains that have been infected by the SoakSoak malware campaign. Below is an example screenshot of what a visitor might see in their browser if they come to a business website that has been infected by SoakSoak and has been flagged by Google.

This is obviously a significant problem for a business 10 days before for the Christmas Holiday. Even if you are able to quickly get your website cleaned up and the malicious code removed, it could still take months for Google to remove the warning about your website. We will follow this post up with information about the reconsideration process and reinclusion requests for Google. This can be a confusing and arduous process for any non-computer scientist business owner.

Thus it is no surprise that this particular hack has gotten a significant amount of press and the Sucuri blog, that we follow religiously, broke a lot of the initial information about this attack last week. What they and others ended up finding was that the SoakSoak attack on the WordPress platform used an attack vector primarily due to a miscoded WordPress plugin called RevSlider. The RevSlider vulnerability, which Sucuri discovered and documented a month ago, allows the hackers to download the wp-config file and steal the database credentials. This in turn allows them to access the site and upload a backdoor that can infect all websites that share the same server account. This means that even websites that don’t use the RevSlider plugin have the potential of being infected as well.

Unfortunately for the 100,000 or so webmasters affected by SoakSoak, many were unaware of this serious security vulnerability in the RevSlider plugin. Others either did not take it seriously or were unable to update it. The latter is most likely because of the fact that it is a premium plugin that can only be updated manually with a legitimate license to the RevSlider software. For a lot of websites this particular plugin was packaged and bundled into premium WordPress themes and this made it even more difficult for many website owners to even know of its existence.

When we first heard about this exploit last month we immediately scanned all our clients websites for the presence of the RevSlider plugin and thankfully did not find anyone using it.

Which brings me to the point of this article, over the same period that the SoakSoak attack was revealed we discovered that a handful of our client’s websites had been penetrated by hackers.  We quickly took down all access points into the sites and began the process of cleanup and analysis.

Because this occurred over the same time frame as the SoakSoak attack it was easy to think that they were related. We read and consulted with colleagues and ran our scanners and analyzed the log files. What was baffling to us was that we already knew the RevSlider plugin had not been present in any of these sites. And the sites that were attacked had no obvious thread that linked them together such as similar plugins or WordPress themes and all were using hardened security methods and very strong passwords. In fact the access points were very limited due to white listed IP addresses. The two telltale files that were modified by the SoakSoak attack, wp-includes/template-loader.php and wp-includes/js/swfobject.js, were unaffected on our clients sites.

We soon became even more baffled as we eventually found one of the attack points. The sequence was as follows:

According to the server logs someone logged directly into the WordPress dashboard from an IP address traced to our hosting provider. They then uploaded a malicious plugin called hellod.php, ran it and then deleted the plugin minutes later. If you didn’t know what to look for, you would have never known this plugin had been installed on your site because it was uploaded, run and deleted in a span of five minutes. However, we found traces of it both in the log files and the record of it being activated temporarily in the database with this entry:


When the plugin was run it installed a variety of files in a large number of places. In one case a variant of the Filesman backdoor program was found and all affected websites included a number of highly obfuscated files that were not initially found using any existing scanners. We created a new regex fingerprint for our scanners that was then able to find all the locations of these files and there were many. They had fairly innocuous file names that could pass for core WordPress files. These obfuscated files were injected into directories and subdirectories of the wp-admin, wp-includes, and in the themes, plugins and uploads folders of the wp-content directory. We will follow up with some more technical details in a latter post. Below is a partial list of some of the file names we found:

  • load.php
  • ms-media.php
  • options.php
  • meta.php
  • class-wp-media.php
  • ms-menu.php
  • admin-meta.php
  • category.php
  • locale.php
  • api.php

This series of events was quickly found in all the other cases and all occurred within a time frame of about 4 days. Below is a screenshot of some of the code from one of the obfuscated files. We have not yet had the time to fully decode these files to see what they might do.

A couple of the injected files (dolly.php and media.php) were simple passthru $cmd files. Full code is shown below. Presumably this would allow someone to take advantage of configuration errors to execute remote shell commands by passing them as parameters to another malicious PHP script. Although, we are not certain what this file might have been used for.

After these files were injected throughout the site, about a week latter they were scanned to see which ones were active and accessible.  Because all of the wp-admin and most of the wp-includes and wp-content folders are locked down by specific security measures only a couple of the injected files returned the 200 status code from non-authenticated requests.

We presume the next sequence in the attack would have occurred very soon after this, had we not discovered the breach and shut it down. At this time it is not clear what the next sequence in the attack would have been.

So how did the breach occur? Like we stated earlier there were no RevSlider plugins installed in any of these sites and there were no other similarities to the SoakSoak attack. We searched mentions of others discovering a malicious hellod.php plugin and found none. Finally, it dawned on us that these particular sites had not heeded our past advise to have SSL certificates installed so that access to the WordPress dashboard would be over a SSL encrypted connection. We had been so busy looking for the Zebra like SoakSoak and had forgotten about the giant horse that was standing in the room. Administrator credentials were being sent as clear text data over an unencrypted connection and had probably been intercepted at some prior point. This made the use of strong passwords, which were being passed as clear text, essentially a mute point (see image below; courtesy of WPWhiteSecurity.com). Where the intercept occurred isn’t yet clear but this process of stealing WordPress login credentials over a non-SSL connection has become a fairly trivial task for any decent hacker as this article illustrates. The only variable is being in the right place at the right time. Once the login and password information had been intercepted it was easy for the hackers to do a whole host of things from within the WordPress dashboard. Our clients were lucky that it hadn’t been script kiddies intent on just doing damage for the fun of it or worse that Google had discovered that their sites were compromised before we did. Lesson learned for us and our clients.


Website Security, WordPress Tips and Tricks

  1. David Stevens
    January 14, 2015 11:46 am | #1

    Good post. I am using SSL on one of my websites and have been considering it on others. I use two factor authentication on all of them.

    Is it possible that if your clients had used two factor authentication that they might have avoided this problem? One of my sites gets login attempts from 600 unique IPs a day from a bot network trying to use a dictionary attack on the password. This has been going on for a month.

  1. No trackbacks yet.