WMI (Windows Management Instrumentation)是微软对基于web的企业管理(WBEM)和来自分布式管理任务组(DMTF)的公共信息模型(CIM)标准的实现。这允许管理员以统一的方式管理一组系统，允许他们获取关于系统的信息、系统当前状态并执行操作。正因为如此，许多攻击者利用它进行枚举、横向移动和持久性攻击。防御者和安全供应商也充分利用了它，事实上，如果没有它，大多数漏洞扫描程序将无法完成他们在windows主机上所做的很多事情。

研究人员起初编写了PSGumshoe PowerShell模块，以帮助执行威胁搜索和事件响应工作。

执行方法

在多年前的一个项目中，我了解到可以通过启用Other Object Access审核设置然后在每个 WMI 命名空间上跟踪类方法的 WMI 执行甚至查询。一个熟练的Windows管理员能够跟踪我的查询和方法执行，并通过使用一些经过优化的摄取过滤器来包含我的操作，这些过滤器会对任何不符合他的环境中的系统正常行为的操作发出警报。

配置GPO时，请在“计算机配置-> Windows设置->安全设置->高级审核策略配置->审核策略->对象访问”下进行设置

审核设置

通过 GPO 设置和推送审核设置后，需要登录脚本或手动过程来设置适当的审核设置以跟踪给定命名空间上的操作。需要手动执行此操作：

打开WMI控制MMC或计算机管理MMC，并打开WMI控制的属性。

选择Security选项卡，选择要应用adit设置的名称空间，然后单击Security。

在下一个窗口中，点击Advanced。

在命名空间的高级安全设置中，我们执行以下操作：

1.点击Auditing选项卡；

2.点击Add；

在“Audit Entry ”窗口中，执行以下操作：

1.选择Principal将应用于的对象，我的建议是Everyone或Authenticated Users；

2.在Type中选择ALL，因为我们想要成功和失败事件。

3.在高级权限中，我建议从Execute Method开始，以检测类方法的后期移动和Full Write的情况下，恶意WMI提供程序创建了一个类或永久事件组件创建在根/订阅名称空间之外。也有助于检测作为C2频道http：//2014.hackitoergosum.org/slides/day1_WMI_Shell_Andrei_Dumitrescu.pdf的WMI

显示的设置不包括查询，没有在将事件发送到 SIEM 之前验证和过滤事件的过程和能力，这在生产环境中会太嘈杂。

一旦应用了设置，任何尝试如下所示，其中本地 Win32_Process 类 Create() 方法用于使用 WMI 创建进程以中断父子关系将被记录。

当我们检查 Security 中的日志时，我们将看到 ID 为 4662 的事件，其中 ObjectServer 将是 WMI。该事件将包括事件发生在什么命名空间中以及在什么用户环境中。在 AdditinalInformation 字段下，我们将查看它是本地的还是远程的以及被调用的方法。

本地方法执行

当从远程系统对主机执行方法时，如下例所示，日志将显示该方法是远程执行的。

我们将在 AdditionalInfo 下看到方法执行是 Remote Execute。

远程方法执行

在 PSGumshoe 中，可以使用 Get-EventWmiObjectAccess 函数来帮助查找这种类型的 IOC。

从帮助信息中可以看到，该函数允许通过某些字段过滤事件，并且可以传递一个或多个EVTX文件，因此我们可以远程或本地执行该函数。

在下面的例子中，我们正在查看一个从系统中提取的EVTX文件，并且我们正在过滤方法的本地执行。

通过管道传递多个 EVTX 文件的示例。

WMI 操作错误事件

在 Microsoft-WMI-Arctivity/Operational 日志中，Windows 默认记录所有与 WMI 相关的操作错误，事件 ID 为 58585。在 Windows 的日常操作中，也取决于操作系统上安装的软件，错误的数量很高。如果 SIEM 解决方案允许在转发日志之前进行过滤，这将有助于提高所发送事件的信噪比。在下图中，我们可以看到在我的实验室 VM 中，错误数量很高。

