How do I repair a hacked WordPress Bricks Builder site?

Rick Tibbe
The recent security issue has raised quite some questions across the community, so here’s a quick summary of what happened, how you can check your sites, and what you should do if your site has been affected.

I recommend everyone to run a manual scan on High Sensitivity mode with the free version of Wordfence, on each one of your Bricks sites, even if they do not show any sign of a breach!

NOTE: I’m not affiliated with Bricks in any way, and this post is based on my own findings and information shared by other users / parties. Feel free to share any extra information in the comments, as I’ll keep updating this post with additional information. I cannot be held responsible or liable if anything happened to your site. Always make a back-up of your site before following any of my steps.

What happened

On February 13th, the Bricks team sent an email that a mandatory security update had been released. Every version before 1.9.6.1 (so not only 1.9.6!) contains a Remote Code Execution (RCE) vulnerability that attackers can exploit to run malicious commands on your server.

In most cases, attackers use this vulnerability to create spam or phishing pages on the breached site, but it can also be exploited to get access to your database, or ultimately, take full control over your server when there are no proper security measures (such as isolated user accounts) in place.

How to check my sites

An RCE vulnerability can be exploited in many different ways. I cannot provide a single solution for every possible situation, but based on recent posts from other users, there are several signs that may indicate your site has been breached:

1. Random PHP files on your website
   In most cases, an attacker will upload a backdoor to the website. This will provide them with access to your site, even after you’ve updated to the latest version, so only updating to the latest version is not enough! Some examples I’ve seen:
   – wp-content/themes/593qp77o/options.php
   – wp-content/themes/twentytwentyfour/Ui.js.php
   – wp-includes/blocks/comments-pagination-numbers/pqniksbk.php
   – wp-includes/blocks/rss/hvsjspjs.php
   The attacker can also modify existing files (e.g. /wp-includes/ files), so if you don’t see any new files, that does not automatically mean you haven’t been breached.
   
   If you’ve got SSH access to your server, you can run the following command in the root directory of your site:
   find . -type f -name "*.php" -newermt "2024-02-13"

   This will return a list of all files that have been created or modified after February 13th. Do note that this will also return legitimate files that have been modified (e.g. through updates), but it’s a good starting point to identify any files with strange names without having to go through every folder manually.
2. New (admin) users
   If you spot any new users (most likely with the Administrator role) that you did not create, that is a sign that your site might have been breached. Delete the users, and check below on how to clean up your site. Some example usernames are:
   – deleted-FVQtG0rd
   – wp_update-1707937628
   – updates
3. Unknown pages or posts
   If any new pages or posts have been added to your sites that you did not create, and they look like spam or phishing sites (or completely unrelated to your site), your site has possibly been breached.
4. Random server errors
   If you encounter any random server errors that weren’t there before, your site has possibly been breached.

In your Bricks account, you can go to the ‘Sites’ tab to see the sites that are using your Bricks license: https://my.bricksbuilder.io/#sites

How to clean my sites

Again, I cannot provide a guaranteed way to clean your site. However, the following steps can (and most likely should) be followed to clean your sites:

1. Restore a back-up from February 13th or earlier to a local environment. The older the back-up, the more likely it is that it hasn’t been breached yet. You should do this locally because that will allow you to update Bricks to the latest version, without allowing the attackers to exploit the vulnerability again between the moments of restoring the back-up and updating Bricks. This seems like overkill, but attackers might be monitoring your website after it has been affected.
   After you’ve updated Bricks on the local site to 1.9.6.1, you can migrate the local site to the live environment. The best way to do this is by using a clean installation of WP on the live site, as some migration tools will not overwrite infected WP core files.
2. Run a manual scan on High Sensitivity mode with Wordfence. The free version of the plugin achieves impressive results against malicious files. When installing the plugin, you need to click ‘Get a license’, and select the free license on their website. When you’ve activated the license on your site, you should go to ‘Wordfence’ > ‘Scan’ and click the ‘Start scan’ button (if it’s not already running).
   After the scan has finished, you’ll get an overview of all possible threats on your website. Check them manually (as there’s a slight chance they might contain false positives), and delete / repair as many files as possible.
3. (Optional) Whenever I come across a breached site, I also take an extra precaution by deleting the /wp-admin/ and /wp-includes/ folder using an FTP client (NEVER the /wp-content/ folder or any files inside the root directory!). After they’ve been deleted, I download the latest WP core files from the official WordPress site, and upload the /wp-admin/ and /wp-includes/ to the server. Again, make sure never to overwrite any of the files that are placed directly inside the root folder, as these contain import information for your site to function properly.
4. Change the database credentials. The attacker might have gained access to your database credentials, so it’s very much recommended to change the database password.
5. Check your cronjobs (thanks to Daniel Blomster). If your server user has access to the file where cronjobs are stored, you might also want to check your cronjobs for malicious entries: https://blog.sucuri.net/2019/05/cronjob-backdoors.html

Again, please note that every situation can be different, and there’s no ‘one solution fits all’ when it comes to infected sites. Please use caution, make a back-up before following any of my steps, and consult a security expert when needed!