Common misconceptions about Windows EventLogs
Common misconceptions about Windows EventLogs
Background
I regularly get people new to DFIR reaching out with questions about Windows EventLogs and it saddens me that there are so many DFIR related write-ups out there that provide these people with incorrect and incomplete information about Windows EventLogs. Windows EventLog is a complex subsystem of Windows with various edge cases. Common misconceptions I come across regularly:
EventID is globally unique.
EventIDs directly map to event messages.
All event strings are used in the message.
All the event message information is in the template string.
Template strings remain the same.
Event XML is proper XML 1.0.
Data element names in Event XML are unique.
EventLogs and ETW are equivalent.
Hopefully this article will help debunk some of these misconceptions and provide people new to DFIR a reference to assess the reliability of information out there.
Misconception 1: EventID is globally unique
Probably one of the most common misconceptions about EventIDs is that they are globally unique. From “Event Identifiers (Event Logging)” by Microsoft [1]:
“Event identifiers uniquely identify a particular event. Each event source can define its own numbered events and the description strings to which they are mapped in its message file.”
"Each event source can define its own numbered events" implies that event identifiers are only unique given a specific event source (also known as locally/relatively unique). Unfortunately there are many sources out there that only reference the EventID without the event source and its version.
If you want to validate this yourself, just lookup EventID 1 on for example MyEventlog. You might have noticed that besides multiple event sources there are also multiple messages for event source “WinVNC4”. This can happen due to differences between different versions of the same event source.
The “Event XML” references the event source name (represented by either “EventSourceName” or “Name”) in the "Provider" element:
Windows uses the event source name or identifier (“Guid” attribute) for example in the “Services\EventLog” and/or “WINEVT\Publishers” Windows Registry keys [2] that contain more information about where the event messages are stored.
Misconception 2: EventIDs directly map to event messages
From “Windows XML Event Log (EVTX) format” section “5.4. Externally stored values” [3] and projects like GrokEVT [4] we know that event messages are stored in (PE/COFF) message resource files. The event messages are stored with a message (template) string identifier. There are multiple ways to determine the message (template) string identifier from an EventIDs:
One-to-one mappings of the EventID to a message (template) string identifier
Mappings that use the EventID and Qualifiers attribute
Mappings that use the WEVT_TEMPLATE PE/COFF resource
Mappings that use the EventID and Qualifiers attribute
In some cases we need the EventID Qualifiers attribute to determine the message (template) string identifier. Let’s consider the following example :
The value of EventID with the Qualifiers correspond to the following message (template) string identifier:
Note that this has only been observed with event sources that are solely defined under the “Services\EventLog” Windows Registry key.
Mappings that use the WEVT_TEMPLATE (PE/COFF) resource
Another way the EventID can be mapped to a message (template) string identifier is via information in the WEVT_TEMPLATE resource. For example we have the following event sources:
As you can see both event sources use the same event message resource files. If we extract the event identifiers and message (template) strings with the following PowerShell commands on Windows 10 20H2:
And compare that against a section of the message table PE/COFF resource in the %systemroot%\system32\en-US\cscsvc.dll.mui file (product and file version 10.0.19041.1).
The %systemroot%\system32\en-US\cscsvc.dll.mui file contains message (template) strings for both the Microsoft-Windows-OfflineFiles and Microsoft-Windows-BranchCacheSMB event source and these to map to different message (template) string identifiers.
In the related %systemroot%\system32\cscsvc.dll file there is a WEVT_TEMPLATE (PE/COFF) resource that contains an “event definition” that maps the EventID to a message (template) string identifier [5]. For example:
Misconception 3: All event strings are used in the message
Typically an EventLog record specifies event strings. For example:
Here the event strings “Volume Shadow Copy” and “stopped” are specified as EventData in the Event XML. In the example the corresponding event message (template) string is “The %1 service entered the %2 state.” where the first event string is used to replace the first placeholder (%1) in the final event message, etc. Where the final event message would be: “The Volume Shadow Copy service entered the stopped state.”
However there are cases where the event message (template) string does not contain a placeholder for a specific event string. For example for Microsoft-Windows-OfflineFiles EventID 2003 on Windows 10 20H2:
As you can see this event message (template) string only has placeholders for the first and thirteenth event strings. How the other event strings should be interpreted in such cases based on the EventLog record, without additional facts, is pure speculation from a digital forensics point-of-view.
Misconception 4: All the event message information is in the template string
Event messages can use a concept referred to as “parameter expansion”. The following event message (template) string: “The %1 call failed for %2 with the following error:
%3.” and event strings in EventData:
However EventLog viewer will translate this to the following string:
As you can see “Access is denied.” is not defined either in the event message (template) string or in the event strings. Here %%5 corresponds to the message string with identifier 5 stored in the parameter message file of the event source [6].
Misconception 5: Template strings remain the same
Event message (template) strings can differ for different versions of (PE/COFF) message resource files. For example comparing the event message (template) string of Microsoft-Windows-BranchCacheSMB EventID 3000 on a Windows 7 and Windows 10 20H2 version of %systemroot%\system32\en-US\cscsvc.dll.mui:
Not only is the event message (template) string different on Windows 10 20H2 it also has placeholders. It is unclear if a Windows 7 EventLog record would contain the event strings that would be expected on Windows 10 20H2.
Misconception 6: Event XML is proper XML 1.0
Though [MS-EVEN6] [7] might hint that Event XML is proper XML 1.0, in practice it is not. The evtx-specimens project has a script that allows you to generate EventLog records with characters considered invalid XML 1.0 [8].
Another example of where Event XML can deviate from proper XML 1.0 can be seen in the following example:
Here the Data element “Besides ‘StateMachine<class KeyMachine,class KeyState>::PumpEvents’“ is not proper. Well-formed XML should not contain < in the XML element data.
Misconception 7: Data element names in Event XML are unique
As you can see in the following Event XML names used for Data elements in EventData are not unique. There are multiple Data elements named “IoCount”, “TotalLatencyUs”, “TotalBytes” and “IoTypeIndex”.
Misconception 8: EventLogs and ETW are equivalent
EventLog is a standard, centralized way for applications (and the operating system) to record important software and hardware events [9], for the purpose of system administration.
ETW is short for Event Tracing for Windows. EWT is a kernel-level tracing facility that lets you log kernel or application-defined events to a log file [10]. Note that a log file in the context of ETW is typically an EWT trace log file (.etl) which is different from an EventLog file (.evt or .evtx).
In Windows Vista and later EventLog uses ETW [11], so in short, they are related but not equivalent.
Conclusion
I hope this article has provided you more insight into common misconceptions about Windows EventLogs. As a digital forensic analyst you need to understand the information and potential edge cases of the data you are analyzing.
Windows EventLog is a complex subsystem of Windows with various edge cases, most of which have not been widely discussed within the digital forensics field. So if you feel you have an interesting one, please reach out on the Open Source DFIR Slack community.
Comments
Post a Comment