This post examines the technical structure of Windows Event Logs in modern systems, focusing on the binary XML .evtx format, default storage paths, remote collection mechanisms, and the standard field schema that underpins every logged event.
Storage Location and File Format
Contemporary Windows operating systems write event logs to the %SystemRoot%\System32\winevt\logs directory as their default storage location. The file format employed is binary XML Windows Event Logging, which carries the .evtx file extension. This structured format replaced the older .evt format and provides improved performance and richer metadata capabilities.
Beyond local storage, Windows supports remote log aggregation through a subscription model. In this architecture, a centralized system running the Windows Event Collector service establishes subscriptions to receive logs from distributed endpoints. Administrators can define collection policies with fine granularity, specifying exactly which event types should be forwarded. Transport occurs over HTTPS on port 5986 using the Windows Remote Management (WinRM) protocol. Group Policy Objects (GPOs) provide a scalable mechanism to deploy remote logging configurations across an enterprise.
Event Log Categories
While the classic trio of Security, System, and Application logs remain central to Windows logging, modern versions of the operating system have expanded the logging ecosystem significantly. The Setup event log captures activities that take place during Windows installation procedures. When remote log collection is active, the Forwarded Logs event log serves as the default repository for events received from other machines.
Additionally, Event Viewer exposes a rich hierarchy under Applications and Services Logs that contains numerous specialized logs tied to specific system components or application behaviors. These targeted logs offer a valuable forensic advantage: because they focus on narrow activity domains, they typically experience slower turnover rates than the high-volume Security log. As a result, they often preserve evidence of events that occurred long before the Security log was overwritten by newer entries.
Always survey multiple log sources during an investigation. Don't overlook archived log files that may exist in backup systems or Volume Shadow Copy snapshots—these can contain critical historical data that has been rotated out of active logs.
Common Event ID Fields
Every event record in the Windows Event Log schema shares a set of standard fields. Understanding these fields is essential for effective log analysis and correlation:
Log Name
Identifies which event log contains the record. This field becomes particularly useful when you're processing a large collection of logs extracted from a single host, helping you maintain context about the source log category.
Source
Specifies the service, Microsoft component, or application responsible for generating the event. This attribution helps analysts understand which subsystem recorded the activity.
Event ID
A numeric code that uniquely identifies the type of audited activity. Event IDs are the primary classification mechanism for Windows events and are essential for detection rule development.
Level
Indicates the severity classification assigned to the event. Common levels include Information, Warning, Error, and Critical, though the exact taxonomy depends on the event source.
User
Records the user account associated with the event. This may represent either the account that triggered the activity or the security context under which the logging source was executing.
The User field frequently shows "System" or service accounts that are not the actual cause of the logged event. Always correlate this field with other event details before drawing conclusions about user attribution.
OpCode
A value assigned by the event source. The semantic meaning of this field is defined by the generating component and is not standardized across Windows.
Logged
The local system date and timestamp indicating when the event was written to the log. This is critical for timeline reconstruction.
Task Category
Another source-defined field whose interpretation depends on the component that generated the event. It provides additional classification beyond the Event ID.
Keywords
Tags assigned by the event source to enable grouping and filtering of related events. These facilitate both real-time monitoring and post-incident analysis.
Computer
The hostname of the system where the event was logged. While valuable for multi-system investigations, this field should not be confused with the originating device in network-based events. For example, when a remote logon occurs, the Computer field reflects the target system that logged the authentication event, not the source IP or hostname of the connecting machine.
Description
A free-text field containing detailed information specific to the individual event instance. This field often holds the most forensically significant data, including process names, file paths, network addresses, and other context-specific details.
While all fields contribute to event context, the Description field typically contains the richest investigative leads. Prioritize parsing and analyzing this field when triaging large volumes of events.
Summary
The binary XML .evtx format and its standardized field schema form the foundation of Windows event logging on modern systems. By understanding where logs are stored, how remote collection operates, and what each common field represents, DFIR practitioners can more effectively extract and interpret forensic artifacts from Windows Event Logs. Remember to look beyond the primary Security log and leverage the diverse ecosystem of specialized logs that modern Windows provides.