Your Website Just Got Hacked: What To Do Next (And How To Prevent It From Happening Again)
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
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).
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.
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:
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.
– 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.