关于Windows事件日志的8个误解
Windows事件日志可能是你作为一个蓝色团队所拥有的最重要，甚至是最重要的遥测资源之一，但似乎有相当多的人缺乏关于它们的关键信息。其中一些是。
关于EventIDs，最常见的误解之一可能是它们是全球唯一的。摘自微软的 '事件标识符（事件记录）' [1]。
'事件标识符可以唯一地识别一个特定的事件。每个事件源可以定义它自己的编号事件和描述字符串，它们被映射到其消息文件中。'
'每个事件源可以定义自己的编号事件 '意味着事件标识符只在特定的事件源下是唯一的（也被称为本地/相对唯一）。不幸的是，有许多来源只引用EventID，而没有引用事件源和它的版本。
如果你想自己验证这一点，只需在例如MyEventlog上查找EventID 1。你可能已经注意到，除了多个事件源，事件源 'WinVNC4 '也有多个消息。这可能是由于同一事件源的不同版本之间的差异造成的。
事件XML '在 '提供者 '元素中引用事件源名称（用 'EventSourceName '或 'Name '表示）。
Windows使用事件源名称或标识符（'Guid '属性），例如在 'ServicesEventLog '和/或 'WINEVTPublishers 'Windows注册表键[2]中，包含关于事件消息存储位置的更多信息。
从 'Windows XML事件日志（EVTX）格式 '的 '5.4. 外部存储值'[3]和像GrokEVT[4]这样的项目，我们知道事件消息被存储在（PE/COFF）消息资源文件中。事件消息是用一个消息（模板）字符串标识符来存储的。有多种方法可以从一个EventIDs中确定消息（模板）字符串标识符。
在某些情况下，我们需要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但不同版本的事件定义。
通常情况下，EventLog记录指定的是事件字符串。比如说。
这里，事件字符串 '卷影复制 '和 '停止 '被指定为事件XML中的EventData。在这个例子中，相应的事件消息（模板）字符串是'%1服务进入%2状态。'其中第一个事件字符串被用来替换最终事件消息中的第一个占位符（%1），等等。其中，最终的事件消息将是。'卷影复制服务进入停止状态'。
然而，有些情况下，事件消息（模板）字符串不包含特定事件字符串的占位符。例如对于Windows 10 20H2上的Microsoft-Windows-OfflineFiles EventID 2003。
正如你所看到的，这个事件消息（模板）字符串只有第一和第十三条事件字符串的占位符。在这种情况下，根据EventLog记录，在没有额外事实的情况下，其他事件串应该如何解释，从数字取证的角度看，这纯粹是一种猜测。
事件消息可以使用一个被称为 '参数扩展 '的概念。下面的事件消息（模板）字符串。'%1对%2的调用失败，错误如下。 %3. '和EventData中的事件字符串。
然而EventLog viewer会将其翻译成以下字符串。
正如你所看到的，'访问被拒绝。'在事件消息（模板）字符串或事件字符串中都没有定义。这里%%5对应的是事件源[6]的参数信息文件中存储的标识符为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上预期的事件字符串。
尽管 [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元素数据中包含<。
正如你在下面的事件XML中所看到的，EventData中的数据元素的名称并不唯一。有多个名为 'IoCount'、'TotalLatencyUs'、'TotalBytes '和 'IoTypeIndex '的数据元素。
事件日志是一种标准的、集中的方式，用于应用程序（和操作系统）记录重要的软件和硬件事件[9]，以便进行系统管理。
ETW是Event Tracing for Windows的缩写。EWT是一种内核级的跟踪工具，可以让你将内核或应用程序定义的事件记录到日志文件中[10]。请注意，ETW中的日志文件通常是EWT跟踪日志文件（.etl），与EventLog文件（.evt或.evtx）不同。
在Windows Vista及以后的版本中，EventLog使用ETW[11]，所以简而言之，它们是相关的，但不等同。
