Event Tracing for Windows (ETW)

Event Tracing for Windows (ETW) is a kernel-level tracing facility for logging events and is intended to be used for application debugging and can be enabled/disabled without restarting the application/system. In short, the system consists of three components – controllers, providers, and consumers. Controllers are used to start/stop the Event Tracing session, which is used to receive events from providers and deliver them to consumers. To start using ETW, I can recommend the most detailed beginners guide[44]. Bmcder shows how to use the logman and wevtutil.exe tools, event manifests, and APIs to access ETW. At the end, there is a list of useful providers for the blue team. Also, it’s important to note that ETW is useful for collecting ongoing events rather than historical ones. However, the number of events is huge and will require post-processing using SIEM and/or Yara.

Let’s investigate how to use ETW for .NET tooling usage visibility. There are two excellent blog posts by F-Secure on how to detect malicious use of .NET. Part 1[45] is dedicated to the process of loading .NET assemblies and how to gain visibility of them. Part 2[46] goes into the details of JIT and Interop tracing, showing how malicious examples of Meterpreter and SafetyKatz can be detected. Method names, assemblies, and common malware API calls will be a security concern for an insightful defender. For both offensive and defensive tests, we can use a great tool created by FuzzySec called SilkETW[47]. Essentially, it is a set of wrappers for ETW that we can use in real time for collecting and filtering .NET events from Microsoft-Windows-DotNETRuntime and other providers. We can further enhance our analysis by applying known indicators of compromise from Yara. Following is a simple example of running renamed Seatbelt[48]:

Figure 2.16 – Process Hacker shows loaded .NET assemblies

We will start SilkETW by using the following command:

 .\SilkETW.exe -t user -pn Microsoft-Windows-DotNETRuntime -uk 0x2038 -l verbose -ot eventlog

After the launch of the SilkETW process, 820 events have been collected already. We execute Seatbelt to get system information by running the following command:

.\legit_binary.exe OSInfo

The number of events goes up to 1,763, and some of them include indicators of compromise. Going through these events allows security products such as Yara or modern AV/EDR solutions to detect our activity:

Figure 2.17 – SilkETW in action

One of the corresponding log entries is as follows:

Figure 2.18 – Multiple Seatbelt entries inside the log

We have two main strategies to avoid detection – tamper with ETW or use some kind of obfuscation. One example of an open source protector is ConfuserEx[49]. It still leaves some IOCs, but it can be a good starting point, as was demonstrated in the blog post by White Knight Labs[50].

A more promising way to bypass ETW is to hide tradecraft from it. XPN published great research on how to do it in his blog[51]. The idea has much in common with AMSI bypass – patch the call to ntdll!EtwEventWrite in a way that will not log anything. Another way to achieve the same result was demonstrated by Cneelis in his TamperETW[52] example.

To observe ETW in action, I encourage you to read an excellent blog post by mez0[53]. The author demonstrates .NET provider creation, simple .NET loader detection, and ETW neutralization. Repairing the ETW provider after execution is demonstrated as well. Links to relevant research and an overview of other security ETW providers are included as well, making this research unique and distinguishable.

A list of other ETW tampering techniques was published by Palantir in their blog[54]. Two of these techniques (Autologger provider removal and provider Enable property modification) will require reboot, and all of them require at least administrator privileges.