Chapter 11: Log File Analysis

The two areas of Microsoft logging of most interested to the forensic examiner are the standard log repository for system, application, and security events (Event Log), and the key Internet serverbased log files (HTTP, FTP, and SMTP). The Event Log details provide insight into what a given user was doing on a machine or what the machine itself was doing. The Internet server log files show what remote activity was attempted or successful on a given system.

Event Logs

Microsoft's answer to Syslog, event logs retain key log event details on Windows systems. The event logs are broken into three areas: application logs, which store information on individual applications; system logs, which maintain operating system event details; and security logs, which hold data on logins/logouts and other security functions.

The standard mechanism for viewing event logs is to use the Microsoft Event Viewer. Event Viewer can be invoked by typing eventvwr from the command prompt on Windows NT/2000/XP/2003 systems. Event Viewer uses the MMC interface to display information on both remote and local logs. By default, the local event logs are viewed . EVT files from other machines can be imported for viewing by selecting Action Open Log File. The log file format is common amongst Window NT versions and a Windows XP analysis machine will be able to open EVT files generated on another system) or viewed remotely with administrative rights by selecting Action Connect to Another Computer.

Tip 

The logs are sortable by clicking the column headings. Note that the Event ID column sorts as a text field, not a number field, so Event ID 21 will appear after Event ID 1000.

Event Viewer has two other capabilities that are useful to an examiner: filtering and exporting. Filtering, available by selecting View Filter, narrows the displayed contents of a particular log file to only the time period or event types relevant to a particular investigation. The example of the Filter displayed in Figure 11-1 will show only Warning and Error events from January, 2005. Both Success and Failure audits should be logged, indicating whether an action such as a login or installation was successful. A common mistake is to log only failed events.

Figure 11-1: Virus infection details

EVENT LOG CORRUPTION

When copying the event logs from a running system, it is often desirable not to stop the event logging services. Stopping to create a forensic copy may involve a reboot and any activities that occur in the interim may go unaccounted for. Because Windows marks the files as open while event logging is running, a direct copy will result in corrupted files that cannot be directly opened on the evidence machine. Fortunately, Windows knows how to self-repair these files when the appropriate steps are taken.

1. Copy the event logs from a system (from %Systemroot\system32\config) and create a read-only, forensically sound copy).

2. Boot a clean analysis machine running Windows XP.

3. Open Services on the analysis machine and change the startup properties of the Event Log service to Disabled.

4. Reboot the machine. The machine needs to be rebooted to actually stop the service in a sound manner. Rebooting also unlocks the analysis machine's log files to allow their renaming in the next step.

5. Rename the AppEvent.evt, SysEvent.evt, and SecEvent.evt files on the analysis machine to include a .fbak extension (for forensic backup).

6. Copy the evidentiary EVT files to the %Systemroot\system32\config directory.

7. Open Services on the analysis machine and change the startup properties of the Event Log service to Automatic.

8. Reboot the analysis machine and run Event Viewer. The logs should be repaired automatically by Windows.

The event logs will now be viewable and not treated as corrupt by the operating system. At this point, the event logs can be analyzed as ordinary event logs, with one exception. There may be additional entries generated by the new system. These should be time-differentiated from the suspect's machine as well as system name delineated. These can and should be filtered (right-click on a log, select properties, and then Filter).

The corrupted copy remains the copy of record. The repaired logs become a working copy. Exports from the repaired copy can be used as evidence in court as long as the actions used to arrive at the final results are appropriately documented.

 

Tip 

To help in identifying installed and previously installed applications, use the Event Source drop-down list box on the filter. It will show any application that has generated an application log event. Category is especially useful with security logs in showing only log-on and log-off information.

The second function is Export. Although Event Viewer offers extensive capabilities, the need to export log files does arise. There are two basic types of export: exporting of the log file in the Event Viewer format for viewing on a remote system and exporting to text format. To save the log file itself and prevent the corruption which occurs when the file is copied directly from the open EVT file, choose Action Save Logfile As and use the default EVT format. For nonEvent Viewer analysis, the contents can also be exported as text (comma or tab delimited) by choosing Action Export List. Text-based logs are useful for raw string searches or importing into programs for more detailed manipulation, such as Excel.

Tip 

A Windows XP machine should be able to read Windows NT/20002003/XPgenerated log files. For even quicker results, run an XP virtual machine under Microsoft Virtual PC.

Application Log

Application logs are used by individual applications. Microsoft permits third parties to write application events through its APIs. In practice, few applications use this capability, but many antivirus and installer programs do.

The application log can be used to assist with the following common tasks from a forensic standpoint:

