安装Sysmon以后，可以捕获到进程创建的相关事件，例如下面的案例中，powershell，创建了一个mofcomp.exe，参数是一个./config.mof

Mofcomp.exe是系统自带的一个工具，用来编译mof文件，并将mof文件中的信息添加到WMI数据库中。

假如我们没有发现上面的Sysmon创建mofcomp.exe进程事件，但是稍后3分钟，应该也会看到一个WMI消费者相关的事件，下面就是Sysmon发现了WMI消费者事件

WMI支持以下几种类型的事件消费者，比如前两个类型的消费者，运行在特定事件发生时，执行一个可执行文件，或者vb、js脚本文件。

甚至我们看到最下面有一种Costom，自定义类型的时间消费者。 虽然目前还没见到有任何恶意样本在使用这中类型的消费者。

但是我们正在一步一步的，迫使攻击者去研究使用这些其类型的事件消费者，这也同时给我们带来更多的挑战！！

攻击者通过powershell来使用WMI，可以很轻松的来绑定、添加针对某种类型的事件消费者函数，同时Powershell也给防御者提供了方便的功能，来检测可疑的WMI事件。

通过下面ps命令，就可以检测当前系统上正在运行的消费者事件、事件过滤器、以及过滤器和消费者之间的绑定关系

攻击者通过powershell来使用WMI，可以很轻松的来绑定、添加针对某种类型的事件消费者函数，同时Powershell也给防御者提供了方便的功能，来检测可疑的WMI事件。

通过下面ps命令，就可以检测当前系统上正在运行的消费者事件、事件过滤器、以及过滤器和消费者之间的绑定关系

查看系统上注册的WMI事件消费者

Get-WMIObject -Namespace root/Subscription -Class __EventConsumer

查看系统上注册的事件过滤器

Get-WMIObject -Namespace root/Subscription -Class __EventFilter

查看系统上已经绑定的过滤器和消费者

Get-WMIObject -Namespace root/Subscription -Class __FilterToConsumerBinding

一般来讲，我们会先检查有没有可疑的Consumer，消费者，下图中，就显示了一个Consumer名字为"wmi"，在触发某种特定过滤事件的时候，就会执行Consumer中CommandLineTemplate中的命令行

通过查看命令行，我们可以发现，当事件被触发的时候，就会执行powershell.exe 并且会执行后面base64加密过的恶意ps代码，只要解密那段base64加密过的字符串，就可以搞清楚攻击者想要干什么，或者将要干什么。

通过上面介绍的方法，我们可以很轻易就可以检查单台机器上的可疑WMI攻击，但是如果要排查整个内网环境，有上百上千台机器时，怎么办？

可以通过域控或者其他方式，给内网的机器下发指令，执行上面的查询WMI消费者的命令，并将结果提交到后台数据库中，

我们可以通过检索数据库来筛选中可疑的wmi consumer，排除正常的consumer， 下面例子中，前两个是正常的consumer，最后一个是可疑的

下面例子中是Windows Server 2012 R2服务器环境，事实上，在Server 2012后面的系统，都默认支持WMI事件审计，我们只需要寻找事件ID为5861的就行

事件5861代表新创建的consumer，这一点很重要，因为在装完系统以后一般不会有新增的consumer，如果发现此类事件，应该高度警惕！！

系统默认的Event功能除了可以记录Consumer以外，还可以记录Filter

开始以为存储在注册表里面，实际独立存放在磁盘上\Windows\System32\wbem\Repository目录下的，里面的文件都是二进制数据库文件。

直接查看这些二进制数据库文件几乎是不可能的，那么在一些应急响应取证的场景下，如何从客户机器上提取这些Repository中的数据库文件回来，

在线下审计WMI呢？比较幸运的是国外的著名安全公司Firere发布了一个py脚本工具，可以读取这些WMI二进制数据库文件，可以看到熟悉的WMI事件信息。

取证必备的工具！！

另一款工具，可以读取Repository下的数据库的类和实例的创建时间来排序，这样我们可以更直观的找到最近被创建的消费者

下面例子中，找到了大概20000+条在同一时间创建的记录，但是通过排序后，立马发现了最新的一条记录，时间跨度长达一年。

