Overview

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.

The first step in restoring normalcy is to figure out how the account was hacked. Almost all hacks are carried out using one of three methods, which are rated in order of likelihood:

A CGI vulnerability in software you’ve uploaded to your website has been exploited, allowing arbitrary code to be written/executed on the server.
The password to your FTP/SSH server has been hacked.
On web-accessible directories, you have world-writable directory permissions.
CGI hacks are more common than FTP/SSH password hacks, which may seem counterintuitive given the vast amount of pre-bundled software that users install and usually neglect to update. FTP/SSH hacks, on the other hand, are the easiest to detect. When the attacker is on the same system as your account, world-writable folders attacks are conceivable. Anyone with an account on the hosting system can put files there if the permissions are set to world-writable (o=w).

Logging into your server

You must first log onto your server through SSH to run the scripts below:

Overview of SSH

Looking for FTP/SSH hacks

Start by removing this option because recent FTP/SSH hacks are the simplest to identify. Use SSH to connect to your user and run the commands below.

Shows you your current month’s login history:

[server]

$ grep username | last -i
Shows you your previous month’s login history:

[server]$ grep username | last -if /var/log/wtmp.1
Last truncates usernames after 8 characters, thus if you have a longer username, you should truncate it in the grep string as well.

This is what the output looks like:

99.139.XXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Wed May 28 06:10 – 07:11 (01:00) username pts/5 66.33.XXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Sun, May 25th, 09:31 a.m. – 12:14 p.m. (02:42)
66.33.XXX.XXX ftpd30715 66.33.XXX.XXX 14:16 – 14:16 – 14:16 – 14:16 – 14:16 – 14:16 – 14 (00:00)
66.33.XXX.XXX.XXX.XXX.XXX.XXX.XXX.XXX.XXX.XX Username pts/2 66.33.XXX.XXX 66.33.XXX.XXX 66.33.XXX.XXX 66.33.XXX.XXX 66.33.XXX.XXX 66.33.XXX.X Tuesday, May 20th, 13:06-13:22 (00:15)
By connecting pipes to a few basic instructions, you may condense this data to output simply IP addresses and counts:

[server]$ grep username | awk ‘print $3’ | sort | uniq -c | last -if /var/log/wtmp.1
This is what the output looks like:

1 99.139.XXX.XXX 4 66.33.XXX.XXX
You can use either way to figure out who has signed into your FTP/SSH account.

If the hack is older than that, GreggHost will not have any records of it because the wtmp logs only go back 1–2 months.

If you’ve determined that the hack came from FTP/SSH, you should:

You should change your password. For further information, see the Change Password article.
Stop using FTP, which sends your password in plaintext over the Internet, and instead use SFTP or SSH. On the same page where you changed your password, you can stop FTP for the account in the control panel.
Ensure that any machines where you’ve used the password/user in question have up-to-date virus/malware scanning.

Looking for CGI hacks

Taking a look at your logs on a given date
If at all feasible, try to figure out when the hack happened. This is frequently determined by noting the hacker’s modification date on any files he or she has altered. Typically, they will all be modified at the same time. Check the logs for that day and time to see what was requested or submitted to your site if that time can be confirmed.

Examining your log files carefully can often disclose how your site was hacked. Every request and post to your site is logged, and the log files can’t be altered by the user, thus the attack record is saved as long as the exploit is detected during the 30 days or so that the logs are kept.

Examining each of your logs
If the original time cannot be determined, the log files can be searched in bulk, albeit finding proof of the breach will be more difficult. After logging in through SSH, run the following command on your web server:

[server]$ gunzip -c /logs/example.com/http/access.log.* /logs/example.com/http/access.log.* /logs/example.com/http/access.log.* | sort -n | gawk ‘a[$7]++ENDfor I in a) print a[i]”t”i’ | gawk ‘a[$7]++ENDfor I in a) print a[i]”t”i’ | gawk ‘a[$7]++ENDfor I in a) print a[i]”t”i
This produces a report of all requests to your site, organized in ascending order, from all available logs. Because the bulk of requests should (ideally) be valid, it’s best to start looking for evidence of the exploit at the top of the report — the least frequent requests:

It’s not uncommon to see a lot of requests that shouldn’t be there, as that’s the nature of a website that’s open to the public. These queries do not indicate a breach in and of itself, but they should be looked into to see if the request successfully revealed a vulnerability.

Looking for world-writable directories

World-writable folders allow any user on the machine to write files, and they may be scanned in bulk. This step should be taken whenever you detect a security issue.

Even if you’re certain you didn’t make any permission errors, some less security-conscious software vendors or plugin developers will frequently use system commands or language-native permission-management functions to create some directories (typically ones used for caching and temporary files, session files, and so on) to make installation and management easier.

Use the UNIX search program to look for folders having world-writable permissions. Use SSH to run this command in the web directory of your domain.

This command looks for files in all folders underneath the one in which it was run:

$ find. -type d -perm -o=w [server]$
No folders are world-writable if no results are displayed.

Making world-writable directories work again
With the UNIX find program, you can modify the permissions of all your world-writable folders in bulk. Using SSH, run the following command:

-type d -perm -o=w -print -exec chmod 770; [server]$ find. -type d -perm -o=w -print -exec chmod 770;
This is what occurs when you execute this command in your web directory:

There are no folders with 777 permissions identified.
777 permissions are modified to 770 permissions in such folders.
Other directories remain unaffected.
It’s always a good idea to list all the world-writable folders before deciding on the appropriate permissions. Some folders necessitate extra care.