Cleaning up your site after a hack

Overview

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 WordPress site on your own, you can request DreamHost's Hacked Site Repair (a professional malware removal service). DreamHost experts will access your account and make the necessary repairs to get you back online quickly. See the Terms of Service page for more information.

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:

In the following examples, username would be your Shell user and example.com your website.

[server]$ find /home/username/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/username/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/username/example.com/ ! -name "log" -mtime -3

Recent HTTPS logs are located in the following directory:

/home/username/logs/example.com/https/

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.

Removing backdoors

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.

After you've cleaned your site

After you have cleaned your site and you believe it to be clean, contact support and request that your site be scanned again to ensure no issues remain.

Changing your website's password

Some websites run software that requires a login. The configuration file that stores the password is different for every application, so you'd need to consult the application's manual for instructions on where the config file is located. The following article lists a few links to common applications:

See also

Did this article answer your questions?

Article last updated PST.

Still not finding what you're looking for?