Product

The essentials of Windows event logging

By
Thorben Jändling

One of the most prevalent log sources in many enterprises is Windows Event Logs. Being able to collect and process these logs has a huge impact on the effectiveness of any cybersecurity team.

In this multi-part blog series, we will be looking at all things related to Windows Event Logs. We will begin our journey with audit policies and generating event logs, then move through collecting and analysing logs, and finally to building use cases such as detection rules, reports, and more.

The purpose of these initial blog posts is to contextualise the concepts behind our new WEC cookbook guide. You could just follow that guide; however, here, you can find out more about the thoughts and reasoning behind the choices made therein.

This week we will cover the essentials of event logging: Ensuring that all your systems are writing logs about the important events or activities occurring on them. Next week we will cover the essentials of centrally collecting these Event Logs on a Window Event Collector (WEC) server, which then forwards all logs to Elastic Security.

1-events-logged-blog-windows-event-part-1.png

Having the right events logged

In Windows, not all the events that a security practitioner would be interested in are logged (nor could they even be logged). So the first stop in our journey will be Windows Audit Policies. These policies control what logs Windows components, services, and applications will generate. All these logs end up in one (or more) of a myriad of event Channels (log files) on a Windows system. My Windows 10 install currently has 1’172 event Channels (so 1’172 log files); but there are only a specific few that we are initially interested in.

Audit policies

Our WEC cookbook accompanying this blog post includes a number of audit policy recommendations based on this summary table, which is derived from Microsoft’s own threat prevention security auditing guidelines. There are recommendations for three classes of system: Domain Controller, Server, and Workstation; documented in both the cookbook and the summary table. However, Microsoft’s guidelines go into even more details and considerations.

On an Active Directory (AD) joined system they are managed centrally through Group Policy Objects (GPOs). On a non-AD domain joined system, audit policies can be configured by the Local Policy Editor.

If a Windows component, service, or application has the ability to log an event, audit policies control that functionality. Therefore, while having suitable audit policies in place on all your Windows systems will ensure that ‘loggable’ security-relevant events are being logged by that system, there is the possibility that, even with audit policies, there are still further important events and activities that gain no visibility. There is no audit policy that you could enable to have these activities logged; because they are outside the scope that audit policies currently cover.

For example, some event Channels are disabled by default, and need to be locally enabled, as shown in these guides from Microsoft. Audit policies control the call to generate a log, not the Channel that a log is destined for. So it is important to enable both the audit policy and the destination Channel. Other events (or system activities) have no logging function monitoring them (and so no applicable audit policy). To address this last issue, most pick one of the following two mainstream solutions.

Sysmon

Sysmon is a utility that is part of the Windows Sysinternals suite. It will hook into various low-level system calls, and can then be configured to generate Windows Event Logs for the actions that it observes.

A popular configuration for Sysmon used by many security practitioners is Sysmon-Modular by Olaf Hartong. This is a collection of Sysmon configuration snippets that a security practitioner can mix and match to meet their own requirements and use cases. Alternatively, practitioners could also do what many of us do and use the prepared Sysmon configuration file that contains them all. Elastic’s Winlogbeat Sysmon module will work happily with this configuration.

The WEC cookbook does not (currently) cover installing and configuring Sysmon. However, if you download Sysmon and the sysmonconfig.xml (above) in the same directory, you can run the following command as administrator to install it:

.\Sysmon64.exe -accepteula -i .\sysmonconfig.xml

With regards to ‘accepteula,’ there is a pain point in that EULA we’ll discuss next.

Endpoint Security from Elastic

There are a couple of major issues with using Sysmon on production systems:

  • It is without any warranty or support (as stated in the EULA), making it something that many would not risk running on critical production systems
  • It is not hardened against attack and lives near user-space

To better support our customers and community — many of whom voiced their concerns to us about using Sysmon with Winlogbeat — Elastic has expanded our Endpoint security agent (beta) to include kernel-level event collection.

This includes event collection for:

  • DLL and driver loading
  • DNS activity
  • File activities
  • Network connections
  • Process activity
  • Registry interactions
  • Security events

The endpoint security agent lives in the kernel space (on Windows), and we are in the process of hardening it against any unauthorised manipulations before making it generally available. This means our users will have a secure means of event collection that also includes full vendor support and SLAs.

However, it also means that these events will not be logged via the Windows Event Log system, consequently sent out via the Elastic Agent managed by Fleet.

In summary

  • Many “raw” system events or activities have no monitoring facility logging them
    • Use “sysmon” to generate Event Logs for such activities; or
    • Use Endpoint Security from Elastic to have kernel level event collection
  • Most Windows components, applications, and services, that can log, only do so if an Audit Policy enabled them to do so
  • Not all Channels on Windows are setup and enabled (by default); logs to these Channels will be lost
    • Review the documentation to ensure that the Channels you want to collect logs from are enabled

At the very minimum be sure that you have suitable Audit Policies in place, so that you are logging the bare essentials; then consider further monitoring methods to log more in depth activities.

Although this blog series is specifically about WEC and Elastic Security, at this point with good windows logging in place, you can already ingest into Elastic Security directly from end systems with Winlogbeat or Elastic Agent and Fleet’s Windows integration.

In our next blog, we will cover centrally collecting these logs with Windows Event Forwarding/Collector (WEF/WEC).

Until then, try out the power of holistic data protection with Elastic Security. Try it free today, or experience our latest version on Elasticsearch Service on Elastic Cloud. And take advantage of our Quick Start training to set yourself up for success.