WMI (Windows Management Instrumentation) 是 Microsoft 对 WBEM 标准的实现。WMI 开箱即用，提供了近 4000 种不同的可配置项。它旨在帮助管理大型分布式环境。WMI 不仅可以用于数据收集，也可以用于的攻击活动。

    WMIC.exe 是执行 WMI 命令的传统门户，但它在很大程度上已被弃用，取而代之的是 PowerShell（支持原生 WMI ）。攻击者经常互换使用WMI与PowerShell。

1. WMI攻击利用

1.1 信息收集

    利用WMI命令进行主机信息收集。

wmic process get CSName,Description,ExecutablePathwmic useraccount list fullwmic group list fullwmic netuse list fullwmic qfe get Caption,Description,HotFixID,InstalledOnwmic startup get Caption,Command,Location,User

1.2 权限提升

    WMI 是最有效的权限提升工具之一，因为它可以提供快速定位可能的错误配置。

查询自启动的未正确引用的服务

wmic service get name,displayname,pathname,startmode | findstr /i "Auto" | findstr /i /v "C:\Windows\\" | findstr /i /v """

查询可能被攻击的高特权进程

 $Owners = @{} Get-WmiObject -Class win32_process | Where-Object {$_} | ForEach-Object {$Owners[$_.handle] = $_.getowner().user

PowerTools的PowerUp.ps1，可以利用 WMI 查询 20 多种可用于提升权限的常见错误配置。

1.3 WMI攻击：横向移动

        通过 WMI 远程执行 == "process call create"

wmic.exe PROCESS CALL CREATE \"C:\\Windows\\System32\\rundll32.exe \\\"C:\\Windows\\perfc.dat\\\" #1

1.4 WMI攻击：持久化后门

WMI 允许设置触发器（过滤器），当满足条件时将运行脚本或可执行文件。

• 事件过滤器（Event Filter）：触发条件事件

• 消费者 （Event Consumer）：脚本或可执行文件

• 绑定（Bind）：将过滤器 + 消费者绑定在一起

事件过滤器可以基于时间（每 20 秒）执行、服务启动、用户身份验证、文件创建等事件。

PowerShell 或 mofcomp.exe 可用于设置触发器，PowerShell 的cmdlet “Get-WmiObject”可以识别并删除可疑WMI事件。

WMI 消费者以 SYSTEM 权限运行

WMI 持久化后面需要三个步骤：

1.必须创建一个事件过滤器来描述要检测的特定触发器（例如，每 20秒）

2.事件消费者被添加到系统中，并带有要运行的脚本和/或可执行文件

3.最后，事件触发器和消费者绑定在一起，并将持久性机制加载到 WMI 存储库中。

这三个步骤通常写在托管对象格式 (MOF) 文件中，该文件用于将新类注册到 WMI 存储库中。为了更加隐蔽，还可以使用 PowerShell Set-Wmilnstance 或 Createlnstance。事件过滤器可以设置为在注册后立即触发或通过任何其他的Windows 事件触发，例如特定时间、创建文件或文件夹时、服务启动或停止时、特定用户登录时等。

2. WMI攻击利用痕迹猎捕

• 命令行分析WMI日志

• 审计 WMI 存储库

• 文件系统残留痕迹

• 异常进程分析

2.1 利用PowerShell发现可疑WMI事件

Microsoft 文档和在野外看到的大多数事件消费者都使用标准的root/Subscription命名空间，但也可以通过root/Default命名空间来实现恶意持久化。

利用PowerShell查询root/Subscription和root/Defaulf命名空间，查找可疑的WMI事件，比如，使用 -Class CommandLineEventConsumer参数的WMI事件。

以下一组命令：

Get-WMIObject -Namespace root\Subscription -Class __EventFilterGet-WMIObject -Namespace root\Subscription -Class __EventConsumerGet-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding
Get-WMIObject -Namespace root\Default -Class __EventFilterGet-WMIObject -Namespace root\Default -Class __EventConsumerGet-WMIObject -Namespace root\Default -Class __FilterToConsumerBinding

2.2 审计 WMI 存储库

WMI存储库的路径：

\Windows\System32\wbem\Repository

PowerShell 可以使用 Get-WmiObject 等命令查询 WMI 数据库，它位于 \Windows\System32\wbein\Repository 文件夹和由五个文件组成（数据主要在 OBJECTS.DATA 中）。

WMI 数据库是压缩的。微软几乎没有提供有关格式和内容的文档。与这些文件的典型交互包括 PowerShell 和 WMIC 查询。

WMI Explorer是一个开源的图形化工具，方便对WMI 数据库进行审计。

https://github.com/vinaypamnani/wmie2

离线解析 WMI 数据库

WMI Forensics PyWMIPersistenceFinder.py by David Pany: https://github.com/davidpany/WMI_Forensics

David Pany 编写了一个脚本搜索 OBJECTS.DATA 中 WMI 事件消费者的实例并显示结果。输出将类似于使用 PowerShell Get-WmiObject 获得的结果。

PyWMIPersistenceFinder.py C:\Windows\System32\wbem\Repository\OBJECTS.DATA

flare-wmi是辅助离线分析的项目，其中包括三个工具：

python-cim是用于 WMI 存储库数据库的纯 Python 解析器。它支持灵活的 API 对 WMI 结构进行读取访问。可以使用提供的脚本，获取时间线活动信息并恢复已删除的数据。

WMIParser是 WMI 存储库数据库文件的取证解析器，可以提取FilterToConsumerBindings恶意劫持的内容。

WMI-IDS是一个概念验证的无代理主机入侵检测系统，旨在展示 WMI 实时响应系统事件的能力。

2.3 调查 WMI 事件消费者

    调查 WMI 事件消费者者时，重要的是要知道有五种主要类型。在这五个中，我们重点关注两个类：

CommandLineEventConsumers允许事件过滤器（触发器）的有效负载成为可执行文件。可能会在属性中看到恶意可执行文件，例如 evil.exe，或者更复杂的东西，例如 rundll32.exe 或 powershell.exe 以及参数。

ActiveScriptEventConsumers非常灵活，可以执行磁盘上脚本。对于这些类型的使用者，Visual Basic 或 JScript 是两种常见的脚本语言。这种类型的使用者中不会看到 PowerShell 脚本。

2.4 WMI 持久化痕迹

关注两类消费者（ActiveScriptEventConsumer和CommandLineEventConsumer）

可以确定事件过滤器（触发事件）

搜索关键词：

.exe .vbs .ps1.dll .eval ActiveXObjectpowershell CommandLineTemplate ScriptText

常见误报：

SCM Event Log Consumer BVTFilter TSlogonEvents.vbsTSLogonFilter RAevent.vbs RmAssistEventFilterKernCap.vbs NTEventLogConsumer WSCEAA.exe (Dell)

2.5 文件系统痕迹：MOF 文件

托管对象格式 (MOF)：用于描述 WMI 类的文本语言。大部分位于：

%SystemRoot%\System32\wbem

Set-WmiInstance 可以用来代替 MOF 文件。

    MOF 文件一般表示为 WMI 类定义和实例的文本文件。Windows 使用 MOF 文件来构建 WMI 存储库。WMI 存储库中的每个定义最初都是在 MOF 中定义的。MOF 文件是将恶意类引入 WMI 存储库的一种非常常见的方法。可以在 WMI 二叉树索引C:\Windows\System32\wbem\Repository\index.btr 中找到对 MOF 文件的引用。

    基本上系统的 MOF 存储在 WBEM 文件夹中。但 MOF 实际上可以存储在任何地方，并且只需要已编译的 MOF 文件存在于存储库中。MOF 文件可以命名为任何名称、位于任何位置，甚至在将其引入 WMI 存储库后将其删除。这使得查找恶意 MOF 文件变得非常困难。

    Mofcomp.exe 用于编译 .MOF 文件并将它们添加到 WMI 存储库。WMI 数据库文件也经常更新，这意味着 Prefetch 的 NTFS 修改时间和文件无法用于识别何时添加了恶意内容。 

    MOF 编译器允许远程命名空间，因此为“-N”选项提供远程机器名称，以及将 MOF 文件编译新类并将其插入远程系统的 WMI 数据库中。

    在这种情况下，MOF 文件 不会写入远程系统上的磁盘。要完成远程 MOF 编译，只需从 MOF 顶部省略 #PRAGMA 命名空间并使用以下命令编译 MOF：

mofcomp -N \\[machinename]\root\subscription test.mof

利用 PowerShell 添加到 WMI 数据库

可以不需要通过MOF 文件来设置使用者。

WMI 对象定义可以在没有 MOF 文件的情况下创建，使用 .NET 代码直接插入到 CIM 存储库中。用于导入项目的 PowerShell 相对简单，但 MOF 文件使其在执行更复杂的事件（如 ActiveScript）时更简洁。

PowerShell 示例（使用 c:\alg.exe 作为恶意负载，并且事件在任何服务修改的 10 秒内触发）：

Set-Wmilnstance -Class EventFilter -NameSpace "root\subscription" -Arguments @{Name="wmi";EventNameSpace="root\cimv2";QueryLanguage="WQL";Query="SELECT * FROM InstanceModificationEvent WITHIN10 WHERE Targetlnstance ISA 'Win32_Service'"}
Set-Wmilnstance -Class CommandLineEventConsumer -Namespace "root\subscription" -Arguments @{Name="wmi";ExecutablePath='C:\alg.exe';CommandLineTemplate ='C:\alg.exe'}
Set-Wmilnstance -Class FilterToConsumerBinding -Namespace "root\subscription" -Arguments @{Filter="wmi";Consumer="wmi"}

2.6 文件系统痕迹：WBEM AutoRecover

当 MOF 文件包含名为“#PRAGMA AUTORECOVER”的内容时。这是一个包含在 MOF 文件顶部附近的可选字段。“PRAGMA AUTORECOVER”确保存储 MOF 文件的副本，以防 WMI 存储库需要重建自身。

这是一种预防措施，以确保MOF最终不会从数据库中过期。

通常攻击者希望将恶意文件无限期地保留在 WMI 存储库中。

当 MOF 文件中包含 #PRAGMA AUTORECOVER 时，其副本存储在 C:\Windows\System32\wbem\AutoRecover 文件夹中。这为 WMI 数据库威胁猎捕提供了绝佳机会。自动恢复功能也可以通过 mofcomp.exe 工具使用“-autorecover”参数来查看。

当备份副本存储在此文件夹中时，它会被重命名。可以通过文件时间戳（创建和修改）帮助识别异常值，并有助于将分析重点放在预期攻击时间范围内包含的项目上。

2.7 文件系统痕迹：WBEM AutoRecover Key

当 MOF 文件中包含 #PRAGMA AUTORECOVER 时，还会为该文件创建一个 Windows 注册表项。位于 HKLM\SOFTWARE\Microsoft\Wbem\CIMOM 键中，在名为“Autorecover MOFs”的值下。

此值中记录的名称不会是原始名称，但会包含编译时所在的文件夹路径。

提供的名称也可能表明消费者的类型——在这个例子中，我们找到了一个“ActiveScript”消费者。路径特别重要，因为几乎所有“真实”的 MOF 文件都在 WBEM 文件夹中。因此，Windows 文件夹之外的这个键中的任何内容都应该是查看磁盘上 C:\Windows\System32\wbem\AutoRecover 文件夹文件的绝佳线索。

HKLM\SOFTWARE\Microsoft\Wbem\CIMOM

2.8 可疑的 WMI 进程

wmiprvse.exe是CommandLineEventConsumers的父进程。

发现可疑 WMI 活动的另一个方式是通过进程。这些信息来自正在运行的系统上的内存，因此需要内存分析方法。可以使用 Volatility、Rekal、GRR 等工具或许多可用的商业 EDR 工具，通过实时或死内存取证来执行此类分析。

在查看内存中的进程时，重要的是要了解每个进程都有一个父进程。通过流程树组织并分析这些父子关系，我们通常可以得出异常。这是一种识别 WMI 事件消费者和大量其他异常 WMI 活动的可靠方法。

标准 WMI 进程是 wmiprvse.exe。一个调制解调器 Windows 系统可能会运行其中的几个，它们的父进程应该是进程 svchost.exe。

如果看到 wmiprvse 与 W3WP（IIS Web 服务器工作进程）之类的父进程一起运行，可能表明 webshell 活动。

wmiprvse.exe 产生了一个 cmd.exe 进程，这是非常不寻常的。这实际上是 WMI CommandLineEventConsumer 执行时的情况。在这种情况下，攻击者似乎正在修改实现受保护进程的 Windows 注册表值（从 Windows 8 开始的一项新功能）。攻击的可能是通过这种机制降低 LSASS 的安全性。

scrcons.exe是ActiveScriptEventConsumers的父进程

当 ActiveScriptEventConsumers 被执行时，它们会生成一个在大多数系统上很少见的进程，即 scrcons.exe。

scrcons.exe 的 Microsoft 官方名称是 WMI 标准事件使用者 - 脚本应用程序。

这个系统上 scrcons.exe 进程的存在很有趣，但是将这些信息与随后由该进程产生的子进程结合起来，来识别异常情况。

例如， cmd.exe 用于执行批处理文件的子进程，C:\Windows\debug\c2.bat。然后，该批处理文件正在通过 FTP 导出数据。

2.9 发现 WMI 活动

威胁猎捕可以非常有效地对抗有害的 WMI 攻击和持久性

• 熟悉常用的攻击工具和脚本

• 使用命令行审计

• 内存分析和进程树分析

可疑活动

• wmic 进程调用创建

• Invoke-WmiMethod / Invoke-CimMethod (PowerShell)

• 带有异常父进程的 wmiprvse.exe（父进程不是 svchost.exe）

• 带有异常子进程的 wmiprvse.exe (子进程有powershell.exe)

• scrcons.exe（ActiveScript Consumer，异常子进程）

• PowerShell（尤其是编码的命令行）

reference

• https://github.com/PowerShellEmpire/PowerTools/blob/master/PowerUp/PowerUp.ps1

• https://www.microsoft.com/security/blog/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/

• https://docs.microsoft.com/zh-cn/windows/win32/wmisdk/monitoring-events?redirectedfrom=MSDN

• https://github.com/davidpany/WMI_Forensics

• https://github.com/mandiant/flare-wmi

• https://docs.microsoft.com/zh-cn/windows/win32/wmisdk/standard-consumer-classes?redirectedfrom=MSDN

• https://docs.microsoft.com/zh-cn/windows/win32/wmisdk/running-the-mof-compiler-on-a-file?redirectedfrom=MSDN

• https://learn-powershell.net/2013/08/14/powershell-and-events-permanent-wmi-event-subscriptions/