//THE ACADEMY IS GROWING DAILY. CHECK OUT THE FIELD NOTES FROM TECHS HERE AT THE ACADEMY
>_DAEMONCORE // ACADEMY
← FIELD NOTES

Windows ETW: Patching EventWrite vs Kernel Providers

2026.10.21//10 MIN READwindowsdetection-engineeringlog-analysismethodology

// Windows Event Tracing Architecture

Windows Event Tracing (ETW) provides an efficient way to log and analyze system events. Understanding the architecture is essential for detection engineers when implementing security monitoring solutions. Two critical areas of ETW worth discussing are the ETWEventWrite function and Kernel ETW providers. Both can be leveraged for logging, but they differ significantly in how they can be manipulated and how effective they are for detecting malicious activities.

// ETWEventWrite Function

The ETWEventWrite function is a user-mode API that allows applications to send events to ETW consumers. Applications can log events with a specific schema, enabling a structured approach to event generation. However, patching ETWEventWrite presents some challenges.

Patching ETWEventWrite

Patching this function can introduce detection issues. When an attacker modifies ETWEventWrite, they can suppress logs, leading to gaps in event data. The attacker can utilize API hooking or similar techniques to overwrite the original function with a modified version that either drops events or sends fabricated ones. This can complicate detection and incident response efforts significantly.

Methodology for Detecting Patching of ETWEventWrite

1. Monitor API Calls: Leverage tools like Sysmon or Process Monitor to track calls to ETWEventWrite. Look for unusual patterns, such as high-frequency calls or calls from unexpected processes.

2. Check for Hooking: Use tools like Detours or EasyHook to check if the ETWEventWrite function has been intercepted. A clean system should show the legitimate function address consistently.

3. Log Integrity Checks: Implement file integrity monitoring on key binaries. If an attacker modifies the system binaries, you'll detect changes.

Example Command to Monitor ETWEventWrite Calls

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Where-Object { $_.Id -eq 15 }

This command filters for Sysmon logs where Event ID 15 indicates a process has made an ETW event write.

// Kernel ETW Providers

Kernel ETW providers, in contrast, operate at a lower level than user-mode applications. These providers can generate events for various system activities, including process creation, thread management, and file access. Because they operate in the kernel space, they are less susceptible to user-mode tampering.

Advantages of Kernel ETW Providers

  • Tamper Resistance: Kernel providers operate below user-space applications, making them harder for attackers to manipulate.
  • Rich Data: Kernel events provide extensive details about system activity, crucial for forensic analysis.
  • Performance: Kernel-level events are less resource-intensive compared to user-mode logging.

Example of Kernel Provider Usage

Enabling kernel providers can be done via the Windows Performance Recorder (WPR) or by using the command line. The following command enables the Kernel Provider for process creation events:

logman create trace MyTrace -p "Microsoft-Windows-Kernel-Process" 0xFFFFFFFFFFFFFFFF

This command establishes a trace named MyTrace that captures all events from the Kernel Process provider.

// Trade-offs and Considerations

When deciding between patching ETWEventWrite and relying on Kernel ETW providers, consider the following trade-offs:

  • Flexibility vs. Integrity: Patching ETWEventWrite offers more flexibility in logging but at the cost of integrity. Kernel providers, while more secure, may not provide the same level of customization.
  • Ease of Detection: Manipulating user-mode event logging can be easier to detect via monitoring API calls, while kernel provider events are inherently more difficult to suppress.
  • Performance Impact: User-mode logging can introduce performance overhead, especially if logging too extensively. Kernel events are optimized for performance but may result in high verbosity.

// Defensive Implications

Given these considerations, detection engineers should prioritize using Kernel ETW providers for critical logging tasks. They should also implement a layered logging approach, using both Kernel and user-mode logs where appropriate. However, one must remain vigilant for signs of manipulation on ETWEventWrite when user-mode logging is necessary.

Checklist for ETW Detection Engineering

  • Regularly audit ETW event logs for anomalies.
  • Implement integrity monitoring for core binaries associated with ETW.
  • Monitor API calls to ETWEventWrite using Sysmon or Process Monitor.
  • Enable Kernel ETW providers for critical activities and ensure performance metrics are monitored.
  • Use third-party tools to validate the integrity of logging mechanisms.

--- // FIELDOPS REPORT AUTHORIZED BY: Rachel H. //