Hijacked WordPress.com Accounts Being Used To Infect Sites

Update on May 23 at 11:50AM: A representative from WordPress.com reached out to us with the following statement:

There has been some misinformation making the rounds, so to clarify, there has been no security breach for user accounts at WordPress.com. But if someone else has your WordPress.com account credentials, they could log in and modify your site.

WordFence notified us of a malicious plugin being installed on some accounts, so we are investigating and will be in touch with those account owners. We’ll also take steps to ensure that none of our users accidentally install that plugin.

In the meantime, we encourage all users to pick a strong password and use 2FA. https://en.support.wordpress.com/selecting-a-strong-password/

–End of update. Original post follows.

Our customer service team raised the alarm about a problem several users have had in the last few days. They all reported a malicious plugin named “pluginsamonsters” suddenly installed on their site. They learned about the problem thanks to an alert from Wordfence.

Our team has investigated these compromises and in this post we will describe how the attackers are gaining access and what you can do to prevent it from happening to you.

High Level Summary

In summary what is happening is the following:

1. An attacker will sign in to a WordPress.com account using compromised credentials.
2. If that account on WordPress.com is set up to manage any WordPress.org WordPress installations via the Jetpack plugin, the attacker will use that access to install a malicious “pluginsamonsters” plugin on the target site.
3. The plugin gives the attacker full control of the target website and the site is now compromised. The plugin is visible on the WordPress.com dashboard but is invisible on the target WordPress site’s plugin list when active. (It is visible when deactivated)

For this attack to occur, the following conditions need to be met:

1. The site owner must have Jetpack installed.
2. Jetpack must be configured to allow the site to be managed from a WordPress.com account.
3. The WordPress.com account must have compromised credentials. This usually happens when you have reused an email/password combination on another site or service that has been compromised.
4. The WordPress.com account must not have two factor authentication enabled.

Weak WordPress.com Credentials And Jetpack as Entry Vector

Jetpack is a popular WordPress plugin with a range of features, including the ability to integrate with WordPress.com. In order to use Jetpack, you have to create an account with WordPress.com. It allows you to manage multiple WordPress sites from one central console at WordPress.com. One of the features available is to manage plugins on your sites, or even install new plugins.

Just as in WordPress installed on your server, you’re able to either select a plugin from the WordPress public repository, or upload your own plugin in a zip file:

When Jetpack is connected to your site, it has the same privileges as the site administrator account. So if you choose to upload a plugin, whatever you upload will be passed along and installed on your site, no questions asked.

As we investigated the sites with “pluginsamonsters” installed, we found signs that this feature is being abused. For example, we checked site access logs at the time the plugin was created (per the timestamp on its directory), and found entries like this:

192.0.89.53 - - [22/May/2018:02:38:06 +0000]
"POST /wp-admin/admin-ajax.php?token=[redacted]&timestamp=1526956686&nonce=uFn5aA
OgH4&body-hash=gwB8z8pKX%2F6xzYdAbNzYTNeD8cc%3D&signature=gxiGNsGi2Z9Ba3SwaNUn7Dq
yBXc%3D HTTP/1.0" 200 141 "-" "Jetpack by WordPress.com"

The source IP address is part of Automattic’s network, the authors of Jetpack. We also worked to identify plugins that all the affected sites had in common, and Jetpack was the only one. Once our lead developer pointed out that Jetpack allows for remote installation of a plugin, the pieces fell into place.

We connected Jetpack on some of our test sites and tried to upload a malicious plugin. It worked, and our access logs showed the same activity.

Pluginsamonsters malware

Our next step was to analyze the malware and find out what it’s doing. This didn’t take long – it’s fairly simple, and as we mentioned, it’s a variation on malware we’ve seen before. Much like its relatives, it hides itself from the list of plugins in a site’s WordPress dashboard. To be clear, the plugin is still visible on the management console of WordPress.com, but is hidden on the admin interface of the victim website when it is activated. The plugin is visible on the victim website when it is deactivated.

The malicious plugin maintains a “.txt” file that can contain code to be executed on the WordPress loop_start action. It also includes a separate PHP script which is a simple file upload tool.

We were able to observe the hackers’ use of this tool. They’re using it for two purposes. First, they’re adding more backdoors to infected sites in order to maintain access. These backdoors are also simple file upload tools, and they’re being created with innocuous names like wpcfgdata.php, wpplugdata.php, etc. Second, they’re altering the root index.php file of the infected sites. This is the real reason for the campaign, the part that’s making profit for the hackers.

