IIS logs that cannot be ignored
In the ever-evolving network, network security has gradually attracted everyone's attention. After the emergence of an endless stream of network services, various attacks targeting their services will follow, however, as these attacks and defenses continue to improve, we often forget the importance of logs. Through understanding the log files, we can know the attack methods and system vulnerabilities to prevent them. Some people say that using IDS can replace daily security management to prevent hacker intrusion, but in fact IDs cannot completely replace security management. Just check the log file, we can find out What IDs missed, from which we can find what IDs didn't notice. Comparing the current intrusion methods, we can find that most of the current methods are for Web Services, and we will introduce them from IIS log files, let everyone know how to analyze hacker intrusion from the log aspect.
Most of today's Web Service intrusions use vulnerabilities in website programs to obtain webshells and intrude hosts, we can use Windows IIS logs to obtain hacker intrusion methods and related operations. The default directory of IIS logs is % SystemRoot %/system32/logfiles/. The log file name is run by date, and the record format is recorded by the W3C standard, the log format is date/time/IP Address/access action (get or post)/accessed address/Access Port/access IP address. However, the access status indicates that 200-299 indicates that the access is successful, and 300-399 indicates that the response from the client is required to meet the request. 400-599 indicates that the client and the server are faulty, respectively, 404 and 403 are the resources we usually see that cannot be found and the access is limited.
I. Information Collection
When the Server opens the IIS service, it will receive different access requests. How can we analyze what is caused by intruders? The common intrusion method is Information Collection (step-by-step). Intruders use a scanner to scan open services on the target host and sensitive server information, in this way, a large number of scanning records will be left during IIS scanning. In the following IIS logs, we can see that the scanner leaves a scan record for port 80.
16:30:28 192.168.111.1 head/scripts/.../../winnt/system32/cmd.exe/C + dir 80-192.168.111.2-404 0 64
16:30:28 192.168.111.1 head/scripts/.../../winnt/system32/cmd.exe/C + dir 80-192.168.111.2-404 0 64
16:30:28 192.168.111.1 head/scripts/.../.././winnt/system32/cmd.exe/C + dir 80-192.168.111.2-404 0 64
16:30:28 192.168.111.1 head/scripts /.. /.. /.. /.. /.. /.. /winnt/system32/cmd.exe/C + dir 80-192.168.111.2-404 0 64
16:30:29 192.168.111.1 head/scripts /.. /.. /.. /.. /.. /.. /winnt/system32/cmd.exe/C + dir 80-192.168.111.2-404 0 64
According to the above logs, we can find that the IP address of 192.168.111.2 is constantly sending access requests to the CGI directory (IIS is scripts, Apache is cgi-bin) of IIS, all these are targeted at the current popular CGI vulnerabilities. From this, we can know that these are not normal access requests, but the vulnerability scans by intruders on the server's IIS before the intrusion, at this time, we must pay attention to the program security of our iis cgi directory.
Ii. intrusion trace analysis
When a website is infiltrated and no trojans left by intruders are found in the file, how can I use IIS logs to find intruders?
17:16:58 192.168.111.1 get/dbm6.asp action = showfile 80-192.168.111.2
17:17:00 192.168.111.1 post/dbm6.asp-80-192.168.111.2
17:17:00 192.168.111.1 get/dbm6.asp action = mainmenu 80-192.168.111.2
17:17:00 192.168.111.1 get/dbm6.asp action = showfile 80-192.168.111.2
17:17:03 192.168.111.1 post/dbm6.asp-80-192.168.111.2
17:17:03 192.168.111.1 get/dbm6.asp action = mainmenu 80-192.168.111.2
17:17:06 192.168.111.1 get/dbm6.asp action = showfile 80-192.168.111.2
From the above we can see that the intruder 192.168.111.2 uses dbm6.asp for operations, so as to use a specific Trojan program to intrude into the host and browse the host file to control each file of the host. IIS records the operations performed by each user, allowing the Administrator to easily analyze each action and the cause of each event. That's why we can find the clues behind intruders! Just like the popular bypass intrusion method, with tools, the program can perform completely automatic intrusion. First, the program will continuously scan the website for uploading pages, then, use the vulnerability upload page to upload webshell! We can see from the following information:
14:41:11 127.0.0.1 get/BBS/upfile. asp 404
14:41:11 127.0.0.1 get/data/dvbbs7.mdb 404
14:41:11 127.0.0.1 get/databackup/dvbbs7.mdb 404
14:41:11 127.0.0.1 get/upfile. asp 404
14:41:11 127.0.0.1 get/BBS/down_addsoft.asp 404
14:41:11 127.0.0.1 get/down_addsoft.asp 404
14:41:11 127.0.0.1 get/BBS/down_picupload.asp 404
14:41:12 127.0.0.1 get/down_picupload.asp 404
14:41:12 127.0.0.1 get/dvbbs/upfile. asp 404
14:41:12 127.0.0.1 get/FORUM/upfile. asp 404
14:41:12 127.0.0.1 get/upfile_soft.asp 404
14:41:12 127.0.0.1 get/upload_soft.asp 404
14:41:13 127.0.0.1 get/BBS/down_picupfile.asp 404
14:41:13 127.0.0.1 get/BBS/z_visual_upfile.asp 404
Users are constantly scanning the upload page. Based on such operation traces, we should begin to notice whether the website has become the target of attacks intended by intruders.
Iii. remote attacks
The IIS service is vulnerable to internal and external attacks. Among the many remote attacks, WebDAV remote overflow is classic! I used this vulnerability to intrude into many hosts! First, let's talk about the WebDAV remote overflow vulnerability:
WebDAV is a component in IIS. Iis5 provides support for WebDAV by default. WebDAV can provide users with remote file storage services through HTTP.
The WebDAV component contained in IIS 5.0 uses NTDLL. some functions in DLL, which do not fully check the data transmitted to some system components. Remote attackers exploit this overflow vulnerability to launch a buffer overflow attack on WebDAV through malformed WebDAV, you can use this vulnerability to obtain the system-authorized shell.
When intruders exploit this vulnerability, they will record the relevant overflow code in the IIS log, because the length of the link will no longer exist! From the record, we can know that intruders use code to think of the system shell. We can check the relevant accounts and other logs to determine if they have been intruded!
From information collection and internal and external attacks, we can know that when Intruders use port 80 for intrusion, our IIS logs will record a lot of them, so that we can learn and analyze the techniques and traces! To make our system more secure, we should never underestimate an IIS log in the zone. It is a good helper for us in terms of management and security, we hope to make good use of every aspect of the system's log records, from which we can see the system's security and health problems! I am a newbie in network security and still lacks maturity in writing and analysis. If you have any mistakes, please point out! Thank you!