Internet Logs | Windows Forensics: The Field Guide for Corporate Computer Investigations

Windows servers log access information on individual requests that arrive through their respective services. Connections to and activity on FTP, HTTP, and SMTP (the main Internet Information Server services) are frequently used in forensic examinations of server use or compromise. The logging for these is turned on by default when the service is started and can provide a wealth of information on Internet-based system activity.

WINDOWS XP FIREWALL LOGS

Windows XP firewall, available with Service Pack 2 (SP2), provides logging capabilities that are turned off by default. To enable logging in SP2:

From the Run dialog box type firewall.cpl.
Open the Advanced tab.
Click the Settings button under Security Logging.
Select both dropped packets and successful connections.
Close the firewall Control Panel.

Logging by default (when enabled) is done to a file under the %SYSTEMROOT% directory called pfirewall.log and can provide details on attacks on or connections to a Windows machine. The log can also provide more detailed information on outbound connections from a particular machine, including HTTP connections that are not deleted when the Temporary Internet Files directory is cleaned. These logging capabilities have actually always been present and are a capability of the underlying Internet Connection Firewall. The SP2 firewall just makes it easier to turn on and log relevant events.

Here is a sample log:

 #Version: 1.5 #Software: Microsoft Windows Firewall #Time Format: Local  #Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 2033 40 S 3955587749 0 2048 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 117 40 S 3955587749 0 3072 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 624 40 S 3955587749 0 3072 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 1516 40 S 3955587749 0 4096 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 684 40 S 3955587749 0 1024 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 1667 40 S 3955587749 0 3072 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 27000 40 S 3955587749 0 4096 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 126 40 S 3955587749 0 1024 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 392 40 S 3955587749 0 2048 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 518 40 S 3955587749 0 4096 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 859 40 S 3955587749 0 2048 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 227 40 S 3955587749 0 4096 - - - RECEIVE 2005-03-22 12:59:55 DROP TCP 10.100.177.123 10.100.177.126 34577 572 40 S 3955587749 0 4096 - - - RECEIVE 2005-03-23 09:35:41 OPEN TCP 10.100.177.126 209.247.228.201 1422 80 - - - - - - - - - 2005-03-23 09:35:41 CLOSE TCP 10.100.177.126 209.247.228.201 1421 80 - - - - - - - - 2005-03-23 09:36:34 OPEN UDP 10.100.177.126 151.197.0.38 1069 53 - - - - - - - - 2005-03-23 09:36:34 OPEN TCP 10.100.177.126 10.24.101.134 1423 3389 - - - - - - - - - 2005-03-23 09:37:24 OPEN-INBOUND TCP 10.243.100.134 10.100.177.126 2652 3389 - - - - - - - - -

