Introduction
Windows systems maintain quite a number of files that are useful from a forensic perspective. In fact, many investigators might not realize the wealth of data they can find within some of the files that Windows systems use to track various activity and functions. Knowing multiple locations where information is maintained within the system allows an investigator to corroborate information that is found in other areas and reduce the amount of uncertainty in their analysis. In this topic, we’ll discuss some of the various files, including log files, you can find on Windows systems as well as information about files in general, along with other specific files that could be of value to an investigator. We will discuss a number of apparently different aspects that are tied together by the fact that they all reside within files or the file system, whether in a human-readable ASCII format or in a cryptic binary format.
Log Files
Windows systems maintain log files for a number of events and actions that may be relevant to an analyst. Besides application log files, which maintain logs of events with respect to specific applications, the Windows operating system also maintains a number of logs. In this topic, we’ll examine the log files most relevant to analysis, the most notable of which is perhaps the Windows Event Log.
Event Logs
The Event Logs are perhaps the most well-known logs on Windows systems, the rough equivalent of syslog on Linux systems. The Event Logs record a variety of day-to-day events that occur on Windows systems and are configurable to record a range of additional events. These events are split into categories that are implemented through the various Event Logs themselves, such as Security, System, and Application Event Logs. The Event Logs can provide a good deal of information that’s useful for troubleshooting issues as well as for understanding events during forensic analysis.
Tip::
On most Windows systems, you can use the Resource Kit tool auditpol.exe to query and set the audit policy. On Windows XP SP2 and 2003 SP1, auditusr. exe allows for per-user audit policies. For example, logon auditing can be set for all users, but more detailed auditing can be enabled for a specific user. Changes made with auditusr.exe modify the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\Lsa\Audit\PerUserAuditing\System Registry key. The use of this tool can give the investigator an indication of the types of events she should expect to see in the Event Log as well as an indication of the technical skill level of the user or administrator.
Understanding Events
On the Windows NT family of operating systems, from Windows 2000 through XP and 2003, the Event Logs consist of a binary structure, with a header and a series of event records stored in the file. Based on the way the operating system was designed, when certain events, such as a user logging on or off, occur, a record of these events is generated.Other aspects of the event log configuration (file size, how long records are retained, etc.) are maintained in the following Registry key:
By default, Windows 2000, XP, and 2003 all have Application, Security, and System Event Logs. Systems that are configured as domain controllers will also have File Replication and Directory Service Event Logs, and systems configured as domain name system (DNS) servers will have DNS Event Logs. Other systems may have application-specific Event Log files, as well.
Administrators are most familiar with interacting with the Event Logs through the Event Viewer, which is a graphical user interface (GUI) manager for the Event Logs. When the administrator views an event record on Windows XP, he will see something similar to what appears in Figure 5.1.
Figure 5.1 Windows XP Event Record Viewed in the Event Viewer
When the Event Viewer opens an event record, it populates the Description: field by reading the strings values from the event record, then locating the appropriate message file (dynamic link library, or DLL) on the system. The message files contain message strings that are used to support internationalization on the Windows operating systems, and the strings values from the event records are inserted into the appropriate locations within those strings. This allows for the internationalization of the Event Logs by providing event message strings in the language native to the system (English, German, French, or the like) and simply "filling in the gaps" with the necessary information (system name, date/time stamp, etc.). This shows a tight correlation among the Event Log, the Windows Registry, and many of the DLLs on the system. It also means third-party applications that write to the Event Log will need to include their own message files.
Prior to Windows 2003, logon events would contain only the NetBIOS name of the system from which the logon originated. Beginning with Windows 2003, the Security Event Log records both the workstation name and the Internet Protocol (IP) address of the system, as Figure 5.2 illustrates.
Figure 5.2 Windows 2003 Event Record Showing IP Address
The information shown in Figure 5.2 (such as Source Network Address) can be extremely useful during an investigation, most specifically because the IP address of the remote system is visible in the event record. This information can be used to determine the source of logons and logon attempts.
Even without the DLL message files it is not difficult to tell what the different event records pertain to, because there is other identifying information in the record. In Figure 5.2, for example, we see an event ID, an event source, and other information we can use to sort on when analyzing event records. There is also a date/time stamp that we can use for timeline analysis; actually, there are two date/time stamps in an event record (as we’ll discuss later in the topic). Microsoft provides a good deal of information regarding some of the event records that you are likely to see. For example, if auditing and logging of logon/logoff events are enabled, the investigator should see event IDs 528 (successful logon) and 538 (logoff) in the Security Event Log. If he sees several event records all with event ID 528, he will want to check the logon type, because there are nine different logon type codes. Table 5.1 lists the various security logon type codes for successful logons and what they mean.
Table 5.1 Event Logon Types
|
Logon Type |
Title |
Description |
|
2 |
Interactive |
This logon type indicates that the user logged in at the console |
|
3 |
Network |
A user/computer logged in to this computer from the network, such as via net use, accessing a network share, or a successful net view directed at a network share. (This has been replaced by Event ID 540) |
|
4 |
Batch |
Reserved for applications that run as batches |
|
5 |
Service |
Service logon |
|
6 |
Proxy |
Not supported |
|
7 |
Unlock |
The user unlocked the workstation |
|
8 |
NetworkClearText |
A user logged on to a network, and the user’s credentials were passed in an unencrypted form |
|
9 |
NewCredentials |
A process or thread cloned its current token but specified new credentials for outbound connections |
Table 5.1 Continued. Event Logon Types
|
Logon Type |
Title |
Description |
|
10 |
Remotelnteractive |
Logon using Terminal Services or a Remote Desktop connection |
|
11 |
Cachedlnteractive |
A user logged on to the computer with credentials that were stored locally on the computer (domain controller may have been unavailable to verify credentials) |
|
12 |
CachedRemotelnteractive |
Same as Remotelnteractive, used internally for auditing purposes |
|
13 |
CachedUnlock |
The logon attempt is to unlock a workstation |
From a more general perspective, Microsoft provides Knowledge Base articles 299475 (http://support.microsoft.com/kb/299475) and 301677 (http://support.microsoft.com/kb/301677) that list Windows 2000 Security Event descriptions. The security events are listed with a brief description as well as placeholders (%1, %2, etc.) where the strings from the event record are inserted.
Tip::
Event ID 540 (network logon) was introduced in Windows 2000 and means the same thing as, and replaces, event ID 528 type 3 (successful logon from the network). Incident responders operating in an enterprise environment may encounter event records that refer to Kerberos, such as event ID 672. Microsoft Knowledge Base article 301677 (http://support.microsoft.com/kb/301677) provides information about these event IDs for Windows 2000, and Knowledge Base article 274176 (http://support.microsoft.com/kb/274176) describes how to associate an account logon event with a process creation event, such as when a service is started with a user account on Windows XP. The event ID 672 records include a client IP address, which may be useful information during an examination.
With Vista and Windows 2008, the logon events were collapsed back down to a single event ID (4624). Microsoft Knowledge Base article 947226 (http://support.microsoft.com/kb/947226) provides a list of security event IDs for Vista and Windows 2008, and describes a method for obtaining more detailed information about events through the use of wevtutil.exe.
For other event records, many sites provide detailed information regarding event record details, why the events are generated, and so on. For detailed information regarding specific entries in the Application Event Log, you might need to check with the vendor. One of the best sites I’ve found for gaining an understanding of what’s in the event records is EventID.net. Some information is available from the EventID.net site without a subscription, but if you’re spending a great deal of time investigating event records of different types, that subscription fee is well worth the additional information and trouble saved in Googling. In many instances, you simply need to provide the event ID in question and you’ll be given information about the event, as generated by various sources, as well as links to references. For example, if I search for event ID 6009, I get four different event sources. From there, I can click the details for the one I want (in this case, the event source is EventLog) and I get commentary from two authors as well as three links to the Microsoft site that provide detailed information regarding the event ID. In this case, in fairly short order, I see that the event ID is generated when a Windows system is booted (so the time that the event record was generated approximates to the time that the system was booted) and that information about the operating system version is written to the Description field of the event.
Tip::
The event ID 6009 record from source EventLog can be used to determine or verify the operating system of the host system as well as the system name. The Computer: entry will contain the host name, and the Description of the event record will contain a string that identifies the version of the Windows operating system.
Besides EventID.net, an excellent source of information on Windows event logging is Eric Fitzgerald’s Windows Security Logging and Other Esoterica blog (http://blogs.msdn.com/ericfitz/default.aspx). Eric’s blog contains a great deal of very useful information regarding Event Logs, including how they can be used to meet Visa’s Payment Card Industry (PCI) compliance standards, as well as auditing tips and tricks. I have found a wealth of information on Eric’s blog, such as a description of logon type 0, as well as how to get detailed security event information for Windows Vista and Windows 2008 Security events. Microsoft also has the Events and Errors Message Center: Advanced Search site (www.microsoft.com/technet/support/ee/ee_advanced.aspx) that you can use to gather information about various Event Log entries.
Tip::
Remember discussing artifacts of USB removable storage devices in next topic? In Windows 2000, whenever a USB removable storage device was connected to a system the Removable Storage Service generated an event record with ID 134. When the device was removed, it generated an event ID of 135. These events are no longer visible as of Windows XP, and Knowledge Base article 329463 (http://support.microsoft.com/kb/329463/en-us) provides a clue as to the reason. The article notes that once the hotfix is installed:
"… Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices."
So, you should not expect to see notifications in the Event Log that USB removable storage devices have been inserted or removed.
Event Log File Format
At times during an investigation you might need to examine the contents of an Event Log .evt file in an understandable format. (The Event Log format discussed in this section pertains to the versions of the Windows operating system from Windows 2000 through 2003, and does not cover Vista.) So, you extract the .evt file from an acquired image, and you figure that you just open the file in the Event Viewer. Or you may try using a tool such as the Event Log Explorer (www.eventlogxp.com/), rather than the native Event Viewer. However, when you attempt to do so, you get an error message telling you that the Event Log is "corrupt." At other times you might be searching through unallocated clusters in an image, looking for some information that could be useful to your case. In either situation, knowing the details of the structure of the Event Log file can be extremely valuable.
The Windows Event Log (for Windows 2000, XP, and 2003) is a binary format with distinct, recognizable features that can assist an investigator in recognizing and interpreting Event Log files or simply event records on a system, either in files or located in unallocated space. Each Event Log consists of a header section and a series of event records, both of which we will discuss in detail. The Event Log is maintained as a circular buffer, so as new event records are added to the file, older event records are cycled out of the file.
Event Log Header
The Event Log header is contained in the first 48 bytes of a valid Event Log file. If the .evt file has not been corrupted in any way, the header will appear similar to the sample Event Log header in Figure 5.3.
Figure 5.3 Event Log Header
The Event Log header consists of 12 distinct DWORD values. Table 5.2 lists nine of those values and provides a brief description of each.
Table 5.2 Event Log Header Structure
|
Offset |
Size |
Description |
|
0 |
4 bytes |
Size of the record; for an .evt file header, the size is 0×30 (48) bytes. Event record sizes are 56 bytes |
|
4 |
4 bytes |
Magic number (LfLe) |
|
16 |
4 bytes |
Offset within the .evt file of the oldest event record |
|
20 |
4 bytes |
Offset within the .evt file to the next event record to be written |
|
24 |
4 bytes |
ID of the next event record |
|
28 |
4 bytes |
ID of the oldest event record |
|
32 |
4 bytes |
Maximum size of the .evt file (from the Registry) |
|
40 |
4 bytes |
Retention time of event records (from the Registry) |
|
44 |
4 bytes |
Size of the record (repeat of DWORD at offset 0) |
The value of importance in the header is the "magic number," which appears as LfLe beginning at the fourth byte (the second DWORD) in the header. This value is unique to the Windows Event Log (for Windows 2000, XP, and 2003) and is associated with event records. Microsoft refers to this value as the ELF_LOG_SIGNATURE. (A description of the event record structure at the Microsoft site states that this is "a DWORD value that is always set to ELF_LOG_SIGNATURE.") Notice that the size of the record (for the header, 0×30,or 48 bytes) brackets the header, appearing at both the beginning and the end of the header record. This allows the investigator to either programmatically (using code) or manually (using a hex editor) locate the header (or an event record), whether looking at an Event Log file, unallocated space, or a file of unknown type. The ID numbers for the next event record to be written and the oldest event record can be used to determine the total number of event records that the investigator should expect to see.
Note
When we’re working with files, we use the term magic number to refer to a specific series of bytes within the file that are unique to that file or file type. These magic numbers are used in performing file signature analysis, a technique used to determine whether a file has the correct file extension based on its magic number. In the case of Event Log files, the magic number is 0x654c664c, or as shown in Figure 5.3, 4C 66 4C 65. Even though this series of bytes translates to the string LfLe when the endianness is reversed, it is still referred to as a magic number.
The values for the maximum size of the Event Log file and the retention time of event records are taken from the Registry of the system where the Event Logs are maintained.
