近日，FireEye 安全公司的高級逆向工程團隊（FLARE）發布了一份標題為《 WMI 攻擊，防御與取證分析技術 》的 PDF 文檔，該文檔頁數多達 90 頁，文檔內容主要從攻擊，防御和取證分析這三個角度分篇對 WMI 技術做了詳細的描述。其中不乏有很多值得學習思考的地方。于是，我利用業余時間翻譯整理了此文檔，拿出來與大家共分享 :），如有紕漏，望各位不吝賜教。
為了對原文檔內容進行全面的翻譯和解讀，我按照文章的分析角度對原文檔進行了分段式的翻譯，本篇文章是分段式里面的第一篇，其余兩篇譯文的標題分別為：
WMI 的全稱是 Windows Management Instrumentation，即 Windows 管理規范，在 Windows 操作系統中，隨著 WMI 技術的引入并在之后隨著時間的推移而過時，它作為一項功能強大的技術，從 Windows NT 4.0 和 Windows 95 開始，始終保持其一致性。它出現在所有的 Windows 操作系統中，并由一組強大的工具集合組成，用于管理本地或遠程的 Windows 系統。
盡管已被大眾所知并且從其創始以來，已經被系統管理員大量使用，但當WMI技術在震網病毒中被發現以后，它開始在安全社區變得非常流行。從那之后， WMI 在攻擊中變得日益普及，其作用有執行系統偵察，反病毒和虛擬機檢測，代碼執行，橫向運動，權限持久化以及數據竊取。
隨著越來越多的攻擊者利用 WMI 進行攻擊，他將會是安全維護人員，事件響應人員，取證分析師必須掌握的一項重要技能，并且要明白如何發揮它的優勢。本白皮書介紹了 WMI 技術，并且演示了在實際攻擊當中使用 WMI 構造 POC 和如何使用 WMI 作為一個基本的 IDS 以及提出了如何在 WMI 存儲庫文件格式中進行取證分析。
在 Win2K 之前的操作系統中，就已經支持了 WMI 技術，只是當時需要下載并安裝一個開發包。從 Win2K 開始，系統自帶了 WMI ，并且 WMI 成為了系統的一個重要組件。隨著 XP、2003、Vista、Win7 等的發布， WMI 所能提供的功能也在不斷的增強和完善中。
下面是操作系統版本中對應的 WMI 的版本：
WMI是微軟實現的由分布式管理任務組（DMTF）發布的基于 Web 的企業管理（WBEM）和公共信息模型（CIM）標準。這兩個標準的目的是提供工業不可知論者手段，收集和傳播在企業中有關的任何托管組件中的信息。
在一個較高的水平上，微軟所實現的這些標準可以總結如下：
托管組件
托管組件被表示為 WMI 對象 —— 表示高度結構化的操作系統數據的類實例。微軟提供了豐富的 WMI 對象用來與操作系統相關的信息進行通信。例如：Win32_Process,Win32_Service,AntiVirusProduct,Win32_StartupCommand等等。
使用 WMI 數據
微軟提供了幾種方式來使用 WMI 數據和執行 WMI 方法。例如， PowerShell 提供了一種非常簡單的方式與 WMI 進行交互。
查詢 WMI 數據
所有的WMI對象都使用類似于一個 SQL 查詢的語言稱為 WMI 查詢語言（WQL）。 WQL 能夠很好且細微的控制返回給用戶的 WMI 對象。
填充 WMI 數據
當用戶請求特定的 WMI 對象時，WMI 服務 (Winmgmt) 需要知道如何填充被請求的 WMI 對象。這個過程是由 WMI 提供程序去實現的。WMI 提供程序是一個基于 COM 的 DLL 文件 ，它包含一個在注冊表中已經注冊的相關聯的 GUID 。 WMI 提供程序的功能 —— 例如查詢所有正在運行的進程，枚舉注冊表項等等。
當 WMI 服務填充 WMI 對象時，有兩種類型的類實例: 動態對象和持久性對象。動態對象是在特定查詢執行時在運行過程中生成的。例如，Win32_Process 對象就是在運行過程中動態生成的。持久性對象存儲在位于 %SystemRoot%\System32\wbem\Repository\ 的 CIM 數據庫中，它存儲著 WMI 類的實例，類的定義和命名空間的定義。
結構化 WMI 數據
絕大多數的 WMI 對象的架構是在托管對象格式 (MOF) 文件中描述的。MOF 文件使用類似于 C++ 的語法并為一個 WMI 對象提供架構。因此，盡管 WMI 提供程序產生了原始數據，但是 MOF 文件為其產生的數據提供了被格式化的模式。從安全維護人員的角度來看，值得注意的是， WMI 對象定義可以在沒有 MOF 文件的情況下被創建。相反，他們可以使用 .NET 代碼直接插入到 CIM 資料庫中。
遠程傳輸 WMI 數據
Microsoft 提供了兩個協議用于遠程傳輸 WMI 數據: 分布式組件對象模型 (DCOM) 和 Windows 遠程管理 (WinRM)。
執行 WMI 操作
部分 WMI 對象包括可執行的方法。例如，攻擊者進行橫向運動時執行的一個常用方法是在 Win32_Process 類中的靜態 Create 方法，此方法可以快速創建一個新的進程。另外， WMI 提供了一個事件系統，使用戶可以使用注冊事件處理函數進行創建，修改或刪除任何 WMI 對象實例。
圖 1 提供了微軟實現 WMI 的一個高級別概述以及微軟實現的組件和實現的標準之間的關系。
圖 1: WMI 體系結構的高級別概述
WMI 代表著大多數與操作系統信息以及以對象的形式操作有關的數據。一個 WMI 對象是高度結構化定義的信息被如何表示的類的實例。在 MSDN 上，有很多常用的 WMI 類的詳細介紹。例如，常見的、有據可查的 WMI 類是 Win32_Process。還有很多未文檔化的 WMI 類，幸運的是，所有的 WMI 類都可以使用 WMI 查詢語言 (WQL) 進行查詢。
WMI 類的命名空間的層次結構非常類似于傳統的，面向對象的編程語言的命名空間。所有的命名空間都派生自根命名空間，在用腳本語言查詢對象并未顯式指定命名空間時，微軟使用 ROOT\CIMV2 作為默認的命名空間。在下面的注冊表項中包含所有 WMI 設置，也包括已定義的默認命名空間:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM
可以使用下面的 PowerShell 代碼遞歸查詢所有的 WMI 類和它們各自的命名空間。
圖 2：列舉所有 WMI 類和命名空間的 PowerShell 示例代碼
我們在 Windows 7 系統上測試后發現已經有 7950 個 WMI 類，這意味著有大量的操作系統數據可被檢索。
下面是由上述腳本執行后返回的完整 WMI 類路徑的一部分結果：
WMI 提供了一種簡單的語法用于查詢 WMI 對象實例、 類和命名空間 — — WMI 查詢語言 (WQL) 。
有三種類別的 WQL 查詢:
1.實例查詢 —— 用于查詢 WMI 類的實例
2.事件查詢 —— 用于一個 WMI 事件注冊機制，例如 WMI 對象的創建、 刪除或修改
3.元查詢 —— 用于查詢 WMI 類架構
實例查詢是最常見的用于獲取 WMI 對象實例的 WQL 查詢。基本的實例查詢采用以下形式:
SELECT [Class property name|*] FROM [CLASS NAME] <WHERE [CONSTRAINT]>
以下查詢將返回所有正在運行的進程的可執行文件名稱中包含"Chrome"的結果。具體的說是，此查詢將返回 Win32_Process 類的每個實例的所有屬性的名稱字段中包含字符串"Chrome"的結果。
SELECT * FROM Win32_Process WHERE Name LIKE "%chrome%"
事件查詢提供了報警機制，觸發事件的類。在 WMI 類實例被創建時被用于常用的事件查詢觸發器。事件查詢將采取以下形式:
SELECT [Class property name|*] FROM [INTRINSIC CLASS NAME] WITHIN [POLLING INTERVAL] <WHERE [CONSTRAINT]>
SELECT [Class property name|*] FROM [EXTRINSIC CLASS NAME] <WHERE [CONSTRAINT]>
內部和外部的事件將在事件章節中進一步詳細解釋。
下面是交互式用戶登錄的事件查詢觸發器。根據MSDN 文檔描述，交互式登錄的LogonType值為 2。
SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance
ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2
下面是在可移動媒體插入時的事件查詢觸發器：
SELECT * FROM Win32_VolumeChangeEvent WHERE EventType = 2
元查詢提供一個 WMI 類架構發現和檢查機制。元查詢采用以下形式:
SELECT [Class property name|*] FROM [Meta_Class<WHERE [CONSTRAINT]>
以下查詢將列出所有以字符串 "Win32" 開頭的 WMI 類：
SELECT * FROM Meta_Class WHERE __Class LIKE "Win32%"
當執行任何 WMI 查詢時，除非顯式提供命名空間，否則將隱式使用默認的命名空間 ROOT\CIMV2。
Microsoft 和第三方供應商提供了豐富的客戶端工具使您可以與 WMI 進行交互。以下是此類客戶端實用程序的非詳盡清單：
PowerShell 是功能極其強大的腳本語言，包含了豐富的與 WMI 進行交互的功能。截至 PowerShell V3，以下 cmdlet (PowerShell 命令術語) 可用于與 WMI 進行交互：
WMI 和 CIM 的 cmdlet 也提供了類似的功能。然而，CIM cmdlet 引入了 PowerShell V3，并通過 WMI cmdlets 提供了一些額外的靈活性。使用 CIM cmdlet 的最大優點是它們工作在 WinRM 和 DCOM 協議之上。WMI cmdlet 只工作在 DCOM 協議之上。但是并不是所有的系統都將安裝 PowerShell v3+。PowerShell v2 是默認安裝在 Windows 7 上的。因此，它被攻擊者視為最小公共程序。
wmic.exe 是一個與 WMI 進行交互的強大的命令行實用工具。它擁有大量的 WMI 對象的方便記憶的默認別名，但你還可以執行更為復雜的查詢。wmic.exe 還可以執行 WMI 方法，攻擊者經常用來通過調用 Win32_Process 的 Create 方法來進行橫向運動。Wmic.exe 的局限性之一是不能接受調用嵌入的 WMI 對象的方法。在 PowerShell 不可用的情況下,使用 wmic.exe 足夠用于執行系統偵察和基本方法的調用。
wbemtest.exe 是一個功能強大的帶有圖形界面的 WMI 診斷工具。它能夠枚舉對象實例、執行查詢、注冊事件、修改 WMI 對象和類，并且可以在本地或遠程去調用方法。它的接口對大多數用戶來說不是特別友好，但從攻擊者的角度來看，在其他工具不可用時，它完全可以作為替代選項 —— 例如，如果應用程序白名單機制阻止了 wmic.exe 和 powershell.exe，那么 wbemtest.exe 將是一個帶有一個不太理想的 UI （如圖 3 所示）但是功能卻很強大的實用工具。
圖 3 wbemtest的圖形接口
WMI Explorer 是一個很好的 WMI 類發現工具。它提供了一個優雅的 GUI （圖 4 所示），你可以使用分層次的方式探索 WMI 存儲庫。它也能夠連接到遠程的 WMI 存儲庫，并執行查詢。對安全研究人員尋找可用于攻擊或防御的 WMI 類來說，像這樣的 WMI 類發現工具是非常有價值的。
圖 4 WMI Explorer
CIM Studio 是 Microsoft 遺留的一個免費工具，你可以方便地瀏覽 WMI 存儲庫。像 WMI Explorer 一樣，此工具也可以很好的進行 WMI 類發現。
Microsoft 提供了兩個 WSH 腳本語言，VBScript 和 JScript。盡管它們比較過時，也算不上高雅的編程語言，但是說到與 WMI 進行交互時，它們的確都是功能強大的腳本語言。事實上，使用 VBScript 和 JScript 編寫的利用 WMI 作為主要的 C&C 機制的后門已經出現了。此外，如后面將要解釋的，它們是唯一支持 ActiveScriptEventConsumer 事件消費者組件的語言，該組件對于攻擊者和防御者來說都是一個非常有價值的 WMI 組件。最后，從攻擊的角度來看， VBScript 和 JScript 是在未安裝 PowerShell 的老版本的 Windows 系統上的最小公共程序。
如果你需要使用非托管語言如 C 或 C++ 與 WMI 進行交互，你將需要使用 WMI 的 COM API。逆向工程師將需要非常熟悉此接口以及每一個 COM Guid 才能充分理解與 WMI 交互的惡意軟件。
.NET 類庫在 System.Management 命名空間中提供了幾個與 WMI 相關的類，可以相對簡單的使用如 C#、VB.Net 和 F# 語言編寫與 WMI 交互的程序。在后續的示例中，這些類將用于在 PowerShell 代碼中補充現有的 WMI/CIM cmdlet。
winrm.exe 可以在運行 WinRM 服務的本地和遠程計算機上進行枚舉 WMI 對象實例、調用方法，并創建和刪除對象實例。也可以用 winrm.exe 來配置 WinRM 設置。
下面的示例顯示了 winrm.exe 可用于執行命令、枚舉對象的多個實例，并檢索單個對象實例:
winrm invoke Create wmicimv2/Win32_Process @{CommandLine="notepad.exe";CurrentDirectory="C:\"}winrm enumerate http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Processwinrm get http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystemwmic 是一個簡單的 Linux 命令行實用工具，用于執行 WMI 查詢。wmis 是 Win32_Process 類的 Create 方法的遠程調用命令行包裝程序，并且支持使用 NTLM 哈希進行連接遠程計算機，因此， wmis 已經被滲透測試人員大量使用。
雖然可以與本地的 WMI 進行交互，但是通過網絡才能顯示出 WMI 的真實能量。目前，由于 DCOM 和 WinRM 這兩個協議的存在，將使得遠程對象的查詢，事件注冊， WMI 類方法的執行，以及類的創建都能夠被支持。
這些協議看起來非常有利于攻擊者，因為大多數組織機構和安全供應商一般不審查這些惡意活動所傳輸的內容。攻擊者需要有效的利用遠程 WMI 則需要有特權用戶的憑據。在 Linux 平臺中的 wmis-pth 實用工具，則需要的是受害者的用戶的哈希。
從 DCOM 出現以來它一直是 WMI 所使用的默認協議，通過 TCP 的 135 端口建立初始連接。后續的數據交換則使用隨機選定的 TCP 端口。可以通過 dcomcnfg.exe 并最終修改下面的注冊表項來配置此端口的范圍：
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet –Ports (REG_MULTI_SZ)
在 PowerShell 中內置的所有 WMI cmdlets 都是使用 DCOM 進行通信的。
最近， WinRM 取代了 DCOM 并成為 Windows 推薦的遠程管理協議。WinRM 的構建基于 Web 服務管理 (WSMan) 規范 —— 一種基于 SOAP 的設備管理協議。此外，PowerShell 的遠程傳輸協議也是基于 WinRM 規范的，同時 PowerShell 提供了極其強大的 Windows 企業級的遠程管理。WinRM 也支持 WMI，以及通過網絡執行 CIM 操作。
默認情況下，WinRM 服務監聽的 TCP 端口是 5985 （HTTP），并且在默認情況下是加密的。還可以配置證書使其支持 HTTPS ，此時監聽的 TCP 端口為 5986。
WinRM 的設置很容易配置，可以使用 GPO ， winrm.exe ，或 PowerShell 中的 WSMan PSDrive 來配置，如下所示：
PowerShell 提供了一個 cmdlet 可以很方便的驗證 WinRM 服務是否正在偵聽 —— Test-WSMan。如果 Test-WSMan 返回了結果，則表明該系統的 WinRM 服務正處于監聽狀態。
為了與系統的 WMI 進行交互以便運行 WinRM 服務，唯一支持遠程 WMI 交互的內置工具是 winrm.exe 和 PowerShell 的 CIM cmdlet。此外，對于沒有運行 WinRM 服務的系統還可以使用 CIM cmdlet 來配置使用 DCOM 。
從攻擊者或防御者的角度來看， WMI 最強大的功能之一就是對 WMI 事件的異步響應的能力。除了少數例外，WMI 事件幾乎可以用于對操作系統的任何事件作出響應。例如，WMI 事件可能用于觸發一個進程創建的事件。這種機制可隨后被用作在任何 Windows 操作系統上執行命令行審計。
有兩類 WMI 事件 —— 它們都運行在本地的單個進程和 WMI 永久事件訂閱的上下文中。本地事件可以維持宿主進程的生存期，盡管 WMI 永久事件訂閱存儲在 WMI 存儲庫中，但是作為 SYSTEM 權限運行后依舊可以在重新啟動之后繼續持續運行。
要安裝一個永久事件訂閱，下面三件事情是必須要做的：
1.事件篩選器 —— 篩選出感興趣的事件
2.事件消費者 —— 要在事件被觸發時執行的操作
3.消費者綁定篩選器 — — 將篩選器綁定到消費者的注冊機制
事件篩選器描述了感興趣的事件并且執行了 WQL 事件查詢。一旦系統管理員配置了篩選器，他們就可以使用它在創建新的事件時接收到通知。舉一個例子，事件篩選器可能用于描述以下一些事件:
事件篩選器都被存儲為一個 ROOT\subscription:__EventFilter 對象的實例。事件篩選器查詢支持以下類型的事件:
內部事件表示的是創建、修改和刪除任何 WMI 類，對象或命名空間的事件。它們也可被用于計時器或 WMI 方法執行的警報。以下內部事件采用了系統類 (以兩個下劃線開頭的那些) 的形式，并存在于每一個 WMI 命名空間:
這些事件的作用非常強大，因為它們可以被用于在操作系統中幾乎任何可以想見的事件的觸發器。例如，如果觸發了一個基于交互式登錄的事件則可以形成下面的內部事件查詢:
此查詢被轉換為創建一個登錄類型為 2 （交互式）的 Win32_LogonSession 類的一個實例。
由于觸發的內部事件有一定的頻率，所以必須在 WQL 查詢語句的 WITHIN 子句中指定事件輪詢間隔。這就是說，它有時可能錯過事件。例如，如果事件查詢的形式目的是創建 WMI 類的實例，如果該實例的創建和銷毀 (如常見的一些進程 —— Win32_Process 實例) 在輪詢間隔內，那么則會錯過這一事件。創建內部 WMI 查詢時，必須考慮這種可能出現的情況。
SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2
外部事件解決了和內部事件有關的潛在的輪詢問題，因為它們在事件發生時立刻被觸發。然而美中不足的是在 WMI 中并沒有太多的外部事件，不過，所有已經存在的外部事件的作用很強大，性能也很高。下面的外部事件對于攻擊者和防御者來說可能是有用的：
以下外部事件查詢形式可以用來捕獲每一個進程已加載的所有可執行模塊（用戶模式和內核模式）：
SELECT * FROM Win32_ModuleLoadTrace
事件消費是一個派生自 __EventConsumer 系統類的類，它表示了在事件觸發時的動作。系統提供了以下有用的標準事件消費類：
攻擊者在響應他們的事件時，大量使用 ActiveScriptEventConsumer 和 CommandLineEventConsumer 類。這兩個事件消費者為攻擊者提供了極大的靈活性去執行他們想要執行的任何 payload 并且無需寫入一個惡意的可執行文件或腳本到磁盤。
圖 5 中的 PowerShell 代碼是修改過的存在于 SEADADDY 惡意軟件家族中的 WMI 持久性代碼實例。該事件篩選器取自 PowerSploit 的持久性模塊，目的是在系統啟動后不久觸發，事件消費者只需執行一個具有系統權限的可執行文件。圖 5 中的事件篩選器在系統啟動后的 200 和 320 秒之間被當作一個觸發器。在事件被觸發時事件消費者會執行已指定好的可執行文件。通過指定篩選器和一個 __FilterToConsumerBinding 實例將篩選器和消費者注冊并將二者綁定在一起。
圖 5 ：SEADADDY 惡意軟件的 WMI 持久性 PowerShell 代碼
在攻擊者的各個階段的攻擊生命周期中，WMI 都是極其強大的工具。系統提供了豐富的 WMI 對象、方法和事件，它們的功能極其強大，可以執行很多東西，從系統偵察、反病毒、虛擬機檢測、代碼執行、橫向運動、隱蔽存儲數據到持久性。它甚至可以打造一個純粹的 WMI 后門且無需寫入文件到磁盤。
攻擊者使用 WMI 有很多優勢：
以下列表顯示了幾個如何使用 WMI 在攻擊的各個階段執行操作的例子。
許多惡意軟件操縱者和滲透測試人員所做的第一件事情就是系統偵察， WMI 包含有大量的類可以幫助攻擊者去感知他們的目標的環境。
下面的 WMI 類是在攻擊的偵察階段可以收集數據的子集:
已安裝的 AV 產品通常會將自己注冊在 WMI 中的 AntiVirusProductclass 類中的 root\SecurityCenter 或者是 root\SecurityCenter2 命名空間中，具體是哪一個命名空間則取決于操作系統的版本。
一個 WMI 客戶端可以通過執行下面的 WQL 查詢示例來獲取已安裝的 AV 產品:
SELECT * FROM AntiVirusProduct
如下圖所示：
惡意軟件可以使用 WMI 對通用的虛擬機和沙盒環境進行檢測。例如，如果物理內存小于 2 GB 或者是單核 CPU ，那么很可能操作系統是在虛擬機中運行的。
WQL 查詢示例如下：
SELECT * FROM Win32_ComputerSystem WHERE TotalPhysicalMemory < 2147483648
SELECT * FROM Win32_ComputerSystem WHERE NumberOfLogicalProcessors < 2
圖 6 顯示了使用 WMI 和 PowerShell 對通用的虛擬機進行檢測的操作：
圖 6 ：檢測通用的虛擬機的 PowerShell 代碼
下面的查詢示例試圖查找 VMware 字符串是否出現在某些 WMI 對象中并且檢查 VMware tools 的守護進程是否正在運行：
SELECT * FROM Win32_NetworkAdapter WHERE Manufacturer LIKE "%VMware%"
SELECT * FROM Win32_BIOS WHERE SerialNumber LIKE "%VMware%"
SELECT * FROM Win32_Process WHERE Name="vmtoolsd.exe"
SELECT * FROM Win32_NetworkAdapter WHERE Name LIKE "VMware%"
圖 7 演示的是使用 WMI 和 PowerShell 對 VMware 虛擬機進行檢測的操作：
圖 7 ：檢測 VMware 虛擬機的 PowerShell 代碼
有兩種常用的方法可以實現 WMI 的遠程代碼執行: Win32_Process 的 Create 方法和事件消費者。
Win32_Process 類包含一個名為 Create 的靜態方法，它可以在本地或遠程創建進程。這種情況下 WMI 就等同于運行 psexec.exe 一樣，只是沒有了不必要的取證操作，如創建服務。下面的示例演示了在遠程機器上執行進程：
一個更切實可行的的惡意使用案例是調用 Create 方法并且使用 powershell.exe 調用包含嵌入的惡意腳本。
實現代碼執行的另外一個方法是創建一個 WMI 永久事件訂閱。通常情況下， WMI 永久事件訂閱被設計為對某些事件持續的做出響應。然而，如果攻擊者想要執行一個 payload ，他們可能只需要配置事件消費者去刪除其相應的事件篩選器、消費者和綁定到消費者的篩選器。這種技術的優點是 payload 是作為系統進程運行的并且避免了以明文方式在命令行審計中顯示 payload。例如，如果采用了一個 VBScript 的 ActiveScriptEventConsumer payload，那么唯一創建的進程是以下 WMI 腳本宿主進程：
%SystemRoot%\system32\wbem\scrcons.exe -Embedding
作為攻擊者，為了使用這個類作為攻擊向量，將會遇到的挑戰是去選擇一個智能的事件篩選器。如果他們只是想要在幾秒鐘后觸發運行 payload，那么可以使用 __IntervalTimerInstruction 類。攻擊者可能會選擇在用戶的屏幕鎖定后執行 payload，在這種情況下，可以使用外部的 Win32_ProcessStartTrace 事件作為創建 LogonUI.exe 的觸發器。攻擊者可以在他們選擇的一個適當的事件篩選器中獲得創意。
攻擊者巧妙的利用了 WMI 存儲庫本身作為一種來存儲數據的手段。其中一種方法是可以通過動態創建 WMI 類并可以將任意數據存儲作為該類的靜態屬性的值。圖 8 演示了將一個字符串存儲為靜態的 WMI 類屬性的值：
圖 8 ：創建 WMI 類的 PowerShell 代碼示例
前面的示例演示了創建本地的 WMI 類。然而，也有可能可以創建遠程的 WMI 類，這個將會在下一節進行說明。遠程的創建和修改類的能力將使攻擊者能夠存儲和檢索任意數據，并將 WMI 變成 C2 的有效通道。
這取決于攻擊者決定他們想用 WMI 存儲庫中存儲的數據來做什么。接下來的幾個例子闡述了攻擊者如何利用此攻擊機制的幾個切實可行的例子。
使用 WMI 作為一種來存儲和檢索數據的機制，同樣也可以使得 WMI 能作為一個純粹的 C2 通道。這種使用 WMI 的聰明想法是由 Andrei Dumitrescu 在他 WMI Shell 工具中被首次公開——利用創建和修改 WMI 的命名空間作為 C2 的通道。
實際上還有很多 C2 暫存機制可以采用， 如剛才討論過的 WMI 類的創建。同樣也有可能使用注冊表進行數據轉儲作為 WMI C2 的通道。下面的示例演示了一些利用 WMI 作為 C2 通道的 POC 代碼。
圖 9 演示了如何遠程創建 WMI 類來存儲文件數據。之后可以遠程使用 powershell.exe 將該文件數據寫入到遠程文件系統。
圖 9 ： 遠程創建 WMI 類并寫入到遠程文件系統的 PowerShell 代碼
圖 10 演示了如何使用注冊表來收取 PowerShell 命令的結果。此外，許多惡意工具試圖捕捉只是將輸出轉換為文本的 PowerShell 命令的輸出。本示例利用了 PowerShell 對象序列化和反序列化方法來保持目前在 PowerShell 對象中豐富的類型信息。
圖 10 : 從 WMI 類屬性拉回命令數據的 PowerShell 代碼
提供程序是 WMI 的主干部分。幾乎所有 WMI 類以及他們各自的方法都是在提供程序中實現的。提供程序是一個用戶模式的 COM DLL 或者是一個內核驅動程序。每個提供程序都具有各自的 CLSID 用于在注冊表中區別相關聯的 COM 。此 CLSID 用于查找實現該提供程序的真正的 DLL 。此外，所有已注冊的提供程序都有各自的 __Win32Provider WMI 類實例。例如，請思考以下已注冊的處理注冊表操作的 WMI 提供程序:
通過引用以下注冊表值來找到 RegistryEventProvider 提供程序對應的 DLL：
HKEY_CLASSES_ROOT\CLSID\{fa77a74e-e109-11d0-ad6e-00c04fd8fdff}\InprocServer32 : (Default)
WMI 提供程序僅用來向用戶提供合法的 WMI 功能，因此，惡意的 WMI 提供程序就可以被攻擊者用于擴展 WMI 的功能。
Casey Smith 和 Jared Atkinson 兩人發布了惡意的 WMI 提供程序的 POC ，這些惡意的提供程序能夠遠程執行 Shellcode 和 PowerShell 腳本。惡意的 WMI 提供程序作為一種有效的持久性機制，它允許攻擊者遠程執行代碼，只要攻擊者擁有有效的用戶憑據。