The discipline of digital forensics and incident response relies fundamentally on the persistent, systemic traces left by both legitimate users and malicious actors. The Windows Event Log system serves as a primary chronological record of operating system activity, capturing security events, application behaviors, service and driver activity, and user authentication telemetry. Due to the immense volume of background events generated by Windows 10 and Windows 11, isolating forensically relevant artifacts is a highly specialized task. A comprehensive understanding of this logging mechanism is often decisive when reconstructing an incident timeline.

How Windows Event Logs are Composed and Stored

To effectively analyze operating system telemetry, investigators must first understand where and how the Microsoft Windows operating system structures, stores, and archives its localized event databases. The shift from legacy systems (pre-Vista) to modern Windows architectures (Vista and later, including Windows 10 and 11) introduced major changes to how these records are maintained, parsed, and protected against unauthorized modification.

Time Normalization, Correlation, and Centralized Telemetry

Event log timestamps are only as useful as the time context used to interpret them. Windows commonly records event times in UTC, while many viewers render those timestamps in local time, which can introduce subtle offsets during daylight saving transitions and after manual clock changes. In investigations spanning multiple endpoints, these differences can distort an otherwise accurate timeline unless analysts normalize times consistently and verify the host’s configured time zone via the Windows Registry, including HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation.

It is also important to treat event logs as only one slice of the evidentiary picture. Log records can be incomplete due to retention limits, policy configuration, or attacker interference, so investigators should correlate log findings with complementary artifacts such as relevant registry hives, filesystem metadata, prefetch execution traces, scheduled task definitions, and application-specific telemetry. This cross-validation is often what turns a plausible narrative into a defensible, reproducible conclusion.

Finally, many enterprise environments rely on centralized collection pipelines such as Windows Event Forwarding, SIEM agents, or EDR telemetry to preserve logs beyond what any single endpoint retains locally. This has a practical implication during triage: local .evtx files may be truncated, rolled over, or cleared, while forwarded copies and centralized indexes can still contain the missing history. For that reason, investigators should treat endpoint logs as necessary but not sufficient, and request the corresponding centralized log sources early in the case.

File Locations and XML Structures

Modern Windows operating systems utilize the .evtx file format, which replaced the legacy .evt format utilized in older iterations such as Windows XP and Windows Server 2003. These .evtx files contain highly structured Extensible Markup Language (XML) data wrapped in a proprietary binary format. This binary XML encoding ensures that each event log entry maintains a consistent schema that includes an Event ID, timestamp, provider source, user security identifier (SID), and a payload of specific event data. Because the data is binary-encoded rather than stored as plaintext, basic string-searching against raw files is incomplete; reliable analysis typically requires proper parsing through dedicated forensic tools.

By default, the primary event log files reside in the system directory located at C:\Windows\System32\winevt\Logs. The operating system maintains hundreds of distinct log files within this directory, categorizing telemetry into highly specific operational silos. The most frequently utilized logs include:

• Security log: tracking authentication attempts, privilege usage, and policy changes.
• System log: capturing operating system issues, service failures, and driver errors.
• Application log: containing application-specific messages.
• Setup log: recording installation and update events.
• Forwarded Events log: acting as a centralized collection point for telemetry pushed from remote endpoint computers.

The exact storage locations and operational parameters for these files are governed by the Windows Registry. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog stores the default and customized configurations for the event logging service. Forensic investigators routinely analyze this specific registry hive to determine if a system administrator or a threat actor has redirected event logs to a custom location.

At the file-format level, .evtx logs store records in a chunked binary structure (rather than the legacy .evt header/EOF record layout). These internal headers and chunks are forensically valuable for determining if a log file has been corrupted, tampered with at the binary level, or if the logging service has been improperly shut down.

Event Log Retention, Backup Versions, and Archival

Because continuous system logging consumes significant storage capacity, Windows event logs are subject to retention policies dictated by system configurations or Group Policy Objects (GPOs).

By default, most logs are configured with a maximum file size threshold (often 20 MB for standard logs, though security logs on servers and domain controllers are commonly configured much larger). Once a log reaches its maximum capacity, the operating system executes one of two behaviors based on its configuration: it either begins overwriting the oldest events (a process known as circular logging), or it archives the full log and creates a new, empty active log file.

When the system is configured to retain old events – a common best practice for enterprise environments and high-security networks – the operating system automatically creates archival backup versions of the .evtx files. Unless an alternative log path has been specifically designated in the registry, these archives are generated within the same default C:\Windows\System32\winevt\Logs directory. These archives utilize a chronological naming convention, typically formatted as Archive-<LogName>-YYYY-MM-DD-HH-MM-SS-NNN.evtx (for example, Archive-Security-2023-10-14-08-30-00-000.evtx). Over time, these archive logs accumulate and are not overwritten by default, requiring adequate disk space allocation and regular administrative monitoring (and, in some environments, scripted cleanup policies).

