Oh, no! Your site has been hacked! What should you do?
In the morning you enter to your site but it is full of alien banners or even locked out? Probably, it has been hacked or infected. Advice No.1 – no panic, as everything can be fixed. First of all, don’t despair and certainly don’t accept an offer to “buy your site back” (as it happens). We don’t conduct negotiations with intruders and we will tell you how to deal with them.
Who is the pest?
Seemingly, who needs to hack someone’s site and to waste time and resources on it? For what purpose? Just to blackmail an owner? In fact, the list is much wider. More often intruders hack sites to:
- Use them for “phishing” – is a type of Internet-cheating, when someone is stealing accounts, bank cards details and other personal data.
- Mail the spam from the hacked site.
- Use them for malicious activity, DDoS attacks.
- Send the users on other sites.
- Annoy a rival, disrupting the work of his site.
That is why, even if you don’t store the personal data of the users on your site and don’t make financial operations it won’t save you from the fraudsters.
The symptoms
For sure, you will notice without any additional diagnostics if the intruders have placed their banners on your site or the visitors are sent to the other resources. Besides, if the hackers have already made harm (send the spam, conduct DDoS attack and so on), probably your site ended up in the search engines’ black list. Google invests huge resources in struggle against pest-sites, that is why it will track your site quickly and start to warn its potential visitors. Of course it will reflect on the attendance.
Also, the symptoms of a hacked or infected site can be unknown files in a folder and a foreign code in the site body or files.
Find the reason
You can detect harmful files and at the same time weak points of the site while doing the following:
Find infected files with a help of antivirus. Antivirus utilities such as ClamAV and Maldet will cope with this task. If ClamAV is in a system, Maldet will be using not only its own bases but also the ClamAV ones at scanning. It is very important for scanning to use a command which won’t move the files into quarantine. Otherwise, the date of their modification will change and fail the future “investigation”. The following command will suit:
-bash-4.1# maldet --config-options quarantine_hits=0 -a /var/www/
Linux Malware Detect v1.5
(C) 2002-2016, R-fx Networks
This program may be freely redistributed under the terms of the GNU GPL v2
maldet(5719): {scan} signatures loaded: 11294 (9343 MD5 / 1951 HEX / 0 USER)
maldet(5719): {scan} building file list for "/var/www/", this might take awhile...
maldet(5719): {scan} setting nice scheduler priorities for all operations: cpunice 19 , ionice 6
maldet(5719): {scan} file list completed in 0s, found 6624 files...
maldet(5719): {scan} found clamav binary at /usr/bin/clamscan, using clamav scanner engine...
maldet(5719): {scan} scan of "/var/www/" (6624 files) in progress...
maldet(5719): {scan} processing scan results for hits: 1 hits 0 cleaned
maldet(5719): {scan} scan completed on "/var/www/": files 6624, malware hits 1, cleaned hits 0, time 26s
maldet(5719): {scan} scan report saved, to view run: maldet --report 170223-1010.5719
maldet(5719): {scan} quarantine is disabled! set quarantine_hits=1 in conf.maldet or to quarantine results run: maldet -q 170223-1010.5719
Important!
Check for viruses the computer used to administrate your site – if the hack is made in the result of a password leak, a new password can be stolen again after a while.
2. Find out time when the virus has been changed for the last time. It can be done with a help of Is utility (a utility for a catalogue content withdrawal).
Usually, time of the last file modification is displayed. The intruders could change it:
[****]# ls -l class-smtp.php
-rw-r--r--. 1 **** 52078 dec 12 00:41 class-smtp.php
But time of the last file change is fixed. You can find it out with a help of parameter - c:
[****]# ls -lc class-smtp.php
-rw-r--r--. 1 **** 52078 feb 1 10:40 class-smtp.php
3. Cross-check time of the last change with the notes in web-server’s logs, using utility Less (the program for file reading) and Grep (the utility for line search).
It will be the following way:
[****]# less remoteoffice.****.log-20170202.gz | grep POST | grep -E ":10:(3([789])|40):"
93.124.244.82 - - [01/Feb/2017:10:39:50 +0200] "POST /wp-content/plugins/LayerSlider/tmp/file65.php HTTP/1.0" 504 183
"http://****/wp-content/plugins/LayerSlider/tmp/file65.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
184.168.152.197 - - [01/Feb/2017:10:39:59 +0200] "POST /wp-includes/SimplePie/Decode/HTML/dir.php HTTP/1.0" 200 64
****/wp-includes/SimplePie/Decode/HTML/dir.php" "Mozilla/5.0 (X11; U; Linux i686; en-US) U2/1.0.0 UCBrowser/9.3.1.344"
37.255.128.50 - - [01/Feb/2017:10:40:03 +0200] "POST /wp-includes/SimplePie/Decode/HTML/dir.php HTTP/1.0" 200 82
"http://****/wp-includes/SimplePie/Decode/HTML/dir.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
184.168.193.197 - - [01/Feb/2017:10:40:06 +0200] "POST /wp-content/plugins/contact-form-7/languages/dump.php HTTP/1.0" 200 57 "http://****/wp-content/plugins/contact-form-7/languages/dump.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
23.91.70.65 - - [01/Feb/2017:10:40:08 +0200] "POST /wp-includes/fonts/global.php HTTP/1.0" 200 62
"http://****/wp-includes/fonts/global.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
97.74.24.221 - - [01/Feb/2017:10:40:14 +0200] "POST /wp-content/themes/Avada/fusion-icon/alias72.php HTTP/1.0" 200 60 "http://****/wp-content/themes/Avada/fusion-icon/alias72.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
50.62.177.78 - - [01/Feb/2017:10:40:16 +0200] "POST /wp-includes/js/jquery/css6.php HTTP/1.0" 200 92
"http://****/wp-includes/js/jquery/css6.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
45.40.164.132 - - [01/Feb/2017:10:40:17 +0200] "POST /wp-content/plugins/LayerSlider/tmp/file65.php HTTP/1.0" 499 0
"http://****/wp-content/plugins/LayerSlider/tmp/file65.php" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
4. Cut unsuccessful requests down and also requests to one and the same script. It’ll be the list:
184.168.152.197 - - [01/Feb/2017:10:39:59 +0200] "POST /wp-includes/SimplePie/Decode/HTML/dir.php HTTP/1.0" 200 64
"http://****/wp-includes/SimplePie/Decode/HTML/dir.php" "Mozilla/5.0 (X11; U; Linux i686; en-US) U2/1.0.0 UCBrowser/9.3.1.344"
184.168.193.197 - - [01/Feb/2017:10:40:06 +0200] "POST /wp-content/plugins/contact-form-7/languages/dump.php HTTP/1.0" 200 57 "http://****/wp-content/plugins/contact-form-7/languages/dump.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
23.91.70.65 - - [01/Feb/2017:10:40:08 +0200] "POST /wp-includes/fonts/global.php HTTP/1.0" 200 62
"http://****/wp-includes/fonts/global.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
97.74.24.221 - - [01/Feb/2017:10:40:14 +0200] "POST /wp-content/themes/Avada/fusion-icon/alias72.php HTTP/1.0" 200 60 "http://****/wp-content/themes/Avada/fusion-icon/alias72.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
50.62.177.78 - - [01/Feb/2017:10:40:16 +0200] "POST /wp-includes/js/jquery/css6.php HTTP/1.0" 200 92
"http://****/wp-includes/js/jquery/css6.php" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
Each out of five (in our case) selected scripts can be the reason of infection.
Important!
As a rule, the intruders hack the site itself but not the system where it operates. The simplest way to check is to have a look at the owner of the infected files. If they belong to a user who ran PHP-scripts (depending on a system settings, it can be either the same user whom another web-site files belong to, or system users Apache or Nobody), more likely the hack has happened as a result of a password leak or a vulnerability of a site code.
How to “cure” the site
After viruses’ detection:
1. Renew CMS of the site and all modules/plugins, as very often a virus gets to the site through the gaps.
2. Change the passwords for all (!) users of the site and all accounting records, which deal with the site (access to FTP-server, hosting control panel and so on). There is a possibility that the virus has already implemented its users into the data base and now quite legally performs any malicious actions.
3. Delete all possible malicious files. It can be done using manual files editing as well as with a help of scripts which will delete files and won’t break the site structure.
4. Restrict the access to all directories of the site.
Extreme measures
If you still can’t “cure” the site, you have to restore it from a backup. Do you make backups every day? So, such opening won’t be a problem. But if from time of the last backup copying have passed days and even weeks, it is very bad as the loss of important changes is almost inevitable.
Prevention
The best treatment is prevention. To minimize the risk of a hack:
- Check the site and virtual machine on viruses on a regular basis.
- Restrict the site access. Every employee should have only that access level he/she needs to do his/her work.
- Never use login and a password which you got by default. Chose the password thoroughly, use all permitted symbols and their variations.
- Restrict the number of user authorization attempts.
- Take care of qualified and regular backup in advance.
- Install plugins which allow to protect the site from hacks. For example WordFence for CMS WordPress and analogues for other CMS.
But the main rule is to verify the site management only to professionals.
Conclusions
Hacked site is not a verdict. The situation can be solved even in the worst cases. But prevention is always better than “aggressive” treatment. That is why we recommend to stick to the elementary security rules before the intruders have an eye on your site. So, for quick site loading and its reliable work take care of high-quality hosting for small as well as for large-scale projects.
No Comment