WordPress Security: Hacked Images, Themes, Redirects and A Gem In The Sand

Editor’s note: This is a guest blog post by Jim Walker [bio] who runs HackRepair and has been cleaning hacked websites for well over a decade. Jim regularly sends us interesting samples of infections he finds and he gets to see all sorts of novel infections in the wild. He put together this guest post about one of the more interesting infections he ran across:

Every once in a while I stumble onto an interesting website hack. Most of the hacked websites I repair are of the run-of-the-mill variety; you know the usual base64 code stuffed into some random WordPress script or plugin, along with a smattering of cookie-cutter back door scripts tossed into random directories. Generally predictable.

Then occasionally a job comes along that sparks my interest. Hacked images are nothing new. They’ve been around for years. Mark Maunder even touched on the subject in his excellent 2011, “Zero Day Vulnerability in many WordPress Themes.” Likewise, a quick search in Google for the word social.png will bring up all manner of discussions on the topic. Don’t get me wrong. All social.png images are not alike. Many free theme authors encode links to their work. Whether encoding text or links into images is appropriate or not, I suppose that’s subject for another article…

Ok, back to what sparked my interest. Client called and started the conversation with a not too uncommon statement, “My site has been hacked for over week. My web designer says my site is clean, but Google shows my site is hacked.”

So I dive in thinking, “Cool, this may be a challenge.” Sadly, at first glance, challenge—not so much. The site was relatively small, fewer than 10k files, and a number of gibberish named back door scripts littering the usual directories were almost too easy to find. And then it dawned on me that something was amiss. There was still a snippet of iframe code showing within the body of the home page HTML. Aha!, not just the common drop-and-run script kiddie at work here.

It turns out our hacker friend used an easy-to-guess administrative password to infiltrate and edit a number of WordPress core and theme files. A scan using the Scan option within Wordfence made that crystal clear. And because the client used a relatively common free theme Wordfence caught that nicely as well. Embedded within the themes’ index.php was the extra include line:

And a gem appeared from the sand. sidebar2.png, a small 107kb image. Nicely named! At first glance the image looks innocuous enough, so I tried loading sidebar2.png in my browser. Result: a broken image.

Since Wordfence so nicely called it out, I then loaded up the image as text and voilà!

That little image was actually 1500 lines long (72 characters per line) of base64 encoded text.

So now the call back. So why was this so special you ask? This is where it got fun. In decoding the script I was amazed to find the hacker had “hand coded” the client’s website address, along with a number of redirects to various websites, and even a number of rules to evade detection.

Some snippets decoded from the image:

and

And the script goes on and on with hundreds of lines of IP rules and the like.

I was impressed—mostly that someone would go though all this trouble for a rather simple blog covering young women’s fashion tips… “My favorite boots today are made by…”

Well, thank you for allowing me to take you down that rabbit hole with me. Suffice it say, please reconsider setting your administrative password in WordPress to password123.

Your destiny is truly in your hands with WordPress. Disrespect it by not updating your WordPress blog and plugins at least quarterly and it will bite you.

About Jim:

Jim Walker has been a website security expert and website hosting services provider for over 16 years. Living in San Diego, California, his current passion is everything WordPress. He manages HackRepair.com, a malware cleanup and website security services company, and HackGuard.com, a WordPress security and WordPress management service.