背景介绍

Windows事件日志可能是你作为一个蓝色团队所拥有的最重要，甚至是最重要的遥测资源之一，但似乎有相当多的人缺乏关于它们的关键信息。其中一些是。

事件ID是全球的。事件ID直接映射到事件信息。所有的事件字符串都在消息中使用。所有的事件消息信息都在模板字符串中。模板字符串保持不变。事件XML是正确的XML 1.0。事件XML中的数据元素名称是的。事件日志和ETW是一样的。

误解1：EventID是全球的

关于EventIDs，最常见的误解之一可能是它们是全球的。摘自微软的 “事件标识符（事件记录）” [1]。

“事件标识符可以地识别一个特定的事件。每个事件源可以定义它自己的编号事件和描述字符串，它们被映射到其消息文件中。”

“每个事件源可以定义自己的编号事件 “意味着事件标识符只在特定的事件源下是的（也被称为本地/相对）。不幸的是，有许多来源只引用EventID，而没有引用事件源和它的版本。

如果你想自己验证这一点，只需在例如MyEventlog上查找EventID 1。你可能已经注意到，除了多个事件源，事件源 “WinVNC4 “也有多个消息。这可能是由于同一事件源的不同版本之间的差异造成的。

事件XML “在 “提供者 “元素中引用事件源名称（用 “EventSourceName “或 “Name “表示）。

Windows使用事件源名称或标识符（”Guid “属性），例如在 “ServicesEventLog “和/或 “WINEVTPublishers “Windows注册表键[2]中，包含关于事件消息存储位置的更多信息。

误解2：EventIDs直接映射到事件信息

从 “Windows XML事件日志（EVTX）格式 “的 “5.4. 外部存储值”[3]和像GrokEVT[4]这样的项目，我们知道事件消息被存储在（PE/COFF）消息资源文件中。事件消息是用一个消息（模板）字符串标识符来存储的。有多种方法可以从一个EventIDs中确定消息（模板）字符串标识符。

事件ID与信息（模板）字符串标识符的一对一映射使用EventID和Qualifiers属性的映射使用WEVT_TEMPLATE PE/COFF资源的映射。

在某些情况下，我们需要EventID Qualifiers属性来确定消息（模板）字符串标识。让我们考虑下面的例子。

事件ID的值与限定词对应于以下信息（模板）字符串标识。

请注意，只有在 “ServicesEventLog “Windows注册表键下定义的事件源中才观察到这种情况。

另一种方法是通过WEVT_TEMPLATE资源中的信息将EventID映射到消息（模板）字符串标识。例如，我们有以下的事件源。

正如你所看到的，两个事件源都使用相同的事件消息资源文件。如果我们在Windows 10 20H2上用以下PowerShell命令提取事件标识符和消息（模板）字符串。

并与%systemroot%system32en-UScscsvc.dll.mui文件（产品和文件版本为10.0.19041.1）中的消息表PE/COFF资源的一个部分进行比较。

%systemroot%system32en-UScscsvc.dll.mui文件包含

Microsoft-Windows-OfflineFiles和

Microsoft-Windows-BranchCacheSMB事件源的消息（模板）字符串，这些要映射到不同的消息（模板）字符串标识。

在相关的%systemroot%system32cscsvc.dll文件中，有一个WEVT_TEMPLATE（PE/COFF）资源，它包含一个 “事件定义”，将EventID映射到一个消息（模板）字符串标识[5]。比如说。

注意，一个WEVT_TEMPLATE可以定义多个具有相同EventID但不同版本的事件定义。

误解3：所有的事件字符串都在信息中使用

通常情况下，EventLog记录指定的是事件字符串。比如说。

这里，事件字符串 “卷影复制 “和 “停止 “被指定为事件XML中的EventData。在这个例子中，相应的事件消息（模板）字符串是”%1服务进入%2状态。”其中个事件字符串被用来替换事件消息中的个占位符（%1），等等。其中，的事件消息将是。”卷影复制服务进入停止状态”。

然而，有些情况下，事件消息（模板）字符串不包含特定事件字符串的占位符。例如对于Windows 10 20H2上的

Microsoft-Windows-OfflineFiles EventID 2003。

正如你所看到的，这个事件消息（模板）字符串只有和第十三条事件字符串的占位符。在这种情况下，根据EventLog记录，在没有额外事实的情况下，其他事件串应该如何解释，从数字取证的角度看，这纯粹是一种猜测。

误解4：所有的事件消息信息都在模板字符串中

事件消息可以使用一个被称为 “参数扩展 “的概念。下面的事件消息（模板）字符串。”%1对%2的调用失败，错误如下。 %3. “和EventData中的事件字符串。

然而EventLog viewer会将其翻译成以下字符串。

正如你所看到的，”访问被拒绝。”在事件消息（模板）字符串或事件字符串中都没有定义。这里%%5对应的是事件源[6]的参数信息文件中存储的标识符为5的信息字符串。

误解5：模板字符串保持不变

不同版本的（PE/COFF）消息资源文件，事件消息（模板）字符串可以不同。例如，比较Windows 7和Windows 10 20H2版本的%systemroot%system32en-UScscsvc.dll.mui上的

Microsoft-Windows-BranchCacheSMB EventID 3000的事件消息（模板）字符串。

在Windows 10 20H2上，不仅事件消息（模板）字符串不同，而且还有占位符。目前还不清楚Windows 7事件日志记录是否会包含Windows 10 20H2上预期的事件字符串。

误解6：事件XML是正确的XML 1.0

尽管 [MS-EVEN6] [7] 可能暗示Event XML是正确的XML 1.0，但实际上它不是。evtx-specimens 项目有一个脚本，允许你用被认为是无效的 XML 1.0 的字符生成 EventLog 记录 [8]。

在下面的例子中，可以看到Event XML可能偏离正确的XML 1.0的另一个例子。

这里的数据元素 “除了StateMachine<class KeyMachine,class KeyState>::PumpEvents”是不恰当的。格式良好的XML不应该在XML元素数据中包含<。

误解7：事件XML中的数据元素名称是的

正如你在下面的事件XML中所看到的，EventData中的数据元素的名称并不。有多个名为 “IoCount”、”TotalLatencyUs”、”TotalBytes “和 “IoTypeIndex “的数据元素。

误解8：EventLogs和ETW是等同的

事件日志是一种标准的、集中的方式，用于应用程序（和操作系统）记录重要的软件和硬件事件[9]，以便进行系统管理。

ETW是Event Tracing for Windows的缩写。EWT是一种内核级的跟踪工具，可以让你将内核或应用程序定义的事件记录到日志文件中[10]。请注意，ETW中的日志文件通常是EWT跟踪日志文件（.etl），与EventLog文件（.evt或.evtx）不同。

在Windows Vista及以后的版本中，EventLog使用ETW[11]，所以简而言之，它们是相关的，但不等同。