How Do You Investigate Windows Event Logs?
Vague notes on Windows event log investigation. I'll add more as I remember.
Note: This is the English translation of the Japanese original. The Japanese version is available at https://sumeshi.github.io/posts/knowledges/windows-eventlog-analysis-101.
Introduction
Mainly a story from an incident response perspective. This kind of information is scattered across various sites, and looking it up one by one is a pain.
1. What Event Log Investigation Is
The purpose of event log investigation is not to comprehensively scoop up suspicious events, but to grasp what happened in the target environment and connect it to initial response and further investigation.
That's why, in the end, the important perspective is to not draw conclusions from event logs alone, but to build hypotheses about the attacker's actions and verify them while cross-referencing other evidence.
With that premise, keep the following at minimum in your head.
Event logs are not a complete record
Windows event logs do not record everything that happened on the machine. Even where a recording feature exists, quite a lot of it isn't enabled by default. Depends on the audit policy.
Even if the recording settings are enabled, event logs have a capacity limit. Depending on the settings, old events get overwritten first.
Logs can also be deleted by the attacker. In ransomware incidents, there are even cases where deletion is automated, and it's not rare for the logs to be wiped clean after the attack.
The possibility of log tampering can't be completely ruled out either. EVTX has a checksum mechanism for integrity checking, but it's not a cryptographic tamper-prevention mechanism. That said, it takes more effort than simply deleting logs, so you don't run into it very often in actual incidents.
Preserve logs before they're lost
While you're reading this article, new events are being recorded and old ones overwritten. The Security log, which is especially useful for investigation, gets overwritten fast — you're lucky if a few days' worth survives, and sometimes only 1–2 hours' worth is left. (Like when it's buried under logon failures.). If you've got time to hesitate, preserve first.
Also, after preservation, it's a good idea to make a list of what period each log covers, and to note down what the log retention settings were.
Reducing noise from massive logs
In event log investigation, be prepared to look at several GB of logs per client machine, and tens to hundreds of GB for servers. No way anyone can actually do that. That's why how to reduce noise from a massive pile of events is extremely important.
The events recorded differ greatly depending on the machine's role and usage, so there's no one-size-fits-all guideline, but understanding how the device is normally used is a big help in finding abnormal events.
"Just look at everything already"? I will punch you.
2. Purpose
You can't investigate logs without knowing what you're trying to investigate. Break down from the big goal and clarify the investigation's purpose.
A viewpoint like 5W1H works, or a framework like the Cyber Kill Chain. Organizing around some axis makes it easier to reduce gaps and overlaps in your investigation items.
- Did an intrusion occur? (Detection)
- Where did they get in? (Initial access)
- How did it spread? (Lateral movement / Persistence)
- What did they do? (Activity)
- What was affected? (Impact scope)
- Why was it possible? (Cause)
Stuff like that.
The reason you want to investigate is usually "whether there was an intrusion", and if there was, "whether there was data leakage" or something along those lines. So what do you need to look at to investigate that? What's recorded in logs is just individual concrete events, so from the chain of those, build and verify hypotheses like "what happened? and if it happened, what other traces should remain?".
For example, if you want to know "whether there was data leakage", the event log is never going to literally say "data was leaked". What you should look at is the traces of actions that could occur on the way to leakage — suspicious logons, file access, external communication, removable media connections, access to admin shares, execution of suspicious tools, and so on.
The Windows Forensic Analysis POSTER published by the SANS Institute is fairly comprehensive, so check it out. The poster itself also covers other artifacts, but it's a useful reference from the perspective of "so this kind of trace might get recorded".
3. Cutting Scope
Log investigation has no end (seriously). Resources vanish in proportion to how much you throw at them, so cutting the scope of what and how far you investigate up front is important. If the results show the scope was too small, you can think about it then.
- Which hosts to investigate? (Servers? Clients?)
- Which time period? (Before/after the suspected intrusion? Before/after the detection time?)
- Which logs? (Security? System? Application? PowerShell? TaskScheduler?)
- Which users? (Admins? Regular users? Service accounts?)
- Which behaviors? (Logon? Process execution? Lateral movement? Persistence?)
When investigating a recent intrusion, finding another suspicious trace that must have happened years ago is a common thing. Of course that itself is worth watching closely, but dealing with the intrusion happening now takes priority.
4. The Knack of Investigation
Once you've decided what you want to investigate and the scope, actually go look at the logs. Use major Event IDs as starting points, and expand the logs and events you look at according to your hypotheses.
Searching by Event ID
Basically, it's best to refer to trusted official docs like MS Learn. If Sysmon is installed you can see finer events too,,, but most environments don't have it. Don't get your hopes up.
Speaking only of the Security log, the Security Log Encyclopedia is also very helpful. There are lots of undocumented events, so if there's an Event ID you're curious about, look it up there.
If you still can't find it, you might find it on detection.wiki or MyEventlog. Amazingly, Event ID is an insane spec that is not a unique identifier, but they're properly organized per Provider/Channel.
For even more niche ones, Googling like crazy will sometimes turn them up. If you've preserved a disk image of the actual machine, you could forcibly boot it and open the logs directly in Event Viewer, I guess.
Reverse-Lookup by Behavior
If you know the tools or techniques used, it's good to look for traces while referring to things like JPCERT/CC's Tool Analysis Result Sheet.
You can also look at Yamato Security's Guide to Windows Event Log Settings for DFIR and Threat Hunting. It references Sigma and discusses what the default event log settings look like. If possible, look at the original Sigma rule definitions too, but there are so many there's no way you could memorize them.
5. Using Generative AI
If your contract allows it, you can use generative AI. As a starting point for looking up Event IDs or fields you're curious about, brainstorming possible attack techniques, writing search queries, organizing investigation results. Lots of places to use it.
However, you must not use AI answers as-is as investigation results. If you ask about niche Event IDs or Windows specs, it will often generate plausible-sounding wrong explanations. Always verify.
Also, logs handled in incident response contain large amounts of sensitive info: usernames, IP addresses, hostnames, file paths, email addresses, etc. Judge carefully whether you may input logs or evidence data to AI.
6. Reporting
Report what might have happened as a result of the investigation and what to do next. Or, if that's not the analyst's job, it's good to clarify where someone else's territory begins. In incident response, pushing nasty work onto each other happens often enough, so negotiating it in advance makes things smoother.
Also, for the materials you hand to the report recipients, you must hammer them into your brain enough that you can explain everything no matter what you're asked. For everything else, just keep materials on hand so you can answer if asked.
If there's a second opinion involved, or the customer has security expertise, you might get asked "Did you check ◯◯?". Resources are limited so you don't need to prepare for everything, but be able to explain why you didn't check that item. "I excluded it from the investigation for such-and-such reasons. It's out of contract scope." and so on.
Also, it's fine to narrow down what you report. Rather, there is absolutely no need to report every hypothesis conceivable from the investigation results. To avoid needlessly worrying or confusing the other party with baseless hypotheses, it's enough to report focusing on the highest-confidence hypothesis and the investigation you did to verify it.
Appendix-1: Major Event IDs
From the perspective of finding a starting point, it's good to look at the following major Event IDs. If you can find a suspicious event as a starting point, diligently tracing the timeline before and after it should turn up something useful even for unknown events.
Logon / Authentication
See who, when, from where, logged onto which machine (lateral movement). Start investigating from the machine where the problem occurred, or the jump server that's the entry point from the internet.
When looking, be conscious of whether the recorded event is from the logon source or the logon destination.
Recorded on the destination
- Security.evtx
Recorded on the source
- Security.evtx
- 4648: A user successfully logged on with explicit credentials while already logged on as a different user
Recorded on the origin of the operation
Event ID 4672 can be correlated with 4624 via Logon ID, so it's useful.
- Security.evtx
About Logon Types
The LogonType of Event ID 4624 is extremely important. For lateral movement, focus on 3 (Network) and 10 (RemoteInteractive), and also look at 9 (NewCredentials) and the like as support.
| Logon Type | Description |
|---|---|
| 0 | Logon type used only by the SYSTEM account. |
| 1 | No information. On Reddit, the rumor is it's a leftover from the NT 3.x era. |
| 2 | Interactive. Logon where a user interactively uses the machine. Console logon, RUNAS, remote shell, KVM, operation via Lights-Out cards, IIS Basic Auth (before 6.0), etc. |
| 3 | Network. Logon to access a target over the network. Shared access via net use, MMC snap-in to a remote computer, PowerShell WinRM, PsExec, Remote Registry, Remote Desktop Gateway, vulnerability scanners, IIS Integrated Windows Auth, SQL Windows Auth, etc. LogonUser does not cache credentials for this logon type. As a rule, reusable credentials do not remain in the destination LSA session, but watch out for exceptions like when Kerberos delegation is enabled. PsExec, when explicit credentials are specified, can create multiple Network + Interactive logon sessions. |
| 4 | Batch. Logon for running a process on behalf of a user without their direct operation. Scheduled tasks, etc. Also used for high-performance server purposes like mail/web servers that process many plaintext auth attempts at once. LogonUser does not cache credentials for this logon type. However, in scheduled tasks, the password may be stored on disk as an LSA Secret. |
| 5 | Service. Logon by a service. The target account needs the "Log on as a service" right. Credentials for running the service can remain in the LSA session as reusable credentials. Also, the password may be stored on disk as an LSA Secret. |
| 6 | Proxy (proxy logon). Officially described as a proxy-type logon. On Reddit, the rumor is it's for internal/dev builds only. |
| 7 | Unlock. Workstation unlock. A logon type for recording the unlock of a user interactively using the machine, like via GINA DLL. |
| 8 | NetworkCleartext (network plaintext auth). Holds the name and password in the auth package, and the server can connect to other network servers while impersonating the client. IIS Basic Auth (6.0+), PowerShell WinRM with CredSSP, etc. Reusable credentials remain on the destination side, so the credential-theft risk is high. |
| 9 | NewCredentials. Clones the current token and specifies different credentials for outbound network connections. Locally keeps the original identity, and only uses the specified credentials for network connections. RUNAS /NETWORK, etc. Reusable credentials can remain in the LSA session, so be careful. |
| 10 | RemoteInteractive (remote interactive). Remote and interactive terminal services session. Remote Desktop, etc. Not only successful RDP logons, but 4625 logon failures can also be recorded as RemoteInteractive. Reusable credentials remain in the destination LSA session, so privileged account RDP to a compromised machine is dangerous. |
| 11 | CachedInteractive (cached interactive). Interactive logon using cached credentials without accessing the network. Not necessarily a logon that authenticated by querying a domain controller. |
| 12 | CachedRemoteInteractive (cached remote interactive). Same as RemoteInteractive. For internal audit purposes. |
| 13 | CachedUnlock (cached unlock). Workstation unlock using cached credentials. |
About Logon Failure Reasons
For Event ID 4625 logon failures, looking at the logon error code tells you why it failed.
Like the username doesn't exist in the first place, or the username is right but the password is wrong... This tells you how much information the attacker had at the time they performed the action. For example, if they logged on successfully on the first try, they were dumping passwords somewhere, or it may have been leaked beforehand.
Kerberos / NTLM
In a domain environment, from Kerberos / NTLM authentication logs you can trace which account, from which machine, tried to authenticate to which service or machine.
Recorded on the destination
- Microsoft-Windows-NTLM%4Operational.evtx
Recorded on the source
- Microsoft-Windows-NTLM%4Operational.evtx
Recorded on the DC
4776 is recorded on the DC for domain users. Note that the event records the name of the authenticating machine, but not the destination machine.
-
Security.evtx
-
Microsoft-Windows-NTLM%4Operational.evtx
RDP / TerminalServices
Look at RDP connection attempts, authentication, session start, disconnect, reconnect, etc. Even if the Security event log has been wiped, RDP-related logs often remain, so sometimes you can trace the flow from here.
Recorded on the destination
-
Security.evtx
-
Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
- 21: Remote Desktop Services: Session logon succeeded
- 22: Remote Desktop Services: Shell start notification received
- 23: Remote Desktop Services: Session logoff succeeded
- 24: Remote Desktop Services: Session has been disconnected
- 25: Remote Desktop Services: Session reconnection succeeded
- 39: Remote Desktop Services: Session disconnected by another session
- 40: Remote Desktop Services: Session disconnected (with reason)
-
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
- 261: Listener RDP-Tcp received a connection
- 1146: Remote Desktop Services: Session initialization succeeded
- 1147: Remote Desktop Services: Session connection succeeded
- 1148: Remote Desktop Services: Session connection failed
- 1149: Remote Desktop Services: User authentication succeeded (however, this alone doesn't confirm a successful RDP logon)
-
System.evtx
- 9009: Desktop Window Manager terminated (may be recorded on RDP session disconnect etc. Note that it's also used for other things.)
Recorded on the source
- Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx
Process Execution
What was launched, under whose privileges, from where, etc. It's often disabled, so if you have it, count yourself lucky.
4688 is recorded when "Audit Process Creation" is enabled. Furthermore, the command line is only recorded if you separately enable "Include command line in process creation events".
PowerShell / Scripting
PowerShell startup, execution content, script blocks, logs, etc. Settings-dependent, so if it's recorded, look at it as much as possible. Some run on a schedule, so grasp the normal operation and do your best to cut noise.
- Windows PowerShell.evtx
- Microsoft-Windows-PowerShell%4Operational.evtx
WMI
Operations via WMI, and event filters / consumers used for persistence. Fairly noisy, so you don't need to look too hard.
- Microsoft-Windows-WMI-Activity%4Operational.evtx
Lateral Movement / Remote Operation
Look at traces of share access, admin shares, file operations over SMB, and remote operations. Many techniques use SMB or admin shares for lateral movement, like PsExec, so it's worth checking.
Recorded on the destination
-
Security.evtx
-
Microsoft-Windows-SMBServer%4Security.evtx
-
Microsoft-Windows-SMBServer%4Operational.evtx
Recorded on the source
-
Microsoft-Windows-SMBClient%4Connectivity.evtx
- 30800: Cannot resolve server name
- 30803: Network connection failed
- 30804: Network connection was disconnected
- 30805: Client lost session with server
- 30806: Client re-established session with server
- 30807: Connection to share was lost
- 30809: Request timed out because the server didn't respond
- 31001 Security context initialization failed
- 31010 SMB client failed to connect to the share
-
Microsoft-Windows-SMBClient%4Security.evtx
Recorded on the host where share settings were changed
- Security.evtx
Service Modification
Look at service creation, start, stop, and startup type changes. Traces of PsExec-family tools, persistence, EDR/AV termination, backup product termination, etc. can be left.
- Security.evtx
- 4697: A service was installed
- System.evtx
Scheduled Tasks
Look at task creation, deletion, enable, disable, update, and execution. It's often used for malware persistence and delayed execution, so check the task name, execution command, creator, and creation time for anything suspicious.
-
Security.evtx
-
Microsoft-Windows-TaskScheduler%4Operational.evtx
- 100: Task started
- 101: Task failed to start
- 102: Task completed
- 103: Action failed to start
- 106: Task registered
- 107: Task triggered by scheduler
- 108: Task triggered by event
- 110: Task triggered by user
- 111: Task terminated
- 118: Task triggered on computer startup
- 119: Task triggered on logon
- 129: Task process created
- 140: Task registration info updated
- 141: Task registration deleted
- 142: Task disabled
- 200: Action started
- 201: Action completed
- 203: Action failed to start
Account / Group Management
Look at account creation, deletion, enable, password change, and group additions. In cases where the attacker was in for a long time, weird accounts are often added.
In particular, check for member additions to strong-privilege groups like Administrators, Domain Admins, and Enterprise Admins.
- Security.evtx
- 4720: A user account was created
- 4722: A user account was enabled
- 4723: An attempt was made to change an account's password
- 4724: An attempt was made to reset an account's password
- 4725: An account was disabled
- 4726: A user account was deleted
- 4728: A member was added to a security-enabled global group
- 4729: A member was removed from a security-enabled global group
- 4730: A security-enabled global group was deleted
- 4731: A security-enabled local group was created
- 4732: A member was added to a security-enabled local group
- 4733: A member was removed from a security-enabled local group
- 4734: A security-enabled local group was deleted
- 4735: A security-enabled local group was changed
- 4737: A security-enabled global group was changed
- 4738: A user account was changed
- 4740: A user account was locked out
- 4756: A member was added to a security-enabled universal group
- 4757: A member was removed from a security-enabled universal group
- 4764: A group type was changed
Policy Change
Active Directory Object Change
- Security.evtx
Windows Firewall
Look at communications by WFP (Windows Filtering Platform) and Windows Firewall setting changes. The communication stuff is fairly noisy and rarely useful, but you can look at it anyway.
Communication related
- Security.evtx
- 5152: WFP blocked a packet
- 5154: WFP permitted an application or service to listen on an inbound port
- 5155: WFP blocked an application or service from listening on an inbound port
- 5156: WFP permitted a connection
- 5157: WFP blocked a connection
- 5158: WFP permitted a bind to a local port
- 5159: WFP blocked a bind to a local port
Windows Firewall setting changes
Watch carefully for things like Direction being Inbound/Outbound, Action being Allow/Block, Enabled being True/False, Profile being Domain/Private/Public, etc.
- Security.evtx
- 4946: A Windows Firewall rule was added
- 4947: A Windows Firewall rule was modified
- 4948: A Windows Firewall rule was deleted
- 4949: Windows Firewall settings were restored to default
- 4950: A Windows Firewall setting was changed
- 4954: Windows Firewall group policy settings were changed / applied
- 4956: The active profile of Windows Firewall was changed
Microsoft Defender (formerly Windows Defender)
Look at malware detection, removal/quarantine, and disabling of protection features. Check the detection name, target path, action taken, and when protection was stopped.
There are a fair number of cases where it detected something but didn't remove/quarantine it, so it ended up running.
Note that the evtx name can differ by environment.
- Microsoft-Windows-Windows Defender%4Operational.evtx
- 1116: Detected malware or potentially unwanted software
- 1117: Took action on a detected threat
- 1118: Failed to take action on a detected threat
- 1119: Failed to take action on a detected threat with a critical error
- 5001: Real-time protection was disabled
- 5004: The configuration of real-time protection was changed
- 5007: Microsoft Defender Antivirus configuration was changed
- 5010: Scanning for malware and potentially unwanted software was disabled
- 5012: Virus scanning was disabled
- 5013: Tamper Protection blocked changes to Defender settings
Log Tampering / Trace Deletion
Log clearing, Event Log service stop, audit event discard, etc.
As written at the beginning, when investigating logs, it's better to first make a list of which logs survive from when to when. So you don't end up with "No suspicious logons found!" → "Since when has the Security log been preserved?" → "...".
-
Security.evtx
-
System.evtx
- 104: Other log cleared
Log Rotation
You might not use this much in investigation, but knowing it makes it easier to judge why there's a gap in the logs when you see one.
For event logs, you can specify per Channel "maximum size" and "what to do when full". The latter has the following three options.
- Overwrite events as needed (overwrite old events as needed)
- Archive the log when full, do not overwrite events (archive the full file and record to a new log file)
- Do not overwrite events / Clear log manually (don't record new events when full)
1 reuses old log space in a FIFO manner to write new events. So old RecordID/RecordNumber numbers appear to be missing. Don't jump to "attacker deletion" just because there's a gap — check the rotation settings and think about why it's gone.
2 archives (auto-backs-up) the full log while creating a new file and keeps recording. As an investigator this is the happiest option, but naturally it eats up capacity fast. If you want to design log management properly, rather than hoarding it on local disk, you should design it to forward to an event log collection server or SIEM for storage. Also in this case, 1105 is recorded in the Security log.
3 stops recording new events once full. This setting is genuinely a pain, please stop using it. What possible joy does it bring. Also in this case, 1104 is recorded in the Security log.
Time / Power / Reboot / Shutdown
Log time settings and such — unglamorous but important. Also I check whether the power state is consistent with other traces. If something is recorded at a time when the power should be off, one of them is wrong. (Or sometimes I'm the one who's wrong.)
- Security.evtx
- 4616: The system time was changed
- System.evtx
- 12: Kernel-General: OS started
- 13: Kernel-General: OS initiated shutdown
- 41: Kernel-Power: System rebooted without a clean shutdown
- 1074: User32: Shutdown/reboot initiated by a process or user
- 6005: EventLog: Event Log service started
- 6006: EventLog: Event Log service stopped
- 6008: EventLog: The previous shutdown was unexpected
- 6009: EventLog: OS version info at boot
- 6013: EventLog: System uptime
Application Anomaly
Application crashes, etc. Sometimes there's info on user-installed applications, sometimes not.
- Application.evtx
Sysmon
If Sysmon is installed, honestly you won't struggle much if you just look at this and logons.
If you're about to set it up, or want to observe malware behavior in an analysis environment, install it. That said, it's not install-and-done; if you don't tweak the config yourself to some extent, it tends to get noisy. The classic config is SwiftOnSecurity/sysmon-config.
A standard feature from Win11 (not that I'm saying it's enabled)
- Microsoft-Windows-Sysmon%4Operational.evtx
- 1: Process creation
- 2: A process changed a file creation time
- 3: Network connection detected
- 4: Sysmon service state changed
- 5: Process terminated
- 6: Driver loaded
- 7: Image loaded
- 8: CreateRemoteThread
- 9: RawAccessRead
- 10: ProcessAccess
- 11: FileCreate
- 12: RegistryEvent (Object create and delete)
- 13: RegistryEvent (Value Set)
- 14: RegistryEvent (Key and Value Rename)
- 15: FileCreateStreamHash
- 16: Sysmon config state changed
- 17: Pipe created
- 18: Pipe connected
- 19: WmiEventFilter activity detected
- 20: WmiEventConsumer activity detected
- 21: WmiEventConsumerToFilter activity detected
- 22: DNSEvent
- 23: FileDelete
- 24: ClipboardChange
- 25: Process Tampering
- 26: File Delete Logged
- 27: File Block Executable
- 28: File Block Shredding
- 29: File Executable Detected
- 255: Error
Appendix-2: Major Log Channels
Preservation itself is fine to just do for everything, but when it's time to actually look and you have no idea what's what, it's time for determined visual grepping. For now, when you want to narrow by Provider/Channel count and skim, focus on the following.
- Application.evtx
- Directory Service.evtx
- Microsoft-Windows-Bits-Client%4Operational.evtx
- Microsoft-Windows-CodeIntegrity%4Operational.evtx
- Microsoft-Windows-DNS-Client%4Operational.evtx
- Microsoft-Windows-DNSServer%4Audit.evtx
- Microsoft-Windows-GroupPolicy%4Operational.evtx
- Microsoft-Windows-Kernel-Boot%4Operational.evtx
- Microsoft-Windows-Microsoft Defender%4Operational.evtx
- Microsoft-Windows-NTLM%4Operational.evtx
- Microsoft-Windows-PowerShell%4Admin.evtx
- Microsoft-Windows-PowerShell%4Operational.evtx
- Microsoft-Windows-RemoteDesktopServicesRdpCoreTS%4Operational.evtx
- Microsoft-Windows-SMBClient%4Operational.evtx
- Microsoft-Windows-SMBClient%4Security.evtx
- Microsoft-Windows-SMBServer%4Operational.evtx
- Microsoft-Windows-SMBServer%4Security.evtx
- Microsoft-Windows-SmbClient%4Connectivity.evtx
- Microsoft-Windows-Sysmon%4Operational.evtx
- Microsoft-Windows-TaskScheduler%4Operational.evtx
- Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
- Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx
- Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
- Microsoft-Windows-Time-Service%4Operational.evtx
- Microsoft-Windows-WMI-Activity%4Operational.evtx
- Microsoft-Windows-WinRM%4Operational.evtx
- Microsoft-Windows-Windows Defender%4Operational.evtx
- Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx
- Microsoft-Windows-Windows Firewall With Advanced Security%4FirewallDiagnostics.evtx
- Microsoft-Windows-WindowsUpdateClient%4Operational.evtx
- Security.evtx
- Setup.evtx
- System.evtx
- Windows PowerShell.evtx
Appendix-3: How to Use Analysis Tools
For Non-Analysts
If you're a field SE or device administrator and you're told to check the logs right now to see whether there might be an intrusion, use the Windows built-in Event Viewer. You can search and filter in the GUI, so it's plenty usable for an initial check.
Even if you're told to export because the investigation department or an external party will handle it, you can save from Event Viewer.
Just click Save All Events As... in the right sidebar.
However, do NOT hand a CSV export to CSIRT or an analyst. Seriously, stop.
From the investigator's side, they have to start by reshaping that garbage CSV into something usable, which is extra work. Also a lot of information is lost. If you're handing it to the investigator, preserve it in .evtx format, not .csv.
Below is an example of a baffling CSV file exported from Event Viewer. A single column contains a large number of line breaks. I will smack you.
If you're collecting data with fast forensics in mind, use something like CDIR-Collector. Click the exe a few times and you can grab the major data in one go.
However, this tool's recognition is limited to Japan, so if you hand it to an overseas security vendor, they'll go "what's that?". Ask the other party which tool to collect with. They'll probably specify CyLR, KAPE, or Velociraptor..
The actual files to preserve are under C:\Windows\System32\winevt\Logs\, but directly copying the files can fail due to locking. If possible, it's safer to get them via the proper export procedure.
If you want to do it with standard commands, here you go. Use this when it's hard to bring external tools in.
Analysts
If you're CSIRT or a forensic investigator, pick whichever method you like. However, it's good to agree within the team on what to use.
Even if you're a contrarian nerd who loves using a different tool from everyone else, don't forget that you have to be able to explain that the tool can guarantee evidentiary integrity.
You need to be able to explain how the tool you used parses what, what format it outputs, and how it maps to the original log.
Below is my personal recommendation order.
| Parser | Overview | Notes |
|---|---|---|
| EvtxECmd | A command-line tool that converts EVTX files to CSV or JSON. | One of the tool suites by Eric Zimmerman, a SANS instructor. Widely used for DFIR. |
| evtx2es/evtx2json | A command-line tool that imports EVTX files into Elasticsearch / converts to JSON. | I made it because the Python parser that was the de facto standard at the time was ridiculously slow. Handy when you want to embed it into your investigation system, such as Elasticsearch or DuckDB. |
| plaso | A tool that creates a super timeline from various artifacts. | Closer to a framework than a single conversion tool. Fairly complex. |
| log2timeline | The perl-based predecessor to plaso. This one is relatively simple. | A tool from way back in ancient times, so unless you have a strong reason, you don't need to adopt it now. |
| PowerShell | Windows' built-in scripting language. Can be used to extract and shape event logs. | Reusable once you make it. Watch out, because a bug can cause secondary damage. |
| Log Parser | A command-line tool provided by Microsoft. Analyzes logs with SQL-like queries. | An official tool, but development has ended. Barely any docs. Someone please write them. |
| Analysis / Shaping Tool | Overview | Notes |
|---|---|---|
| Timeline Explorer | A tool for viewing CSV etc. in timeline format. Strong at filtering and grouping. | One of Eric Zimmerman's tools. Basically the one to use for a quick look, but saving/loading project files is weak. |
| Quilt | A fast CSV filtering / conversion tool. | Made to address pain points when using xsv (processing 100GB-class text, chaining processing, etc.). |
| LibreOffice Calc | Open-source spreadsheet software. | Usable even where there's no Excel. Huge CSVs are a bit tough, huh. |
| Excel | Spreadsheet software from Microsoft. Everyone knows it. | Paid. Lots of users, but it can't load huge logs and auto-converts times to numbers. Unbelievable. |
| Elasticsearch + Kibana | Search engine / visualization tool. Efficiently analyzes super-large logs. | Strong at log indexing and cross-search. The query language is a rookie-killer, so using it together with generative AI might help. |
| Event Log Explorer | A GUI tool specialized for viewing and analyzing event logs. | Paid for commercial use. A trusted tool also used in SANS training, but I don't find it very easy to use. |
| TimeSketch | A Google-made log analysis support tool. You can flag suspicious ones in the GUI. | High affinity with plaso. I tried it, and it is seriously slow. Maybe it has merits if multiple people work simultaneously. |
| Log Parser Studio | A GUI front-end for Log Parser. | Probably no longer distributed. You can still find it if you look, though. |
| Log Parser Lizard | A GUI tool in the Log Parser family. | More capable than Log Parser Studio. But I can't really figure out how to use it. |
| Splunk | A commercial log management / analysis platform. Strong at searching and visualizing huge logs. | I hate it. |
Also, slightly different in flavor from the above, an intro to hunting tools?. You can scan logs with pre-made detection rules and catch suspicious events.
They don't just extract simply but also process and normalize, so it's hard to use the results directly for reporting, but a quick scan to grasp the overall picture and then detailed analysis makes it easy to find suspicious points fast.
That said, false positives can't be prevented, so don't swallow the results whole and watch out for bias.
| Hunting Tool | Overview | Notes |
|---|---|---|
| Zircolite | A tool that scans event logs with Sigma rules and detects. | The pioneer of this kind of tool, I think. (Sorry if I'm wrong.) |
| Chainsaw | Same as above. Insanely fast. | Seems fairly popular overseas. |
| Hayabusa | Same as above. Super high-function. | The famed Yamato Security product. Docs are abundant and easy to use. The commit frequency is insane. |
Working with CSV
For human eyes, CSV is the most handable format. You can grep it too.
EvtxECmd is recommended. Convert with file spec -f or folder spec -d.
With a folder spec, the .evtx files underneath are merged into a single .csv.
Timeline Explorer is recommended for data filtering.
You can filter with conditions like Event Id = 4624, click columns to sort, group, and do almost anything you can think of.
However, note that the various filters can't be saved (bug?). Automation is also difficult, but for a "let's just roughly look at it" moment, this is fine.
Once you've established your investigation methodology to some extent, consider automating it. See Log Analysis Patchwork for details.
Working with JSON
If you're systematizing, or handing data to AI, this way is better. You don't have to worry about headers, and it's easier to manage meaning through structure.
Download evtx2es. The exe version may be detected by Defender, so if that bothers you, install via pip or clone the repository.
You can put it into Elasticsearch and analyze it, but if you feel the system side is overly complex for simple tasks like searching, use DuckDB. It comes with a Web UI too, which is a nice bonus.
You can work with JSONL files directly.
Or you can make a table out of it.
If you just want to poke at it from the CLI, jq works too, but the commands aren't very intuitive so I can never remember them. Ask AI, or just do it with CSV.
Closing
I'm so done with event log investigations!
The end