In part 1, we looked at the PowerShell command to work with the event log: Get-WinEvent, with some examples for filtering the results and using the pipeline. In part 2 we looked at 10 practical examples of using Get-WinEvent to perform threat hunting. In part 3 we looked at using Convert-EventLogData to make the Message property elements more easily accessible in the PowerShell pipeline.
We’ll wrap up our look at working with the event log in PowerShell with some tips for tweaking event log settings.
For many years Windows has had classic and new event log sources. Instead of making all logging data in the three classic sources (Security, Application, System), there are hundreds of different logging sources:
Windows 10 is similarly configured with approximately 440 log sources. However, a significant number of these log sources are disabled. We can test for enabled vs. disabled log sources using the IsEnabled property:
On Windows 11, 86 log sources are disabled by default. Fortunately, we can change that with PowerShell!
Unfortunately, Microsoft offers little documentation about these disabled log sources. However, with some experimentation there are a few worthy of turning on:
To turn on an event log source, retrieve the event log properties using Get-LogProperties. Next, change the Enabled property to $true with Set-LogProperties:
It’s best to turn on new logging sources in a test environment for easy monitoring. Some of these disabled-by-default logging sources will generate a lot of activity which can have negative impact to system performance (but positive impact on your ability to respond to an incident).
One thing about Windows event log sources I find very odd is that Microsoft allocates only a tiny amount of storage for the vast majority of logs. For example, this PowerShell command counts the number of log sources whose total capacity (not to exceed) is just over 1MB:
For the three classic logs, the default for maximum log size before old events are purged (circular logging) is about 20 MB:
Some logs have a lot of churn, like the Security log. It’s not unusual for that log to meet capacity and start overwriting old events within a few days on a busy server. The System and Application logs often have a longer history since they record fewer events (depending on the system).
Let’s change the Security log maximum size to 100MB. This seems like it would be a similar case of Get-LogProperties and Set-LogProperties, but not so:
This is one of (many) times where I find PowerShell frustrating enough that I have to walk away for a few minutes.
My testing indicates that you can use Set-LogProperties to change the IsEnabled property, but not the MaxLogSize property. However, we can create an System.Diagnostics.Eventing.Reader.EventLogConfiguration object in PowerShell, initialized with the settings from a named event log, then change the MaximumSizeInBytes property and save the changes using the SaveChanges() method:
Fine, PowerShell. Be that way.
The big question is this: how large should you make the event log sources? This will depend a lot on organizational policies for log retention periods, how effective your threat hunting/threat identification processes are, and the organizational goals for incident response. Fortunately, we can use PowerShell to get some insight to guide the decision making process.
When figuring out the target size of an event log source, we can consider what the average log entry size is. This is easily accessible in PowerShell by using the FileSize and RecordCount properties for a specific log using Get-WinEvent -ListLog:
By dividing the number of records in the log by the current log file size, we get an approximate average size per log entry. We can use this to estimate the number of possible entries per log file:
This can be useful for planning purposes, but without an idea of how many logs are stored per day it can be difficult to put this into context. Fortunately, we can use filter hash tables and a simple date range query to get an idea of how many events are stored in a day for a specific log:
If the average log entry size is 98,187 bytes and there are 9,087 log entries in a typical 24 hours, then we can figure out approximately how many days of logging entries we can store:
This tells us that we get less than 11 days of logging entries before the log overwrites old entries.
There’s nothing spectacular about this result, and it’s a naive method of estimating (What if a given day is a lot busier? What if the last 24 hours is a slow day? What if the median log size is much larger than the average?). But it gives us a starting point to work with, and to keep adjusting as we monitor.
In this article we looked at how we can adjusts the configuration of the event log sources, using the Get-WinEvent cmdlet, but also Get-LogProperties, Set-LogProperties, and a custom System.Diagnostics.Eventing.Reader.EventLogConfiguration object. With this insight, we can estimate the amount of storage needed for different logs, adjust the size of event log storage to meet organizational needs, and turn on logging sources that provide additional insight for our incident response practices.
In this series we reviewed a lot of different techniques for working with the event log using PowerShell. Before I started writing this series, I felt like it was often easier to just run the Event Viewer GUI to find answers. Now though, I think PowerShell might just be a bit easier, is certainly more flexible, and is a lot faster than waiting for the GUI utility. Working with the event log is not without frustration, and it is well-augmented with third-party scripts to make the data more easily accessible, but with some practice I think I’m able to accomplish a lot more than I could before.
Thank you for reading!
