As Windows auditing subsystem is complex, this article focuses on part of it: the Event Logger. In modern Windows systems audit events are saved to files with extension .evtx (Windows XML Event Log). These files are stored in C:\Windows\System32\winevt\Logs location. As the log files are saved in binary XML format, we need specialized libraries to open and convert them to readable format.
Sample subset of Windows Event logs
The problem starts once we opened .evtx files. Where to start? For instance the log fileSecurity.evtx, with provider Microsoft-Windows-Security-Auditing, consists of at least 412 unique Event IDs — based on WELM project datasets — and a lot of them will not be useful for our investigation.
Example of an important event ID:
Event 4624: An account was successfully logged on
So it generates a fundamental question: which log files are the most important?
Of course, we can say every of file is important and only the sky is a limit. But still we are limited in time, as always, and we must start with some baseline. In the table below we provide you with a summary of the minimum log files that are usually useful and universal for every type of DFIR case (at least it works for me). The list is not exhaustive but might be a silver bullet during the beginning of the investigation, assuming the audit will be set properly to log successful and failed events.
Important logs summary
Log file name
What information it provides
Windows PowerShell.evtx
- PowerShell audit
System.evtx
- Audit log clearing
- Services installation/execution/modification
Security.evtx
- Modifications in account/groups
- Audit log clearing
- Windows firewall connections
- User logons
- Process creation
- Creation/Deletion/Modification of Scheduled tasks
- Services installation
Microsoft-Windows-WinRM%4Operational.evtx
- WinRM sessions
Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx
- Windows firewall connections
- Windows firewall rules modification
Microsoft-Windows-Windows Defender%4Operational.evtx
- Antivirus logs
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
- RDP logons
Microsoft-Windows-TerminalServices-RDPClient%254Operational.evtx
- RDP logons
Microsoft-Windows-TaskScheduler%4Operational.evtx
- RDP logons
Microsoft-Windows-TaskScheduler%4Operational.evtx
- Creation/Deletion/Modification of Scheduled tasks
- Execution of Scheduled tasks
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx
- RDP logons
Microsoft-Windows-Sysmon%4Operational.evtxx
- Very detailed auditing events from various categories focused on malicious or anomalous activity
Microsoft-Windows-PowerShell%4Operational.evtx
- Full content of ScriptBlocks
- PowerShell audit
Now when we know which log files are good to start, it is time to focus on particular Event IDs (EIDs) which will be crucial for our investigation. Facing this problem, I realized that the significant number of EIDs, and the necessity to select the meaningful ones, is not the only a challenge to face, but also the normalization of data. And when the problems of Scalability, Normalization and reducing investigation time arise, it is an indicator that it is the right time for automation. Thus, I came up with the idea to create a tool for fast initial triage of Windows Event Logs – https://github.com/yarox24/EvtxHussar.
TL;DR;
You can check github project to see how it works. If you are looking only for these EIDs, which are “crown jewels”, check this out here https://github.com/yarox24/EvtxHussar/tree/main/maps.
The tool has been written in GoLang. To simplify importing new Event IDs (EID) all EIDs were saved as external files in YAML format. It supports all log files from the above table, and contains list of important EIDs. The minimum EIDs collection – required for initial triage – is available here https://github.com/yarox24/EvtxHussar/tree/main/maps
As an input It takes the path to folder with multiple .evtx files from various computers. The output will be segregated based on computer names present in log files. If you are in possession of logs from backup or VSS, you should also provide them as output events will be deduplicated.
Depending on future post-processing needs there are following options:
- .xlsx (Excel, this one is default)
- .csv (Comma separated)
- .json
- .jsonl (newline-delimited JSON)
The output is saved in different categories of events (logons, PowerShell etc.) inside single directory with the same computer name.
Example directory structure for single computer with hostname: DESKTOP-SecurityDive (with Excel format as output):
Output from single file (truncated) – Click to preview on full screen
The next challenge is normalization. Indeed it is the biggest concern whenever log parsing comes in. The objective I put for EvtxHusar is to minimize the number of unnecessary fields, especially duplicates like Application, ApplicationName, ApplicationPath or ID, RuleID or ProcessName, Process. To solved it, I implemented simple mapping with YAML option: fields_remap.
fields_remap in FirewallUniversal.yaml
By Jaroslaw Oparka,
Principal CERT Engineer
Share this article
