Tip: F#*K! My blog got hacked. Now what?

Tip: F#*K! My blog got hacked. Now what?

This article is part two of two covering blog hacking for Security Month, a month-long look in the importance of security. You can read the previous part (one dealing with prevention) here. Part Two covers what to do after your blog just got hacked. Enjoy!

This article was written by Catalin Cosoi.

Recovering from a hack can be a painstaking experience, and the effects of a hack may be felt over a long period of time. The faster you identify and solve the issues though, the less damage will be inflicted to your blog. Here is a short list of immediate actions to be taken after a potential attack has been discovered.

I. Block traffic and don’t delete (just yet)

First and foremost, you need to render your domain inaccessible to users and search engine crawlers. Since all the website files will be required for later analysis and (probably) for restoration, deleting any of them is not recommended. You can block all traffic instead by placing a .htaccess file inside the root directory of your website. If using .htaccess files is not supported, or your webserver is not running Apache, you are advised to rename the index.php file and create a blank one in its place. Beware: do not forget to create a dummy index.php page or you risk exposing other files in your FTP account. The .htaccess file should contain a single line reading: deny from all.

Stopping traffic and search engines is an essential part of the process. You don’t want to lead any more of your users to malware or to attack another website, nor do you want to get flagged by Google® as a malicious website.

II. Backup, Backup, Backup!

Make a full backup of your home folder. This usually includes not only all the files in your hosting account, but also the SQL dumps of the databases you may have. If you are unable to create a full backup, download the contents of your account using a FTP client and then manually export the database(s) as SQL file(s). You might want to run a deep scan using your favorite antivirus on the downloaded files too, since some of the malicious scripts injected by cyber-criminals are picked up by string scanners.

III. Check your logs

Pull off the access logs from your webserver and store them in a secure place. The faster you get them, the better, as most webhosting providers keep them only for a limited period of time (usually 12 to 24 hours). You will need the logs for investigating what exactly the attackers have done on your website. This forensic analysis on your hosting account will likely be able to reveal where exactly your website has failed and, subsequently, will hint you towards what actions to take in solving the issue.

IV. Copy your themes and plugins

Make a copy of whatever customised files you may have. Customised files may include themes, plugins and files uploaded as content – practically everything that can’t be downloaded from the web again. Just keep whatever you consider necessary for a fresh start without losing any content.

V. Start digging

Start looking inside every plugin and theme file for suspiciously-looking fragments of text. Pay special attention to lines of text like ‘eval(base64_decode)’, followed by a series of illegible numbers and letters, as well as any script inclusions from domains you don’t know (such as <script src=”http://[unknowndomainname]/scriptname.php”>. Base64 obfuscation is the method of choice for concealing malicious code from the human eye. If you have found something like that, it doesn’t necessarily mean that it is malicious, as some theme designers use Base64 encoding to protect their copyright notices from being altered. However, you should compare your modified theme to the original one – if there is no Base64 code in the latter, you should clean it from the modified file.

VI. Check the database

Go through the database table by table and look for any sign of suspicious linking. Pay extra attention to the tables holding the administrators, the configuration settings and the blog post articles. If you find any administrator you are unaware of, remove it at once. The last two tables might contain a Javascript-based redirect. Delete any JavaScript calls you are unaware of (by default, WYSIWYG editors do not output JavaScript, so it’s safe to assume that any trace of JavaScript inside blog posts is malicious).

VII. Now delete

After the inspection and cleaning process is completed, you should remove any files from your webserver. If the database was also affected, you should drop it and restore the copy you have manually checked.

VIII. Start (almost) from scratch

Start uploading your blog script back onto the server. Make sure you have downloaded it from the official repository and the archive’s MD5 hash is identical to the one displayed on the official website. It is mandatory that you download the latest version of the blog script. Modify the config file to match your web server’s details (SQL user, database, password, file path and the rest of your settings).

As a side note, many of the commercially-supported CMS scripts can be downloaded from ‘warez’ boards and BitTorrent sites, with their commercial protection defeated. Please note that using ‘nulled’ scripts is extremely dangerous, as they usually contain ‘bombed’ code (backdoors) set in place by the ‘nuller’ (the one who hacked the original code) to be able to take control over the user’s website.

IX. Permissions

Make sure that you do not set file and folder permissions higher than the script actually needs to run properly. Setting files and folders to CHMOD 777 may allow an attacker to actually write to them and re-inject malicious code. Check the script’s technical documentation and set the right permissions for each file and folder. Also change the blog’s administrator passwords and the FTP ones.

X. Final Steps

Push your modified files back to their right place via FTP. If you have blocked access to the site’s root with a .htaccess file, please remove it now. Flush the browser’s cache and access your website. Additionally, look your blog up in a search engine using your name or the blog’s title as keywords and follow the search result provided by the engine. Most of the time, blog malware checks the referrer to see if the visitor accessed the website directly or via a search engine and only manifests itself to referred visitors.

Catalin Cosoi is BitDefender’s antispam research labs.

Did you know, you can actually win one of ten copies of BitDefender Total Security 2010 for free. Yes, you heard that right. For FREE! You can enter the competition right here.

Image by:Jacob Bøtter/Flickr (CC)

Share Tweet Send
You've successfully subscribed to TechGeek
Great! Next, complete checkout for full access to TechGeek
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.