立马就可以引起你的怀疑，到底这个consumer在是做什么用的？

当然了，攻击者也会利用WMI仓库的特性，专门来隐藏一些可以的脚本代码或其他东西，这点也需要我们注意。

ok上面介绍的大部分在WMI仓库目录下的Objects.data文件中

上面介绍了几种方法可以找到wmi相关的数据，在拿到数据以后如何来找到数据中恶意的东西呢？

我比较推荐先检查WMI消费者，在消费者数据中，一般会发现一些可疑的脚本代码、Powershell命令行、可疑命名的可执行文件、陌生的文件夹等都是危险的特征。

下图中的

 Intersting Search Terms 中代表是一些可疑的特征，

Connom False positives 代表的是一些常见正常的WMI消费者，我们需要在识别数据时，排除这些正常的WMI事件。

当然了，下图中最下面一行，Note，说明了一些攻击者也会把创建的消费者取名和正常的一样，来混淆取证人员分析，隐藏自己。

如果想把一些编译好的东西添加到wmi仓库中，最简单的方法就是通过mof文件，mof文件本质是txt文本，在文件中列出了写好的过滤器、消费者、绑定等

然后你就可以使用mofcomp.exe来把这些事件添加到WMI仓库中了。这也是Stuxnet震网病毒使用思路，在机器上添加WMI事件消费者。但是会留些mof文件的痕迹。

下图中底部，我们可以使用powershell来添加WMI事件，并不需要mof文件。当然了用什么思路来添加取决于攻击者，有些攻击者比较赖可能就会留些一些痕迹给我们。

你还可以使用mofcomp.exe来远程添加，这样mofcomp就不会在目标机器中出现，直接是在内存中完成的操作。

刚才说了mof文件本质是txt文件，默认不会存在#PRAGMA AUTORECOVER这行语句

假如WMI仓库被重建了，通过MOF添加进去的内容，不会在重建后的WMI仓库中。

系统会备份好之前通过mof文件添加进来的数据，把这些数据再次备份成mof文件，并在文件开头添加#PRAGMA AUTORECOVER，然后再将这些数据引入新建的WMI数据库中。

这些mof文件会保留下来

这些备份的mof文件在AutoRecover目录下，而且都是txt文件，你可以直接查看内容，来检查是否含有可疑的消费者

可能会有很多文件，但是我们可以通过时间来排除，找到可疑的mof文件

除了AutoRecover目录，我们还可以检查注册表，Autorecover MOFs下面会记录，之前编译的MOF文件路径。

下图中我可以看到之前有人在TEMP目录下编译了一个MOF文件到WMI数据库中。

通过wmi启动的进程，一般都会出现在WmiPrvSe.exe这个进程下面

下图左上角，进程链中，可以看到通过wmi启动了powershell.exe进程。

下图右上角，如果我们想通过powershell执行命令在一台远程机器上的时候，本地的进程是powershell.exe，远程机器上出现的进程就是wsmprovhost.exe

下图左下角，和上面一样，通过远程执行WMI命令时，本地可能是通过wmic.exe，在远程机器上出现的进程就是wmiprvse.exe

下图右下角，可以看到有人在这台机器上远程执行powershell命令，通过进程链的sc.exe可以知道是在执行和服务相关的命令。

下面例子中，进程链中的services.exe->svchost.exe->wmiprvse.exe看起来是正常的，

但是最后一行wmiprvse.exe启动了cmd.exe在添加一个注册表，这点就很可疑了，而且这个注册表key也非常可疑。。

而且注册表key设置的值也非常可疑，这点就非常值得我们去深挖一下，而且这一看就不是正常的wmi命令。

scrcons.exe进程是ActiveScriptEventConsumers的父进程。如果你在进程列表中看到了这个进程的命令，说明有WMI的活动脚本事件消费者函数正在执行

下面这个进程链就是著名的MyKings家族僵尸网络传播挖矿木马，还有MBR感染等。。有兴趣的可以去关注下！！

下面是我们需要熟悉的一些常见高危的WMI用法

使用这种无文件攻击的木马病毒正在与日俱增，而作为安全研究、应急响应、内存取证、病毒分析人员还是值得在进程级别以及文件级别掌握这些攻击原理以及分析方法！！