Regardless of the mode of the intrusion, you'll want to clean up after a hack to ensure the integrity of your site and to ensure that it cannot be compromised again.
The following describes the important steps to take in order to fix and secure your website after a suspected hack.
If you're not comfortable fixing your site on your own, you can request DreamHost's "Hacked Site Repair" professional malware removal service. For a one-time fee of $199, DreamHost experts will access your account and make the necessary repairs to get you back online quickly. Please submit a ticket from within your DreamHost Panel if you'd like to explore this option.
Removing a hacked file
To remove a hacked file, you must go through all of the files under the compromised user account and delete anything which you did not place there. If you're using an FTP client, make sure to enable viewing "hidden" files – and the same for shell by using the -a option with ls.
It can sometimes help to first look for files with modification timestamps that occurred since you last modified your site or around the time the hack took place. If you have identified a file that was definitely modified in the hack (such as a defaced index page), you may be able to pinpoint the files used to modify the hacked file by searching for the file's timestamp in your HTTP logs via shell.
The following is a useful command for finding modified files:
[server]$ find /home/yourusername/www.example.com/ ! -name "log" -mtime -3
where the "-3" is the number of days in the past to look for modified files. This command lists all files under /home/user/example.com that have been modified in the past 3 days.
If the above command does not work, try without 'www'. For example:
[server]$ find /home/yourusername/example.com/ ! -name "log" -mtime -3
Recent HTTP logs are located in the following directory:
Cleaning up database hacks
Certain hacks, particularly SQL injection attacks against vulnerable Joomla! installations, may result in the database becoming altered with malicious code. Such a modification can allow the hacker back in even if you've updated to the latest version and cleaned off all foreign files.
For this reason, it's a good idea after a hack to inspect the database in the same way you check your files to see if anything has been changed that should not have been. If you know when the hack occurred, you may even wish to revert the database back to a prior time via the backup feature available in the panel. View the Backup article for further details.
Restoring lost/modified files
Finally, to restore files that have been modified or deleted in the hack please see the article on restoring your domain. DreamHost offers database and domain restores from the panel, and the sooner you get to them the better as backups are only kept for a few days.
View the Backup article for further details and options.
The main purpose of exploiting insecure websites is to gain and maintain access for the benefit of the hacker. Therefore, after discovering a vulnerability, backdoors are almost always installed so that the hacker can return at a later time. Failure to identify and remove these backdoors can result in your site becoming exploited again.
Common methods or retaining access include:
- installing a shell – A file which can be requested like any other page on your site, but gives the requester complete access. These are often written in PHP but can be in any language. They are often given innocent sounding names or contain obfuscated code. They may also be appended to legitimate files with extra code added so that the functionality is only available when an extra parameter is passed to the file during the request.
- creating new users – These may be new database users or web app users.
- storing authenticated cookies – Most apps have the option of remembering who is logged in by storing a cookie on the user's computer. If a hacker manages to modify/create a user and receive an authenticated cookie, then this cookie can often be reused until it expires even if the password for that user is changed. To force holders of authenticated cookies to log in again, the salt used to encrypt the cookies must be changed after passwords have been reset. How to do this depends on your software.
- changing folder and file permissions to world-writable
- adding a public key to .ssh/authorized_keys
Unfortunately, there is no single-step, foolproof way of finding and removing backdoors. It takes time and knowledge to investigate the mode of entry and the actions that occurred afterwards. There are many examples on the web of the types of steps that you can take.