PSGumshoe 提供 Get-EventWmiOperationalError 函数来搜索和过滤生成的错误日志。攻击者可能会犯错误或根本无权执行生成要记录的错误的操作。该事件将包括计算机和进程的 PID，该进程不仅在本地生成事件，而且还为远程操作生成事件。

就像其他 WMI 函数一样，该函数可以在另一台计算机上远程运行，在本地运行，也可以对一个或多个 EVTX 文件运行。

我们可以通过 ClientMachine 分组查询远程主机并查看是否有来自其他主机的事件。在这个例子中，我们可以看到 SDCL1 有 2 个操作错误。

我们可以查询主机，以便仅匹配可疑 ClientMachine 的事件。

我们可以根据Resultcode进行分组，结果代码是错误号，我们可以使用Microsoft文档中的错误常量引用来识别任何感兴趣的内容。

WMI提供程序加载

用于持久性的 WMI 提供程序是一种古老但未广泛使用的技术，攻击者在系统上安装 WMI 提供程序，当与它提供的一个或多个类交互时，它会加载它，提供编码到其中的任何功能，作为 SYSTEM 执行。 Casey Smith 创建并删除了公开共享该技术的第一个公共 POC，随后 Jared Atkinson 也公开了一个 POC。

加载提供程序并在 Microsoft-Windows-WMI-Activity/Operational 中创建事件 ID 5857。重要的字段是 ProvierPath 和 TimeCreated，因为这可以关联以构建可能访问的类的时间线，因为仅当 wmiiprvse.exe 需要类执行请求的操作时才会加载提供程序。

PsGumshoe提供了Get-EventWmiProviderStart函数来查询这个事件。

这是一个查看每个提供程序已加载多少次的示例，这可能有助于识别正在使用的可疑提供程序。

WMI永久事件

WMI永久事件从Windows 2000/XP时代开始就被滥用，永久事件由 3 个部分组成：

Filter——WQL 查询我们想要的事件；

Consumer——触发过滤器时采取的行动；

Binding——向Consumer注册过滤器。

每个组件都是一个类的实例，该类创建并存储在CIM数据库(objects.data)的根或根/订阅名称空间下。当Consumer被执行时，该操作在wmiprvse.exe的环境中以SYSTEM的形式运行。因为我们必须单独构建每个部分并将其保存在CIM数据库中，所以它们确实要花费更多的精力，但大多数攻击者只是简单地将这个过程自动化。它的局限性在于只有一小部分Consumer行为可用。

ActiveScriptEventConsumer——当一个事件被传递给它时，用任意的脚本语言执行一个预定义的脚本。该用户可在Windows 2000及更高版本上使用。

CommandLineEventConsumer——当一个事件被传递给它时，在本地系统环境中启动任意进程。该用户可在Windows XP及更高版本上使用。

当事件发送到文本日志文件时，将自定义字符串写入到文本日志文件中。该用户可在Windows XP及以上版本上使用。

NTEventLogEventConsumer——当事件被发送到Windows NT事件日志时，将特定的消息记录到该事件日志中。该用户可在Windows XP及以上版本上使用。

SMTPEventConsumer——每次将事件发送给它时，使用SMTP发送一条电子邮件消息。该用户可在Windows 2000及以上版本上使用。

对于Event Filter对象，将创建一个查询来监视WMI CIM数据库中的内部或外部事件，这些事件可以是任何类实例的创建、修改或删除，或者订阅将为某些操作生成事件的提供程序。

当 __EventFilter 和任何Consumer类型类对象用于在 WMI CIM 数据库中创建 Binder 实例以创建永久事件时，Microsoft-Windows-WMI-Activity/Operational 中 ID 为 5861 的事件日志条目由以下人员创建默认情况下无需启用任何审核。如果任何组件类实例被修改，该事件也会在修改中创建。即使在可能原因子元素下的 UserData 元素中，该事件也将包含与永久物相关的所有信息。

