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.
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
451Windows 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:
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
86On 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:
| Log Source | Description |
|---|---|
| Microsoft-Windows-PrintService/Operational | Capture print job details including file names; often useful for insider incident investigations (thanks to Jake Williams for this tip) |
| Microsoft-Windows-DNS-Client/Operational | Log all DNS queries and cache lookups (Warning: high activity) |
| Microsoft-Windows-TaskScheduler/Operational | Captures details for scheduled task execution |
| Microsoft-Windows-LSA/Operational | Log groups assigned to logins (except for built-in accounts) |
| Microsoft-Windows-CAPI2/Operational | Log Windows Crypto API private keys access |
| Microsoft-Windows-DriverFrameworks-UserMode/Operational | Identify user-mode drivers for potentially malicious USB devices. |
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:
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 : 1052672It'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).
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
395For 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 SystemSome 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:
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.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:
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 : 104857600Fine, 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.
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 FileSize and RecordCount properties for a specific log using Get-WinEvent -ListLog:
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
875By 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.9714285714This 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
9087If 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.8052162429845This 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.
Conclusion
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!
-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.
