Through what hole hacked the site?

If the site is hacked, it is not enough to remove the virus and downloaded PHP Shell from it. We still need to find the reason for the hacking, otherwise in a day or two the beautiful Turkish foreign flag will flutter on the site again with vigorous music. The most common cause is a stolen FTP password, an outdated version of the CMS or a plugin for it, but how to find out what exactly was used for penetration?

Having some experience in this area (on average, our technical support is looking for the reason for hacking the site once a week), we systematized the accumulated information.

So why bother hacking sites at all? And what if the site is hacked, how to find the cause and protect against subsequent attacks?

Why hack sites

The process of hacking sites is now on stream. Botnets use known exploits to popular CMS, hack sites, install their scripts on them and can use the hacked site for any purpose. Viruses steal FTP passwords, connect to sites and infect them with viruses, which in turn infect site visitors, after which the circle repeats. Most often after hacking the site the following occurs:

1. Site deface. This can be called, rather, mischief, things often do not go beyond deface.
2. Infection of the site pages with a virus. Viruses can be as simple as being added to the end of each page of the site, and to be quite sophisticated. For example, we encountered a virus that infected a specific Joomla class that is responsible for displaying data in the browser.
3. Search for other sites in neighboring folders and their infection.
4. Spamming.
5. Download PHP Shell and perform arbitrary actions - for example, an attempt to hack a server using existing exploits to operating systems.
6. Installing bots that connect to the IRC server and can execute arbitrary host commands — for example, produce DDoS from other sites.

That is, the actions of hackers are aimed at the further distribution of bots, the creation of a network (botnet) and its further use for their own purposes.
')

Algorithm for finding the cause of hacking

The algorithm itself is very simple:

1. Find traces of hacking.
2. Determine the exact time of hacking.
3. According to the logs to find how exactly broke the site.

The complexity of the implementation of paragraphs 1 and 3. We will focus on them in more detail.

How to look for traces of hacking

Tracking almost always leaves traces: files that the attacker used to work, for example, PHP Shell. The classic way of hacking CMS:

1. Download PHP Shell through any vulnerability (or get CMS administrator access via the vulnerability and download PHP Shell through the file manager).
2. Through PHP Shell do the rest.

Therefore, the first step is to look for such files - files that obviously do not belong to the site. As a rule, downloaded scripts are called rather unusual and stand out among their own CMS scripts:

• wzxp.php
• gwd.php
• a10881d.php.2046

The result of an exploit running to hack a server might look like this:

• ./w.sh
• ./env
• ./env.c
• ./program.c
• ./program.o
• ./w00t.so.1.0
• / tmp / sh
• / tmp / sh2

These files can be located either in the root of the site or in the tmp / or cache / folder. You should also search for them in folders like images /, upload /, user_files /, etc. - often through vulnerabilities in editors or photo libraries, scripts are loaded into the place where photos are usually loaded or temporary files are stored.

In addition to the site files, you should also check the common / tmp server - it may contain temporary files used for hacking or launching bots.

Be sure to take a look at the .htaccess file - it can add redirects to other sites that spread the virus. In this case, the .htaccess file can be placed both in the root of the site and above, so do not be lazy to look at all the directories of your account.

In other words, it is necessary to look for all the unusual / incomprehensible and look inside all suspicious files. PHP Shell might look like this:

<?php #v2.3 //Version
$auth_pass = ""; //75b43eac8d215582f6bcab4532eb854e
$color = "#00FF66"; //Colour
$default_action = "FilesMan";
$default_charset = "Windows-1251";
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65
\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7b1tVxs50jD8OXvO9R9Er3fanhhjm2Q2Y7ADIZCQSSAD5
GUC3N623bZ7aLs93W0Mk+W/31Wll5b6xZhkdq/7OedhJtDdKpVKUkkqlapK3rDM1tzJLL4tl7qn+ycf90/
// ... base64

Key points to pay attention to in PHP scripts:

• Co0lHaZZkeR style of writing text.
• The presence of the words Exploit and Shell.
• The presence of a large amount of code in base64.
• The presence of eval () or the function preg_replace () with the / e key in the first argument.

