Overview

Regardless of how the breach occurred, you’ll need to clean up after a hack to guarantee that your site’s integrity is preserved and that it cannot be compromised again.

The methods to fix and safeguard your website after a suspected hack are outlined in the next section.

If you’re not confident in your ability to repair your WordPress site on your own, GreggHost’s Hacked Site Repair solution is available (a professional malware removal service). Experts from GreggHost will gain access to your account and make the required repairs to get you back online as soon as possible. For additional information, see the Terms of Service page.

Removing a hacked file

To get rid of a hacked file, go through all of the files in the compromised user account and delete anything you didn’t put there. Make sure to enable viewing “hidden” files in your FTP client, and do the same in shell by using the -a option with ls.

Looking for files with modification timestamps that occurred since you last edited your site or around the time the attack occurred can occasionally help. You may be able to trace the files used to edit the hacked file by searching for the file’s timestamp in your HTTP logs through shell if you’ve identified a file that was certainly modified in the hack (such as a defaced index page).

For finding modified files, use the following command:

In the examples below, username is your Shell user, and example.com is your website.

[server]$ find /home/username/www.example.com/! -name “log” -mtime -3, where “-3” is the number of days to search for modified files in the past. This command displays all files updated in the last three days under /home/username/example.com.

If the above command fails, try it without the ‘www’. Consider the following scenario:

[server]$ find /home/username/example.com/! -name “log” -mtime -3 -mtime -3 -mtime -3 -mtime -3 -mtime -3 -mtime -3 -mtime -3 -m
The following directory contains recent HTTPS logs:

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

Cleaning up database hacks

Certain hacks, notably SQL injection attacks against Joomla! installations that are vulnerable, can cause harmful code to be added to the database. Even if you’ve upgraded to the latest version and deleted all foreign data, such a tweak can let the hacker back in.

Like a result, it’s a good idea to verify the database after a hack, just as you would your files, to see if anything has been modified that shouldn’t have been. If you know when the hack happened, you can use the backup feature in the panel to restore the database to a previous state. For further information, see the Backup article.

Restoring lost/modified files
Finally, visit the article on recovering your domain to recover files that were modified or destroyed as a result of the attack. GreggHost’s control panel allows you to restore databases and domains, and the sooner you do so, the better, as backups are only retained for a few days.

For further information and alternatives, see the Backup article.

Removing backdoors

The primary goal of exploiting unsecure websites is to get and keep access for the hacker’s profit. As a result, backdoors are usually always implemented after a vulnerability is discovered, allowing the hacker to return at a later date. If you don’t discover and delete these backdoors, your site may be exploited again.

The following are some of the most common strategies for retaining access:

installing a shell – A shell is a file that may be accessed in the same way as any other page on your site, but it allows the requester full access. These are typically written in PHP, although they can be created in any language. They’re usually given innocent-sounding names or have cryptic code. They can even be attached to legitimate files with additional code such that the functionality is only available when the file is supplied an extra parameter during the request.
attracting new customers – These could be first-time database or web app users.
Authenticated cookies are stored – Most apps provide the option of saving a cookie on the user’s computer to remember who is logged in. If a hacker is successful in modifying/creating a user and receiving an authenticated cookie, the cookie can typically be reused until it expires, even if the user’s password is changed. After passwords have been reset, the salt used to encrypt the cookies must be modified to force holders of authenticated cookies to log in again. Depending on your software, you can achieve this in a variety of ways.
Changing the permissions of folders and files to “world-writable”
.ssh/authorized keys/public keys/public keys/public keys/public keys/public keys/public keys
Unfortunately, there is no surefire technique to discover and remove backdoors in a single step. Investigating the mode of entrance and the actions that followed needs time and knowledge. There are numerous instances of the types of steps you can take on the internet.

After you’ve cleaned your site

After you’ve cleaned your site and are satisfied it’s clean, contact support and have it checked again to make sure no problems remain.

Changing your website’s password

Some websites use software that requires a username and password. Because each application’s configuration file that holds the password is different, you’ll need to reference the application’s documentation for information on where to find it. A few links to common applications are provided in the following article:

Password should be changed (3rd party applications)