:::: MENU ::::

Hacker headaches

Yesterday I got one of the most frustrating wake-up calls a website owner can get: My site got hacked. I don’t know when it occurred, exactly, as the form this attack takes is invisible to everyone but Google (and, presumably, similar search engines). It was not directed at any of my active sites, but at Monkey Law, my old webcomic. The attack, which appears to be a variant on the WordPress Pharma Hack, changes the title of the site and fills it up with pharmaceutical spam when searched for. Viewing the site directly in a browser shows none of this.

So I started searching. The process of putting in text that is hidden from users but visible to search engines is called “cloaking,” and I was able to use a cloaking detector to see that my site did indeed present a whole assload of spam to search engines.

I also discovered what the WordPress Pharma Hack is, and got some suggestions for getting rid of it. And indeed, I had had this hack once before. Back then, the hack was accomplished by somehow getting malicious data injected into my MySQL database. In the equivalent of the wp_options table, the “active_plugins” entry was modified to run a file that was hidden somewhere in my filesystem.

That didn’t end up being the cause this time. I scoured my database for hours, and found nothing offensive. Then I started going file by file through WordPress’s base install, and found one file on my system that didn’t exist in a clean one: wp-stat.php.

Sure enough, this file was mainly encoded, and when I searched for the filename, I found that it was mentioned in .htaccess. Someone had gotten to .htaccess. Yikes. Upon examination, I found that the .htaccess hack was indeed sending all search engine traffic to wp-stat.php.

So I removed wp-stat.php, and cleaned out the offending code from .htaccess.

Today it all came back. Indeed, some reports I’ve seen online have complained about hacks like this coming back every day. So I’ll troubleshoot it like I would any other issue: Change one variable at a time and see if the attacks stop. Today it was hardening my .htaccess file using instructions I found at this site. I added the following lines:

# STRONG HTACCESS PROTECTION
<Files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</Files>

We’ll see if this helps.

[Update 2012-07-31 3:49pm]: It didn’t. So now I’ve changed the password of my WordPress admin user (who is not named “admin”) and updated all my plugins.


4 Comments

  • Reply Sarvesh |

    Hi Brad,

    My site (www.internshala.com) is facing exact same attack – any direction on what finally worked for you and were you able to clean the hack out completely?

    Any pointers would be most appreciated.

    Thanks
    Sarvesj

    • Reply Brad |

      Well, it’s complicated by the fact that I found a LOT of what seem to be intrusive files in my uploads directory for a forum that I run at stripshow.monkeylaw.org. Hopefully I’ve cut off that avenue of attack. But the main thrust of the problem was a file I found nestled in my filesystem… I thought I’d written down its name, but I don’t seem to have. But it was a PHP file which, when accessed with a particular GET string, gave complete and unfettered access to my filesystem. Even had a nice little user interface. I don’t know how it got there, but once I removed it I never had another issue. I will try and find its name.

      • Reply Sarvesh |

        Hi Brad,

        Thanks for your response. Finally we got to the root of it; 5 new files (with rather harmless names but suspicious locations such as index.php in a theme’s image folder) and 7 infected files (actual code files with a nasty encrypted piece of code) were found and cleaning them up prevented the issue from appearing again.

        Unfortunately we are on shared hosting and did not have full access to FTP/HTTP logs and would never know how exactly it got in there. Basis the infected files we can only guess that couple of plug ins may have played spoil sport.

        Thanks
        Sarvesh

        • Reply Brad |

          I found the name of the file in question — it was ro.php. Odds are that changes from attack to attack.

          What I did was search my entire site for the phrase “decode” — found some files that were using the various decode functions legitimately, but others that had encrypted PHP code in them.

So, what do you think ?