In the end, you can simply go to the browser and see what this script does.

Files can also be searched manually, but faster, if a hack has occurred recently, use the find command:

# find ./public_html -mtime -3d
# find ./public_html -mtime -10h

(find syntax specified for FreeBSD). These commands will show files that have changed in the last three days and the last 10 hours, respectively.

If all else fails, you can simply search for all files that contain base64-encoded content, for example:

# find ./ -name '*.php' | xargs grep -E '[0-9a-zA-Z/]{80}'

This command will find all PHP scripts that contain lines that are similar to base64 with a length of at least 80 characters.

Break time determination

When files are found, it is very easy to determine the time of hacking - just look at the time when the earliest file was modified.

If no suspicious files are found, but the site is infected with a virus, look at the date of the change of the index.php, index.html files or those in which you find a virus. Most likely in this case, the site was hacked, stealing the password from FTP.

Search logs hacking site

Now the most important thing is for these magazines to be available!

If a site only has a deface or a virus has been added to all index.html files, the site is most likely hacked through theft of the FTP password (or, much less often, SSH). View FTP and SSH connection logs during hacking - the presence of unknown IP addresses or a large number of different IP addresses that made a successful connection to the site means that the password has been stolen.

In this case, it is enough to check the computers from which the site was accessed for viruses, change FTP passwords and never save passwords in FTP clients again.

If the site contains PHP Shell or malicious scripts (for example, to send spam), most likely the site was hacked through a vulnerability in CMS or any of its plugins. In this case, you will need to analyze the web server logs.

To better understand what needs to be looked for, consider how a CMS is hacked.

1. The attacker determines that the site has CMS installed or its plug-ins, or other software (outdated Joomla, phpMyAdmin, WYSIWYG editor, photo gallery, etc.) potentially vulnerable to vulnerabilities.
2. He begins to sort out known exploits for this software. The goal - in any way upload your file to the site.
3. When a vulnerability is found, the cracker downloads PHP Shell.
4. Having connected to PHP Shell, the hacker gets full access to the site and can then use it for any purpose.

An important point - download PHP Shell. In the previous section, we determined the time at which malicious scripts were uploaded to the site. Now it suffices to find references to them in the web server log. In this way we will be able to determine the IP address of the attacker. This can be done with a simple grep in access.log by the name of the PHP Shell file.

If you managed to determine the IP address

Having determined the IP address of the hacker, we search for this IP address using the web server log and see all the actions that he did. Somewhere close to accessing PHP Shell, the site vulnerability will be successful.

If the determine the IP address failed

The method described above works if you know the specific name of the file through which the work with the site was performed after hacking. However, this name is not always known. In this case, you will have to look for the moment of hacking a little longer, but you can still find it.

Most, the overwhelming majority of hacks are peculiar to HTTP POST requests, as they are used to upload files to the hacked site. Through POST, an attacker can also attempt to crack a password entry form or simply enter the administration section with a stolen password.

If you know the time of hacking the site (and we already know it), it is necessary to search in the web server log all POST requests that are close to the time of the hack. There are no specific tips here - they can look completely different, but they will look unusual anyway. For example, it may be queries containing '../../../../' or long queries containing file names or SQL queries.

If nothing could be found

This can also be. In this case, you can only recommend a clean reinstall of the CMS and its extensions and the subsequent import of data. Be sure to make sure that the version of the CMS and its extensions is the latest.

And its extensions! Most often, hacks are not made through the core of the site management system, but through some obsolete plugin, the author of which abandoned its development a long time ago.

Well, of course, change all the passwords that have any relation to the site.

Mistress note

• In the process of searching for vulnerabilities on the site, if it is not possible to block access to it for visitors, block at least POST requests. This will prevent the use of most standard exploits.
• Do not use outdated versions of CMS and plugins to them. Stay tuned!
• After determining the cause of hacking, do not limit yourself to deleting the found scripts - the penetration points added by the attacker can be well hidden. The best scheme for recovering a site after hacking is to close access to it for visitors, find the reason for hacking, restore the site from a backup (we exclude any site changes that an attacker could have done), update the CMS, making sure that the vulnerable component was also updated, after which open access to the site again.