• Confirm installation of software. Installation of a particular software package is indicated by Event ID 11707 for successful and 11708 for unsuccessful installations if Microsoft Installer is used. Event 11724 indicates a product was removed. By viewing these events, the time a piece of software was installed or a user attempted to install it can be noted, as well as the removal time (for example, when a suspect was tipped off).

• Confirmation/Refutation of virus Infection. Most of the major antivirus software vendors generate an Event ID 5 event when a virus is detected . If a user is making the "a virus did it" claim, it can be shown that antivirus was running, was up-to-date, and no alerts were generated at the time of the claim by viewing the antivirus software event details. Similarly, a found virus event can prove an infection was present and could have had specific ramifications at a given time. A sample infection notice from Symantec is displayed in Figure 11-2.

  
  Figure 11-2: Sample application log filtering

• Startup/Shutdown of firewalls. On Windows XP, the Windows Security Center service is logged to Event Viewer when a user opens it for the first time in a given session. The service startup can be indicative of a user starting, stopping, or changing firewall settings for the Windows XP SP2 firewall.

• Detection of hacking attempts. Many hacking attempts exploit buffer overflows or similar attacks which can cause an application to fail. Applications with Event IDs 1000-1004 show up as errors in the Application log and could indicate exploitation through that application, especially if the application has an associated network listener or interface. Event ID 4097 may indicate similar activity and may indicate the presence of a Dr. Watson debugging log.

Other application log events are highly dependent on the specific applications installed on a particular machine and their independent use of the Event Log service. If an application does not use the Event Log service, it may still have a proprietary local log file. Even if it does use the Event Log, it may supplement that with local logging. Always check program directories for application-specific local logs in addition to those in the application log.

System Log

Events generated by the operating system itself are captured in the system log. Any actions taken automatically or user-driven actions that directly utilize the underlying operating system will be logged, including software and hardware installations, print jobs, and network-level events.

The system events relevant to an investigation are varied and specific to the allegations posed. Some of the more common investigation areas covered by the system log include:

• Event Log start/stop. Event ID's 6005 and 6006 represent the Event Log service starting and stopping, respectively. Individuals looking to hide their actions may stop the Event Log service, but the most likely cause of these events is a system shutdown. Look for other 6008/6009 events in the immediate vicinity to verify a legitimate shutdown.

• System shutdown/restart. Event ID 6008 indicates an unexpected shutdown, and 6009 the associated restart. Event ID 6009 is generally preceded by a 6006 event to stop the Event Log service. 1074 is used to show the process which initiated a shutdown, and 1076 (on Windows 2003) shows the reason provided for the shutdown.

• Detection of hacking attempts. Many hacking attempts exploit buffer overflows or similar attacks that can cause an application to fault. Similar to the events in the application log, Event ID 26 in the system log may indicate a successful buffer overflow attempt. Event ID 1001 indicates a memory dump was performed and will list the location of the dump file.

• Service Pack update/installation. Showing a particular patch was installed at a particular time can be useful in refuting claims of infection or exploit by malware. Event ID 19 shows successful installation of an automated patch. Event ID 4377 shows specific package hotfix installations. The initial Windows installation with build number should be one of the first listed events ( assuming log recycling has not occurred) with an event ID 60054.

• Log-on failures. Network log-on failures, such as those generated by FTP, show up in the system log. Event ID 100 indicates a failure to authenticate against a known account, and a series of these events may indicate password guessing or a brute force tool use.

• Alteration of machine information. Event ID 6011 denotes a system name change. Investigations into a particular machine name that does not match with existing information should look for this ID to indicate a potential change of name after an event occurred.

• Printing. If the machine in question is acting as a print server, the jobs printed and their source will be listed as Event ID 10. The originating machine for the request is not shown, but the user name of the requestor is. In Figure 11-3, the user Administrator printed out a map from http://www.mapquest.com on March 24th at 2:34 P.M.

Figure 11-3: Printing event

Security Log

The security log is the mother of all logs in forensic terms. Log-ons, log-offs, attempted connections, and policy changes are all reflected in the event contained therein. Unfortunately, security logging is turned off by default. It needs to be enabled by Group or Local Policy to be useful. To support later investigations, the Audit Policy under the Local (or Group) Policy should be enabled for the following actions at a minimum:

Audit account log-on events	Success, Failure
Audit account management	Success, Failure
Audit log-on events	Success, Failure
Audit policy change	Success, Failure
Audit privilege use	Success, Failure

These major categories will cover 95 percent of the security events analyzed in an investigation. The impact of further auditing needs to be weighed against system performance and disk storage issues. Although it would be useful, from a forensic standpoint, to audit all file access, the practical implications of doing so make it infeasible.

Tip 

The overhead associated with file access auditing does not mean that no file access should be audited . The company's key intellectual property shares (if they can be isolated) should have auditing enabled and regularly reviewed at a file-level.

