Blog Hacking: Recovery 101

Blogging is one of the most popular forms of written expression on the Web, regardless whether it is used for personal or business purposes. The spike in popularity has been also fueled by the emergence of free blogging services such as Blogspot® and WordPress®, two major players in the blogging platform development sector.

Bloggers who opt for a free account with installations of the Blogger™ and WordPress® CMS respectively also get the service along with professional maintenance and support directly from the provider. This means that blog CMS versions are automatically updated for the end-user, along with any other kinds of server-side fixes and upgrades.

That is why most of the security incidents and hacks usually happen on self-hosted blogs which run obsolete versions of CMS software with various vulnerabilities or which are running on misconfigured web server software.

If you’re reading this article, chances are that your blog isn’t quite in the best of its moments. However, getting hacked is not the end of the world, although recovering from a successful hack attack is a painstaking experience. Bottom line is that the faster you identify and solve the breaches, the less damage will your blog suffer. Here is a short rundown of the time-critical actions that need to be taken immediately after you have noticed that your blog behaves in a suspicious, unusual manner.

1. Right after you noticed there is something wrong with your blog, your primary concern should be shutting the blog down in order to prevent your users from getting exposed to potential malware. Also, blocking search engines from crawling your website will save you a lot of effort later: if your blog is hosting malware or redirecting users to hazardous web-pages, it will be labeled as an attack site and filtered from the search results.

2. You may prevent access to your blog by placing a one-line .htaccess file inside the root folder of your blog installation. The file should read deny from all. If you’rerunning your blog on a different server platform than Apache, or if you aren’t allowed to use .htaccess files, then you can shut down your blog by renaming the index.php page to something else and placing a “dummy”, blank one instead. Beware: don’t leave your root folder without an index page, because you might expose other files in your FTP account.he next step is to make a full backup of your home folder using either a FTP transfer utility or via the cPanel built-in backup feature, if available. Remember to create a SQL dump for the blog’s database. After the backup has been downloaded, you might want to scan the files using your antivirus of choice, as some malicious scripts injected by cyber-criminals are picked up by string scanners.

3. Download the access logs from your webserver and store them somewhere safe. This operation is time-critical, since most webhosting providers have them available for 12 or 24 hours. Log analysis will help you detect how your blog has been attacked and what exactly have the attackers been doing while in control. Identifying the point of failure will help you secure the exploited breach and ensure you don’t get hacked again using the same technique.

4. Take out the essential files from the downloaded backup. By essential, I mean everything that can’t be downloaded from the web again and would be necessary for a fresh start. Make sure that you have taken out modified plugins, themes and other files uploaded as content: documents, pictures etc.

5. Start inspecting any file that you have taken out. Be on the lookout for suspiciously-looking fragments of text such as “eval(base64_decode(" followed by a series of illegible numbers and letters), as well as for any script calls from domains you don’t know (such as < s cript src = " http://[unknowndomainname] / scriptname.php" >. Base64 obfuscation is cyber-criminals’ preferred technique of hiding malicious code from the human eye. However, it is also used by theme designers to protect their copyright notices from being altered, so if you found a base64-encrypted string, this doesn’t necessarily mean that it’s malicious. You should compare your modified theme to the original one – if there is no base64 code in the later, you should clean it from the modified file.

6. Inspect your database table by table and search for unknown administrative accounts that might have been injected straight into the database – if you find any that hasn’t been created by you, delete it at once. Also, look for Javascript-based redirects that might be injected in blog posts. Usually, WYSIWYG editors do not output JavaScript code in blog posts, which should dramatically ease your search.

7. Clean up your hosting account using a FTP client. Delete the entire blog installation and ensure that you don’t leave any unnecessary files. The less files, the safer. Make sure that you truncate the database and restore the copy you have manually checked.  

8. Download a copy of your blog script from an official repository and start uploading the files on the server. You might want to check the archive’s MD5 hash against the one displayed on the script’s official website. It’s mandatory that you always use the latest version of the blog script. Modify the configuration file to reflect your web server environment (SQL user, database, password, file path and the rest of your settings). Pay special attention to the Authentication Unique Keys or any type of salting and make sure you are not using the default values.

As a side note, many of the commercially-supported CMS scripts can be downloaded from “warez” boards, 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 victim’s website.

9. Ensure that all the files you have uploaded have the right permission. Don’t set permissions higher than the script actually needs to run. Setting files and folders to CHMOD 777 may allow an attacker to actually write to them and re-inject malicious code. When in doubt, check the script’s technical documentation for the recommended setup or ask the community. Also, it is highly recommended that you change the blog’s administrators’ passwords and the FTP credentials. If possible, change the default administrator’s username from admin to something harder to guess.

10. Flush your browser’s cache and point it to you website’s address. If everything went fine, you should have a working and healthy blog. If not, make sure that the .htaccess file set in place in step 1 has been deleted or overwritten.

Look your blog up in Google by querying your name or your blog’s title and access the search result. This is an extra precaution to ensure that your blog is clean, as some malicious scripts look for the referrer and only redirect to attack sites only users who have got there via a search engine.

If your blog has been hacked although you have taken all the necessary precautions to secure your files and usernames, then you should investigate if your server meets the blog script’s requirements. Poor server configurations, vulnerable server software, improper blog installations or vulnerable plugins are also a main cause of successful web hacks. In order to prevent any issues from impacting on your blog, you need to follow some simple, yet extremely efficient guidelines:

• Only use blog scripts coming from official repositories. If it’s available for free straight from the producer, why download it from somewhere else? Also, stay away from “nulled” scripts from warez  services – you’re not only committing a crime, but you also expose your site – and probably the entire web server – to unwanted intrusions via backdoors set in place by the nuller.
• Do not populate your FTP account with files you don’t need. This includes themes or plugins you’re not using, but you uploaded for tested. Some plugins and themes may be vulnerable to various attacks, so the less you have, the smaller the chances of getting hacked. Plus that your blog will load faster.
• Do not use multiple scripts on the same URL. You may offer an attacker a nice way of taking advantage by the features of a, say, upload form to place an exploit file in your account and then use it to have your blog owned. If you like testing various scripts do the testing on a locally installed webserver.
• Generate and store SQL backups regularly or install a plugin to take care of backups. It is advisable that you either have these backups sent by mail, or stored on a secondary FTP account. Never use the same FTP account for storing backups, since an attacker can compromise your backups should a blog hack occur.
• Make sure you use strong passwords for both FTP accounts and administrative users. Never disclose your passwords to other persons, not even when you ask for community support. Installing a complete antimalware solution on your computer would also be a good idea, since some of the successful blog attacks were carried using legit usernames and passwords intercepted by keyloggers or cache-monitoring Trojans.
• Always choose high-quality webhosting. Since paid hosting is much better than the free alternatives, make sure that you spend your money well: pick up a hosting solution recommended by the blog script’s provider. Ensure that your web-hosting provider offers you automatic daily backups and access logging.