Configuring Windows event logs for Enterprise Security use

Ingesting events from the Windows event log is not a complicated process, but you'll typically need to make adjustments to how you configure these logs for Splunk Enterprise Security to ensure you get the most out of this log source. Whether you're looking to ingest these logs for the first time, or you're looking to revisit this log source, you might have questions about ingesting and filtering these logs, including:

• Which Windows audit policies are required to generate logs for my SIEM?
• How can I extract an audit trail from Active Directory?
• How can I qualify which Windows event log security event codes can be safely filtered out?
• What other log sources should I ingest?
• Where can I find an example inputs.conf file for this log source?
• What is best practice for tuning Windows event codes?
• How can I find guidance on creating allow/deny lists for particular event codes?

This article answers these questions and provides some tips for getting started, as well as acts as a reference for a few of the Windows inputs that can be valuable to security professionals.

This article assumes knowledge of how to install the universal forwarder and how to push out configurations via the deployment server.

Audit policy requirements

Windows audit policies are essential within a Windows environment. They tell the host operating system which events to write to the event log, which is a crucial function for incident response and detection. See Configuring Windows security audit policies for Enterprise Security visibility to see which audit policies are required, and how to deploy the policies via group policy object (GPO) within a Windows domain environment.

Active Directory monitoring

In order to enable an audit trail from Active Directory, both audit policies and System Access Control Lists (SACLs) are required. See Enabling an audit trail from Active Directory for guidance on enabling the necessary configurations.

PowerShell script block logging

PowerShell script block logging provides visibility into scripts that are run on the host, even when the entire script is downloaded and run in memory, never touching the disk. This is one of the most important Windows log sources and it compliments Sysmon or other endpoint telemetry log sources. Follow the process described in Hunting for malicious PowerShell using script block logging to deploy PowerShell script block logging policies via GPO.

Process command line logging

Process command line logging enhances the Windows event ID 4688, providing visibility into any parameters passed through to the process at run time. This additional context is often required to differentiate between benign process execution events and malicious activity. See Enabling Windows event log process command line logging via group policy object to enable this logging enhancement via group policy.

Tuning Windows event codes

There are two approaches to tuning Windows event log inputs - the allow list approach, and the deny list approach. Pros and cons to each method are detailed in the table below.

The allow list approach:

1. Identify which event codes are required for alerting use cases and dashboards
2. Ingest only these event codes
3. All remaining event codes are not ingested into the SIEM

• Lower ingestion
• An easy method for linking ingestion to security outcomes

• Event codes that are missed from the allow list can lead to false negatives
• Potential delays accessing information during incidents, threat hunts, or writing new detections
• Additional maturity and domain knowledge are required to make informed decisions
• Increases the chance of false negatives
• Additional time is spent scoping out the allow list during implementation
• Additional time expenditure each time a new event code needs to be ingested

The deny list approach:

1. Ingest all Windows event codes for a particular source (i.e. Security)
2. Identify the most noisy event codes
3. Identify which of these noisy event codes can be blocked out entirely
4. Identify which of these noisy event codes can be selectively filtered
5. Deny the targeted events
6. All other events remaining are ingested into the SIEM

• Quick time to value during implementation
• Less domain knowledge is required for maintaining the input configuration
• Obscure event codes are available during incident response with historical data
• Detection engineers, incident responders, and threat hunters have access to more event codes
• Less time is lost during incident response when attempting to retrieve missing events

• Noisy event codes that require tuning can add additional management overhead
• When tuning is not performed, larger ingestion
• Limited to 10 deny list entries per Windows event log source
• Increased time and difficulty when tying ingestion to security outcomes

Example WinEventLog inputs.conf (Denylist approach)

The following deny list-based inputs.conf serves as a recommended baseline configuration for Windows endpoints. You should review and tune it to your environment.

