brencronin

Apr 14, 20235 min read

The Log and Pony Show - Windows Logging (Instrumentation and Telemetry)

Updated: Feb 27

SOC Triad reference.

????pic????

Windows systems have been equipped with a robust logging system consisting of three main constructs: Event Publisher, Event Channel, and Event Log File. The diagram below illustrates the three most common Windows event channels: Application, Security, and System, which collect logs of specific types.

You can logon to any Windows system open up a built-in Windows tool called Event Viewer and see distinct Windows log types (Application, System & Security), and their respective "log event channels".

There are also many more log channels that can be setup to audit and collect many different types of logs on Windows systems. This screenshot displays additional log channels on a laptop. A server would have even more log channels.

Two log channels of note are Sysmon and powershell because they can provide some better signals related to possible nefarious activities on your systems.

One of the next items of important is the actual location of the logs on the Windows system. The diagram below displays the default location of Windows logs and that they are in .evtx format. In order to read evtx formatted logs you need a specialized tool like the Windows event viewer.

Logging comes down to a few basic questions:

What do I log?
How do I log what I want to log?
How do I analyze the logs?
What do I look for in the logs?

What do I log?

This is a frequent point of contention in the cybersecurity field. Some advocate for logging everything, while others argue for a more selective approach to logging. Personally, I advocate for being more discerning in what you choose to audit. I've witnessed numerous instances where the performance and costs of logging systems were adversely affected by the "log everything" approach. After a few years, you may reflect and wonder if certain types of log events were ever used in any investigation. If the answer is no, it's likely unnecessary to audit them. Viewing the "audit everything" strategy from another perspective reveals its lack of precision. It essentially reflects a mindset of logging everything without discernment, relying on the hope of figuring things out if an incident occurs – a situation that's far from ideal.

Here are some of the most important things to log in Windows. Note that Account management events, Logon/logoff events, Process command line, Clearing Logs, and Disable firewall or AV are all security related so should all be in the Security event channel.

Account management events
Logon/logoff events
Process command line
Clearing Logs
Disable firewall or AV
Powershell
Scheduled tasks
Process events
Honey XYZ

If you want to look up what different log event IDs log check this link from Randy Franklin Smith at Ultimate IT security: lhttps://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

How do I log what I want to log?

Most of the log types listed are within the Security event channel so can be found within that channel or logged externally to a logging system by pulling all the events from the security event channel. Some of the other important log types are found in other Windows logging channels or need to be specifically enabled for logging. Lets first look scheduled task and process create events.

4698: A scheduled task was created, 4699: A scheduled task was deleted, 4700: A scheduled task was enabled, 4702: A scheduled task was updated

loggeds Powershell

How do I analyze the logs?

Analyzing Logs Locally

There are several options for analyzing the logs locally. Analyzing the logs locally can be done via a tool that is loaded on the server or by exporting the Windows log channel evtx file off the of the server to a device that has a tool for log analysis. One of the main limitations of relying on analyzing the logs locally is that the server only has so much storage so at some point logs will rollover and older logs will be written over with newer logs.

Windows Event viewer
Powershell Get-WinEvt
EVTX Explore
Chainsaw
Event Log explorer

Powershell vieiwng event logs

get-winevent -logname <log name>

get-winevent -filterhashtable @{logname=<logname>;id=4624}

get-winevent -filterhashtable @{logname=<logname>;id=4624} | out-gridview

eric zimmerman tool

https://ericzimmerman.github.io/#!index.md

evtx analysus tool for Linux

convert Chris's sample file to jsonl on an Arm Macbook:

Download (or compile) the Rust binary for this platform at https://github.com/omerbenamram/evtx/releases and run:

./evtx_dump-v0.8.1-aarch64-apple-darwin -o jsonl -f ws01-4688.json ws01-4688.evtx

Chainsaw log analysis

Other dinwso event viewer tool

Analyzing Logs Remotely

Why not just send these logs to a centralized logging system like a SIEM and call it a day?

Most people wish Windows logging were that easy. Here are some factors that make Windows logging more complex.

Windows does not natively support syslog so how do you send Windows logs to a SIEM?
Its impractical to send all of the Windows systems Security, Application and System logs to the SIEM so which ones do you send?
How do you detect malicious behavior for which there is no log?
How do you get more useful data with your logs?

Windows does not natively support syslog so how to you send Windows logs to a SIEM?

To collect Windows logs from Windows systems you need a log shipper function to get them into the SIEM. The log shipper can either be a push or pull. The log shipper function is represented by the square in the diagram.

Examples of Windows log shippers are:

Splunk - Forwarder
ArcSight - Connector
WinlogBeat
Snare

There are drawbacks to both methods of collecting logs from Windows systems.

Pull - Having log shipper software logon to Windows systems
- Need to create another service account and deal with logon credentials issues
- Many implementations would not allow you to pull logs by event ID but rather only by log type (e.g., Security, Application, System). Application and System logs are large log generators so you could easily overload your SIEM, system and network with log collection from these types of logs.
- Many implementations were old in there collection mechanism. for example, collecting the logs via SMBv1 (SMBv1 is extremely vulnerable and should not be allowed on any of your systems. Just take a look at WannaCry https://en.wikipedia.org/wiki/WannaCry_ransomware_attack )
Push - Having a log shipper software agent on all Windows systems that is responsible for sending the Windows logs to the SIEM. the log shipper basically follows/tails the log channels you tell it to and sends those logs to the SIEM.
- Admins have to install and patch another piece of software on all of the Windows systems. Multiply this by hundreds/thousands of systems and this can be a burden.

Windows Event Forward (WEF)/Windows Event Collection (WEC)?

A few years back Windows came up with a native way to collect Windows logs from Windows systems natively using WinRM https://learn.microsoft.com/en-us/windows/win32/winrm/portal called Windows Event Forwarding (WEF) (Push) or Windows Event Collection (WEC) (Pull).

To get logs to the SIEM you still need a log shipper at the Windows Event Collection server, but that is a single agent which makes everyone's lives much easier.

Another positive of Windows Event Collection is that it allows you to collect logs based on event-ID rather than just log type. So, if there is a specific System or Application log you want to collect for cyber security you don't have collect all of the System and Application logs.

There are numerous well done articles that go in depth into Windows Event Collection https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector