Why has Event Tracing for Windows (ETW) become so pivotal for endpoint detection and response (EDR) solutions in Windows 10 and 11? The answer lies in the value of the intelligence it provides to security tools through secure ETW channels, which are now also a target for offensive researchers looking to bypass detections.
为什么 Windows 事件跟踪 （ETW） 对于 Windows 10 和 11 中的终结点检测和响应 （EDR） 解决方案如此重要？答案在于它通过安全的 ETW 通道向安全工具提供的情报的价值，这些通道现在也是希望绕过检测的进攻性研究人员的目标。
In this deep dive, we’re not just discussing ETW’s functionalities; we’re exploring how ETW works internally so you can conduct novel research or forensic analysis on a system. Security researchers and malware authors already target ETW. They have developed several techniques to tamper with or bypass ETW-based EDRs, hook system calls, or gain access to ETW providers normally reserved for anti-malware solutions. Most recently, the Lazarus Group bypassed EDR detection by disabling ETW providers. Here, we’ll explain how ETW works and what makes it such a tempting target, and we’ll embark on an exciting journey deep into Windows.
在这次深入探讨中，我们不仅要讨论 ETW 的功能;我们正在探索 ETW 在内部的工作方式，以便你可以对系统进行新的研究或取证分析。安全研究人员和恶意软件作者已经将 ETW 作为目标。他们开发了多种技术来篡改或绕过基于 ETW 的 EDR、挂接系统调用或访问通常为反恶意软件解决方案保留的 ETW 提供程序。最近，Lazarus Group 通过禁用 ETW 提供程序绕过了 EDR 检测。在这里，我们将解释 ETW 的工作原理以及是什么让它成为如此诱人的目标，我们将踏上深入 Windows 的激动人心的旅程。
Overview of ETW internals
ETW 内部结构概述
Two main components of ETW are providers and consumers. Providers send events to an ETW globally unique identifier (GUID), and the events are written to a file, a buffer in memory, or both. Every Windows system has hundreds or thousands of providers registered. We can view available providers by running the command logman query providers:
ETW 的两个主要组件是提供者和使用者。提供程序将事件发送到 ETW 全局唯一标识符 （GUID） ，并将事件写入文件和/或内存中的缓冲区。每个 Windows 系统都注册了成百上千个提供程序。我们可以通过运行以下命令 logman query providers 来查看可用的提供程序：
By checking my system, we can see there are nearly 1,200 registered providers:
通过检查我的系统，我们可以看到有近 1,200 个注册提供商：
Each of these ETW providers defines its own events in a manifest file, which is used by consumers to parse provider-generated data. ETW providers may define hundreds of different event types, so the amount of information we can get from ETW is enormous. Most of these events can be seen in Event Viewer, a built-in Windows tool that consumes ETW events. But you’ll only see some of the data. Not all logs are enabled by default in Event Viewer, and not all event IDs are shown for each log.
每个 ETW 提供程序都在清单文件中定义自己的事件，使用者使用该文件来分析提供程序生成的数据。ETW 提供程序可以定义数百种不同的事件类型，因此我们可以从 ETW 获得的信息量是巨大的。其中大多数事件都可以在事件查看器中看到，事件查看器是一个使用 ETW 事件的内置 Windows 工具。但你只会看到一些数据。默认情况下，并非所有日志都会在事件查看器中启用，并且不会为每个日志显示所有事件 ID。
On the other side we have consumers: trace logging sessions that receive events from one or several providers. For example, EDRs that rely on ETW data for their detection will consume events from security-related ETW channels such as the Threat Intelligence channel.
另一方面，我们有使用者：从一个或多个提供程序接收事件的跟踪日志记录会话。例如，依赖 ETW 数据进行检测的 EDR 将使用来自与安全相关的 ETW 通道（如威胁情报通道）的事件。
We can look at all running ETW consumers via Performance Monitor; clicking one of the sessions will show the providers it subscribes to. (You may need to run as SYSTEM to see all ETW logging sessions.)
我们可以通过性能监视器查看所有正在运行的 ETW 使用者;单击其中一个会话将显示它订阅的提供商。（可能需要以 SYSTEM 身份运行才能查看所有 ETW 日志记录会话。
The list of processes that receive events from this log session is useful information but not easy to obtain. As far as I could see there is no way to get that information from user mode at all, and even from kernel mode it’s not an easy task unless you are very familiar with ETW internals. So we will see what we can learn from a kernel debugging session using WinDbg.
从此日志会话接收事件的进程列表是有用的信息，但不容易获得。据我所知，根本无法从用户模式获取该信息，即使从内核模式获取该信息也不是一件容易的事，除非您非常熟悉 ETW 内部结构。因此，我们将看到我们可以从使用 WinDbg 的内核调试会话中学到什么。
Finding ETW consumer processes
查找 ETW 使用者进程
There are ways to find consumers of ETW log sessions from user mode. However, they only supply very partial information that isn’t enough in all cases. So instead, we’ll head to our kernel debugger session. One way to get information about ETW sessions from the debugger is using the built-in extension !wmitrace. This extremely useful extension allows users to investigate all of the running loggers and their attributes, consumers, and buffers. It even allows users to start and stop log sessions (on a live debugger connection). Still, like all legacy extensions, it has its limitations: it can’t be easily automated, and since it’s a precompiled binary it can’t be extended with new functionality.
可通过多种方式从用户模式查找 ETW 日志会话的使用者。但是，它们只提供非常部分的信息，在所有情况下都不够。因此，我们将转到内核调试器会话。从调试器获取有关 ETW 会话的信息的一种方法是使用内置扩展 !wmitrace 。这个非常有用的扩展允许用户调查所有正在运行的记录器及其属性、使用者和缓冲区。它甚至允许用户启动和停止日志会话（在实时调试器连接上）。尽管如此，像所有遗留扩展一样，它也有其局限性：它不能轻易自动化，而且由于它是一个预编译的二进制文件，所以它不能用新功能进行扩展。
So instead we’ll write a JavaScript script—scripts are easier to extend and modify, and we can use them to get as much data as we need without being limited to the preexisting functionality of a legacy extension.
因此，我们将编写一个 JavaScript 脚本——脚本更易于扩展和修改，并且我们可以使用它们来获取所需的尽可能多的数据，而不受传统扩展的预先存在的功能的限制。
Every handle contains a pointer to an object. For example, a file handle will point to a kernel structure of type FILE_OBJECT. A handle to an object of type EtwConsumer will point to an undocumented data structure called ETW_REALTIME_CONSUMER. This structure contains a pointer to the process that opened it, events that get notified for different actions, flags, and also one piece of information that will (eventually) lead us back to the log session—LoggerId. Using a custom script, we can scan the handle tables of all processes for handles to EtwConsumer objects. For each one, we can get the linked ETW_REALTIME_CONSUMER structure and print the LoggerId:
每个句柄都包含指向对象的指针。例如，文件句柄将指向 类型的 FILE_OBJECT 内核结构。该类型的 EtwConsumer 对象的句柄将指向一个名为 ETW_REALTIME_CONSUMER 的未记录的数据结构。此结构包含指向打开它的进程的指针、因不同操作而收到通知的事件、标志，以及一条（最终）将引导我们返回日志会话的信息 LoggerId 。使用自定义脚本，我们可以扫描所有进程的句柄表，以查找 EtwConsumer 对象的句柄。对于每一个，我们可以获取链接 ETW_REALTIME_CONSUMER 结构并打印： LoggerId
"use strict";
function initializeScript()
{
return [new host.apiVersionSupport(1, 7)];
}
function EtwConsumersForProcess(process)
{
let dbgOutput = host.diagnostics.debugLog;
let handles = process.Io.Handles;
try
{
for (let handle of handles)
{
try
{
let objType = handle.Object.ObjectType;
if (objType === "EtwConsumer")
{
let consumer = host.createTypedObject(handle.Object.Body.address, "nt", "_ETW_REALTIME_CONSUMER");
let loggerId = consumer.LoggerId;
dbgOutput("Process ", process.Name, " with ID ", process.Id, " has handle ", handle.Handle, " to Logger ID ", loggerId, "\n");
}
} catch (e) {
dbgOutput("\tException parsing handle ", handle.Handle, "in process ", process.Name, "!\n");
}
}
} catch (e) {
}
}
Next, we load the script into the debugger with .scriptload and call our function to identify which process consumes ETW events:
接下来，我们将脚本加载到调试器中， .scriptload 并调用我们的函数来标识哪个进程使用 ETW 事件：
dx @$cursession.Processes.Select(p => @$scriptContents.EtwConsumersForProcess(p)) @$cursession.Processes.Select(p => @$scriptContents.EtwConsumersForProcess(p)) Process svchost.exe with ID 0x558 has handle 0x7cc to Logger ID 31 Process svchost.exe with ID 0x114c has handle 0x40c to Logger ID 36 Process svchost.exe with ID 0x11f8 has handle 0x2d8 to Logger ID 17 Process svchost.exe with ID 0x11f8 has handle 0x2e8 to Logger ID 3 Process svchost.exe with ID 0x11f8 has handle 0x2f4 to Logger ID 9 Process NVDisplay.Container.exe with ID 0x1478 has handle 0x890 to Logger ID 38 Process svchost.exe with ID 0x1cec has handle 0x1dc to Logger ID 7 Process svchost.exe with ID 0x1d2c has handle 0x780 to Logger ID 8 Process CSFalconService.exe with ID 0x1e54 has handle 0x760 to Logger ID 3 Process CSFalconService.exe with ID 0x1e54 has handle 0x79c to Logger ID 45 Process CSFalconService.exe with ID 0x1e54 has handle 0xbb0 to Logger ID 10 Process Dell.TechHub.Instrumentation.SubAgent.exe with ID 0x25c4 has handle 0xcd8 to Logger ID 41 Process Dell.TechHub.Instrumentation.SubAgent.exe with ID 0x25c4 has handle 0xdb8 to Logger ID 35 Process Dell.TechHub.Instrumentation.SubAgent.exe with ID 0x25c4 has handle 0xf54 to Logger ID 44 Process SgrmBroker.exe with ID 0x17b8 has handle 0x178 to Logger ID 15 Process SystemInformer.exe with ID 0x4304 has handle 0x30c to Logger ID 16 Process PerfWatson2.exe with ID 0xa60 has handle 0xa3c to Logger ID 46 Process PerfWatson2.exe with ID 0x81a4 has handle 0x9c4 to Logger ID 40 Process PerfWatson2.exe with ID 0x76f0 has handle 0x9a8 to Logger ID 47 Process operfmon.exe with ID 0x3388 has handle 0x88c to Logger ID 48 Process operfmon.exe with ID 0x3388 has handle 0x8f4 to Logger ID 49
While we still don’t get the name of the log sessions, we already have more data than we did in user mode. We can see, for example, that some processes have multiple consumer handles since they are subscribed to multiple log sessions. Unfortunately, the ETW_REALTIME_CONSUMER structure doesn’t have any information about the log session besides its identifier, so we must find a way to match identifiers to human-readable names.
虽然我们仍然没有获得日志会话的名称，但我们已经拥有比用户模式下更多的数据。例如，我们可以看到，某些进程具有多个使用者句柄，因为它们订阅了多个日志会话。不幸的是，除了标识符之外，该 ETW_REALTIME_CONSUMER 结构没有任何关于日志会话的信息，因此我们必须找到一种方法将标识符与人类可读的名称相匹配。
The registered loggers and their IDs are stored in a global list of loggers (or at least they were until the introduction of server silos; now, every isolated process will have its own separate ETW loggers while non-isolated processes will use the global list, which I will also use in this post). The global list is stored inside an ETW_SILODRIVERSTATE structure within the host silo globals, nt!PspHostSiloGlobals:
已注册的记录器及其 ID 存储在记录器的全局列表中（或者至少在引入服务器孤岛之前是这样;现在，每个独立进程都将有自己单独的 ETW 记录器，而非隔离进程将使用全局列表，我也将在本文中使用该列表）。全局列表存储在主机思洛存储器全局变量中的结构 ETW_SILODRIVERSTATE 中： nt!PspHostSiloGlobals
dx ((nt!_ESERVERSILO_GLOBALS*)&nt!PspHostSiloGlobals)->EtwSiloState
((nt!_ESERVERSILO_GLOBALS*)&nt!PspHostSiloGlobals)->EtwSiloState : 0xffffe38f3deeb000 [Type: _ETW_SILODRIVERSTATE *]
[+0x000] Silo : 0x0 [Type: _EJOB *]
[+0x008] SiloGlobals : 0xfffff8052bd489c0 [Type: _ESERVERSILO_GLOBALS *]
[+0x010] MaxLoggers : 0x50 [Type: unsigned long]
[+0x018] EtwpSecurityProviderGuidEntry [Type: _ETW_GUID_ENTRY]
[+0x1c0] EtwpLoggerRundown : 0xffffe38f3deca040 [Type: _EX_RUNDOWN_REF_CACHE_AWARE * *]
[+0x1c8] EtwpLoggerContext : 0xffffe38f3deca2c0 [Type: _WMI_LOGGER_CONTEXT * *]
[+0x1d0] EtwpGuidHashTable [Type: _ETW_HASH_BUCKET [64]]
[+0xfd0] EtwpSecurityLoggers [Type: unsigned short [8]]
[+0xfe0] EtwpSecurityProviderEnableMask : 0x3 [Type: unsigned char]
[+0xfe4] EtwpShutdownInProgress : 0 [Type: long]
[+0xfe8] EtwpSecurityProviderPID : 0x798 [Type: unsigned long]
[+0xff0] PrivHandleDemuxTable [Type: _ETW_PRIV_HANDLE_DEMUX_TABLE]
[+0x1010] RTBacklogFileRoot : 0x0 [Type: wchar_t *]
[+0x1018] EtwpCounters [Type: _ETW_COUNTERS]
[+0x1028] LogfileBytesWritten : {4391651513} [Type: _LARGE_INTEGER]
[+0x1030] ProcessorBlocks : 0x0 [Type: _ETW_SILO_TRACING_BLOCK *]
[+0x1038] ContainerStateWnfSubscription : 0xffffaf8de0386130 [Type: _EX_WNF_SUBSCRIPTION *]
[+0x1040] ContainerStateWnfCallbackCalled : 0x0 [Type: unsigned long]
[+0x1048] UnsubscribeWorkItem : 0xffffaf8de0202170 [Type: _WORK_QUEUE_ITEM *]
[+0x1050] PartitionId : {00000000-0000-0000-0000-000000000000} [Type: _GUID]
[+0x1060] ParentId : {00000000-0000-0000-0000-000000000000} [Type: _GUID]
[+0x1070] QpcOffsetFromRoot : {0} [Type: _LARGE_INTEGER]
[+0x1078] PartitionName : 0x0 [Type: char *]
[+0x1080] PartitionNameSize : 0x0 [Type: unsigned short]
[+0x1082] UnusedPadding : 0x0 [Type: unsigned short]
[+0x1084] PartitionType : 0x0 [Type: unsigned long]
[+0x1088] SystemLoggerSettings [Type: _ETW_SYSTEM_LOGGER_SETTINGS]
[+0x1200] EtwpStartTraceMutex [Type: _KMUTANT]
The EtwpLoggerContext field points to an array of pointers to WMI_LOGGER_CONTEXT structures, each describing one logger session. The size of the array is saved in the MaxLoggers field of the ETW_SILODRIVERSTATE. Not all entries of the array are necessarily used; unused entries will be set to 1. Knowing this, we can dump all of the initialized entries of the array. (I’ve hard coded the array size for convenience):
该 EtwpLoggerContext 字段指向 WMI_LOGGER_CONTEXT 指向结构的指针数组，每个指针描述一个记录器会话。数组的大小保存在 ETW_SILODRIVERSTATE 的 MaxLoggers 字段中。并非必须使用数组的所有条目;未使用的条目将设置为 1。知道了这一点，我们可以转储数组的所有初始化条目。（为方便起见，我已对数组大小进行了硬编码）：
dx ((nt!_WMI_LOGGER_CONTEXT*(*)[0x50])(((nt!_ESERVERSILO_GLOBALS*)&nt!PspHostSiloGlobals)->EtwSiloState->EtwpLoggerContext))->Where(l => l != 1)
((nt!_WMI_LOGGER_CONTEXT*(*)[0x50])(((nt!_ESERVERSILO_GLOBALS*)&nt!PspHostSiloGlobals)->EtwSiloState->EtwpLoggerContext))->Where(l => l != 1)
[2] : 0xffffe38f3f0c9040 [Type: _WMI_LOGGER_CONTEXT *]
[3] : 0xffffe38f3fe07640 [Type: _WMI_LOGGER_CONTEXT *]
[4] : 0xffffe38f3f0c75c0 [Type: _WMI_LOGGER_CONTEXT *]
[5] : 0xffffe38f3f0c9780 [Type: _WMI_LOGGER_CONTEXT *]
[6] : 0xffffe38f3f0cb040 [Type: _WMI_LOGGER_CONTEXT *]
[7] : 0xffffe38f3f0cb600 [Type: _WMI_LOGGER_CONTEXT *]
[8] : 0xffffe38f3f0ce040 [Type: _WMI_LOGGER_CONTEXT *]
[9] : 0xffffe38f3f0ce600 [Type: _WMI_LOGGER_CONTEXT *]
[10] : 0xffffe38f79832a40 [Type: _WMI_LOGGER_CONTEXT *]
[11] : 0xffffe38f3f0d1640 [Type: _WMI_LOGGER_CONTEXT *]
[12] : 0xffffe38f89535a00 [Type: _WMI_LOGGER_CONTEXT *]
[13] : 0xffffe38f3dacc940 [Type: _WMI_LOGGER_CONTEXT *]
[14] : 0xffffe38f3fe04040 [Type: _WMI_LOGGER_CONTEXT *]
…
Each logger context contains information about the logger session such as its name, the file that stores the events, the security descriptor, and more. Each structure also contains a logger ID, which matches the index of the logger in the array we just dumped. So given a logger ID, we can find its details like this:
每个记录器上下文都包含有关记录器会话的信息，例如其名称、存储事件的文件、安全描述符等。每个结构还包含一个记录器 ID，它与我们刚刚转储的数组中记录器的索引匹配。因此，给定一个记录者 ID，我们可以找到它的详细信息，如下所示：
dx (((nt!_ESERVERSILO_GLOBALS*)&nt!PspHostSiloGlobals)->EtwSiloState->EtwpLoggerContext)[@$loggerId]
(((nt!_ESERVERSILO_GLOBALS*)&nt!PspHostSiloGlobals)->EtwSiloState->EtwpLoggerContext)[@$loggerId] : 0xffffe38f3f0ce600 [Type: _WMI_LOGGER_CONTEXT *]
[+0x000] LoggerId : 0x9 [Type: unsigned long]
[+0x004] BufferSize : 0x10000 [Type: unsigned long]
[+0x008] MaximumEventSize : 0xffb8 [Type: unsigned long]
[+0x00c] LoggerMode : 0x19800180 [Type: unsigned long]
[+0x010] AcceptNewEvents : 0 [Type: long]
[+0x018] GetCpuClock : 0x0 [Type: unsigned __int64]
[+0x020] LoggerThread : 0xffffe38f3f0d0040 [Type: _ETHREAD *]
[+0x028] LoggerStatus : 0 [Type: long]
…
Now we can implement this as a function (in DX or JavaScript) and print the logger name for each open consumer handle we find:
现在我们可以将其实现为一个函数（在 DX 或 JavaScript 中），并打印我们发现的每个打开的消费者句柄的记录器名称：
dx @$cursession.Processes.Select(p => @$scriptContents.EtwConsumersForProcess(p))
@$cursession.Processes.Select(p => @$scriptContents.EtwConsumersForProcess(p))
Process svchost.exe with ID 0x558 has handle 0x7cc to Logger ID 31
Logger Name: "UBPM"
Process svchost.exe with ID 0x114c has handle 0x40c to Logger ID 36
Logger Name: "WFP-IPsec Diagnostics"
Process svchost.exe with ID 0x11f8 has handle 0x2d8 to Logger ID 17
Logger Name: "EventLog-System"
Process svchost.exe with ID 0x11f8 has handle 0x2e8 to Logger ID 3
Logger Name: "Eventlog-Security"
Process svchost.exe with ID 0x11f8 has handle 0x2f4 to Logger ID 9
Logger Name: "EventLog-Application"
Process NVDisplay.Container.exe with ID 0x1478 has handle 0x890 to Logger ID 38
Logger Name: "NOCAT"
Process svchost.exe with ID 0x1cec has handle 0x1dc to Logger ID 7
Logger Name: "DiagLog"
Process svchost.exe with ID 0x1d2c has handle 0x780 to Logger ID 8
Logger Name: "Diagtrack-Listener"
Process CSFalconService.exe with ID 0x1e54 has handle 0x760 to Logger ID 3
Logger Name: "Eventlog-Security"
...
In fact, by using the logger array, we can build a better way to enumerate ETW log session consumers. Each logger context has a Consumers field, which is a linked list connecting all of the ETW_REALTIME_CONSUMER structures that are subscribed to this log session:
事实上，通过使用记录器数组，我们可以生成一种更好的方法来枚举 ETW 日志会话使用者。每个记录器上下文都有一个 Consumers 字段，该字段是一个链表，用于连接订阅此日志会话的所有 ETW_REALTIME_CONSUMER 结构：
So instead of scanning the handle table of each and every process in the system, we can go directly to the loggers array and find the registered processes for each one:
因此，我们可以直接进入 loggers 数组并找到每个进程的已注册进程，而不是扫描系统中每个进程的句柄表：
function EtwLoggersWithConsumerProcesses()
{
let dbgOutput = host.diagnostics.debugLog;
let hostSiloGlobals = host.getModuleSymbolAddress("nt", "PspHostSiloGlobals");
let typedhostSiloGlobals = host.createTypedObject(hostSiloGlobals, "nt", "_ESERVERSILO_GLOBALS");
let maxLoggers = typedhostSiloGlobals.EtwSiloState.MaxLoggers;
for (let i = 0; i < maxLoggers; i++)
{
let logger = typedhostSiloGlobals.EtwSiloState.EtwpLoggerContext[i];
if (host.parseInt64(logger.address, 16).compareTo(host.parseInt64("0x1")) != 0)
{
dbgOutput("Logger Name: ", logger.LoggerName, "\n");
let consumers = host.namespace.Debugger.Utility.Collections.FromListEntry(logger.Consumers, "nt!_ETW_REALTIME_CONSUMER", "Links");
if (consumers.Count() != 0)
{
for (let consumer of consumers)
{
dbgOutput("\tProcess Name: ", consumer.ProcessObject.SeAuditProcessCreationInfo.ImageFileName.Name, "\n");
dbgOutput("\tProcess Id: ", host.parseInt64(consumer.ProcessObject.UniqueProcessId.address, 16).toString(10), "\n");
dbgOutput("\n");
}
}
else
{
dbgOutput("\tThis logger has no consumers\n\n");
}
}
}
}
Calling this function should get us the exact same results as earlier, only much faster!
调用此函数应该会获得与之前完全相同的结果，只是速度更快！
After getting this part, we can continue to search for another piece of information that could be useful—the list of GUIDs that provide events to a log session.
获取此部分后，我们可以继续搜索另一条可能有用的信息，即向日志会话提供事件的 GUID 列表。
Finding provider GUIDs 查找提供程序 GUID
Finding the consumers of an ETW log session is only half the battle—we also want to know which providers notify each log session. We saw earlier that we can get that information from Performance Monitor, but let’s see how we can also get it from a debugger session, as it might be useful when the live machine isn’t available or when looking for details that aren’t supplied by user-mode tools like Performance Monitor.
查找 ETW 日志会话的使用者只是成功的一半，我们还想知道哪些提供程序会通知每个日志会话。我们之前看到，我们可以从性能监视器中获取该信息，但让我们看看如何从调试器会话中获取它，因为当实时计算机不可用或查找性能监视器等用户模式工具未提供的详细信息时，它可能很有用。
If we look at the WMI_LOGGER_CONTEXT structure, we won’t see any details about the providers that notify the log session. To find this information, we need to go back to the ETW_SILODRIVERSTATE structure from earlier and look at the EtwpGuidHashTable field. This is an array of buckets storing all of the registered provider GUIDs. For performance reasons, the GUIDs are hashed and stored in 64 buckets. Each bucket contains three lists linking ETW_GUID_ENTRY structures. There is one list for each ETW_GUID_TYPE:
如果我们查看结构 WMI_LOGGER_CONTEXT ，我们将看不到有关通知日志会话的提供程序的任何详细信息。为了找到这些信息，我们需要回到前面的 ETW_SILODRIVERSTATE 结构并查看字段 EtwpGuidHashTable 。这是一个存储桶数组，用于存储所有已注册的提供程序 GUID。出于性能原因，对 GUID 进行哈希处理并存储在 64 个存储桶中。每个存储桶包含三个列表链接 ETW_GUID_ENTRY 结构。每个 ETW_GUID_TYPE 都有一个列表：
EtwpTraceGuidTypeEtwpNotificationGuidTypeEtwpGroupGuidType
Each ETW_GUID_ENTRY structure contains an EnableInfo array with eight entries, and each contains information about one log session that the GUID is providing events for (which means that an event GUID entry can supply events for up to eight different log sessions):
每个结构都包含一个 EnableInfo 包含八个条目的数组，每个 ETW_GUID_ENTRY 条目都包含有关 GUID 为其提供事件的一个日志会话的信息 （这意味着事件 GUID 条目最多可以为八个不同的日志会话提供事件） ：
dt nt!_ETW_GUID_ENTRY EnableInfo.
+0x080 EnableInfo : [8]
+0x000 IsEnabled : Uint4B
+0x004 Level : UChar
+0x005 Reserved1 : UChar
+0x006 LoggerId : Uint2B
+0x008 EnableProperty : Uint4B
+0x00c Reserved2 : Uint4B
+0x010 MatchAnyKeyword : Uint8B
+0x018 MatchAllKeyword : Uint8B
Visually, this is what this whole thing looks like:
从视觉上看，这就是整个事情的样子：
As we can see, the ETW_GUID_ENTRY structure contains a LoggerId field, which we can use as the index into the EtwpLoggerContext array to find the log session.
正如我们所看到的，该 ETW_GUID_ENTRY 结构包含一个 LoggerId 字段，我们可以将其用作数组的 EtwpLoggerContext 索引来查找日志会话。
With this new information in mind, we can write a simple JavaScript function to print the GUIDs that match a logger ID. (In this case, I chose to go over only one ETW_GUID_TYPE at a time to make this code a bit cleaner.) Then we can go one step further and parse the ETW_REG_ENTRY list in each GUID entry to find out which processes notify it, or if it’s a kernel-mode provider:
考虑到这些新信息，我们可以编写一个简单的 JavaScript 函数来打印与记录器 ID 匹配的 GUID。 ETW_GUID_TYPE 然后，我们可以更进一步，分析每个 GUID 条目中的 ETW_REG_ENTRY 列表，以找出哪些进程通知它，或者它是否是内核模式提供程序：
function GetGuidsForLoggerId(loggerId, guidType)
{
let dbgOutput = host.diagnostics.debugLog;
let hostSiloGlobals = host.getModuleSymbolAddress("nt", "PspHostSiloGlobals");
let typedhostSiloGlobals = host.createTypedObject(hostSiloGlobals, "nt", "_ESERVERSILO_GLOBALS");
let guidHashTable = typedhostSiloGlobals.EtwSiloState.EtwpGuidHashTable;
for (let bucket of guidHashTable)
{
let guidEntries = host.namespace.Debugger.Utility.Collections.FromListEntry(bucket.ListHead[guidType], "nt!_ETW_GUID_ENTRY", "GuidList");
if (guidEntries.Count() != 0)
{
for (let guid of guidEntries)
{
for (let enableInfo of guid.EnableInfo)
{
if (enableInfo.LoggerId === loggerId)
{
dbgOutput("\tGuid: ", guid.Guid, "\n");
let regEntryLinkField = "RegList";
if (guidType == 2)
{
// group GUIDs registration entries are linked through the GroupRegList field
regEntryLinkField = "GroupRegList";
}
let regEntries = host.namespace.Debugger.Utility.Collections.FromListEntry(guid.RegListHead, "nt!_ETW_REG_ENTRY", regEntryLinkField);
if (regEntries.Count() != 0)
{
dbgOutput("\tProvider Processes:\n");
for (let regEntry of regEntries)
{
if (regEntry.DbgUserRegistration != 0)
{
dbgOutput("\t\tProcess: ", regEntry.Process.SeAuditProcessCreationInfo.ImageFileName.Name, " ID: ", host.parseInt64(regEntry.Process.UniqueProcessId.address, 16).toString(10), "\n");
}
else
{
dbgOutput("\t\tKernel Provider\n");
}
}
}
break;
}
}
}
}
}
}
As an example, here are all of the trace provider GUIDs and the processes that notify them for ETW session UBPM (LoggerId 31 in my case):
例如，下面是所有跟踪提供程序 GUID 以及通知它们 ETW 会话 UBPM 的进程（在我的例子中为 LoggerId 31）：
dx @$scriptContents.GetGuidsForLoggerId(31, 0)
Guid: {9E03F75A-BCBE-428A-8F3C-D46F2A444935}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\svchost.exe" ID: 2816
Guid: {2D7904D8-5C90-4209-BA6A-4C08F409934C}
Guid: {E46EEAD8-0C54-4489-9898-8FA79D059E0E}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\dwm.exe" ID: 2268
Guid: {D02A9C27-79B8-40D6-9B97-CF3F8B7B5D60}
Guid: {92AAB24D-D9A9-4A60-9F94-201FED3E3E88}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\svchost.exe" ID: 2100
Kernel Provider
Guid: {FBCFAC3F-8460-419F-8E48-1F0B49CDB85E}
Guid: {199FE037-2B82-40A9-82AC-E1D46C792B99}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\lsass.exe" ID: 1944
Guid: {BD2F4252-5E1E-49FC-9A30-F3978AD89EE2}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\svchost.exe" ID: 16292
Guid: {22B6D684-FA63-4578-87C9-EFFCBE6643C7}
Guid: {3635D4B6-77E3-4375-8124-D545B7149337}
Guid: {0621B9DF-3249-4559-9889-21F76B5C80F3}
Guid: {BD8FEA17-5549-4B49-AA03-1981D16396A9}
Guid: {F5528ADA-BE5F-4F14-8AEF-A95DE7281161}
Guid: {54732EE5-61CA-4727-9DA1-10BE5A4F773D}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\svchost.exe" ID: 4428
Guid: {18F4A5FD-FD3B-40A5-8FC2-E5D261C5D02E}
Guid: {8E6A5303-A4CE-498F-AFDB-E03A8A82B077}
Provider Processes:
Kernel Provider
Guid: {CE20D1C3-A247-4C41-BCB8-3C7F52C8B805}
Provider Processes:
Kernel Provider
Guid: {5EF81E80-CA64-475B-B469-485DBC993FE2}
Guid: {9B307223-4E4D-4BF5-9BE8-995CD8E7420B}
Provider Processes:
Kernel Provider
Guid: {AA1F73E8-15FD-45D2-ABFD-E7F64F78EB11}
Provider Processes:
Kernel Provider
Guid: {E1BDC95E-0F07-5469-8E64-061EA5BE6A0D}
Guid: {5B004607-1087-4F16-B10E-979685A8D131}
Guid: {AEDD909F-41C6-401A-9E41-DFC33006AF5D}
Guid: {277C9237-51D8-5C1C-B089-F02C683E5BA7}
Provider Processes:
Kernel Provider
Guid: {F230D19A-5D93-47D9-A83F-53829EDFB8DF}
Provider Processes:
Process: "\Device\HarddiskVolume3\Windows\System32\svchost.exe" ID: 2816
Putting all of those steps together, we finally have a way to know which log sessions are running on the machine, which processes notify each of the GUIDs in the session, and which processes are subscribed to them. This can help us understand the purpose of different ETW log sessions running on the machine, such as identifying the log sessions used by EDR software or interesting hardware components. These scripts can also be modified as needed to identify ETW irregularities, such as a log session that has been disabled in order to blind security products. From an attacker perspective, gathering this information can tell us which ETW providers are used on a machine and which ones are ignored and, therefore, don’t present us with any risk of detection.
将所有这些步骤放在一起，我们终于有办法知道哪些日志会话在计算机上运行，哪些进程通知会话中的每个 GUID，以及哪些进程订阅了它们。这可以帮助我们了解在计算机上运行的不同 ETW 日志会话的用途，例如识别 EDR 软件或相关硬件组件使用的日志会话。还可以根据需要修改这些脚本，以识别 ETW 异常情况，例如已禁用的日志会话，以便使安全产品失效。从攻击者的角度来看，收集此信息可以告诉我们在计算机上使用了哪些 ETW 提供程序，哪些提供程序被忽略，因此不会给我们带来任何检测风险。
Overall, ETW is a very powerful mechanism, so getting more visibility into its internal workings is useful for attackers and defenders alike. This post only scratches the surface, and there’s so much more work that can be done in this area.
总体而言，ETW 是一种非常强大的机制，因此更深入地了解其内部工作原理对攻击者和防御者都很有用。这篇文章只是触及了表面，在这个领域还有很多工作要做。
All of the JavaScript functions shown in this post can be found in this GitHub repo.
本文中显示的所有 JavaScript 函数都可以在此 GitHub 存储库中找到。
原文始发于Yarden Shafir：ETW internals for security research and forensics
相关文章
