In the past 30 days we’ve seen a new attack vector on WordPress websites – management consoles.

 

First, a disclaimer. The infections discussed here are NOT the result of faulty programming by any of the listed vendors. It’s strictly the result of hackers knowing the WordPress ecosystem and finding a way into various WordPress sites.

 

Where it all began…

 

We began seeing files being modified and bogus plugins being installed on WordPress websites. As we stream the access logs to our servers for real-time analysis, we began correlating entries in the logs with file modifications. 

 

The logs revealed the plugins were being installed from various management consoles. Some of the consoles we saw were, ManageWP, WPUmbrella and MainWP, but there were others.. 

 

Again!

 

These attacks were not the result of faulty programming by these companies.

 

Hackers knowing the WordPress ecosystem find various ways of infection

 

Some of the management consoles require you to login to their site and then you can manage your sites from there. Other management consoles, such as MainWP, also offer self-hosted services. You rent your server from Vultr, Ovh, Digital Ocean, Google, etc., then install their software on your self-hosted server. This server is not for hosting websites, but solely for managing your WordPress websites.

 

It was here we were able to get to the bottom of these attacks. We have installed our services on some of our customer’s self-hosted MainWP servers – just in case one comes under attack. Then we started looking at the user agents and IP addresses used in the other attacks installing bogus plugins during this time.

 

User agents and IP addresses all looked legitimate, but yet, we still could see the bogus plugins being installed. 

 

At first we thought, “Were these management console companies breached?” That couldn’t possibly be the reason, as it was across many different services.

 

A common phrase here is, “The truth is in the logs!” Further analysis revealed that apparently hackers were logging into the management consoles as legitimate users and using the management function to install plugins.

 

For instance, the string in the logs for sites using ManageWP is very specific to ManageWP. It’s not something that is very common and easily distinguishable. Not that it can’t be forged, but there are a number of details that led us to believe it was legitimate traffic. And ManageWP publicly lists their IP addresses to be added to allowed lists. https://managewp.com/troubleshooting/general/managewp-ips-can-white-list

 

During this 30 day window, we saw 1,711 sites compromised utilizing this point of entry. In many cases, where it was a self-hosted server that was being abused, the admin logins to the self-hosted servers were coming from other servers: Vultr and Digital Ocean and a few others, like a hosting provider in Latvia. These were all indications that those servers were compromised and used as a “cushion” for the hackers. We frequently see this activity in the logs – logins from web servers. Keep in mind that we knew the IP address of the self-hosted server legitimately logging into the websites. We were seeing logins from other servers into the self-hosted servers.

 

So the IP address would be legitimate as would the user agent.

 

Note: Many security people don’t believe in using a user agent to help identify malicious vs. legitimate traffic, because a user agent can be easily spoofed, but in certain cases, it can verify the legitimacy of certain events.

 

Furthermore, we found the majority (78%) of the users having login credentials to these management consoles were Mac users. We had them run a variety of malware scans on their local devices – only to come up with nothing! Not a single anti-virus program was able to find anything malicious on the local devices.

 

So how do login credentials get compromised?

 

We did find that in the cases we were able to pursue, these Mac users were recently using open WiFi – like at a coffee shop or some other public place. In addition, from the people we were able to communicate with directly, or through the agency, they typically just close out of the browser tab or window. They rarely logout.

 

One person speculated this might have been leftovers from the LastPass breach. It’s entirely possible.

 

A few lessons here. 

 

#1. Be careful when using open WiFi. If you can, tether off your phone instead of using open WiFi. Many cell carriers have unlimited data plans. If you’re on one – use it. DO NOT trust open WiFi.

 

#2. All devices need virus protection. Get something. Even though our research came up empty on virus scans, there could be something there that just hasn’t been seen yet. I don’t care if you’re using a Mac or a PC. Install some antivirus software and run full system scans every day.

 

#3. Be very careful when ending a logged in session. ALWAYS logout! That kills the authentication cookie. Remember, authentication cookies bypass 2FA because it’s already authenticated. But, having said that, always use 2FA. It adds a layer of security to your stack. If you logout of your sessions, then 2FA could be your savior.

 

#4. If you’re using a self-hosted service, contact me and I’ll set up a free monitoring service for your self-hosted server. That way, we can all be safe. Contact me at traef@wewatchyourwebsite.com.