Chapter 9: Fixing the Hack: Freeing a Site on the 4th of July–A Real-world Example
Sometimes, as characters in the Mitford books series are wont to say, there is just no rest for the wicked, & the righteous don’t need none.” & so, on a holiday in the States, when most folks were celebrating the nation’s independence w/their families & taking a break, I found myself at my computer keyboard, working to fix a compromised site.
It was really visible too. When I typed in the domain in my address bar–&, incidentally, it had nothing to do w/coachmen, the following (redacted) message appeared:
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 & show how I went about repairing & reclaiming this compromised site. & by time July 4 was ended in the States, the website owner had their site under their control once more & I still managed to watch some fireworks w/the hubby.
BTW, absolutely do not call the above number! & 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.
- Since I knew my machine was clean (a malware scan had just finished, & 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 & had attempted a fix, but because the backdoors were not closed, those efforts were for naught. So much for notifying the host.
- 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.
- 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 & 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 & 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 & chaned the database username & password.
- While in there, I also went to
WordPress.org secret-key service
& changed all the salts. That logs out all users, forcing them to log in again.
- I also went to the ‘Users > All Users’ portion of the dashboard & looked for any users w/escallated privileges I didn’t recognize. I found one & 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 & 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 & 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.
- Now that I had a complete site backup & 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 & 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) & uploaded the uploads folder to the server.
- I then logged into the dashboard & reinstalled the remaining plugins & themes, w/the exception of those that were unmaintained.
- I scanned the site w/both Sucuri & 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
in case it’s of interest–& no, I have no financial or any other affiliation w/the company). I looked for words there like:
- <script “
- <? php
Note that this is not an exhaustive list, & 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 & 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.
- I also registered the website w/Google Search Console
Google Search console I checked both the ‘Security Issues’ & the ‘Search Traffic > 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 & reclaimed & 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 & 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 & creatively. Noble, if that were indeed the case, but all it did was compromise the site. Boo, hiss!
- There were multiple unmaintained plugins & 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 & reclaimed, I discussed my findings & 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 & 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.
Chapter 9: Fixing the Hack: Freeing a Site on the 4th of July–A Real-world Example — No Comments
HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>