Skip to content

Windows xml event log (evtx)

The Windows XML Event Log (EVTX) format was introduced in Windows Vista as a replacement for the Windows Event Log (evt) format.

Event Viewer

On Windows the event logs can be managed with "Event Viewer" (eventvwr.msc) or "Windows Events Command Line Utility" (wevtutil.exe). Event Viewer can represent the EVTX files in both "general view" (or formatted view) and "details view" (which has both a "friendly view" and "XML view"). Note that the formatted view can hide significant event data that is stored in the event record and can be seen in the detailed view.

If you export an event log from Event Viewer additional "display information" can be exported. This display information is stored in a corresponding file named:

LocaleMetaData\%FILENAME%_%LCID%.MTA

Where LCID is the locale identifier.

Location

C:\Windows\system32\winevt\Logs

Parsing considerations

Corrupted and recovered records

Parsers differ in how they handle corrupted chunks and records. For example the Rust evtx crate skips the remainder of a chunk after an invalid record, while libevtx can also recover records. When a file is dirty or partially overwritten, compare record counts and event record identifiers between tools.

Event data and event message

Most EVTX parsers read the binary XML (BinXml) of the event records and output the event data. They do not render the event message that Event Viewer shows in its "general view". Keep the following in mind when interpreting their output.

Note that not all data in an event record is used in the message, and the message can contain information that is not in the rendered event message. From a digital forensics perspective such data must be interpreted with care.

  • The event message is not stored in the EVTX file. It is looked up in the message resource files, which are typically PE/COFF executable files, of the event provider on the system that renders it. They can differ between versions and languages of Windows and applications. Output of a parser that does not use these resources contains the event data, but not the message.
  • An event is identified by a combination multiple aspects such as the provider and the event identifier and version. The qualifiers and version of the event change how the event data should be interpreted.
  • An event can also contain parameter references (%%N), such as %%1833, which can be resolved using the provider's parameter message file. Without that file the reference, Event Viewer outputs them as-is.

Converting Event data to XML, JSON or JSONL

Converting records to XML, JSON or JSONL keeps most of the event data, and JSON(L) is convenient to query with tools such as jq or to ingest in a Security Information and Event Management (SIEM), or equivalent. However:

  • The XML produced is not always proper XML 1.0. Event data can contain characters that are not allowed in XML or that are not escaped.
  • Data element names within EventData are not guaranteed to be unique. JSON objects cannot hold duplicate keys, so a converter has to rename them, for example the Rust evtx crate appends _1, _2, etc., keep only one value or store them as a list. Check which behavior a tool uses before searching on a field name.
  • Events without named data elements, for example events written through the legacy ReportEvent API, have positional values only, which are output as a list without field names.
  • Data types can be flattened. For example binary data is output as a hexadecimal string and a SID or GUID as a string.
  • EventData and UserData are structured differently; converters and queries that only handle EventData miss UserData events.

Normalization to CSV or JSON with per-event maps

Tools such that flatten each record into a fixed set of columns, such as user name, remote host or executable, use per-event maps that select fields from the event XML. This makes records from different providers comparable in a single timeline. However:

  • A map only extracts the fields its author selected. Other event data is only available in the raw payload column.
  • Events for which no map exists are only available as raw payload.
  • A map is keyed on provider, channel and event identifier. This can be incorrect when the event layout differs between versions of the event or of Windows.
  • The column names are the map author's interpretation of the data. The same column can hold different kinds of values for different events.

Rule-based threat hunting

Chainsaw and Hayabusa match Sigma (and tool specific) rules against the event data. Field names in rules have to match the field names produced by the tool's parser, including renamed duplicate fields. A rule not matching does not mean that the activity did not occur, for example when the log was cleared, rolled over or the relevant audit policy was not enabled.

See Also

File Format

Windows Vista/2008

Windows 7

Tools

Threat hunting

Warning: The tools listed below are not necessarily forensic tooling in the sense of forensic tooling, but are known to be widely used for threat hunting in the context of intrusion analysis.

  • Chainsaw, hunts EVTX files with Sigma rules
  • evtx, Rust parser and evtx_dump CLI tool, which can output in XML, JSON, JSONL
  • EVTX parser, browser-based EVTX viewer, which uses the Rust evtx crate compiled to WebAssembly. EVTX files are parsed locally and not uploaded to the web.
  • EvtxECmd, normalizes events to CSV/JSON using per-event maps
  • Hayabusa, Sigma-based EVTX timeline and threat-hunting tool