The forensic meaning of these archived backup versions is significant. Incident response investigations often commence weeks or months after the initial intrusion vector was exploited, particularly when breaches are detected by external third parties rather than internal security teams. Because modern Windows systems generate vast amounts of event data, the active Security.evtx file on a busy server may only contain hours to a few days of telemetry before rolling over. The archived backup files allow forensic analysts to bridge this chronological gap, reconstruct the timeline of the initial access, trace early lateral movement, and identify likely “patient zero” systems. If these archives are missing in an environment that purportedly retains them, it can indicate either poor retention enforcement or deliberate anti-forensic activity by an adversary.

The Forensic Implication of Log Clearing

Deliberate log clearing is one of the most prominent indicators of compromise evaluated during a digital investigation. Threat actors frequently attempt to clear the Security log to eliminate traces of privilege escalation, lateral movement, or malware execution. This tactic is especially common in ransomware deployments, where adversaries seek to erase evidence of their network traversal immediately prior to encrypting host systems.

However, via standard Windows interfaces, event logs are not selectively cleared; the action is effectively all-or-nothing for a given log. When a clearing action occurs, it should generate a specific forensic artifact. Event ID 1102 is recorded in the newly cleared Security log, while Event ID 104 is generated in the System log if other standard logs (such as the Application or Setup logs) are cleared.

The presence of Event ID 1102 has strong forensic meaning. Clearing the Security log requires the Manage auditing and security log user right (commonly held by local administrators and SYSTEM, but it can be delegated). As a result, this event indicates that a highly privileged context was used to clear the audit trail. If investigators observe this event occurring outside of a known administrative maintenance window, it could be treated as a high-confidence indicator of suspicious activity and correlated with surrounding authentication and privilege events (including the account and Logon ID recorded with the clear event, when present).

Live System Extraction and Triage Methodologies

In contemporary forensic analysis, the traditional methodology of completely powering down a compromised system and seizing its physical hard drive for laboratory analysis is often impractical and counterproductive. Shutting down critical enterprise infrastructure disrupts essential business operations, alerts the threat actor to the investigation, and destroys volatile evidence stored in Random Access Memory (RAM). Consequently, the industry relies heavily on live system forensic triage, a methodology designed to extract maximum intelligence with minimal systemic impact.

Forensic Triage Principles

Live system triage involves utilizing specialized extraction tools on a running machine to quickly acquire the most valuable digital artifacts – such as the registry hives, memory dumps, prefetch files, network configurations, and .evtx logs – without destabilizing the host environment. Tools explicitly designed for this rapid collection, such as Elcomsoft Quick Triage or custom frameworks like Wintriage, are typically executed from external storage media.

These applications operate under local or domain administrator privileges to bypass standard user-level access restrictions. The core philosophy of these tools is strict prioritization; rather than generating a bit-for-bit physical clone of a multi-terabyte server drive – which could take days to process – triage tools automate the collection of specifically defined volatile and non-volatile artifact subsets. This approach yields on-site identification and interpretation of digital evidence in a matter of minutes, accelerating the preliminary investigation and allowing incident responders to swiftly contain active threats.

Employing Volume Shadow Copies (VSS) for Log Extraction

One of the most complex technical challenges encountered during live forensic triage is the acquisition of event logs that are actively locked by the operating system, or logs that have been recently deleted, overwritten, rolled over, or cleared by an attacker. To effectively circumvent these inherent file-system limitations, advanced forensic extraction methodologies can leverage the Windows Volume Shadow Copy Service (VSS). VSS is an underlying Windows infrastructure technology that may capture point-in-time snapshots (shadow copies) of the file system, preserving historical versions of files regardless of their current active state (when shadow copies exist and have not been removed).

During live system analysis, investigators utilize command-line parsing tools to extract event log telemetry directly from the live file system and, when available, from Volume Shadow Copies. The inclusion of VSS data can materially alter the trajectory of an investigation. If a threat actor cleared the Security.evtx log shortly before triage to hide lateral movement, the active file system will reflect a newly cleared log containing the clearing event. However, a Volume Shadow Copy taken earlier may contain an intact historical Security.evtx instance. By processing the shadow copies, a forensic tool can recover historical telemetry preserved in VSS, allowing the investigator to observe earlier authentication, privilege escalation, and tool execution that would otherwise be absent from the active log.

Data Parsing, Normalization, and Deduplication