如果我们使用Sysmon并将其配置为捕获WMI事件，则将捕获正在创建的每个组件。Sysmon提供了将更改定位到已经绑定在一起的过滤器或使用者的优势，以便融合到环境中。我们已经看到APT28在修改目标环境中已经存在的使用者和过滤器。Bellow是一个将捕获所有事件的配置。

在下面的示例中，我们将使用PowerShell创建每个组件，永久事件将检测USB设备何时被插入，并将可执行文件复制到设备上，并在设备上设置autorun.ini。

我们将首先创建一个Event Filter实例，该实例将在可移动卷添加到主机时触发。

我们可以看到该操作记录在 Sysmon 日志下，事件 ID 为 19，它包含过滤事件的所有部分，并且该操作已创建。

PSGumshoe有get - sysmonwmfilter，它允许查询这个事件，并将结果作为一个对象返回给我们。

如前所述，攻击者可以修改现有的事件过滤器并替换查询。Sysmon能够跟踪这一变化。让我们更改查询，使其中没有换行符。

正如我们所看到的，Sysmon使用相同的ID记录了更改，但操作声明它已被修改。

PSGumshoe中的函数允许按字段过滤，因此我们只能查询修改过的事件。我们看到Sysmon创建了2个事件，一个是更改之前的实例，另一个是实例现在的样子。

现在我们将创建一个Consumer实例，这个Consumer类型为Action Script，它将执行一个VBScript脚本，该脚本将Base64解码二进制文件并将其存储在可移动驱动器上，它还将创建一个autorun.ini并修改它，使其隐藏在驱动器上。

该操作将被Sysmon记录为事件ID 20，并包含来自actionscriptConsumer的整个脚本。

我们可以使用Get-SysmonWmiConsumer函数来查询事件。Sysmon只记录Action Script和CommandLine事件Consumer，其他Consumer不被记录，因为他们不被认为是一个安全风险。

为了将过滤器与Consumer绑定，我们需要创建一个Binder实例，该实例同时引用这两个过滤器。它可以在Root命名空间或Root/Subscription中创建。让我们首先在Root/Subscription名称空间中创建一个实例，它是此类实例的默认实例。

Windows将记录所有绑定事件，每个部分的完整信息作为事件ID 5861下的事件的一部分。

我们可以使用Get-EventWmiPermanentEvent函数来查询这个事件。

Sysmon还会将事件记录为事件ID 21，但只会引用每个组件的路径。我们可以使用Get-SysmonWmiBinding函数来查询事件。

在Root中创建绑定事件将绕过WMI-Activity和Sysmon，了解这一点很重要，在wmiprvse.exe下的可疑进程的情况下，也要检查根路径中可能隐藏的永久事件。

临时事件

一些参与者已经开始使用临时事件Consumer。它们可以用 C++、.Net、WSH 和 PowerShell 编写，它们允许使用 WMI 事件过滤器来触发由应用程序本身执行的操作。最大的优势是，我们可以利用用于编写临时事件的语言的功能，而不仅限于 Windows 脚本宿主和命令行工具。我们可以使用事件Id 5860来跟踪这些事件。一旦应用程序注册了事件Consumer，事件就被创建了。Sysmon不提供此类事件的检测。

下面是PowerShell中一个临时事件使用者的例子，它只是简单地写入已经启动的进程的名称。

当 Event Consumer 注册到 Register-WmiEvent 时，我们会在系统上记录以下事件。

我们可以使用Get-EventWmiTemporaryEvent函数来查询这个事件。我们将看到这种类型的事件在Windows中被大量使用。

我们可以将对象通过管道传输到 Out-GridView 以更好地可视化输出。

我们可以看到这个进程的PID是5992，当我们查看这个进程时，我们看到Sysmon服务正在运行这个订阅。

总结

PSGumshoe PowerShell模块在调查由Windows和Sysmon生成的WMI类型事件时提供了极大的灵活性。该模块可以在PowerShell 库和GitHub 上找到。

本文翻译自：https://www.darkoperator.com/blog/2022/3/27/tracking-wmi-activity-with-psgumshoe如若转载，请注明原文地址