[WinEventLog] renderXml = true index = windows start_from = oldest current_only = 0 checkpointInterval = 5 evt_resolve_ad_obj = 1 ###### Core OS Logs ###### [WinEventLog://Application] disabled = 0 [WinEventLog://Security] disabled = 0 # Filter out noisy Splunk Communication #blacklist1 = $XmlRegex="(?ms)5156.*\\device\\harddiskvolume\d+\\program\sfiles\\splunkuniversalforwarder\\(bin\\splunkd\.exe|etc\\apps\\splunk_ta_stream\\windows_x86_64\\bin\\streamfwd\.exe)(9997|443|8000)<" # Filter out link local & loopback communication #blacklist2 = $XmlRegex="(?ms)5156.*(127.0.0.1|::1|0:0:0:0:0:0:0:1|169.254.*?|fe80:.*?)<" # Filter out noisy Splunk process execution events #blacklist3 = $XmlRegex="(?ms)4688.*C:\\Program Files\\SplunkUniversalForwarder\\(etc\\apps\\Splunk_TA_stream\\windows_x86_64\\bin\\streamfwd.exe|bin\\(splunk-powershell.exe|splunk-MonitorNoHandle.exe|splunk-netmon.exe|splunk-regmon.exe|splunkd.exe|btool.exe|splunk.exe|splunk-winevtlog.exe|splunk-admon.exe|splunk-perfmon.exe|splunk-winprintmon.exe|splunk-wmi.exe))<" # Domain Controller only: Filter out noisy AD Read Events from service account - update ldap_svc with offending account #blacklist4 = $XmlRegex="(?ms)4662.*ldap_svc.*(0x4|0x10|0x20000)C:\\Users\\Administrator\\example.ps1$" [WinEventLog://PowerShellCore/Operational] disabled = 0 ###### Windows Security Extension ###### [WinEventLog://Microsoft-Windows-Windows Firewall With Advanced Security/Firewall] disabled = 0 [WinEventLog://Microsoft-Windows-AppLocker/EXE and DLL] disabled = 0 [WinEventLog://Microsoft-Windows-AppLocker/MSI and Script] disabled = 0 [WinEventLog://Microsoft-Windows-CodeIntegrity/Operational] disabled = 0 [WinEventLog://Microsoft-Windows-Windows Defender/Operational] disabled = 0 [WinEventLog://Microsoft-Windows-BitLocker/BitLocker Management] disabled = 0 [WinEventLog://Microsoft-Windows-Security-Mitigations/KernelMode] disabled = 0 [WinEventLog://Microsoft-Windows-Security-Mitigations/UserMode] disabled = 0 ###### Persistence ###### ### Process Execution Events from reg run keys [WinEventLog://Microsoft-Windows-Shell-Core/Operational] disabled = 0 ### Scheduled Tasks [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] disabled = 0 ###### Data Exfiltration ###### ### Removable Media [WinEventLog://Microsoft-Windows-Kernel-PnP/Configuration] disabled = 0 ### BITS [WinEventLog://Microsoft-Windows-Bits-Client/Operational] disabled = 0 ###### Lateral Movement ###### ### WMI [WinEventLog://Microsoft-Windows-WMI-Activity/Operational] disabled = 0 ### WinRM [WinEventLog://Microsoft-Windows-WinRM/Operational] disabled = 0 ### SSH [WinEventLog://OpenSSH/Operational] disabled = 0 ### RDP [WinEventLog://Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational] disabled = 0 ### RDP [WinEventLog://Microsoft-Windows-TerminalServices-LocalSessionManager/Operational] disabled = 0 ### RDP [WinEventLog://Microsoft-Windows-TerminalServices-RDPClient/Operational] disabled = 0 ### RDP [WinEventLog://Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational] disabled = 0 ###### Additional Log Sources ###### ### Domain Controller only: Directory Service [WinEventLog://Directory Service] disabled = 1 ### Key Management Service [WinEventLog://Key Management Service] disabled = 1 ### DHCP [monitor://$WINDIR\System32\DHCP] disabled = 1 whitelist = DhcpSrvLog* crcSalt = sourcetype = DhcpSrvLog index = dhcp ### DNS Server [WinEventLog://DNS Server] disabled = 1 [WinEventLog://Microsoft-Windows-DNSServer/Audit] disabled = 1 index = dns

Example WinEventLog inputs.conf (Allow list approach)

This allow list inputs.conf file created by @mdecrevoisier is an excellent example of an advanced configuration (and is the reference for the example deny list configuration above).

FAQs

1. Do I need Windows event logs if I'm ingesting Sysmon?
   The short answer is yes.
   Sysmon is a detailed and modular log source which provides rich security relevant endpoint telemetry. There is a lot of detail found within Sysmon events that can't be captured using Windows event logs. The inverse is also true - there is a wealth of information present in Windows event logs which cannot be found in Sysmon. The recommended approach is to use the two in conjunction with one another.
   There are some notable overlaps between the two log sources which should be addressed to avoid doubling up on the same events. In each of the examples below, the Sysmon event takes precedence over the Wineventlog event.
   • [Process Execution Events] Sysmon Event ID 1 > Wineventlog ID 4688
   • [Network Traffic] Sysmon Event ID 3 > Wineventlog ID 5156/5157
   • [Network Share Access] Sysmon Event ID 17/18 > Wineventlog ID 5140/5145
2. Should I deploy the universal forwarder directly on Windows endpoints or set up Windows event forwarding (WEF) to avoid having another agent installed on my standard operating environment?
   A direct universal forwarder install is the preferred method. The universal forwarder provides functionality above what WEF does. See What the WEF. choosing Windows event forwarding or Splunk Universal Forwarder for further details.
   
3. What is the preferred method for ingesting Windows event logs - XML or the traditional multi-line events?
   XML. This is for a few reasons. First, the Splunk Security Research team develops content for the XML formatted events. Secondly, XML has a smaller event size, reducing ingest. Also, field names in XML format are constant regardless of which language is defined on the operating system.
   
4. Should I take an allow-list or a deny-list approach to tuning?
   The answer to this question depends upon several factors:
   • Your appetite for risk (see the section Tuning Windows event codes for the pros and cons for each method)
   • Your domain knowledge relating to required Windows event codes, and how they relate to security events
   • Your available time and resources
   • Your data ingestion strategy
5. How do I decide which Windows event logs to keep and which to tune out?
   There are a number of good resources put together by subject matter experts which list which event codes should be logged to the SIEM, for example, Which Windows events are used by Splunk UBA? It can be quite time-consuming to go through all of the resources to identify all of the required event codes, so you can also use the app Windows Event Code Security Analysis for Splunk which provides recommendations for the event codes that should be logged to the SIEM.
   
6. I've enabled PowerShell scriptblock logging, but it's too noisy. How can I tune these events?
   Using the example deny list input.conf you can write regex statements to selectively ignore events to tune out noise. It is safer to exclude noisy scripts from alerts, however in the events where they are causing a large amount of ingestion, this option isn't always viable. The method featured in the deny list inputs.conf file identifies the noisy scripts via the full script path and excludes them. When using this option, a good practice is to configure logging and alerting for modification events to the script itself.

• Written by Dean Luxton
• Sales Engineer at Splunk

1. Back to top
2. • Comparing security domain dashboards in Enterprise Security
   • Configuring Windows security audit policies for Enterprise Security visibility

Recommended articles

1. Applies To Enterprise Security Article Type Topic Author Name Dean Luxton
2. Tags This page has no tags.