Windows Event Logs present a unique analytical challenge because they lack a uniform data structure; the XML schema for an authentication event differs entirely from the schema for a service installation. Common forensic tools resolve this architectural inconsistency through the use of mappings in their extraction logic. In addition, when merging active system logs with historical logs extracted from multiple Volume Shadow Copies, investigators should be aware of event de-duplication (enabled by default in many forensic tools). This helps prevent redundant telemetry when the same log appears across multiple shadow copies, producing a cleaner, chronologically accurate timeline that can be imported into visualization tools for threat hunting and keyword filtering.

High-Value Event Log Artifacts for Real-Life Investigations

The following sections detail commonly high-value Windows 10 and 11 Event Log artifacts. These records are categorized logically by their systemic function and are sorted in order of frequent usefulness in real-world investigations, beginning with authentication telemetry.

Group 1: Authentication and Account Logon Activity

Authentication logs serve as the baseline of many intrusion investigations. Before an adversary can manipulate a system, they must authenticate to it – whether through brute-forcing exposed remote desktop portals, using stolen credentials, or executing other attacks. The operating system’s Security event log records authentication activity, providing metadata regarding the account, the origin point of the request, and the protocol utilized. A precise evaluation of the “Logon Type” contained within these events helps distinguish a local console session from remote access and lateral movement.

• Artifact: Successful and Failed Logon Events
  • Location: C:\Windows\System32\winevt\Logs\Security.evtx
  • Meaning: Event ID 4624 indicates a successful logon. Event ID 4625 indicates an authentication failure. Event ID 4648 indicates a logon using explicit alternative credentials.
  • Forensic Value: Primary method for detecting brute-force attacks and credential stuffing. Key field is Logon Type (Type 2: Console, Type 3: Network, Type 10: RDP).
• Artifact: Special Privileges Assigned to New Logon
  • Location: C:\Windows\System32\winevt\Logs\Security.evtx
  • Meaning: Event ID 4672 indicates special administrative privileges assigned to a session.
  • Forensic Value: Highlights sessions with powerful rights (e.g., SeDebugPrivilege). In practice, correlate with the associated logon (4624) and the account’s normal behavior, since some service accounts can legitimately trigger this event.

Group 2: Remote Desktop Protocol (RDP) and Interactive Sessions

Following successful initial access, adversaries frequently use Remote Desktop Protocol (RDP) to navigate graphically through a compromised environment. The TerminalServices operational logs provide a granular view of RDP session lifecycle events that can complement the Security log.

• Artifact: Local Session Manager Operational Events
  • Location: C:\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
  • Meaning: ID 21 (Logon success), ID 22 (Shell start/GUI loaded), ID 24 (Session disconnected), ID 25 (Session reconnection).
  • Forensic Value: High-value artifacts for RDP-based lateral movement. Often includes a Source Network Address, but it may appear as LOCAL depending on the session type – so pair with Security logon events and other RDP telemetry for confirmation.

Group 3: Process Execution, Services, and Persistence Mechanisms

To survive a system reboot, malicious software often embeds itself into startup routines, including via rogue Windows Services. Tracking execution commonly relies on process creation auditing and service installation telemetry (when enabled).

Important: Cross-check these artifacts against the corresponding Windows Registry entries.

• Artifact: Service Installation and Modification
  • Location: System.evtx and Security.evtx
  • Meaning: ID 7045/4697 (New service installed), ID 7040 (Start type modified), ID 7034 (Service crashed).
  • Forensic Value: High-fidelity indicators of persistence. Useful for identifying malware masquerading as legitimate services.
• Artifact: Process Creation and Command Line Auditing
  • Location: C:\Windows\System32\winevt\Logs\Security.evtx
  • Meaning: Event ID 4688 records process creation including parent process and, when configured, command-line arguments.
  • Forensic Value: Often critical for reconstructing attacker actions and “living off the land” abuse. Ensure Audit Process Creation is enabled, and enable “Include command line in process creation events” if command-line fidelity is required.

Group 4: Power States, Modern Standby, and Physical Access

In cases of insider threats or physical theft, establishing the machine’s power state can be important. Modern Standby (S0) allows background activity while the device appears asleep, making Kernel-Power logs useful for understanding sleep/wake behavior.

• Artifact: Modern Standby and Physical Power Cycles
  • Location: C:\Windows\System32\winevt\Logs\System.evtx
  • Meaning: ID 12 (System start), ID 1074 (User shutdown), ID 506 (Entering Connected Standby), ID 507 (Exiting Connected Standby).
  • Forensic Value: Helps establish power and sleep/wake timelines. The “Reason” fields can indicate lid, power button, idle timeout, or other wake sources, so treat them as strong context rather than absolute proof of human interaction on their own.

Group 5: External Storage and Universal Serial Bus (USB) Artifacts

