Oh, our website was hacked! So what has to be done?

You opened your website in the morning, and it is full of unknown banners, or is it blocked at all? Most likely, it was hacked or infected. Tip #1 — Do not panic, everything is fixable. The main thing is, do not fall into despair, and do not agree to "buy out" your site back (yes, such things also happen). Personally, we do not negotiate with intruders. And we will tell you how to deal with them. :)

 

Who is the saboteur?

 

You would think, what kind of person needs to hack someone's website, spend time and resources on it? For what? Is it just about blackmailing the owner? In fact, the list is much broader. Most often, attackers hack websites to:

• Use it for "phishing", a type of Internet fraud, when accounts, bank card details, and other personal information are stolen from visitors on fake websites.
• Send spam from the hacked site.
• Use the site for malicious activity, DDoS attacks.
• Forward visitors to other sites.
• Or just annoy a competitor by disrupting the operation of their website.

 

Therefore, even the fact that you do not store users' personal data on your site and do not conduct financial transactions will not protect you from coming to the attention of hackers.

 

Symptoms

 

Of course, if the attackers placed their banners on the site or forward visitors to other resources at the entrance, you would probably notice this without additional diagnostics.

 

In addition, if hackers have already managed to "cheat" (send spam, conduct a DDoS attack, etc.), search engines might have blacklisted your site. Google invests lots of resources to fight against malicious sites, so it will quickly track it down and start warning its potential visitors. Of course, this will affect traffic.

 

 

Also, other "symptoms" of a hacked or infected site may be unknown files in the directory and unfamiliar code in the body or files of the site.

 

Finding the reason

 

To identify malicious files and weak points of the site, you can do this:

 

1. Find infected files using an antivirus. The antivirus utilities such as ClamAV and Maldet will cope with this task. If ClamAV is in the system, Maldet will use for scanning not only its databases but also ClamAV databases.

It is crucial to use for scanning a command that will not move files to quarantine. Otherwise, the date of their modification will change, and further "investigation" will not work. The following command will do:

-bash-4.1# maldet --config-options quarantine_hits=0 -a /var/www/
Linux Malware Detect v1.
(C) 2002-2016, R-fx Networks proj@rfxn.com
(C) 2016, Ryan MacDonald ryan@rfxn.com
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 on the computer which you use to manage the site – if the hack was a result of a password leak, a new password may be stolen again after some time.

 

2. Find out the time when the virus was last modified. This can be done using the ls utility (utility for displaying content of catalogs).

Usually, it displays the time of a file's last modification. Attackers could have changed it:

[****]# ls -l class-smtp.php
-rw-r--r--. 1 **** 52078 січ 12 00:41 class-smtp.php

 

And the time of the last file change is fixed. You can find it using the parameter –c:

[****]# ls -lc class-smtp.php
-rw-r--r--. 1 **** 52078 лют 1 10:40 class-smtp.php

 

3. Check the time of the last change with the entries in the webserver logs using the utilities less (a program for reading files) and grep (a string search utility).

You will see something like this:

[****]# 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 off unsuccessful requests (the response from the server is not 200) and requests to the same script. You will get a 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 of the five (in our case) selected scripts may be the cause of infection.

 

Important!

As a rule, attackers hack the site itself, and not the system in which it works. The easiest way to check is to see those to whom the infected files belong. If the same user on whose behalf PHP scripts were run (depending on the system settings, it is either the same user who owns other website files or apache or nobody system users), most likely the hacking occurred as a result of the password leak or vulnerability in the site code.

 

How to "cure" a website

 

After virus detection:

1. Update the CMS of the site and all modules/plugins, as the virus often gets through the holes (vulnerabilities) and not the site.

2. Change passwords for all(!) users of the site and all accounts that are related to the site (access to the FTP server, hosting control panel, etc.). There is a possibility that the virus was able to instill its users into the database and already legally performs any malicious actions.

3. Delete all possible malicious files. This can be done both by manually editing files and using scripts that will delete files and not violate the structure of the site.

4. Restrict access to all directories of the site.

 

Extreme measures

 

If you have failed to "cure" the site, you will have to deploy it from a backup copy. Do you make copies every day? Then such a deployment will not cause any big problems. But if days or even weeks have passed since the last copy, it is a disaster, the loss of critical changes is almost inevitable.

 

Preventive measures

 

The best treatment is prevention. To minimize the risk of hacking:

• Check the site and the virtual machine for viruses.
• Restrict access to the site. Each employee should have exactly the level of access that they need to do the job.
• Never use the username and password that you got by default. Choose your password carefully, use all valid characters and their variations.
• Limit the number of user authorization attempts.
• Take care of regular backups in advance.
• Install plugins that allow protecting your site from hacking, for example, WordFence for WordPress CMS and analogs for other CMS.

 

But the most important rule is to entrust the site management only to professionals.

 

Conclusions

 

A hacked website is not a verdict. The situation is fixable even in the most neglected cases. But prevention is always better than "aggressive" treatment. Therefore, we recommend adhering to basic security rules even before intruders get on your site. And for fast website loading and reliable operation, take care of high-quality hosting for both small and large-scale projects.