Attacked by phishers? This is what you need to know
The last thing most website administrators want to hear is that they have to deal with a website phishing attack. No website is immune from phishing attacks and sometimes, no matter what measures you put in place to prevent such a scenario, your website can be compromised – with the subsequent loss of reputation and probable decline in search engine positioning.
The knee-jerk reaction of some administrators is to deal with a website phishing attack by immediately removing the compromising files and resetting passwords. However, by taking a little extra time to gather all the information about the uploaded content, administrators can ensure they find all the website´s vulnerabilities and completely clear the website of any further phishing content that may be dormant in their system.
This guide on how to deal with a website phishing attack discusses how to gather the information you need to clear your site of phishing content, what to do with the compromised files once you have found them and how best to prevent the risk of further phishing attacks in the future. We recommend that, if necessary, you engage professional help to accelerate the cleaning process in order that your website can be restored as quickly as possible, removed from any website blacklist and recover its position in the search engines and to help reduce the potential for further website phishing attacks.
Before you do anything else, back up your system.
Location, Location, Location
The first step of how to deal with a website phishing attack is finding the location of the phishing content. Often you will have been provided with a report about specific files by your hosting provider, but sometimes the information provided for you is limited. Security experts we have spoken to recommend Sucuri Sitecheck (https://sitecheck.sucuri.net/) to identify the location of the phishing content.
It is important not to make any changes to directories or delete files until you have completed a full investigation of your system. This is because making changes and deleting files as you go reduces the chances of you finding the source of the attack. Without finding the source, you may not discover where you vulnerabilities are and you will leave your system open to further phishing attacks in the future.
During your investigation, it is important to keep notes as you go along. Record the full path to any phishing sites you find in addition to any malicious files, code injections, and scripts with unsafe code. Also keep track of their timestamps and any related log entries. We will explain more about this below. At the end of your investigation you will be able to refer to your notes in order to determine the best course of action to take to remove the malicious items and help prevent repeat attacks in the future.
An example of how to deal with a website phishing attack
For our example of how to deal with a website phishing attack, we are going to assume that we have received a report of a WordPress phishing link (http://www.example.com/Apple/securelogin.html) running on a cPanel Linux/Unix Apache web server. Links such as these are commonly used by hackers for phishing attacks; however, there are many different variations as the complexity of phishing evolves.
Most security professionals asked to deal with a website phishing attack will be able to complete the following procedures within 15-20 minutes on a standard sized web site. If you are attempting these procedures without professional help, or you have a larger-than-average website to clean, allow some extra time to complete your investigations and address the issues that you find.
Start by reviewing the timestamps of the affected files
To review the timestamps of the affected files, you should use the “stat” command on the infected file you already know about.
As you are looking for anomalies, one of the first things you will notice is that the “Modify” and “Change” dates are two days apart. This is because the “Modify” date refers to the content of the file, while the “Change” date refers to the metadata. The “Modify” date is usually the most significant, but take a note of both in case you need to use the “Change” date later in your investigation.
Now compare your timestamps with your logs
Now that you have the time when the content of the file was changed, you can compare it to your logs. The Apache access log is the most common place you will find the information you are looking for (alternatively you may find an upload recorded in the FTP logs or the cPanel logs).
As you are going to see the POST commands, it is best to filter the Apache access log for POST, date, and hour, like so:
It is important to keep in mind that the timestamps will not match up exactly with the log records. The Apache access log records the time the file was accessed at the start of the transaction, while the file system timestamps records when the last transaction was written to the file.
Using the ARIN database and GeoIP to establish phishing content
The likely outcome of filtering the logs in POST, date, and hour order is that several hundred entries like the one below will appear:
There are several indicators of unauthorized activity in this entry. There should not be a PHP file in this directory. There is no referrer link provided for the HTTP/1.0 protocol and, although the request is identified as Googlebot, once the IP address is checked against the ARIN database (http://whois.arin.net/) or the GeoIP Tool (http://www.geoiptool.com/) you will find that it does not belong to Google.
Common hacker tactics can throw you off the trail
Now that you have identified a trail to follow, it should be easy to find the source of the phishing attack – or so you might think. Consequently, when you try to examine the “xXx.php” file through the stat facility, you may get an answer like this:
This indicates that the file has been moved or deleted by the attacker to throw you off the trail. If the file still exists in your system, it should become apparent later on.
If this happens to you, go back to the Apache access log to review the “Change” time you noted earlier. This should give you a link to a different file which has a different IP and user agent. For example:
This file does not appear to be scripted like the previous entry. However, the attacker(s) is POSTing to a file in the theme which is unusual. If you review the contents of the file to see if what was being attempted during the phishing attack, you will get an obfuscated PHP code like the one that appears in the image below:
This PHP code does not necessarily mean that the content is malicious, and you should be able to use UnPHP.net to decode it. Even when the service does not decode it completely, you should be able to extract enough information to establish whether the code is malicious or unsafe.
There are valid reasons for doing this and it could really be part of the theme. You can use UnPHP.net to decode it. While that service doesn’t always completely decode it, usually it will give you enough information to determine whether it is malicious or unsafe.
As we know the file was used by the attacker (because the stat facility was unable to locate the original PHP file), add whatever you discover to your list and keep following the trail using the timestamps and log entries.
Don´t stop until there is nowhere else to look
You should always follow this same process on the “js.php” file. You are likely to find that the process leads to other files to trace, points to a vulnerability in your application or theme, or you could find more files that point back on themselves. You should also filter the logs a little differently to view all the POST’s from any unauthorized IPs that are identified:
By using the above command, you are likely to find something similar to the following:
These results indicate either that a password has been compromised or that there is a vulnerability in WordPress. You could review the logs further to find out which it is or, to save time, apply updates if they are available and reset all administrator passwords.
Continue your investigation with recently modified files and directories
Once you have exhausted the list of known malicious files you have discovered, you need to be a little bit creative to find any remaining items. For this part of the investigation you need to start in the document root directory. Examine the directory structure and the most recently modified files using the following command:
# ls -lrt
You should find directories with the name of a third-party company or directories that do not follow your directory-naming conventions. You should extend your investigation to look for any files with timestamps out of sync with surrounding files. As previously, you will need to examine the content and relevant log entries for any suspicious items you find.
To establish the existence of any phishing content, it is recommended to examine each directory 2 to 3 levels deep from the document root directory. Within each directory examine the directory structure and any contents of the files that appear out of place. If they appear to be malicious, compare them to the Apache access logs and note everything you find.
Finally, you should go back to the root directory and run some targeted searches. Start by searching for any files that have a “Modified” date within the last seven days – assuming you have chosen to deal with a website phishing attack immediately of being informed by your hosting provider. If you have already found malicious content aged older than a week, you may have to go back further in time; but you can narrow the list down using the grep command and filter out files you are already aware of.
It is sometimes useful to investigate files with recent “Change” dates. Most commonly the results will not differ too much from the “mtime” enquiry, but there could be some key findings.
Another enquiry you should conduct is for Symlinks. Symlinks are often used in an attempt to break out of a user’s account. Most websites do not use Symlinks at all and they are almost always safe to remove. You can enquire about the presence of Symlinks by using the following command:
The final enquiry you should make is:
This is a command often used to detect code obfuscation, common with malicious code. This will naturally unearth many items that are valid elements of your site, and you will need to crosscheck each file with the coding and log file access to ensure they are not only valid elements, but safe and protected code.
Remove the malicious files and reset compromised passwords
Once you have completed the investigation, you can start removing the phishing content. Delete any malicious files that have been uploaded and clean any code injected files. Malicious code injections can be cleared using a file editor, and usually you will find the added code on the first or last line of a file.
If you have identified any patterns with the malicious requests in the logs, you can block future unauthorized access with .htaccess rules. For example, if all of the requests were from the same subnet or location you could block them temporarily until you have fully secured your site.
You can now update any applications on your site and repair any insecure scripts you found during the investigation. When updating your software be sure to check for things like Timthumb and TinyMCE as they are frequently overlooked. If you’re running a CMS like WordPress then updating the following is usually enough to repair any issues you find:
- the WordPress core,
- all plugins,
- and themes.
If you have a custom-built website, it is likely you will have found an unsecure upload form during the investigation. You will need to add validation to the script to prevent the form´s misuse in the future. The simplest method of achieving this is to password-protect the form so only you can use it.
De-Listing from a blacklist
Now your website is clean, safe and phishing-content free. However, potential visitors to your website are still seeing a safety warning due to your site being blacklisted. Fortunately, getting de-listed from blacklists is straightforward.
Potential visitors to your website will most likely be warned away by Google’s Safe Browsing. You can use https://www.google.com/safebrowsing/report_error/ to request a de-listing. Google will crawl your website again and check for any issues. If none are found, you should be removed from the blacklist shortly.
Minimizing your website´s vulnerability
The most common mistakes causing website phishing attacks and security issues are the same across the board – unapplied updates, weak passwords, test accounts, and unsecure custom scripts. We mentioned at the top of this article that, despite the measures you put in place, you might again have to deal with a phishing attack. However, the less vulnerable your website it, the less likely it is to be attacked – phishers will simply consider your website too difficult to manipulate and move somewhere else.
Neglected development sites also need to be made secure. If hackers gain access to your development site via a vulnerability, they will also have access to your regular site. If you use a development site – or have used one in the past – do not neglect its security. Ideally all development sites and test accounts should be removed once their purpose has been fulfilled.
In order to minimize your website´s vulnerability and reduce the risk of having to deal with a website phishing attack, take advantage of these helpful hints: