File Analysis (Windows Forensic Analysis) Part 2

Event Record Structure

Event records have some structure values in common with the Event Log header, but event records contain much more information, as illustrated in Figure 5.4. However, the basic header for an event record is somewhat larger than the header of the Event Log itself (as described above), weighing in at 56 bytes. Although the record size provided in the event record (0xF4, or 244 bytes) is larger than 56 bytes, the first 56 bytes of the event record constitute an event record header.

Figure 5.4 Sample Event Record Structure

As you can see, the Event Log magic number appears in the second DWORD value of the event record, just as it does for the header. Table 5.3 provides details of the content of the first 56 bytes of an event record.

Table 5.3 Event Record Structure

Offset	Size	Description
0	4 bytes	Length of the event record, or size of the record in bytes
4	4 bytes	Reserved; magic number
8	4 bytes	Record number
12	4 bytes	Time generated; measured in UNIX time, or the number of seconds elapsed since 00:00:00 1 Jan 1970, in Universal Coordinated Time (UTC)
16	4 bytes	Time written; measured in UNIX time, or the number of seconds elapsed since 00:00:00 1 Jan 1970, in UTC
20	4 bytes	Event ID, which is specific to the event source and uniquely identifies the event; the event ID is used along with the source name to locate the appropriate description string within the message file for the event source
24	2 bytes	Event type (0×01 = Error; 0×10 = Failure; 0×08 = Success; 0×04 = Information; 0×02 = Warning)
26	2 bytes	Number of strings
28	2 bytes	Event category
30	2 bytes	Reserved flags
32	4 bytes	Closing record number
36	4 bytes	String offset; offset to the description strings within this event record
40	4 bytes	Length of the user Security Identifier (SID); size of the user SID in bytes (if 0, no user SID is provided)
44	4 bytes	Offset to the user SID within this event record
48	4 bytes	Data length; length of the binary data associated with this event record
52	4 bytes	Offset to the data

Table 5.3 illustrates the first 56 bytes of an event record. Keep in mind that the actual length of the record itself is listed in the first and last DWORDs of the record. (The size of the record brackets the actual record, just as it does with the file header.) With this information in hand, it is a relatively straightforward process to parse through the contents of an Event Log file, extracting and displaying the event records.

Having the event record structure definition also makes it possible to reassemble partial event records found in unallocated space. Using the magic number as a guide post, an analyst can search through unallocated space; should she locate the magic number, all she has to do is read the preceding DWORD for the size of the event record, then extract that number of bytes for the full event record. Even if the entire event record is not available, the first 56 bytes will provide a road map for reconstructing portions of an event record.

Tools & Traps…

Reading Event Logs

Once, I was assisting with a case in which an analyst who is extremely familiar with Linux was using PyFlag (www.pyflag.net) as his forensic analysis tool. He decided that he wanted me to open the Event Logs and retrieve available records; he’d tried to do so, but when he copied the .evt files to his Windows desktop system and tried to open the files with Event Viewer, he received a message that the files were corrupted.

I had already been researching the Event Log and event record structure, so I tweaked my Perl script just a bit and parsed through the Event Log files, retrieving all the event records with no problems whatsoever. However, I found a disparity between the information I was receiving from the header of one of the Event Logs and what I was seeing in the output of the event records; no matter how I approached the situation, I always had one more complete event record than the header information was telling me I should have. After investigating this issue for some time, I determined that according to the application program interface (API), a section of the Event Log just preceding the first record was a buffer area left over from when the Event Log was cleared. This buffer area was not read by the API, and if the system had been allowed to continue normally, it would have been flushed out of the circular buffer as new event records were written to the file. However, this buffer contained one complete event record; because the tool I was using did not use the API to retrieve event records but instead read through the file in binary mode, parsing the information it found, the tool didn’t recognize this buffer area.

Although the "lost" event record did not have a significant impact on the case, it did show the usefulness (with regard to forensic analysis) of understanding the format of certain files on Windows systems, and where possible, developing tools that parse through the information in those files in a manner that does not rely on the Windows API. Not only does this provide the investigator with the possibility of discovering "hidden" information, but it also allows the investigator to perform analysis on platforms other than Windows (particularly on Linux); investigators are not restricted to analyzing Windows images on a Windows platform.

The ch5\code\EVT directory on the accompanying DVD contains several Perl scripts that allow you to collect information from Event Log files from Windows 2000, XP, and 2003 systems. Evtstats.pl displays simple statistics collected from an .evt file, as shown here:

The script parses the header of the Event Log file and determines the number of records that should exist, then parses through the contents of the Event Log file itself and, using various tags from within each event record, performs an actual count of the number of event records found within the Event Log file.

Tip::

To install the code within the ch5\code\EVT directory on your system, simply copy all of the files within the directory to your analysis system. If you’re going to use the Perl scripts, be sure to have Perl installed and to keep the ReadEvt.pm Perl module within the same directory as the scripts. Alternatively, you can use the executable files, but you will need to keep the DLL in the same directory as the EXE files.

The evtrpt.pl Perl script displays additional statistics about an Event Log file:

Total number of event records counted: 260

Event Source/ID Frequency Source	Event ID	Count
Security	513	4
Security	514	28
Security	515	34
Security	518	4
Security	520	3
Security	528,2	7
Security	528,5	35
Security	529,2	7
Security	538,2	5
Security	538,3	8
Security	540,3	12
Security	551	7
Security	576	42
Security	612	5
Security	615	5
Security	680	14
Security	806	4
Security	848	4
Security	849	4
Security	850	28
Total: 260

Event	Type	Frequency
Type AUDIT SUCCESS AUDIT FAILURE Total: 260			Count
			245
			15

I use evtrpt.pl quite often when I’m conducting Event Log analysis. I usually start by parsing the Security hive file for the audit policy to see what types of events I should expect to see within the Event Log, as well as determining whether auditing is enabled. From there, I tend to run evtrpt.pl against the Event Log file (extracted from the acquired image) to determine the frequency of the different event IDs and sources within the Event Log file, as well as determine the date range of the events within the Event Log. The time field that evtrpt.pl collects is the time at which the event was generated (as opposed to when it was written), and this will let me know whether there are event records within the log file that fall within the time window for the incident in question. This can be very revealing with respect to the various Event Logs, particularly if the Application Event Log contains events generated by the antivirus application.

Another Perl script, lsevt.pl, uses the ReadEvt.pm Perl module to parse through the Event Log file and display event records in a simple listing format, as illustrated here:

Record Number	: 251
Source	: Security
Computer Name	: PETER
Event ID	: 528
Event Type	: EVENTLOG AUDIT SUCCESS
Time Generated	: Mon Sep 26 23:37:51 2005
Time Written	: Mon Sep 26 23:37:51 2005
SID	: S-1-5-21-83 95 22115-1801674531-214720096 3-1003
Message Str
Record Number	: 252
Source	: Security
Computer Name	: PETER
Event ID	: 576
Event Type	: EVENTLOG AUDIT SUCCESS
Time Generated	: Mon Sep 26 23:37:51 2005
Time Written	: Mon Sep 26 23:37:51 2005
SID	: S-1-5-21-83 95 22115-1801674531-214720096 3-1003
Message Str

Lsevt.pl includes parsing of the user’s SID (where applicable) into a format that is readable and can be correlated with other data (e.g., from the Registry) during analysis.

Lsevt2.pl provides a bit more flexibility than lsevt.pl in that it allows you to choose to output the format as comma-separated values (CSVs). This way, the investigator can run the script against a Windows Event Log file using the following command line:

She can then open the resultant testevt.csv file in Excel for sorting, searching, and analysis. Further, lsevt2.pl is a stand-alone script and does not require the use of the ReadEvt.pm Perl module. However, lsevt2.pl does not translate the user’s SID into a more recognizable format.

Evt2xls.pl is a Perl script that reads through the Event Log file, extracting all of the event records, parses them, and writes them to a spreadsheet format that is binary-compatible with Microsoft Excel. This allows you to open the spreadsheet and sort on various fields, such as the event source (e.g., to show all Application Popup event records) or event ID. To use evt2xls.pl, you need to specify several options at the command line; for example:

The preceding command line uses the —e switch to specify an Event Log file to be read, and the —o switch specifies the location and name of the output spreadsheet file. Simply typing evt2xls.pl at the command line, with no arguments, will display the syntax usage information. For example, the —r switch will allow you to specify the location of a report file, similar to what is generated by evtrpt.pl. Also, the —x switch allows you to specify a comma-separated list of event IDs that you’d like to skip or leave out of the resultant spreadsheet. This was originally intended for large Event Logs that had more than 65,535 entries, as some versions of Microsoft Excel are limited to that number of rows per worksheet. However, Excel 2007 apparently does not contain this limitation, and other spreadsheet applications, such as the one that is part of OpenOffice (www.openoffice.org/), should have no trouble opening the file. Further, evt2xls.pl uses the Spreadsheet::WriteExcel Perl module to create the spreadsheet, and the Spreadsheet::Read or Spreadsheet::ParseExcel module can be used to extract data from the output spreadsheet.

Tip::

Rob Faber wrote an excellent article titled "Windows log forensics: did you cover your tracks?" for the April 2008 edition of INSECURE magazine (Issue 16, available from www.net-security.org/dl/insecure/INSECURE-Mag-16.pdf). In the article, Rob presents some excellent information that can be used in a wide range of examinations. It’s well worth printing this issue of INSECURE magazine, if not for the entire magazine, then just for Rob’s article.

All of these Perl scripts parse through the Event Log files in binary mode, bypassing the Windows API altogether. This way, not only can the Event Log files be parsed on a platform other than Windows (Mac OS X, Linux, etc.), but an investigator can still parse the Event Log files even if the Event Viewer gives him error messages that the file is somehow corrupted. Several of the scripts do require the use of the ReadEvt.pm Perl module that is also included on the accompanying DVD.

Warning::

In February 2007, Andreas Schuster blogged about a special condition regarding Event Log records, in which a record is written to the end of the .evt file but wraps around to the beginning of the file so that part of the record follows the header. This record will be incorrectly read by tools (such as the Perl scripts listed in this topic) that look for the event record magic number, because only part of the record will be identified. Andreas was kind enough to provide an example .evt file so that parsers can be tested (and improved) against this condition (you can find the blog post and sample test file at http://computer.forensikblog.de/en/2007/02/a_common_misconception.html).

Vista Event Logs

A lot about the Windows operating system has changed with the advent of Vista, including the Event Log structure used by the operating system. For example, this service is now referred to as Windows Event Log rather than Event Logging, and it takes on a whole new format for the saved event records. Vista uses an XML format for storing events, and now supports central collection of event records.

Other changes include the fact that although Vista still maintains the three main categories of event log (Application, Security, and System), it now has a wide range of categories under which different events can be logged, as Figure 5.5 illustrates.

Figure 5.5 Vista Event Viewer

As Figure 5.5 illustrates, there are now more Event Logs, including one for Internet Explorer as well as Hardware Events. (Installing the new Internet Explorer Version 7 also adds an Internet Explorer Event Log to Windows XP and 2003.) Although the log container is created, it is not enabled and seems to be used only for application compatibility testing (http://msdn.microsoft.com/en-us/library/bb250493.aspx); as such, there does not seem to be much value from a forensic analysis perspective.

Also notice on the lower right-hand side of Figure 5.5, under Actions, the item called Attach Task To This Event.. As tools are developed for parsing through Vista Event Logs and as incident responders and forensic analysts use those tools, this item will be of interest.

Andreas Schuster and Eric Fitzgerald have posted some information in their respective blogs about the structure used to store event records. Andreas also provides a blog post that describes some of the data types available in the new Event Logs (http://computer.forensikblog.de/ en/2007/08/evtx_data_types.html), as well as a parser to convert Vista Event Logs into plain text (http://computer.forensikblog.de/en/2007/08/evtx_parser.html).

On a live Vista system, you can use the wevtutil.exe command to retrieve information about the Windows Event Log that isn’t readily apparent via the Event Viewer user interface. For example, the following command will display a list of the available Event Logs on the system:

From there, you can use the next command to list configuration information about a specific Event Log, including the name and path to the file:

Much of the information displayed by this command is also available in the following Registry key on a Vista system:

This will be useful information for incident responders and forensic analysts alike. Tools and techniques need to be developed that allow incident responders and forensic analysts to extract relevant and pertinent information from the Windows Event Logs on Vista systems.

For ease of analysis when examining Event Logs from both XP and Vista systems, Event Log (.evt) files can be converted to the Windows Event Log (.evtx) format using any of the options listed in the Ask the Performance Team blog on Microsoft’s TechNet site (http://blogs.technet.com/askperf/archive/2007/10/12/windows-vista-and-exported-event-log-files.aspx).