RSS Twitteer Facebook linkedIn YouTube foursquarePinterestGoogle

Your Website Just Got Hacked: What To Do Next (And How To Prevent It From Happening Again)

Jul 21st, 2014

Website owners are notoriously unaware of what’s going on on their servers.
They pay someone (the web designer) to create a pretty website and then they pay someone else (the hosting company) to keep the website online and alive, and that’s it.
And in many cases, this symbiotic relationship lasts for a long time, and everybody can live happily and go about their business.
Security routines, backup schedules and other intrusion prevention measurements in most cases are never implemented (“Do we really need that?”).

It Only Matters When It’s Too Late

Sucuri SiteCheck
But when the hosting company (in this case one of Germany’s largest hosting companies) shuts their website down due to a horrible malware infection, or when Google starts classifying their site as “potentially dangerous” or “malicious”, they call the web designer (usually to yell at him).
And the web designer then calls us for help.

It’s Really Not About You

Unless you’re a Fortune 500 company, work for the DOD, are stupid enough to store sensitive user information on your server (like your customer’s credit card information), or any combination of the above, attacks on your website are NEVER personal. It’s really not about you, it just happens to happen to you.

With the rise in popularity of CMS systems like WordPress, Joomla and others, attacks on servers have become a “sport” of sorts for bored script kiddies, and literally anybody who can execute a google search.

The majority of these hacks rely on commonly known factors or exploits, default installation routines and paths and – the most vulnerable – weak passwords.
Anther common reason for infections is of course an already infected theme, plugin or other package, acquired via “obscure” sources (that claim to provide all the newest templates for free) that got uploaded to the server and “sleeps” there until awakened on a set date (let’s say on 12/13/14 at 15:16), through direct access (by accessing the file directly in the browser) or via a random activation routine (every third pageview, only for users not logged in to the backend, etc).
Read Sucuri’s Blog Article “Unmasking “Free” Premium WordPress Plugins” here

The Proverbial Needle In The Haystack

All these CMS systems come with hundreds or thousands of files just for the basic “core” installation; not counting theme (or template) files, plugins, extensions and whatever else people like to put on their server(s).

For somebody who doesn’t know the default file structure or what to look for it’s nearly impossible to find infected files and to clean an infection properly.

Infections can hide as images (really – images containing executable php code as shown in this example: http://blog.spiderlabs.com/2013/10/hiding-webshell-backdoor-code-in-image-files.html), they use images disguised as txt files, they can attach themselves to already existing files, or “hide in plain sight” – disguised as files that seem to be part of the installed (CMS) system (do you know if a file called “wp-main.php” is part of a default WordPress installation or not?) – the possibilities are endless.

WebShells, Phishing, Spamming & More

On this particular server we didn’t just find one particular infection. We found 4 different ones.

One of the more common ones was a version of WebShell – an (admittedly extremely well written) script that gives the user complete control over the server.
WSO WebShell

We also found a highly configurable Email sending script:
SMTP Server

Another PHP Spamming script (it actually calls itself “Spamming Script” in its title):
Spamming Script

And the phishing script (pretending to be a login screen for a Brazilian bank) that triggered the alert from PhishTank, a site that lists known phishing sites:
PhishTank Details

Cleaning & Prevention

All of the above scripts consist of more than 1 single file – they have dependencies and configuration files, stylesheets and embedded graphics just like any other (well-written) software. They can be remotely updated, changed, moved and even deleted.

It’s extremely important that every single last bit of an infection is identified and cleaned – otherwise they’re almost guaranteed to reoccur.

The easiest (and cheapest) way is always to scrap the complete site and reinstall the latest (not infected) backup.
It’s also the least likely one since almost nobody has a recent and certifiable clean backup.

Painstakingly go through the installation and identify files that were created or modified after the known file creation or modification date.
Don’t even try to do this by looking at the file timestamps in your FTP program. All of the infections we have seen (and cleaned) modified the timestamps of the affected files to pretend to be part of the original installation.

Start over with a clean install.
Re-install your CMS, your theme and all plugins from scratch. Of course you lose all modifications you might have made to the code or any other changes made by the previous live system (image uploads, comments, etc).

Do you still think paying for a security package is not worth it?

Better Safe Than Sorry

– Did I mention already how important regular backups are?
– Use strong passwords and change them regularly.
– Make sure all files have the correct permissions.
– There are many ways to secure a website’s installation. From file modification monitoring to enumeration prevention – ask us if you are interested in a security evaluation of your website or if you need help with a cleanup.

Your website’s security is a job for professionals

Because the infection most likely happened because an amateur was working on it in the first place.

About the author:

Nina Khoury is a computer scientist, software engineer, data and information junkie and online marketer. She taught at various universities for more than six years and worked on projects for Fortune 500 companies including cisco, Intel and HP.

Leave a Comment