Elevate your security with improved Event Tracing for Windows (ETW) logs. Now you can know who initiated the actions for each device to aid in threat detection and analysis. Whether you’re in cybersecurity, IT, performance, or software development, diagnosing cybersecurity threats has never been easier. In this article, get ready to:
- Learn about Windows event tracing.
- Find new security-related information on a Windows device.
- Interpret security-related events.
We’ll leverage ETW to better understand what’s happening on a system and take appropriate actions.
Learn about Windows event tracing
If you work in security, you’ve likely used the event log for limited audit functions. While previously you couldn’t always tell who or what actually caused a specific event, now you can!
Event Tracing for Windows (ETW) is an efficient kernel-level tracing facility. ETW events are an essential tool for understanding what is happening under the hood of a Windows device. Many components and applications in Windows have been instrumented (that is enhanced) with ETW. Back in the day, ETW was created to track debugging and performance details. Now, however, you can access this instrumentation to diagnose cybersecurity threats, too.
Over time, we have identified several events where the causal process appears as different from the acting deputy. To address this, we have updated the event schema by adding new fields to the event payload: Process ID and Process Start Key. We’ve also increased the event version as events are updated over time, following the application compatibility policy. Our hope is that these changes are beneficial to the security community and help address possible gaps in event analysis. Now, let’s get started.
Find new security-related information on a Windows device
To locate new security-related information, view enabled ETW events in one of two ways:
- Using Event Viewer
- Through APIs (refer to official documentation on StartTraceA function and EnableTraceEx2 function)
Windows Event Viewer
Let’s walk through the first method. We’ll start by opening Windows Event Viewer.
- Select the Windows Start icon (or the Windows key on the keyboard).
- Type in “Event Viewer” and press Enter to open it.
- Expand the Windows Logs menu in the left-hand pane.
- Select Security to bring up security events and actions.
At this point, you’ll see a summary of all security events on the device in the middle pane. These events are organized in chronological order with the most recent ones at the top. To see the log for any selected event, select the Details tab at the bottom of the middle pane.
Event structure
ETW events contain two parts, both under the Details tab in the Event Viewer:
- System (also known as header)
- Event data (also known as payload)
The <System> header contains properties like Process ID and Process Start Key, as well as versioning information, among others. Process Start Key is a sequence number guaranteed to be unique across boots. These two properties belong to the process that raised the event, which may or may not be the same process that caused the event to happen. Thankfully, we’ve solved this for you by adding these elements to the payload.
While the header of the event cannot be restructured for semantic reasons, look for the helpful enhancements in the bottom portion, the payload.
The payload data included with the event is defined by a template, as described in Instrumenting your code with ETW. Let’s see how to use this portion to determine who or what caused security-related events.
Where do events come from?
Before now, ETW logs listed some events and processes affecting a device with a generic message of “The system/kernel logged this event.” As such, some events might have appeared as if they incorrectly attributed action initiation. This is especially problematic for the security domain, such as Digital Forensics and Incident Response (DFIR) or detection engineering. If you’re in this domain, you know that attribution of action to a process is essential for timelining and correlation of malicious activity. Today, the initiating process is added to the payload part of the event.
It’s widely recognized that attack tools often clear the event log and disable auditing. Now, you can successfully check these events for data on the process that requested the action. Specifically, each of the following events now lists the Process ID and the Process Start Key.
Microsoft-Windows-Security-Auditing: these events are sent to the security channel of the event log.
- 4697: A service was installed in the system.
- 4698: A scheduled task was created.
- 4699: A scheduled task was deleted.
- 4700: A scheduled task was enabled.
- 4701: A scheduled task was disabled.
- 4702: A scheduled task was updated.
- 4719: System audit policy was changed.
Clear Eventlog events: Provider Microsoft-Windows-Eventlog.
- 1102: Security audit log was cleared. Displayed in the Security channel.
- 104: The {channel name} log file was cleared. Displayed in the System channel.
To see events of a specific type in Windows Event Viewer, use the actions on the right-hand side:
- Locate Actions > Security.
- Select Filter Current Log and type in the ID number or numbers that you want to audit (e.g., “4698, 4688”).
- Confirm by selecting OK.
Check these events for the process responsible for the action to significantly improve your cybersecurity monitoring. By doing this, you can now detect malicious actions that want to establish persistence, self-updating mechanism, tampering, and the like.
Interpret security-related events
Now that you have access to the new initiating process properties included in the events, you can attribute each action to the correct process that initiated it. You just need to know how to interpret this data! Windows has several ETW providers that show process creation, but the key is to match the process ID to the process and evaluate if this action is suspicious. Security vendors and applications that collect events do this automatically, but let’s walk through an illustration.
The simplest way for you to translate process properties back to a process name is by exploring two related events, like the following:
Let’s inspect a suspicious activity by exploring what process initiated the creation of a scheduled task. You can learn more about the risks of this adversary technique under T1053.005 in the reputable MITRE ATT&CK database. We’ll first create and examine a scheduled task (event ID 4698) and then compare its details with the new process creation event (event ID 4688).
Example: Create and examine a scheduled task
First, to examine the new properties for a scheduled task creation event (SchTasks), let’s create a sample one. You can use the user interface or a simple command line prompt, as below:
- Go to Start > Command Prompt.
- Input the following string into the command line:
C:\Users\Administrator> SchTasks /Create /SC WEEKLY /D MON,TUE,WED /TN "Test" /TR "C:\temp\test.bat" /ST 16:30
|
Note: For this command and task to work, you will need a C:\temp directory and run an elevated cmd.exe. |
You’ve just created a scheduled task with the name “Test” and ran the corresponding batch file.
Now, let’s find this event in the Event Viewer:
- Go to Start > Event Viewer > Windows Logs > Security.
- (Optional) Use the Refresh action from the right pane if needed.
- Browse or filter for the latest 4698 event (“A scheduled task was created”).
- Select the event and switch over to the Details tab to learn more about it.
Let’s examine the header of this event, under <System>.
Notice that the event is uniquely defined by the Provider ID (GUID), EventID, and Version. The version number will now reflect any updates to the event to support application compatibility. The header contains the ExecutionProcessID equaling 756. This ID stands for lsass.exe, [1] the process that keeps information about logging in and secure portions of Windows. However, since we just created this event in the command line above, we know that it wasn’t the SchTasks.exe application that initiated the action.
So let’s keep exploring the payload under <EventData>, since that’s the portion we’ve enhanced.
Notice the new Client Process Start Key and the Process ID data added to indicate the cause of the event. In this example, the ClientProcessID equals 712 and the ParentProcessID equals 1404. In this instance, 1404 stands for the cmd.exe process, [1] which we’ll confirm from the event ID 4688 in the next example. That’s what you’d expect. Just remember to check the payload, not the header, for the most precise data.
Example: Compare with the new process creation event
Now let’s compare this data with the new process creation event ID 4688. As you look it up in Event Viewer, it shows that the created process SchTasks.exe corresponds to ProcessID 712 and its ParentProcessID 1404.
Since these ID numbers of the new process creation match the scheduled task creation data, you’ve just established the expected event provenance. You can dismiss this activity as not suspicious. If the processes did not match, you’d have serious reasons to investigate further. Specifically, keep a close eye on the auditing and log-clearing events we’ve just enhanced with the same properties.
Stay more secure with Event Tracing for Windows
Now you know how to leverage Event Tracing for Windows (ETW) instrumentation in threat detection and analysis for security products and purposes. Specifically, add the 9 updated events to your watch list to allow correlation and timelining with the process that initiated the action. With a few illustrative examples, we hope that you’ll have a better signal to detect suspicious behavior.
We’ll continue updating Windows instrumentation in an application compatible way to help keep your organization protected and productive. To learn more, check out the following resources:
- Instrumenting your code with ETW
- Event tracing - Win32 apps
- ENABLE_TRACE_PARAMETERS (evntrace.h)
- Describe Windows Server event logs
Continue the conversation. Find best practices. Bookmark the Windows Tech Community ,then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.
[1] The tools you use will usually match the Process ID to the corresponding application automatically. You can also manually look up what application each Process ID value represents in Windows > Task Manager > Details > PID.