Tracking attackers through WEB Log Security Analysis

This article mainly describes the ideas and common skills in WEB log security analysis, and describes the Security Events in the event of a complete instance, how to track attackers by analyzing WEB logs and combining other clues.

WEB logs, as an important part of the WEB server, detail the access requests from the client to the WEB application and the running status of the server during the running of the server. Similarly, attackers may intrude into the website, which is recorded in WEB logs. Therefore, during daily website operations and security emergency response, we can analyze WEB logs and track attackers and restore the attack process based on other situations.

WEB Log Structure

Before conducting security analysis on WEB logs, we need to first understand the structure of WEB logs. There are two common types of logs supported by mainstream WEB servers:

1. NCSA log format used by Apache, 2. W3C log format used by IIS.

The NCSA log format is classified into NCSA common log format (CLF) and NCSA extended log format (ECLF). Which one can be defined in the WEB server configuration file. Apache also supports custom log formats. You can customize the log format in the configuration file. For example, in Apache, you can modify the httpd. conf configuration file to implement 1.

Figure 1

Next let's look at an Apache access log:

192.168.1.66--[06/Sep/2012: 20: 55: 05 + 0800] "GET/index.html HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; rv: 15.0) Gecko/20100101 Firefox/15.0"

The specific explanation is as follows:

192.168.1.66: IP address of the client

[06/Sep/2012: 20: 55: 05 + 0800]: Access time and server time zone

GET: The data packet submission method is GET. Common types include GET and POST.

/Index.html: the URL accessed by the client

HTTP/1.1: Protocol Version Information

404: Status Code of the WEB server response. 404 indicates that the file does not exist on the server, 200 indicates that the response is normal, and 500 indicates that the server error occurs.

287: number of bytes transmitted during this access

Mozilla/5.0 (Windows NT 6.1; rv: 15.0) Gecko/20100101 Firefox/15.0: client browser and system environment information.

You can configure the IIS access log format and storage path in IIS manager, as shown in figure 2.

Figure 2

3 is the W3C extended log format of IIS.

Figure 3

It is worth noting that the access time in the W3C log format of IIS adopts Greenwich Mean Time, which is 8 hours different from that in Beijing and cannot be modified.

WEB log security analysis principles

Based on the above knowledge, we know that WEB logs record client access requests to WEB applications, including normal user access requests and malicious behavior by attackers. So how can we distinguish between normal users and malicious attackers? Through a large number of analyses, we found that when attackers intrude into the website, the requests sent to the website contain specific attack characteristics, for example, WEB scanners often generate a large number of 404 error logs when scanning websites for vulnerabilities, as shown in figure 4.

Figure 4

When an SQL injection vulnerability is detected on a website, the following logs are usually displayed in the WEB access log, as shown in Figure 5:

Figure 5

Therefore, we can identify the access behavior of attackers and normal users by analyzing whether there are specific attack features in WEB logs.

However, WEB access logs are not omnipotent, and some attacks are not recorded in WEB access logs. For example, POST-SQL injection is not recorded in WEB access logs. In this case, we need to monitor such attacks by other means.

WEB Log Security Analysis ideas

When conducting security analysis on WEB logs, you can follow the two ideas below to gradually deepen the attack process.

1. First, determine the time range of attacks and intrusions. Take this as a clue to search for suspicious logs within the time range for further troubleshooting. Finally, determine the attacker and restore the attack process. 6.

Figure 6

2. After attackers intrude into a website, they usually upload a backdoor file to facilitate future access. We can also use this file as a clue for analysis. 7.

Figure 7

WEB log security analysis skills

WEB log files are usually large and contain a wealth of information. When we perform security analysis on WEB logs, we usually only focus on logs containing attack characteristics. Other logs are useless to us. At this time, we can extract the log content that we pay attention to by hand or by using tools for separate analysis to improve efficiency. Several frequently-used commands in log analysis include "find", "findstr", "grep", and "egrep". You can find relevant information on the usage of these commands.

1. Extract the logs with the data submission method "GET", 8

Figure 8

The preceding Command finds the log content with the GET character from the iis. log File and saves the result to iis_get.log. Expected result 9 is displayed.

Figure 9

2. check whether there is any attack behavior using the IIS write permission vulnerability in WEB logs. 10.

Figure 10

3. Because manual log analysis is time-consuming and inefficient. Therefore, the author developed a WEB log security audit tool to automate WEB log security analysis. You can go to workshop.

Figure 11

Figure 12

Instance analysis

We have talked about some of the techniques that are often used in WEB Log Security Analysis. Now we use an instance to fully understand how to track attackers by analyzing WEB logs, and restore the attack process.

Background

