http://www.microsoft.com/en-us/download/details.aspx?id=24659
참조 : http://technet.microsoft.com/en-us/library/ee692659.aspx
▶ 잘못된 패스워드로 인해 발생하는 실패한 로그온을 추적하는 방법 (체크 필요)
C:\>LogParser “SELECT TimeGenerated, SourceName, EventCategoryName, Message INTO report.log FROM failure.txt WHERE EventID = 528 AND SID LIKE ‘%TESTUSER%'” -resolveSIDs:ON
▶ 웹 서버 로그의 공격 흔적(SQL-Injection 취약성을 이용한 공격 흔적,유니코드 공격)
공격 키워드 : “cmd.exe”, “%”, “..”, “%:”, “$”, “%00”, “%3c”, “%3e”, “%”, “cmdshell”
c:>Logparser “SELECT DISTINCT TO_LOWERCASE(cs-uri-stem) AS URL, Count(*) AS Hits FROM ex*.log WHERE sc-status=200 GROUP BY URL ORDER BY URL” -rtp:-1
▶ 가장 최근에 수정된 파일 로그 찾기
☞ 침해사고 기점으로 수정된 파일을 찾을 경우, 악성코드 및 Webshell을 찾을 수 있습니다.
C:\> Logparser -i:FS “SELECT TOP 20 Path, LastWriteTime FROM *.* ORDER BY LastWriteTime DESC” -rtp:-1
▶ 하루 동안 10번 이상 동일 페이지에 접속을 시도한 클라이언트 IP 확인
C:\> logparser “SELECT DISTINCT date, cs-uri-stem, c-ip, Count(*) AS Hits FROM ex*.log GROUP BY date, c-ip, cs-uri-stem HAVING Hits>10 ORDER BY Hits DESC”
-rtp:-1
▶ 로그 ASP 에러 기록 확인
C:\> logparser “SELECT cs-uri-query, Count(*) AS Total FROM ex*.log WHERE sc-status>=404 GROUP BY cs-uri-query ORDER BY Total DESC” -rtp:-1
참조 : http://www.symantec.com/connect/articles/forensic-log-parsing-microsofts-logparser
Investigating a web-based intrusion can be a daunting task, especially when you have no information other than knowing it was web-based. It is easy to waste precious time digging through megabytes, perhaps even gigabytes, of log files trying to locate suspicious activity. Often this search turns up little useful evidence.
Consider this scenario: an e-commerce site receives several reports from customers about unauthorized orders on their accounts. They suspect that someone has compromised their web-based ordering system so they gather the log files from several different IIS web servers. They have the dates and times of the orders, but the corresponding IP addresses in the log files turn out to be anonymous proxies used by the suspect. Searching for activity from those IP addresses in the log files turns up nothing. Browsing through the raw log files for those dates also turns up nothing. Somehow, someone found a flaw in the ordering system but he or she could have discovered the flaw months before exploiting it. Tracking down the flaw and IP addresses used by the suspect seems impossible. But there are techniques that can facilitate log file forensics. The purpose of this article is to demonstrate log file forensics of IIS logs using SQL queries with Microsoft’s LogParser tool.
IIS Log Fields
The first step is to prepare for security incidents by logging as much information as possible. IIS can log a significant amount of information about each web request, but many of the available log fields are not enabled by default. To enable full logging, open the Internet Services Manager and edit the Extended Logging Properties to include all available log fields. Much of this information has some forensics value as shown in Table 1.
Table 1: IIS Log Fields
| Field Name | Description | Uses |
| Date (date) | The date of the request. | Event correlation. |
| Time (time) | The UTC time of the request. | Event correlation, determine time zone, identify scanning scripts. |
| Client IP Address (c-ip) | The IP address of the client or proxy that sent the request. | Identify user or proxy server. |
| User Name (cs-username) | The user name used to authenticate to the resource. | Identify compromised user passwords. |
| Service Name (s-sitename) | The W3SVC instance number of the site accessed. | Can verify the site accessed if the log files are later moved from the system. |
| Server Name (s-computername) | The Windows host name assigned to the system that generated the log entry. | Can verify the server accessed if the log files are later moved from the system. |
| Server IP Address (s-ip) | The IP address that received the request. | Can verify the IP address accessed if the log files are later moved from the system or if the server is moved to a new location. |
| Server Port (s-port) | The TCP port that received the request. | To verify the port when correlating with other types of log files. |
| Method (cs-method) | The HTTP method used by the client. | Can help track down abuse of scripts or executables. |
| URI Stem (cs-uri-stem) | The resource accessed on the server. | Can identify attack vectors. |
| URI Query (cs-uri-query) | The contents of the query string portion of the URI. | Can identify injection of malicious data. |
| Protocol Status (sc-status) | The result code sent to the client. | Can identify CGI scans, SQL injection and other intrusions. |
| Win32 Status (sc-win32-status) | The Win32 error code produced by the request. | Can help identify script abuse. |
| Bytes Sent (sc-bytes) | The number of bytes sent to the client. | Can help identify unusual traffic from a single script. |
| Bytes Received (cs-bytes) | The number of bytes received from the client. | Can help identify unusual traffic to a single script. |
| Time Taken (time-taken) | The amount of server time, in milliseconds, taken to process the request. | Can identify unusual activity from a single script. |
| Protocol Version (cs-version) | The HTTP protocol version supplied by the client. | Can help identify older scripts or browsers. |
| Host (cs-host) | The contents of the HTTP Host header sent by the client. | Can determine if the user browsed to the site by IP address or host name. |
| User Agent (cs(User-Agent)) | The contents of the HTTP User-Agent header sent by the client. | Can help uniquely identify users or attack scripts. |
| Cookie (cs(Cookie)) | The contents of the HTTP Cookie header sent by the client. | Can help uniquely identify users. |
| Referer (cs(Referer)) | The contents of the HTTP Referer header sent by the client. | Can help identify the source of an attack or see if an attacker is using search engines to find vulnerable sites. |
While I normally recommend logging all fields, the actual fields you choose to log should be based on a balance between forensics capabilities and disk space.
Custom Logging
IIS does provide many log fields, but there may be other fields you wish to record. For example, if the request comes from a proxy server, you may want to see if the proxy server sends the client’s real IP address through other HTTP headers. For example, some proxy servers add the “X-Forwarded-For” header containing the client’s real IP address.
IIS has a limited capability to log custom fields through the Response.AppendToLog method. The limitation, however, is that a new field is not created in the log files, but this data is appended to the URI Query field. To distinguish the two values, you can separate them with a character such as the pipe (“|”). Below is example ASP code to log additional proxy headers:
<%
sHeader= Request.ServerVariables("X-Forwarded-For")
If Len(sHeader) Then Response.AppendToLog "|" & sHeader
%>
Note that other common proxy headers are Forwarded, Client_IP, Remote_Addr, Remote_Host, Forwarded, VIA, HTTP_From, Remote_Host_Wp, Xonnection, Xroxy_Connection, and X_Locking.
Trojan Files
Before we dig in to the actual log files, it may be useful to do a quick check of the newest files on the web site. If the intruder was able to create or modify files within the web content directories, he or she may have uploaded Trojan ASP scripts or executables. You might just get lucky and find these files. The following query lists the 20 newest files on the web site:
C:\>logparser -i:FS "SELECT TOP 20 Path, CreationTime from c:\inetpub\wwwroot\*.* ORDER BY CreationTime DESC" -rtp:-1