This Is What Happens When You’re Lackadaisical About WordPress Security

June 2, 2016

When I started building WordPress blogs a few years back, they were constantly being hacked. I spent countless hours rebuilding sites only for them to get hacked again.

But slowly I learned how to harden sites against hackers. It’s a skill not enough WordPress webmasters learn and many are unaware of just how easily an unprotected WP blog can be hacked.

Since I’d developed some expertise in building secure blogs, it’s a service I offer to clients and customers. But, every so often, a client messes with the security plugins and protocols I set up and something bad happens.

There were two such cases in point just in the last week.

Hacked Blog #1

One blog was for a financial site related to pensions (I won’t be mentioning any names or URLs). I’d built a secure site for them last year. A week ago, they came back to me asking to have the site migrated to a new webhost.

As part of my standard procedure, I run a malware check against any site I deal with – I don’t want to inadvertently get infected with malware myself.

This particular site threw up several red flags. While the site appeared to be operating normally – there was no defacement and no odd redirects to off-site pages but there were a lot of suspect new files in the WordPress install. A malware check showed that the site was infected and was trying to inject malware into the web-browser.

When I informed the client that the site would need to be disinfected and cleaned up, they made the decision to kill the site instead.

So how did this infection happen?

The client had gone to another web designer and asked them to use a different theme and re-design the site. However, that web designer seems to have known nothing about site security. Some of the security plugins I had originally installed had been deleted and the remainder had all been deactivated. That left the site wide open to attack. There may be a small performance hit in using security plugins but the consequences of not using them are much, much higher.

This site turned out to be a disposable one, but imagine if this was your business site and how your reputation could be damaged long-term because a hacker took control of your business website?

Hacked Blog #2

The second hacked blog was for a small business. Again, the site appeared to superficially be working normally but the client had received an email from Google alerting them that malware had been detected on the site. The email indicated that immediate action was required before the site would be blacklisted (click the image to enlarge):

When I checked the site, the front page worked as normal but once other posts and pages were loaded, the visitor was redirected to off-site pages showing unrelated offers. The real danger here is that a visitor gets redirected to a page whose sole purpose is to infect a visitor’s PC with malware.

I ran a malware check using Sucuri’s tool which gave this result (click the image for a full size view):

As you can see, several pages were affected and some oddly named files were identified. Unfortunately, the MW:JS:GEN2 links provided led to dead pages on Sucuri’s site, so I couldn’t get more information on this specific infection.

But a look in the public_html folder showed a folder and file that were not a part of WordPress. I deleted these and a few more suspect files I identified. Yet, when I rechecked the site, the redirections to off-site pages were still occurring.

It’s common to find that after an infection is seemingly removed that it “magically” reappears. This was the case here. A common injection point is the WordPress theme header.php file. Code will be added to check that if the malware has been removed that it’s added back into the site.

So I deactivated the theme, deleted it from the themes folder, reinstalled it and activated the new install. And, again, the malware reappeared.

Even deleting WordPress itself and doing a full reinstall didn’t get rid of the malware. So that suggested that the malware had been injected into the WordPress database itself and regardless of what remedial action was taken outside of the database, the malware would always reassert itself.

The client didn’t have a full site backup but, luckily, did have a database backup that was a week old. No changes had been made to the site in the meantime, so no content would be lost by reverting to that backup.

I made a backup of the current database, just in case it would be needed, then deleted all the tables and restored the backup database. I then did fresh new install of WordPress and reinstalled all plugins.

There’s more to what I did to clean the site, but that’s the gist of it. The site is now clean, deactivated security plugins have been reactivated and I added another couple of security plugins to beef up security.

Now that the site’s clean, the client has been able to file a Reconsideration Request with Google to get the malware warnings removed from the site’s search engine listings.

So how did this infection happen?

The client had deactivated some of the security plugins I had originally installed. Why I don’t know. It was probably an inadvertent deactivation because I keep harping on to clients about how important it is to have those security plugins working.

Lesson: Don’t ever skimp on the security of your WordPress blog.