USB devices are common vectors for data exfiltration and malware. The Plug and Play (PnP) subsystem generates specialized logs that track hardware identifiers after a device is connected.

Important: Cross-check these artifacts against the corresponding Windows Registry entries.

• Artifact: USB Plug and Play Device Enumeration
  • Location: Storage-ClassPnP%4Operational.evtx and DriverFrameworks-UserMode%4Operational.evtx
  • Meaning: Tracks driver initialization (IDs 10000-10002) and storage volume status (IDs 507, 512).
  • Forensic Value: Strong indicators of device presence and volume mount behavior. Correlate these with registry, filesystem, and shortcut artifacts to tie a specific drive (VID/PID/serial) to actual data access.

Identifying and Filtering Noisy, Unimportant, and Legacy Artifacts

Exhaustive logging introduces “noise” – benign telemetry that causes alert fatigue. Effective forensics requires filtering obsolete artifacts and high-volume event classes that are low signal unless the investigation specifically demands them.

Legacy and Deprecated Event IDs

Modern Windows 10 and 11 environments use a different numerical schema than legacy versions (pre-Vista). Investigators should ignore legacy IDs found in outdated literature.

• Successful Logon: Ignore 528, 540; Focus on 4624.
• Failed Logon: Ignore 529-537, 539; Focus on 4625.
• Logoff: Ignore 538; Focus on 4634, 4647.

Excessively Verbose and Low-Signal Telemetry

Some modern IDs generate massive volumes and are often low signal at scale. Windows Filtering Platform (WFP) events (5156, 5158) can log extremely high connection volume and may roll logs quickly; many investigators prefer higher-level network telemetry unless they are validating a narrow hypothesis. Similarly, Directory Service Access (4662) and Kerberos Ticket Renewals (4770) can be noisy in domain environments and are typically tuned and filtered – but they can be high value in specific investigations (for example, targeted AD object access/replication abuse or Kerberos anomaly hunts).

Conclusion

In practice, Windows forensics is only getting more complex. Each new feature, service, and security control adds more telemetry and more places for useful traces to hide – so the volume of potential artifacts keeps snowballing. Keeping up with what changes between versions, what gets logged by default, and what requires deliberate configuration is hard even for experienced investigators, which is why modern investigations rely heavily on specialized forensic tools to collect, parse, and organize evidence at scale.

But tools are not investigators. Even the best utilities can miss context, mislead through assumptions, or produce output that looks authoritative while still being incomplete. The responsibility for interpretation – and for the decisions made from that evidence – always rests with the human examiner. Use tools to accelerate and structure the work, but treat their output as a starting point to validate, correlate, and reason about, not as a substitute for professional judgment.

Acknowledgments and References

This article builds upon the collective knowledge of the digital forensics community. The detailed analysis of Windows 10 and 11 Event Log artifacts presented here would not be possible without the research and documentation provided by the following authors and organizations. We extend our gratitude to them for their contributions to the field.

1. Windows Event Log Analysis: Techniques for Every SOC Analyst | CyberDefenders Blog
2. Windows Event Log Forensics: A Comprehensive Guide | by ShellXploit – Medium
3. Windows Event Logs – Forensafe
4. Understanding the Windows Server Event Log | Microsoft Community Hub
5. Event Log File Format – Win32 apps – Microsoft Learn
6. Windows event logging and forwarding – Australian Cyber Security Centre
7. Windows Server Event Log and Event Log Policies 2025
8. Event Log Clearing and Malware Execution: Evidence from Windows Logs – Medium
9. Windows Forensic Artifacts Cheat Sheet | PDF – Scribd
10. One Windows Event Log ID To Rule Them All: Why You Should Hunt With Event 4624
11. Critical Windows Event ID’s to Monitor – Graylog
12. Detecting Lateral Movements in Windows Infrastructure – CERT-EU
13. Request for List of High and Critical Windows Security Event IDs – Microsoft Learn
14. Windows Event Viewer: List of Common Event IDs – tenfold
15. Windows Terminal Services – Local Session Manager Log – Cyber Triage
16. Windows RDP-Related Event Logs: Identification, Tracking, and Investigation
17. Making Sense of RDP Connection Event Logs – FRSecure
18. Remote Desktop Shell Start- Local – Microsoft Q&A
19. Windows event codes for startup/shutdown lock/unlock – Server Fault
20. Modern Standby Wake Sources | Microsoft Learn
21. USB Artifact Analysis Using Windows Event Viewer, Registry and File System Logs – MDPI
22. USB Forensics on Windows 10 | Netscylla’s Blog
23. Important Windows Event IDs: Which Events You Should Monitor and Why – BeyondTrust
24. Windows Security Log Event ID 4662 – An operation was performed on an object