Shortcode

🔊 Play

Sometimes, as characters in the Mitford books series are wont to say, “There is just no rest for the wicked, and the righteous don’t need none.” and so, on a holiday in the States, when most folks were celebrating the nation’s independence w/their families and taking a break, I found myself at my computer keyboard, working to fix a compromised site.

The hack was really visible too. When I typed in the domain in my address bar–and, incidentally, it had nothing to do w/coachmen, the following (redacted) message appeared:and
hxxp://thecoachmen.tk is requesting your username and password. The site says: “Security Update Error 0xB1983959 Help Desk: 888-386-1497 (TOLL-FREE)”

Well, definitively not cool! So this is an attempt to put all the steps together and show how I went about repairing and reclaiming this compromised site. and by time July 4 was ended in the States, the website owner had their site under their control once more and I still managed to watch some fireworks w/the hubby.

BTW, absolutely do not call the above number! and I’ll leave it to you to figure out whether my situation falls under being wicked, righteous, or, as is more likely the case, somewhere between.

The below steps are precisely those listed in the section on Fixing the Hack.

Notifying the Host, Cleaning Devices, and Securing the Network

Since I knew my machine was clean (a malware scan had just finished, and I take great care to keep my devices squeaky, plus my home network is locked down hard, I skipped these steps. The client’s host was also aware of the compromise and had attempted a fix, but because the backdoors were not closed, those efforts were for naught. So much for notifying the host.

Backing up the Site

Next, I backed up the site. I started by backing up the entire web root folder, in this case public_html. I was using Filezilla to do this, but found myself being disconnected from the server quite regularly. I therefore also initiated a backup using the client’s hosting provider’s control panel as well, as I was concerned that the backup obtained using Filezilla might contain errors due to the multiple disconnects.

Simultaneously, I backed up the database, as detailed in the post:
Backing Up Your Database w/phpMyAdmin

I created a folder with the site’s domain name in my ‘Documents’ folder, then under the site folder I created a new folder called ‘hacked’, where I put the backed up site files. It looks like documents\sitename\hacked. Placing the files in a folder called hacked will allow me to back up the website for safekeeping in the sitename folder once the site has been cleaned. It will also serve as a warning not to use these files unless they’ve been checked carefully.

Changing Passwords

The next step was to change passwords. Obviously I could not log into the dashboard, so I changed the password by way of the database, as shown in the post
Create A New WordPress Admin User Via phpMyAdmin

I also created a new database user and password, as shown in:
Creating a Database User and Granting Privileges in order to change the database credentials.

I next opened the client’s configuration file, in this case, wp-config.php to change the credentials and noted that the first few lines of the file read:
”
Uh, yeah–definitely that’s not supposed to be there. So I deleted the lines and changed the database username and password.

Examine Database, User Content, and .htaccess

Additionally, I also went to WordPress.org secret-key service and changed all the salts. That logs out all users, forcing them to log in again. That way, if unauthorized users were logged into the site, they’d be unceremoniously kicked out.

I also went to the ‘Users > All Users’ portion of the dashboard
and looked for any users w/escallated privileges I didn’t recognize. I found one and deleted it, though I suspect it was probably just the client’s hosting provider. Still, at this point I was taking no chances.

I also installed Wordfence and did a site scan to see what concerns would be raised. In addition to multiple malicious files, including some in the uploads folder, there were issues w/a number of plugins which I noted and sent to the client. 1 of these was the plugin that started the hack (more on that later), as well as several plugins that appear to be no longer maintained by their authors.

I tend to tweak the Wordfence settings pretty liberally when dealing w/a site compromise. Not all of these need to be checked when running routine scans, as they can take up server resources. Therefore, once completed, Wordfence can be reset to its defaults to cut down on resource usage. When in the midst of a site compromise, though, I check the following options:

• Scan core files against repository versions for changes;
• Scan theme files against repository versions for changes;
• Scan plugin files against repository versions for changes;
• Scan wp-admin and wp-includes for files not bundled with WordPress;
• Scan for signatures of known malicious files;
• Scan file contents for backdoors, trojans and suspicious code;
• Scan file contents for malicious URLs;
• Scan posts for known dangerous URLs and suspicious content;
• Scan comments for known dangerous URLs and suspicious content;
• Scan WordPress core, plugin, and theme options for known dangerous URLs and suspicious content;
• Scan for out of date, abandoned, and vulnerable plugins, themes, and WordPress versions;
• Scan for admin users created outside of WordPress;
• Scan for unauthorized DNS changes;
• Scan files outside your WordPress installation;
• Scan images, binary, and other files as if they were executable;

Running Wordfence in a situation like this is not strictly necessary, ie, I could’ve looked the plugins up on my own, but doing so did alert me to files in the uploads folder that I would’ve otherwise had to look through manually, as well as alerting me to abandoned plugins, which I would have also had to check by hand.

Replace and Reinstall Files

Now that I had a complete site backup and the credentials had been changed, I next deleted the files. Normally I just reinstall a site using FTP, but, because of the flakiness I was experiencing using it, I decided to opt for using Softaculous via the client’s control panel instead, since there was no access to the command line. Meh! The steps for doing that are found at: Installing a Website Using Softaculous I used Softaculous’s ‘Advanced Options’ tab to specify the database name I wished to use and changed the table prefix to that of the existing database. Once I hit the ‘Install’ button, I had a fresh clean install of WordPress’s core files.

I deleted the files flagged by Wordfence in the uploads folder (I had actually found them manually beforehand) and uploaded the uploads folder to the server.

I then logged into the dashboard and reinstalled the remaining plugins and themes, w/the exception of those that were unmaintained.

I scanned the site w/both Sucuri and Wordfence to insure that the site was clean. I then deactivated 1 of those security plugins.

Next, I examined the backed-up database using a text editor (EmEditor, for those who are interested, available at Em Editor in case it’s of interest–and, no, I have no financial or any other affiliation w/the company). I looked for words there like:

• < script>
• <?php >
• ‘base64’
• ‘eval’
• ‘preg_replace’
• ‘strrev’

Note that this is not an exhaustive list, and the words by themselves do not definitively prove a site compromise, though some are more suggestive than others, i.e., `strrev`, as that often is an attempt to hide what the code is doing. It’s definitively worth having a professional take a look if you’re uncertain.

I next examined the .htaccess files, both in the web root and in subfolders, if it existed, for any evidence of backdoor code. In this case, no such code was present.

The site backup I initiated using CPanel allowed me to look at some configuration files I normally would not have had access to on a shared hosting platform, so I examined those, too, for any evidence that they had been compromised. They weren’t.

Rebuild Your Reputation

I also registered the website with Google Search console
I checked both the ‘Security Issues’ and the ‘Search Traffic and ‘Manual’ tabs to see if Google found any issues, but it had not. Well, good–less work to do.

At this point, the site was completely repaired and reclaimed and back in the hands of the site owner. So what do I believe happened?

There are several things which I feel led to the hack.

• The major cause of the hack seemed to be stolen wordpress.com credentials, which caused the criminals to be able to log into the site and modify the account. Details can be found here:
  Hijacked WordPress.com Accounts Being Used To Infect Sites
  I believe this because the plugin called “pluginsamonsters” which was associated w/the compromise, was also present on this site. This is 1 very good reason why the same password should not be used on multiple sites. The supposed goal of the plugin was to help kids work together collaboratively and creatively. Noble, if that were indeed the case, but all it did was compromise the site. Boo, hiss!
• There were multiple unmaintained plugins and themes on the site which could’ve contributed to a site compromise, though in this case, I feel strongly it was stolen credentials that caused it.
• The password the client chose was not as strong as it should’ve been.

Once the site was repaired and reclaimed, I discussed my findings and recommendations w/the site owner, including how to make a passphrase as opposed to a password, as well as the importance of using well-maintained 3rd-party software and of keeping the website updated. I suspect that, under the watchful eye of an educated owner, the site should do well for years to come.