Security – A cleanup of a hacked site – a case study

Last Updated: 18.03.2024 – 16:00 CEST

Note: The article below covers a simple case scenario of a hacked WordPress site. It’s neither an all-case scenario approach to the problem, nor it is the best way to handle that kind of infection: with some steps like database check being omitted here. See the bottom section of the article for further reading. I also, do not guarantee, that the steps provided below may help one out in his case scenario.

Discovering a hack

Front End Security Discovery

Site #1 – hacked WordPress files

A couple of days ago, a friend approached me that his site grafpoint.net went randomly offline. I was like, give me a minute or two and I’ll fix it xD At first, I took a look at his website and I thought, it’s just offline, the debugger is disabled, so, I’ll just log in, I will check the error.log, fix issues, and voila. I expected an auto-update to crash the website.

Later on, I checked the website via mobile phone, and I realized (actually pretty randomly) that in some case scenarios, the site was displaying an awkwardly looking content with Chinese text and some bags for sale, see the images below:

Desktop screnshot of the website

Mobile screenshot of the website

I realized, there was something wrong, and that my first impression, that an auto backup failed was wrong. The above page was displayed only in several rare case scenarios, i.e. browsers w/o any firewall or virus scanner, so I thought this was pretty odd.

Site #2 – hacked WordPress database

On December 2023, a friend of mine approached me, that their website was having a redirect problem, where visitors viewing their website https://zawszenawakacjach.pl/ from mobile have been experiencing an odd problem, i.e. they have been irregularly redirecting to a malicious website. Upon investigating the issue myself I realized, they were infected with Balada Injector I figured this out by googling the problematic website and landing on the Sucuri Security blog.

A proof of potential infection, found in the source code

Back End Discovery (files)

So, I decided to login to the site via FTP and I found, a bunch of suspiciously looking files and directories under the hood, say:

Manual malware pursuit & cleanup try

Site #1

Since, the site was, most likely infected and I had no means of accessing the website via wp-admin / wp-login.php and so on. I did the following:

• I logged in via FTP and I manually removed as many infected/suspicious files as possible – to prevent further infections (if any). I did that directly via FTP or Control Panel, w/o downloading the files to my local PC (to prevent potential infection of my local PC – remember not to open these files (if not required) and if you are certain of potential risks involved).
• In some case scenarios, where files couldn’t be removed I checked the server-side logs. Some oddly looking files were being blocked from being accessed. These files that I missed while traversing the FTP, have also been quite suspiciously looking:

Some suspicious files as seen in the logs

• Again, I removed these files manually, I tried enabling the debugger again, and I tried checking the logs, and the site was still inaccessible… I thought I got rid of all the infections, yet nothing has changed.
• Digging further into the files, I discovered that WordPress core files may have been tampered with, so there was not much I could do, but just overwrite everything with the latest core WordPress files.

Site #2

Similarly to #1, I tried to find the malicious code directly within the WordPress files first – to no avail. With no code found in the files of their install, I decided to investigate the database of the website, taking into account the mitigation steps outlined on the Sucuri Blog. The script to find the code was pretty simple, I searched the {prefix}_options table of the website, with a simple search as such SELECT * FROM `wp_options` WHERE `option_value` LIKE ‘%startperfectsolutions%’. To simplify the process, you can use the phpMyAdmin tool, usually available with most hosting providers, and perform a search there.

phpMyAdmin is a great tool for performing easy db operations through its GUI

With the usage of the above tool, I managed to find and remove the infected row directly from the db. Thus getting rid of it and preventing any further redirects.

Temporarily Blocking the site

Enabling Maintenance Mode

This section applies to both of the websites. The problems described above, and inability to relaunch the site, made me do the following:

1. I’ve uploaded latest WordPress core files, overwriting everything (i.e. files, directories) we have had with the latest WordPress files. Note: The FTP client, gives a good info of potential failures, with information of what has been overwritten and what not. I got to the point where I was quite certain no core file would remain infected, as they were simply overwritten.
2. I’ve set up a new WordPress install, loading vanilla WordPress within the same directory as the previous one (using separate DB). This gave me the option to log in to a fresh Dashboard and run the updates of all WordPress existing plugins, again reducing the risk of having malicious files on the platform. Hence, after a longer while of fighting with the updates, I got to a point, where the client’s website was accessible from the browser 🙂
3. For the sake of visitors, I used the Maintenance Mode plugin to inform them, that we were dealing with some sort of problem here – no details were provided/needed at this point.

Website after enabling Maintenance Mode

Possible Security Penalty

Cleaning up Malware

Site #1

The above temporary solution gave me some extra time and room for different kinds of work. With WordPress Dashboard being accessible and most likely all files up-to-date, I started proceeding with hardening and checking the site for any remains of the malware. Note: It’s not a problem to run a separate DB on the same WordPress install, as long as you don’t touch the DB of the original site – this gives one an access to the files from the Dashboard of the original install. Also, I’ve run Sucuri Security, Malcare, and iThemes Security plugins one by one with the hope of them removing any remains of malware. Find the results here:

A follow up from the iThemes

Update: A follow up quote from Daniel Knauss from the iThemes. This is a part of the conversation to be found on Linkedin.

IThemes Security is quite different from the others you looked at. It does not have a malware detection tool. The Site Scan feature checks if you have installed software with known vulnerabilities that could be hacked. It also checks if Google has flagged your site for the presence of malware, which indicates you have been hacked: https://ithemes.com/security/site-scan/   You can also use our File Change scanner to look for malware, but this really is not a comprehensive breach detection and cleanup tool. Finding and cleaning up a breach is not a security activity. Security is about prevention, so those hacks never happen, and you never have to do cleanup. So iThemes Security is focused on helping you harden your site and protect your users so you never get malware on your site.   It looks like your friend’s hosting account may not be capable of running these scans — if you run into rate limiting you can wait and hope the server fres up, but you really may need more server resources. Here’s a support forum discussion about this: https://wordpress.org/support/topic/exceeded-rate-limit-please-wait-81-seconds/

What was I to do next, I asked myself? The site was up-to-date, and most likely most of the identified malicious files (excluding the potentialy malicious files mentioned by Sucuri) have been removed, while Sucuri (first choice) helped me out by adding an extra layer of protection. So, I gave it a try and I tried enabling the previous version of the website. I edited the wp-config.php file, to load the DB of the original website, to see if it would work now, and it did. Here’s what the site looked like next:

Post Removal Website Up & Running

The site seemed to be running properly now. With “everything” up-to-date and an extra hardening applied on top of that. Based on the Sucuri Check, the site was free from Malware and was not blacklisted.

Site #2

With the row containing the Mailcious script removed from the db the website, was clean. However, to prevent this issue from happening again, we’ve updated all of the plugins and WordPress to their latest version and we’ve applied hardening methods described in the final section of the article, thus preventing any other infections from happening.

Conclusion

Dealing with an infected WordPress website is a PITA, not only you may have problems fixing the website yourself (as I had), but commonly used Malware Scanners may fail as well. The best way to prevent a malware infection or a hack is to stick to several rules, that improve the website’s layers of protection. The term is called risk mitigation, and with WordPress, one can follow several rules to prevent an infection:

1. Keep your site and plugins up-to-date always.
2. Enable 2FA.
3. Use a plugin to Limit login attempts.
4. Use strong passwords.
5. Perform regular checks of your website, including security scans, they may fail (as in my case scenario) but they may give you an impression of having problems.
6. Use an up-to-date PHP version.
7. Use Sucuri Site Check to verify any exisiting malware.

Finally, If you are having a problem with your website and you are looking for help, don’t hesitate to reach out the me via the Contact Page, or directly through the Codeable.

Follow up reading

• WordPress Security
• Hardening WordPress
• Why WordPress Scanners are Worthless
• Codeable Security Experts
• Details of the Balada Injector

Recommended Secure WordPress Hosting

Please leave this field empty

Oh hi there 👋
It’s nice to meet you.

Sign up to receive WordPress tips in your inbox, every month.

Email Address *

I don’t spam! Read my privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.