Most important to an investigation are log-on and log-off events. These are essential to proving who performed an action on a computer at a particular time. Both failed and successful log-ons are relevant, and other security events support specific investigations. The main event types of use to an investigation are detailed in the next sections.

Successful Log-on/Log-off Events

Successful log-on events are used to show who performed a particular action. Interactive log-on events are characterized by Event ID 528, with a subcategory defining the log-on type. Table 11-1 lists the key log-on types frequently encountered .

Table 11-1: Log-on Types

LOG-ON ID	TYPE	DESCRIPTION
2	Local	Interactive, local log-on to the machine itself.
3	Network	Connecting to a computer across the network.
7	Unlock	Unlocking a computer (which has been locked by pressing Ctrl+Alt+Del or through automatic screen locking).
10	RDC	Connecting using Remote Desktop Connection or Terminal Services.
11	Cached	Logging in locally when a domain controller is unavailable and used the cached user credentials.

Most of the log-ons encountered of interest will be of type 2 indicating a local log-on. Showing an individual used remote access to connect can be done with Type ten log-ons. Connections across a network (for example, via FTP) will appear as type three log-ons, though connecting to or viewing a network share is a different Event ID540. Predicting when a user came back from lunch (or reengaged his or her notebook in the morning) can be had with logons of type 7.

Log-offs are also of interest. They bound the time an individual was connected. Log-offs are slightly less reliable for time as there can be events that force a log-off that is not recorded such as power outages. Depending on the amount of data logged, the failure event time may be able to be calculated based on the lack of log entries for a specific period. Log-off events are initiated with a 551 Event ID for user-initiated log-offs and completed with a 538 Event ID.

Remote Desktop Connection events can be bounded by connection types other than log-offs as well. Disconnects leave the user logged in but detach the actual terminal machine from the server. Reconnects re-attach and are accompanied by log-on events. The disconnection is an Event ID of 683 and the subsequent reconnection a 682.

Note 

Windows 2003 started recording the source of the log-on/log-off events for network-based connections. Prior versions of Windows recorded only the local workstation name.

Failed Log-on Event

Failures to log on are one of the best indicators of password guessing or bruteforce attacks on a system. Failed attempts are logged based on the reason for failure: wrong password or user name (Event ID 529; may be a hacking attempt), account is disabled or expired or locked (Event IDs 531 and 532 and 539, respectively; could be password sharing or disgruntled former employees ), or the user tries to log in to a resource to which he or she is not permitted access (Event ID 533; possible unauthorized access).

Unfortunately, failed log-ons also occur in large numbers for legitimate reasons. Users forget passwords, automated tools are misconfigured, and Caps Lock keys are accidentally depressed, making it difficult to separate out malicious log-on failures. In generally, malicious failures will be more numerous in nature, will be closer together (if an automated tool is used), and may show failures to multiple account names (from the same source machine).

Change of Policy

Changing of the audit policy ( specifically removing the auditing of certain events) is indicative of a hacking attempt or root kit installation. Event ID 612 is a change of audit policy. Any change from prior 612 Event ID entries that show a removal (minus sign) of policy that was previously present (plus sign) should be questioned.

Successful or Failed Object Access

Auditing for specific NTFS files and folders can be turned on using the Advanced button on the Security tab within the particular object's properties. Enabling auditing on an object can log anything from attempted reads of that object to successful deletion of that object. If this level of auditing is enabled, it can show when a given entity was accessed and by whom and when a file or folder was changed or deleted, or highlight unauthorized access attempts on key objects. The events associated with individual objects are detailed in Table 11-2.

Table 11-2: Object Access Events

EVENT ID	EVENT NAME	DESCRIPTION
560	Object Open	Attempts to open a file or directory (for reading or direct access) generate Event ID 560. Both failed and successful attempts generate the same ID. Attempted deletion may show up as a large number of 560 Failures.
564	Object Deleted	Successful deletions of files or folders show up as Event ID 564. The file or directory deleted will be shown in the most recent Event ID 560 preceding the 564 event which has the same process ID.
567	Object Access Attempt	The attempt to open an object for access shows up as Event ID 567 on Windows 2003 systems. This can indicate opening the file itself or its metadata.

Account Change

Changes to an individuals account settings may be the result of malicious activity. Event ID 642 indicates an account settings change. Event ID 628, the most common follow-up event, indicates that the password and a particular account were changed.

Log Clearing

An Event ID of 517 indicates the security event log was cleared. There is no corresponding event for clearing the application or system logs. Clearing the security log is almost never done without saving the old log to a file for legitimate reasons, but may indicate an intruder covering his or her tracks. A search for EVT files or a text search for common Event ID wording on the drive may turn up old Event Viewer details if the log was saved before deletion.