On a certain day, the website server's webcatalog contains a file named shell.php.jpg. After checking the file content, it is found that the file is a WebShell file, which is often referred to as WebShell. As a result, it is suspected that the website has been hacked. Then, the website administrator analyzes WEB logs and, in light of other situations, successfully traces the attacker and restores the entire attack process. In this process, we also discovered security vulnerabilities on the website, fixed the vulnerabilities in time afterwards, and conducted a comprehensive security test on the website, improving the security of the website.

Analysis ideas

According to the current information analysis, we know that a suspicious file exists in the WEB directory. We will take this file as a clue to first find out which IP addresses have accessed the file, then, further investigate the operations performed on these IP addresses, and finally confirm the attackers and their attack methods.

Analysis Process

1. First, find the WebShell file that exists, that is, the WebShell file mentioned above. It was found that the file was created on July 13, February 7, 2013.

Figure 13

2. Let's first find out which IP addresses have accessed this file. You can use the following command to extract the relevant log Content, 14 and 15.

Figure 14

Figure 15

3. We can confirm that only 192.168.1.2 has accessed the file. This IP address is very suspicious. Next we will look for the operations on this IP address, 16 and 17.

Figure 16

Figure 17

4. From the above log, we can see that this is a typical SQL injection. After further analysis, attackers can use SQL injection to obtain the website administrator account and password.

192.168.1.2--[07/Mar/2013: 22: 50: 21 + 0800] "GET/leave_show.php? Id = 40% 20and % 201 = 2% 20 union % 20 select % 20 unhex (hex (concat (0x5e5e5e, group_concat (id, 0x5e, user, 0x5e, pwd, 0x5e, userclass, 0x5e, loginip, 0x5e, logintimes, 0x5e, logintime), 0x5e5e5e), 0, 0, 0, 0, 201 0% 20 from % 20 (select % 20 * % 20 from % 20 (select % 20 * % 20 from % 20 admin % 20 where % 1% = 201% 20 order % 20by % 20 limit % 201,100) % 20 t % 20 order % 20by % 201% 20 desc) t % 20 -- HTTP/1.1 "200 18859"-"" Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; server Load balancer ;.. net clr 2.0.50727; Media Center PC 5.0 ;. net clr 3.0.04506 ;. net clr 1.1.4322 )"

5. Then the attacker successfully enters the website background using the obtained account. For details, see the following log:

192.168.1.2--[07/Mar/2013: 22: 51: 26 + 0800] "GET/mywebmanage/web_manage.php HTTP/1.1" 200 5172 "http: // 192.168.1.107/mywebmanage/"" Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2--[07/Mar/2013: 22: 51: 44 + 0800] "POST/mywebmanage/check. php HTTP/1.1 "200 47" http: // 192.168.1.107/mywebmanage/web_manage.php "" Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2--[07/Mar/2013: 22: 51: 45 + 0800] "GET/mywebmanage/default. php HTTP/1.1 "200 2228" http: // 192.168.1.107/mywebmanage/check. php "" Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

6. Then attackers access the add_link.php page, which is a page for Adding links, 18.

Figure 18

Attackers can obtain a WebShell by using Apache Parsing Vulnerability. For details about Apache parsing vulnerability can view the author of an article (http://secsky.sinaapp.com/89.html), this vulnerability has a detailed description.

192.168.1.2--[07/Mar/2013: 22: 53: 40 + 0800] "GET/mywebmanage/link/add_link.php HTTP/1.1" 200 3023 "http: // 192.168.1.107/mywebmanage/LeftTree. php "" Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2--[07/Mar/2013: 22: 54: 50 + 0800] "POST/mywebmanage/link/add_link_ OK .php HTTP/1.1" 200 77 "http: // 192.168.1.107/mywebmanage/link/add_link.php "" Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2--[07/Mar/2013: 22: 55: 48 + 0800] "GET/link/shell.php.jpg HTTP/1.1" 200 359 "-" "Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2--[07/Mar/2013: 22: 55: 54 + 0800] "POST/link/shell.php.jpg HTTP/1.1" 200 132 "http: // 192.168.1.107/link/shell.php.jpg "" Mozilla/5.0 (Windows NT 6.1; rv: 19.0) Gecko/20100101 Firefox/19.0"

7. Now we can understand the Attack Process of the attacker. The details are as follows:

Combined with the Apache parsing vulnerability, the WebShell is obtained successfully.

Analysis Process summary

Through the security analysis on WEB logs, we not only tracked attackers, but also detected website vulnerabilities. Next, we should delete the backdoor files uploaded by attackers, fix existing security vulnerabilities, perform comprehensive security detection on the website, and reinforce the security of the WEB server, prevent this type of security event from happening again