The preceding log displays both inbound and outbound traffic that is successful in navigating the firewall (that is, it is permitted to go through) as well as unsuccessful (that is, dropped). Several interesting items are ascertainable from the preceding logs. First, there are numerous dropped packets originating from the same machine and trying to connect on random ports, indicative of a port scan. In this case they were generated by an nmap portscan from machine 10.100.177.123. The source of attacks can be identified using this information as it could from any other firewall log. Second, outbound connections are logged. The connection from the local machine to 209.247.228.201 (http://www.playboy.com) indicates the individual on the local machine may have been viewing inappropriate information. Finally, successful connections on port 3389, both inbound and outbound, show Remote Desktop Connection was used successfully to connect to and from this particular machine.

Automated tools are now being developed to aggregate information from the XP firewall logs. A simple tool, FirelogXP, is shown in the following figure. By aggregating source and destination data, the tool can easily identify port scanning, filter activity to a specific IP, and show only data of interest. In the example that follows , only outbound traffic is shown.

Because of the utility in the XP Firewall logs for forensics and other activities such as identifying spyware, the default client builds should turn on logging by default on SP2 machines.

Firewall fraffic originating from the suspect's machine

HTTP Logs

Internet Information Server (IIS), Microsoft's built-in web server, is one of the most commonly used on the Internet (second to Apache) and even more common on intranets .

Note	Technically, IIS refers to all of Microsoft's Internet Information Services, not just the web server, but common usage equates IIS with the specific HTTP service and associated ASP services.

The web logs for IIS websites are stored by default under %SYSTEM-ROOT%\System32\Logfiles\W3SVC, and each date is provided its own log file (although dates with no accesses will have no log file). Administrators may change the directory for performance and back-up reasons as well as the file cycling frequency.

Note	If multiple web servers are present, each will have its own W3SVC directory suffixed with a unique number.

The default log file settings contain several key fields that are indicated at the start of the file (shown under the #Fields metadata for the example file that follows). The key fields of interest in an examination are:

Date and time (date time). The date and time, listed in GMT unless an offset is included, is the current time on the server when a request was made. If a website defacement occurs, look at the first request after the defacement. Many times an attacker will use a shell account from a compromised machine to launch an attack, and then view their handiwork from their home machine.
Server IP (s-ip). The IP address of the server that the request was made to. When multiple server IPs are logging to a single file, this will help differentiate where the request (or attack) was directed against.
Method (cs-method). The HTTP method used. For pages disappearing or appearing, PUT or DELETE methods from WebDAV may be present. GET requests to a form will contain the query string sent to the form (but POST requests will not). TRACK and TRACE methods show up with Cross-Site Scripting attacks.
URL (cs-uri-stem). The URL, sans the fully qualified domain name and query string, is shown in this field. The page requested and its associated directory are listed here.
Query string (cs-uri-query). The query string sent to a form is shown in this field. Any query string containing SQL characters should be suspect as a potential SQL Injection attack.
Port (s-port). The port (usually 80 or 443) a web connection was made on.
User name (cs-username). The user name that made the request. Only valid on local Windows domain requests and not generally available outside an Intranet.
IP address (c-ip). The most important piece of information in the log file, the IP address is the location from which a particular request came. The IP address is the single most important piece of information in tracking down an attack source.
User agent [cs(User-Agent)]. The browser used to make a request is listed. Attack tools such as Nikto, Nessus, and ISS may show user agents indicating the tool as a source. Similarly, the operating system used to launch an attack may be present in the user agent.

Request status (sc-status and sc-substatus and sc-win32-status). The code returned by the web server is shown in the status field. Table 11-3 lists common status codes.

Table 11-3: HTTP Response Codes
CODE	DESCRIPTION
100	Client should continue request. Not generally shown in web logs, but may appear on sniffer results.
200	OK. The page was found and returned to the client.
301/302/307	Page moved. The client requested a page that has since been moved. A request to the main directory without a file name will generate a 30 x request, as will an old link.
401	Access to a file for which the client is not authorized was requested. Repeated 401 log items may indicate enumeration attempts.
403	Access to a file which is forbidden was made. Requests for common directory names in 403 errors may indicate enumeration tools were used.
404	Not found. 404 messages can be indicative of bad links, but also enumeration attempts (if the files are commonly named, from the same IP).
500	Server error. Buffer overflow attacks may generate server error messages.
501	Method not implemented. TRACK/TRACE requests or WebDAV requests may show failed cross-site scripting activity attempts.

Referer (cs-Referer). The Referer is not included by default with several log formats but should be added to all web logs for forensic use. The field shows the previous site visited before the server in question, giving a possible homepage location or additional clue to the identity of an attacker. The referring site can include a query string as well, useful if the previous site was a search engine.

HTTP LOG SAMPLE

This sample log shows multiple requests from a client on IP address 192.168.1.113 on the date of 9/4/2003.

 #Software: Microsoft Internet Information Services 6.0 #Version: 1.0 #Date: 2003-09-04 00:34:01 #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs- username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status 2003-09-04 00:34:01 192.168.1.113 GET /students/default.aspx - 80 - 146.186.240.68 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+Q312461;+.NET+CLR+1 .1.4322) 302 0 0 2003-09-04 00:34:02 192.168.1.113 GET /login.aspx ReturnUrl=%2fstudents%2fdefault.aspx 80 - 146.186.240.68 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+Q312461;+.NET+CLR+1 .1.4322) 200 0 0 2003-09-04 00:34:02 192.168.1.113 GET /images/Horizontal.gif - 80 - 146.186.240.68 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+Q312461;+.NET+CLR+1 .1.4322) 200 0 0

Detailed analysis may be difficult on large log files, where a quick summary analysis can be used. A summary analysis, using tools like WebTrends or Analog can quickly parse out areas of interest and highlight potential issues. The reports of interest from these include:

Browser report. Scanning tools like Nessus may show up in the Browser report, as shown in Figure 11-4.

Figure 11-4: Browser report showing a Nessus scan
Directory report. Requests for non-existent or protected directories will be visible in this report.
Failure report. Failed web page requests are shown, including those which indicate enumeration attempts.
Status code report. The majority of requests should have a status code of 200. Other status codes with large numbers indicate server problems or hacking attempts.
Usage reports. Denial-of-service attacks or attempts and scans may show up as usage spikes in the general usage reports.

CROSS SITE SCRIPTING AND SQL INJECTION

Two of the most common exploits of web-based applications are cross-site scripting attacks and SQL Injection attacks. Cross-site scripting gathers information from unsuspecting users by carefully crafted URLs that exploit application issues. SQL Injection attacks attempt to read or delete or alter database information through web application which use poor input validation and detailed error message information.

Cross-site scripting relies on poor parsing of input on a system to steal cookies from a user, execute malicious code on his or her behalf , or launch a denial-of-service attack. A modification of this attack, dubbed cross-site tracing (XST), makes use of the TRACK and TRACE HTTP methods present in IIS to echo malicious code back to a client, done as part of the method itself. URLScan, a Microsoft add-on for IIS, protects against this particular type of cross-site scripting attack by disabling these methods.

The forensic examiner looking for evidence of a website being used for cross-site scripting attacks has two places to look: the method and the query string. If cross-site scripting attacks are used as part of the method, a TRACK or TRACE request will be seen, frequently with an associated HTML tag or tags (the <SCRIPT> tag being the most common). If a GET request is used, the <SCRIPT> tags will be found in the query string itself. Because any legitimate web application should filter out HTML tags (or better yet restrict input to only allowed values), the mere presence of these tags in a web log indicate attempted or actual exploitation of cross-site scripting at the worst or a poorly coded application that is potentially vulnerable to cross-site scripting at the best.

SQL Injection attacks use escape characters, string termination characters, or other SQL commands to interact with an underlying database in unplanned for ways. Like cross-site scripting attacks, SQL Injection relies on poor input validation. Applications that pass values users type into forms directly to database queries are the most vulnerable. A typical SQL injection may show a user entering text such as:

 ' OR '1'='1

into a text field meant to capture names, addresses, or other innocuous information. A subsequent query, such as:

 SELECT * FROM TBL_USERS WHERE NAME=' & fieldvalue & ';

becomes:

 SELECT * FROM TBL_USERS WHERE NAME='' OR '1'='1'

Instead of returning a single value, all user values are returned. Different databases are subject to different syntax variations, but common characters include single and double quotes, SQL commands such as SELECT, DROP, UPDATE, DELETE, and INSERT, and other special characters like semicolons, colons, and commas. These values should be disallowed by an application but may not be if it is poorly coded.

(Both client and server-side debugging should be turned off on production servers, as they may reveal information on the sites underlying code. A generic "Server Error" message should be returned instead. While this does not prevent SQL Injection attacks, it makes them significantly more difficult to exploit using techniques such as Blind SQL Injection.)

Searching the HTTP logs for GET requests with any of the previously mentioned terms in a query string is a good indication that a SQL Injection attack was attempted and potentially successful against a website.

To evaluate the likelihood of success of a SQL Injection or cross-site scripting attack, the investigator can reconstruct the attack string by putting the URL stem together with the query string (separated by a question mark) and typing that into a web browser following the site name. The testing should ideally be done on an isolated staging server configured the same as production to prevent damage to the production database or revealing information inadvertently as part of the testing.

To test TRACK-or TRACE-based attacks, the TRACK and TRACE information can be sent using a Telnet client to port 80. A simple test of reflection using Track and Trace should return a 200 status code. A simple OPTIONS request may show a false positive. The PuTTY SSH client in RAW mode is an excellent tool for doing this. An example of the values returned in a successful TRACE is shown in the following listing.

Unfortunately, POST requests will not reveal the information sent in the log files, but they are not undetectable. A large number of POST requests to the same URL from the same IP address which generate 400 or 500 level return codes is a good indicator some type of application-level attack may be occurring. Connecting a sniffer or using an application profiler or detailed application-level logging can reveal more information on these attacks.

 OPTIONS / HTTP/1.1 HOST: foo.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Tue, 29 Mar 2005 18:06:12 GMT MS-Author-Via: DAV Content-Length: 0 Accept-Ranges: none DASL: <DAV:sql> DAV: 1, 2 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK Cache-Control: private TRACE / HTTP/1.1 HOST: foo.com

In addition to the standard weblogs, a final place to look for web reporting is the HTTPERR directory, under %SYSTEMROOT%\System32 on Windows 2003 machines. IIS 6, included with Windows 2003, runs its application server ASP.Net as a separate process. Errors with the application server are sent to specific logs in the previously mentioned directory. Since only errors are logged, buffer overflow attempts or illegal requests are easier to pinpoint than in a crowded IIS HTTP log file.

Tip	When viewing logs and other fixed-format items, use a fixed-width font such as Courier New to line up the columns correctly.

FTP Logs

Similar to HTTP logs, FTP logs record successful and failed File Transfer Protocol interactions. Stored in the %SYSTEMROOT%\System32\MSFTPSVC### subdirectory (where ### is a unique number), the FTP service logs include connections, attempted connections, and commands used when connected. FTP logs are frequently reviewed for two types of attacks: attempts to connect and file creation/deletion for unauthorized users. Additionally, authorized user actions may need to be recorded.

Attempted connection. Attempted connections will appear with a status code (sc-status) of 331 on a USER command followed by 530 on a PASS command. 331 indicates that a user name has been entered and a password is requested. 530 indicates a password authentication failure. Common findings may use password guessing or anonymous account attempts (user name is anonymous; password is email address by convention). The example FTP log here shows an attempt with the account name FTP, then anyone , followed by multiple attempts with the account name root (the name for the administrator account on most Unix systems). The attack shown is likely untargeted and using an automated tool from source IP 10.70.37.249.
```
 #Software: Microsoft Internet Information Services 6.0 #Version: 1.0 #Date: 2004-07-26 23:15:03 #Fields: time c-ip cs-method cs-uri-stem sc-status sc-win32-status 23:15:03 10.70.37.249 [40]USER ftp 331 0 23:15:03 10.70.37.249 [40]PASS ftp@ftp.net 530 1326 23:15:03 10.70.37.249 [41]USER anyone 331 0 23:15:03 10.70.37.249 [41]PASS - 530 1326 23:15:12 10.70.37.249 [42]USER root 331 0 23:15:12 10.70.37.249 [42]PASS - 530 1326 23:15:12 10.70.37.249 [43]USER root 331 0 23:15:12 10.70.37.249 [43]PASS - 530 1326  23:15:14 10.70.37.249 [44]USER root 331 0 23:15:14 10.70.37.249 [44]PASS - 530 1326 23:15:14 10.70.37.249 [45]USER root 331 0 23:15:14 10.70.37.249 [45]PASS - 530 1326 
```
Attempted or successful creation of files. Many scanners attempt to find open FTP sites to use as repositories for movies, music, pornography, or warez. After connecting successfully (with a 230 status code), an attempt will be made to create a file (with a code of 226 if successful) or a directory (with a code of 257 if successful). Failed attempts will show a 550 error code. Here is an example session of file creation and subsequent deletion:
```
 15:37:48 10.221.41.8 [436]USER anonymous 331 0 15:37:56 10.221.41.8 [436]PASS - 230 0 15:38:46 10.221.41.8 [436]created /test.txt 226 0 15:38:52 10.221.41.8 [436]DELE test.txt 250 0 15:39:02 12.221.41.8 [436]MKD test 257 0 
```
Authorized user activity. Authorized users can take unauthorized actions on an FTP server, or perform authorized actions that need to be proven at a later date. Authorized users will connect first with a USER command having status 331 including their user names. Searching the file for their user names will turn up the start of activity. Next, a PASS command, with a valid 230 response code will be returned. Following that will be the valid user activity, and a final log-out QUIT command and a 550 status code or a Closed message with a 421 status code if the session was closed by timeout.

CASE STUDY: PHISHING

One of the civil matters that often arise on the Internet is trademark infringement, frequently as part of another criminal action. Websites claiming to be something they are not may be used for generating fraudulent transactions, perpetuating misinformation , or most commonly phishing for personal information to facilitate identity theft.

A large banking client of ours became fed up with websites impersonating their online client portal. Phishers would send out spam messages requesting that users update their passwords or other personal information and embed links purporting to be at the banking site. In reality, the links used numerous techniques to bury the real destination and hide the fact that users clicking them would be redirected to compromised hosts , which were used to serve up similar-looking web pages to the client's portal. Unlike the portal, individuals logging into the fake site would have their user name and password stolen, along with any other personal information (such as social security number) they entered.

Investigations into one of the more sophisticated phishing sites revealed the actual sites were hosted on individual user's machines which had been hacked by the actual identity theft ring. The machines would come up and down frequently, and traces only turned up home machines used as one hop in a chain of machines and became dead ends without a warrant to trace further. Likewise, the e-mail messages directing users to the site were from compromised machines acting as spambots and the DNS entries for the sites made with stolen accounts.

Because the sites needed to maintain the look and feel of the actual website, they needed to visit the real portal site to steal the graphics and underlying HTML. Examining one of the phishing sites revealed a modification date of several weeks earlier on an image from a less-used secondary page, shown only after logging in. The image in question matched almost exactly an image from the actual portal.

To trace the user, we analyzed the IIS HTTP logs from the portal site. The image we were looking for had only been accessed one time within hours of the modification date listed. Because the image was only viewable after authentication, we looked up the IP address in the backend application server log to reveal which specific user session it was identified with. Doing so revealed the account name and personal information of the downloader. It turned out that the individual established a legitimate account with the bank to understand how the site worked.

Through civil means, the bank was able to successfully go after the individual for trademark infringement based on their use of the bank's look and feel. A subsequent criminal investigation for the identity theft was also enacted by law enforcement and is currently ongoing.

SMTP Logs

Microsoft's SMTP server logs details on all messages sent or received, successful or otherwise . Unfortunately, the default log settings capture little information: the commands typed, the IP address the connection was from/to (with no indication of direction), and the status codes. Although somewhat useful in showing a connection was made to a particular server at a particular point in time, the information is still limited.

The example that follows shows a connection to an SMTP server from 192.168.1.1. The connection starts with a HELO command, introducing the connecting server. Following is a MAIL FROM command, indicating the sender of the message, and a RCPT TO command, indicating the recipient of the message. Next, a DATA command starts the message text itself, and finally a QUIT command terminates the connection. As noted previously, little can be determined forensically from the log here except a connection between 192.168.1.1 and the local server was made at a particular time and successfully completed the commands that follow (250 is a success code and 240 a successful termination code):

 #Software: Microsoft Internet Information Services 6.0 #Version: 1.0 #Date: 2005-03-30 17:20:09 #Fields: time c-ip cs-method cs-uri-stem sc-status 17:20:09 192.168.1.1 HELO - 250 17:20:15 192.168.1.1 MAIL - 250 17:20:21 192.168.1.1 RCPT - 250 17:20:27 192.168.1.1 DATA - 250 17:20:30 192.168.1.1 QUIT - 240

To be forensically useful, several additional fields can be added in IIS Administrator to the SMTP logs if the W3C format is chosen , specifically , the date, time, c-ip, cs-username, cs-method, and cs-uri-query fields. The date and time are self-explanatory. The IP represents the address of the machine to which the server is connected. If it is inbound, there will be no OutboundCon-nection message in the user name field; instead, the domain reported in the HELO message will be shown. The cs-method and cs-uri-query fields show what command was typed and with what detail. Although the data itself cannot be seen in the logs, the source and destination can. The following example that follows shows a successful attempt to exploit an open relay from machine 10.221.41.8 to send a message to a http://www.yahoo.com account. The message is successfully received, then relayed to the Yahoo! mail server at 10.28.114.35 10 minutes later:

 #Software: Microsoft Internet Information Services 6.0 #Version: 1.0 #Date: 2005-03-30 18:27:06 #Fields: date time c-ip cs-username cs-method cs-uri-query 2005-03-30 18:27:06 10.221.41.8 foo.com HELO +foo.com 2005-03-30 18:27:13 10.221.41.8 foo.com MAIL +from:+hacker@foo.com 2005-03-30 18:27:18 10.221.41.8 foo.com RCPT +to:+csteel@yahoo.com 2005-03-30 18:27:34 10.221.41.8 foo.com MAIL +from:+hacker@foo.com 2005-03-30 18:27:34 10.221.41.8 foo.com RCPT +to:+csteel@yahoo.com 2005-03-30 18:27:34 10.221.41.8 foo.com DATA <CMSSWEByt3cew8k69RK00000015@cmssweb> 2005-03-30 18:27:34 10.221.41.8 foo.com QUIT foo.com 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionResponse - 220+YSmtp+mta151.mail.dcn.yahoo.com+ESMTP+service+ready 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionCommand EHLO cmssweb 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionResponse - 250- mta151.mail.dcn.yahoo.com 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionCommand MAIL FROM:<hacker@foo.com>+SIZE=415  2005-03-30 18:37:00 10.28.114.35 OutboundConnectionResponse - 250+sender+<hacker@foo.com>+ok 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionCommand RCPT TO:<csteel@yahoo.com> 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionResponse - 250+recipient+<csteel@yahoo.com>+ok 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionCommand DATA - 2005-03-30 18:37:00 10.28.114.35 OutboundConnectionResponse - 354+go+ahead 2005-03-30 18:37:01 10.28.114.35 OutboundConnectionResponse - 250+ok+dirdel 2005-03-30 18:37:01 10.28.114.35 OutboundConnectionCommand QUIT - 2005-03-30 18:37:01 10.28.114.35 OutboundConnectionResponse - 221+mta151.mail.dcn.yahoo.com