Month of PowerShell - Working with the Event Log, Part 4 - Tweaking Event Log Settings

#monthofpowershell

In part 1, we looked at the PowerShell command to work with the event log: [code]Get-WinEvent[/code], with some examples for filtering the results and using the pipeline. In part 2 we looked at 10 practical examples of using [code]Get-WinEvent[/code] to perform threat hunting. In part 3 we looked at using [code]Convert-EventLogData[/code] to make the [code]Message[/code] 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.

Lots of Log Sources

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:

PS C:\Windows\system32> Get-ComputerInfo | Select-Object -Property OsName

OsName
------
Microsoft Windows 11 Enterprise


PS C:\Windows\system32> (Get-WinEvent -ListLog *).Count
451

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 [code]IsEnabled[/code] property:

PS C:\Windows\system32> Get-WinEvent -Listlog * | Where-Object -Property IsEnabled -EQ $false | Select-Object -Property LogName

LogName
-------
Windows Networking Vpn Plugin Platform/OperationalVerbose
Windows Networking Vpn Plugin Platform/Operational
Network Isolation Operational
Microsoft-Windows-ZTraceMaps/Operational
Microsoft-Windows-Wordpad/Admin
Microsoft-Windows-wmbclass/Trace
...
PS C:\Windows\system32> (Get-WinEvent -ListLog * | Where-Object -Property IsEnabled -Eq $false).count
86

On Windows 11, 86 log sources are disabled by default. Fortunately, we can change that with PowerShell!

Turning on Useful Logging

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 [code]Get-LogProperties[/code]. Next, change the [code]Enabled[/code] property to [code]$true[/code] with [code]Set-LogProperties[/code]:

PS C:\Windows\system32> Get-LogProperties 'Microsoft-Windows-DNS-Client/Operational'


Name       : Microsoft-Windows-DNS-Client/Operational
Enabled    : False
Type       : Operational
Retention  : False
AutoBackup : False
MaxLogSize : 1052672



PS C:\Windows\system32> $logsource = Get-LogProperties 'Microsoft-Windows-DNS-Client/Operational'
PS C:\Windows\system32> $logsource.Enabled = $true
PS C:\Windows\system32> Set-LogProperties -LogDetails $logsource
PS C:\Windows\system32> Get-LogProperties 'Microsoft-Windows-DNS-Client/Operational'


Name       : Microsoft-Windows-DNS-Client/Operational
Enabled    : True
Type       : Operational
Retention  : False
AutoBackup : False
MaxLogSize : 1052672

Logging Capacity

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:

PS C:\Windows\system32> (Get-WinEvent -ListLog * | Where-Object -Property LogMode -EQ 'Circular' | Where-Object -Property MaximumSizeInBytes -LT 1.1MB).Count
395

For the three classic logs, the default for maximum log size before old events are purged (circular logging) is about 20 MB:

PS C:\Windows\system32> Get-WinEvent -ListLog Application,Security,System

LogMode   MaximumSizeInBytes RecordCount LogName
-------   ------------------ ----------- -------
Circular            20971520        2347 Application
Circular            20971520       15600 Security
Circular            20971520        2732 System

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 [code]Get-LogProperties[/code] and [code]Set-LogProperties[/code], but not so:

PS C:\Windows\system32> $logsource = Get-LogProperties Security
PS C:\Windows\system32> $logsource.MaxLogSize = 100MB
PS C:\Windows\system32> Set-LogProperties -LogDetails $logsource
Failed to save configuration or activate log Security.
The parameter is incorrect.

My testing indicates that you can use [code]Set-LogProperties[/code] to change the [code]IsEnabled[/code] property, but not the [code]MaxLogSize[/code] property. However, we can create an [code]System.Diagnostics.Eventing.Reader.EventLogConfiguration[/code] object in PowerShell, initialized with the settings from a named event log, then change the [code]MaximumSizeInBytes[/code] property and save the changes using the [code]SaveChanges()[/code] method:

PS C:\Windows\system32> $logsource = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Security
PS C:\Windows\system32> $logsource.MaximumSizeInBytes = 100MB
PS C:\Windows\system32> $logsource.SaveChanges()
PS C:\Windows\system32> Get-LogProperties 'Security'


Name       : Security
Enabled    : True
Type       : Admin
Retention  : False
AutoBackup : False
MaxLogSize : 104857600

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.

Projecting Entries Per Log Source

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 [code]FileSize[/code] and [code]RecordCount[/code] properties for a specific log using [code]Get-WinEvent -ListLog[/code]:

PS C:\Windows\system32> $seclog = Get-WinEvent -ListLog Security
PS C:\Windows\system32> $seclog.FileSize
18944000
PS C:\Windows\system32> $seclog.RecordCount
21659
PS C:\Windows\system32> $avgentrysize = [Math]::Round($seclog.FileSize / $seclog.RecordCount, 0)
PS C:\Windows\system32> $avgentrysize
875

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:

PS C:\Windows\system32> ($seclog.MaximumSizeInBytes - $seclog.FileSize) / $avgentrysize
98186.9714285714

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:

PS C:\Windows\system32> $now = Get-Date
PS C:\Windows\system32> $then = (Get-Date).AddDays(-24)
PS C:\Windows\system32> (Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=$then; EndTime=$now}).count
9087

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:

PS C:\Windows\system32> 98187/9087
10.8052162429845

This tells us that we get less than 11 days of logging entries before the log overwrites old entries.

Conclusion

In this article we looked at how we can adjusts the configuration of the event log sources, using the [code]Get-WinEvent[/code] cmdlet, but also [code]Get-LogProperties[/code], [code]Set-LogProperties[/code], and a custom [code]System.Diagnostics.Eventing.Reader.EventLogConfiguration[/code] 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!

-Joshua Wright

Return to Getting Started With PowerShell

Joshua Wright is the author of SANS SEC504: Hacker Tools, Techniques, and Incident Handling, a faculty fellow for the SANS Institute, and a senior technical director at Counter Hack.