The malicious code added to index.php is obfuscated, but fairly simple. It reaches out to a malicious domain – in all our samples, it was roi777[dot]com. From that domain, it gets another malicious domain – we observed dozens of these, all in the “.tk” TLD. It uses Javascript to redirect visitors to a page on the second malicious domain, and sets a cookie so that the redirect only happens once every 12 hours.

The following is a screenshot showing the obfuscated code added to index.php.

In our tests so far, the malicious pages to which visitors were directed contained scareware, complete with text-to-speech, popups, and mouse hijacking:

But there may be other content served based on the device, source IP address, and so on. On infected sites, the “.tk” domains are refreshed once every minute.

In some cases, the attackers are also editing core Javascript files, infecting them with code to produce popups when visitors click anything in the site. They seem to be targeting jQuery files located in /wp-includes/js/jquery.

The first instance of this attack we observed was on May 16. Starting yesterday, May 21, the attackers started installing the same malicious plugin under a different name, “wpsmilepack.”

How Attackers Are Getting In

We observed these same attackers using “credential stuffing” attacks in February. They were taking stolen usernames and passwords from data breaches and trying to use them to log in to WordPress sites directly, even going so far as to check domain registration records for sites registered to a compromised email address. In response, we updated Wordfence to prevent logins using compromised passwords.

These attackers are resourceful, and it looks like the Jetpack angle is just the latest they’ve found to try. It further demonstrates how dangerous it can be to reuse passwords across services.

What You Can Do

To protect yourself from this attack, we recommend you take the following actions:

• Make sure you are using a strong and unique password on your WordPress.com account. This account has administrative level access to all sites that you manage via WordPress.com and Jetpack.
• Enable two-factor authentication on your WordPress.com account. You can use this guide to enable two-factor authentication (or 2fa) on your WordPress.com account.

Taking these steps will lock down your WordPress.com account and ensure that attackers can’t use it as an entry vector into the sites that you manage.

Centralized Management Services As A Target

WordPress.com gives you the ability to remotely manage multiple sites via the Jetpack plugin. This kind of functionality is provided by several other services. This can be a powerful enabler for agencies and developers who manage large numbers of WordPress websites. Let’s face it, updating hundreds of websites is not fun and anything that makes it easier is a valuable service.

It is important to realize that, while remote management tools are powerful enablers, they also have administrative level access to the sites that they manage. As a user, it is your responsibility to ensure that your user account uses a strong and unique password along with two factor authentication. If not, you risk mass compromise of all sites managed by a service like this.

These compromises we are reporting today are not the result of a vulnerability. They are the result of site owners reusing credentials. As the old saying goes: “There are no victims. Only volunteers.” In this case if you reuse credentials on a management level account and don’t have two factor authentication enabled, you are volunteering to have a bad week.

Wordfence Free Detects This Malware Variant

If you have been hit by this attack, our site cleaning team can resolve the compromised site quickly and effectively. You can find out more about Wordfence site cleanings on this page.

In all cases, customers with compromised sites discovered they were hacked because the Wordfence malware scan picked up on the malicious code the attacker had installed. Because this is a variant of older malware we have been tracking, both our free and Premium scans can detect the malware the attacker is installing. So to protect yourself against this, simply install the free version of Wordfence and it will alert you if a variant of this malicious plugin is detected.

We have been recommending Troy Hunt’s “HaveIBeenPwned” service for some time now. I had the pleasure of meeting with Troy a few weeks ago in Redmond. Once again we are recommending you use HaveIBeenPwned to check if your email address has been involved in previous data breaches. If it has, ensure that you change your password on all services you use. Use a strong and unique password on each service and use a password manager like 1Password to manage your strong unique passwords.

Wordfence has integrated the HaveIBeenPwned database to ensure that you don’t use breached passwords for your WordPress accounts. We don’t have control over the user account that you use for WordPress.com so you will need to manually ensure that you are not using a breached password for that account.

As always we very much appreciate your comments and questions. Please post below and I’ll be around to answer them.

Written by Brad Haas and Mark Maunder with research by Åsa Roseberg and James Yokobosky. Technical editing by Matt Barry. Final editing by Dan Moen. Special thanks to Åsa, James, Matt and Brad for the primary research that resulted in this publication.  

PS: No businessmen were harmed during the production of the stock photo used in this blog post.