近日，FireEye 安全公司的高階逆向工程團隊（FLARE）釋出了一份標題為《 WMI 攻擊，防禦與取證分析技術 》的 PDF 文件，該文件頁數多達 90 頁，文件內容主要從攻擊，防禦和取證分析這三個角度分篇對 WMI 技術做了詳細的描述。其中不乏有很多值得學習思考的地方。於是，我利用業餘時間翻譯整理了此文件，拿出來與大家共分享 :），如有紕漏，望各位不吝賜教。

為了對原文件內容進行全面的翻譯和解讀，我按照文章的分析角度對原文件進行了分段式的翻譯，本篇文章是分段式裡面的第一篇，其餘兩篇譯文的標題分別為：

• 《 WMI 的攻擊，防禦與取證分析技術之防禦篇 》
• 《 WMI 的攻擊，防禦與取證分析技術之取證分析篇 》

0x00 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 儲存庫檔案格式中進行取證分析。

0x01 修訂歷史

---

在 Win2K 之前的作業系統中，就已經支援了 WMI 技術，只是當時需要下載並安裝一個開發包。從 Win2K 開始，系統自帶了 WMI ，並且 WMI 成為了系統的一個重要元件。隨著 XP、2003、Vista、Win7 等的釋出， WMI 所能提供的功能也在不斷的增強和完善中。

下面是作業系統版本中對應的 WMI 的版本：

• Nt 4.0 1.01
• Sms 2.0 1.1
• Win2000 1.5
• WinXP/2003 2.0

0x02 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 體系結構的高階別概述

0x03 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 類路徑的一部分結果：

0x04 查詢 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。

0x05 與 WMI 進行互動

---

Microsoft 和第三方供應商提供了豐富的客戶端工具使您可以與 WMI 進行互動。以下是此類客戶端實用程式的非詳盡清單：

PowerShell

PowerShell 是功能極其強大的指令碼語言，包含了豐富的與 WMI 進行互動的功能。截至 PowerShell V3，以下 cmdlet (PowerShell 命令術語) 可用於與 WMI 進行互動：

• Get-WmiObject
• Get-CimAssociatedInstance
• Get-CimClass
• Get-CimInstance
• Get-CimSession
• Set-WmiInstance
• Set-CimInstance
• Invoke-WmiMethod
• Invoke-CimMethod
• New-CimInstance
• New-CimSession
• New-CimSessionOption
• Register-CimIndicationEvent
• Register-WmiEvent
• Remove-CimInstance
• Remove-WmiObject
• Remove-CimSession

WMI 和 CIM 的 cmdlet 也提供了類似的功能。然而，CIM cmdlet 引入了 PowerShell V3，並透過 WMI cmdlets 提供了一些額外的靈活性。使用 CIM cmdlet 的最大優點是它們工作在 WinRM 和 DCOM 協議之上。WMI cmdlet 只工作在 DCOM 協議之上。但是並不是所有的系統都將安裝 PowerShell v3+。PowerShell v2 是預設安裝在 Windows 7 上的。因此，它被攻擊者視為最小公共程式。

wmic.exe

wmic.exe 是一個與 WMI 進行互動的強大的命令列實用工具。它擁有大量的 WMI 物件的方便記憶的預設別名，但你還可以執行更為複雜的查詢。wmic.exe 還可以執行 WMI 方法，攻擊者經常用來透過呼叫 Win32_Process 的 Create 方法來進行橫向運動。Wmic.exe 的侷限性之一是不能接受呼叫嵌入的 WMI 物件的方法。在 PowerShell 不可用的情況下,使用 wmic.exe 足夠用於執行系統偵察和基本方法的呼叫。

wbemtest.exe

wbemtest.exe 是一個功能強大的帶有圖形介面的 WMI 診斷工具。它能夠列舉物件例項、執行查詢、註冊事件、修改 WMI 物件和類，並且可以在本地或遠端去呼叫方法。它的介面對大多數使用者來說不是特別友好，但從攻擊者的角度來看，在其他工具不可用時，它完全可以作為替代選項 —— 例如，如果應用程式白名單機制阻止了 wmic.exe 和 powershell.exe，那麼 wbemtest.exe 將是一個帶有一個不太理想的 UI （如圖 3 所示）但是功能卻很強大的實用工具。

圖 3 wbemtest的圖形介面

WMI Explorer

WMI Explorer 是一個很好的 WMI 類發現工具。它提供了一個優雅的 GUI （圖 4 所示），你可以使用分層次的方式探索 WMI 儲存庫。它也能夠連線到遠端的 WMI 儲存庫，並執行查詢。對安全研究人員尋找可用於攻擊或防禦的 WMI 類來說，像這樣的 WMI 類發現工具是非常有價值的。

圖 4 WMI Explorer

CIM Studio　

CIM Studio 是 Microsoft 遺留的一個免費工具，你可以方便地瀏覽 WMI 儲存庫。像 WMI Explorer 一樣，此工具也可以很好的進行 WMI 類發現。

Windows 指令碼宿主（WSH）語言

Microsoft 提供了兩個 WSH 指令碼語言，VBScript 和 JScript。儘管它們比較過時，也算不上高雅的程式語言，但是說到與 WMI 進行互動時，它們的確都是功能強大的指令碼語言。事實上，使用 VBScript 和 JScript 編寫的利用 WMI 作為主要的 C&C 機制的後門已經出現了。此外，如後面將要解釋的，它們是唯一支援 ActiveScriptEventConsumer 事件消費者元件的語言，該元件對於攻擊者和防禦者來說都是一個非常有價值的 WMI 元件。最後，從攻擊的角度來看， VBScript 和 JScript 是在未安裝 PowerShell 的老版本的 Windows 系統上的最小公共程式。

C/C++ 呼叫 IWbem* COM API

如果你需要使用非託管語言如 C 或 C++ 與 WMI 進行互動，你將需要使用 WMI 的 COM API。逆向工程師將需要非常熟悉此介面以及每一個 COM Guid 才能充分理解與 WMI 互動的惡意軟體。

.NET System.Management 類

.NET 類庫在 System.Management 名稱空間中提供了幾個與 WMI 相關的類，可以相對簡單的使用如 C#、VB.Net 和 F# 語言編寫與 WMI 互動的程式。在後續的示例中，這些類將用於在 PowerShell 程式碼中補充現有的 WMI/CIM cmdlet。

winrm.exe

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_Process
• winrm get http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_OperatingSystem

Linux版本的 wmic 和 wmis-pth

wmic 是一個簡單的 Linux 命令列實用工具，用於執行 WMI 查詢。wmis 是 Win32_Process 類的 Create 方法的遠端呼叫命令列包裝程式，並且支援使用 NTLM 雜湊進行連線遠端計算機，因此， wmis 已經被滲透測試人員大量使用。

0x06 遠端使用 WMI

---

雖然可以與本地的 WMI 進行互動，但是透過網路才能顯示出 WMI 的真實能量。目前，由於 DCOM 和 WinRM 這兩個協議的存在，將使得遠端物件的查詢，事件註冊， WMI 類方法的執行，以及類的建立都能夠被支援。

這些協議看起來非常有利於攻擊者，因為大多陣列織機構和安全供應商一般不審查這些惡意活動所傳輸的內容。攻擊者需要有效的利用遠端 WMI 則需要有特權使用者的憑據。在 Linux 平臺中的 wmis-pth 實用工具，則需要的是受害者的使用者的雜湊。

分散式元件物件模型 (DCOM)

從 DCOM 出現以來它一直是 WMI 所使用的預設協議，透過 TCP 的 135 埠建立初始連線。後續的資料交換則使用隨機選定的 TCP 埠。可以透過 dcomcnfg.exe 並最終修改下面的登錄檔項來配置此埠的範圍：

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet –Ports (REG_MULTI_SZ)

在 PowerShell 中內建的所有 WMI cmdlets 都是使用 DCOM 進行通訊的。

Windows 遠端管理 (WinRM)　

最近， 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 。

0x07 WMI 事件

---

從攻擊者或防禦者的角度來看， WMI 最強大的功能之一就是對 WMI 事件的非同步響應的能力。除了少數例外，WMI 事件幾乎可以用於對作業系統的任何事件作出響應。例如，WMI 事件可能用於觸發一個程式建立的事件。這種機制可隨後被用作在任何 Windows 作業系統上執行命令列審計。

有兩類 WMI 事件 —— 它們都執行在本地的單個程式和 WMI 永久事件訂閱的上下文中。本地事件可以維持宿主程式的生存期，儘管 WMI 永久事件訂閱儲存在 WMI 儲存庫中，但是作為 SYSTEM 許可權執行後依舊可以在重新啟動之後繼續持續執行。

事件觸發條件

要安裝一個永久事件訂閱，下面三件事情是必須要做的：

1.事件篩選器 —— 篩選出感興趣的事件
2.事件消費者 —— 要在事件被觸發時執行的操作
3.消費者繫結篩選器 — — 將篩選器繫結到消費者的序號產生器制

事件篩選器

事件篩選器描述了感興趣的事件並且執行了 WQL 事件查詢。一旦系統管理員配置了篩選器，他們就可以使用它在建立新的事件時接收到通知。舉一個例子，事件篩選器可能用於描述以下一些事件:

• 建立一個具有特定名稱的程式
• 將 DLL 載入到程式中
• 建立具有特定 ID 的事件日誌
• 插入可移動媒體
• 使用者登出
• 建立、修改、刪除任何檔案或目錄

事件篩選器都被儲存為一個 ROOT\subscription:__EventFilter 物件的例項。事件篩選器查詢支援以下型別的事件:

內部事件

內部事件表示的是建立、修改和刪除任何 WMI 類，物件或名稱空間的事件。它們也可被用於計時器或 WMI 方法執行的警報。以下內部事件採用了系統類 (以兩個下劃線開頭的那些) 的形式，並存在於每一個 WMI 名稱空間:

• __NamespaceOperationEvent
• __NamespaceModificationEvent
• __NamespaceDeletionEvent
• __NamespaceCreationEvent
• __ClassOperationEvent
• __ClassDeletionEvent
• __ClassModificationEvent
• __ClassCreationEvent
• __InstanceOperationEvent
• __InstanceCreationEvent
• __MethodInvocationEvent
• __InstanceModificationEvent
• __InstanceDeletionEvent
• __TimerEvent

這些事件的作用非常強大，因為它們可以被用於在作業系統中幾乎任何可以想見的事件的觸發器。例如，如果觸發了一個基於互動式登入的事件則可以形成下面的內部事件查詢:

此查詢被轉換為建立一個登入型別為 2 （互動式）的 Win32_LogonSession 類的一個例項。

由於觸發的內部事件有一定的頻率，所以必須在 WQL 查詢語句的 WITHIN 子句中指定事件輪詢間隔。這就是說，它有時可能錯過事件。例如，如果事件查詢的形式目的是建立 WMI 類的例項，如果該例項的建立和銷燬 (如常見的一些程式 —— Win32_Process 例項) 在輪詢間隔內，那麼則會錯過這一事件。建立內部 WMI 查詢時，必須考慮這種可能出現的情況。

SELECT * FROM __InstanceCreationEvent WITHIN 15 WHERE TargetInstance ISA 'Win32_LogonSession' AND TargetInstance.LogonType = 2

外部事件

外部事件解決了和內部事件有關的潛在的輪詢問題，因為它們在事件發生時立刻被觸發。然而美中不足的是在 WMI 中並沒有太多的外部事件，不過，所有已經存在的外部事件的作用很強大，效能也很高。下面的外部事件對於攻擊者和防禦者來說可能是有用的：

• ROOT\CIMV2:Win32_ComputerShutdownEvent
• ROOT\CIMV2:Win32_IP4RouteTableEvent
• ROOT\CIMV2:Win32_ProcessStartTrace
• ROOT\CIMV2:Win32_ModuleLoadTrace
• ROOT\CIMV2:Win32_ThreadStartTrace
• ROOT\CIMV2:Win32_VolumeChangeEvent
• ROOT\CIMV2: Msft_WmiProvider*
• ROOT\DEFAULT:RegistryKeyChangeEvent
• ROOT\DEFAULT:RegistryValueChangeEvent

以下外部事件查詢形式可以用來捕獲每一個程式已載入的所有可執行模組（使用者模式和核心模式）：
SELECT * FROM Win32_ModuleLoadTrace

事件消費者

事件消費是一個派生自 __EventConsumer 系統類的類，它表示了在事件觸發時的動作。系統提供了以下有用的標準事件消費類：

• LogFileEventConsumer - 將事件資料寫入到指定的日誌檔案
• ActiveScriptEventConsumer - 執行嵌入的 VBScript 或 JScript 指令碼 payload
• NTEventLogEventConsumer - 建立一個包含事件資料的事件日誌條目
• SMTPEventConsumer - 傳送一封包含事件資料的電子郵件
• CommandLineEventConsumer - 執行一個命令列程式

攻擊者在響應他們的事件時，大量使用 ActiveScriptEventConsumer 和 CommandLineEventConsumer 類。這兩個事件消費者為攻擊者提供了極大的靈活性去執行他們想要執行的任何 payload 並且無需寫入一個惡意的可執行檔案或指令碼到磁碟。

惡意的 WMI 持久化示例

圖 5 中的 PowerShell 程式碼是修改過的存在於 SEADADDY 惡意軟體家族中的 WMI 永續性程式碼例項。該事件篩選器取自 PowerSploit 的永續性模組，目的是在系統啟動後不久觸發，事件消費者只需執行一個具有系統許可權的可執行檔案。圖 5 中的事件篩選器在系統啟動後的 200 和 320 秒之間被當作一個觸發器。在事件被觸發時事件消費者會執行已指定好的可執行檔案。透過指定篩選器和一個 __FilterToConsumerBinding 例項將篩選器和消費者註冊並將二者繫結在一起。

圖 5 ：SEADADDY 惡意軟體的 WMI 永續性 PowerShell 程式碼

0x08 WMI 攻擊技術

---

在攻擊者的各個階段的攻擊生命週期中，WMI 都是極其強大的工具。系統提供了豐富的 WMI 物件、方法和事件，它們的功能極其強大，可以執行很多東西，從系統偵察、反病毒、虛擬機器檢測、程式碼執行、橫向運動、隱蔽儲存資料到永續性。它甚至可以打造一個純粹的 WMI 後門且無需寫入檔案到磁碟。
攻擊者使用 WMI 有很多優勢：

• 它被預設安裝在所有的 Windows 作業系統中，並且可以追溯到 Windows 98 和 NT4.0。
• 對於執行程式碼，它可以隱蔽的執行 PSEXEC。
• WMI 永久事件訂閱是作為系統許可權執行的。
• 防禦者通常沒有意識到 WMI 可以作為一個多用途的攻擊向量。
• 幾乎每一個系統操作都能夠觸發一個 WMI 事件。
• 除了在 WMI 儲存庫中儲存之外不會對磁碟進行任何操作。

以下列表顯示了幾個如何使用 WMI 在攻擊的各個階段執行操作的例子。

系統偵察

許多惡意軟體操縱者和滲透測試人員所做的第一件事情就是系統偵察， WMI 包含有大量的類可以幫助攻擊者去感知他們的目標的環境。
下面的 WMI 類是在攻擊的偵察階段可以收集資料的子集:

• 主機/作業系統資訊:Win32_OperatingSystem, Win32_ComputerSystem
• 檔案/目錄列舉: CIM_DataFile
• 磁碟卷列舉: Win32_Volume
• 登錄檔操作: StdRegProv
• 執行程式: Win32_Process
• 服務列舉: Win32_Service
• 事件日誌: Win32_NtLogEvent
• 登入賬戶: Win32_LoggedOnUser
• 共享: Win32_Share
• 已安裝補丁: Win32_QuickFixEngineering

反病毒/虛擬機器檢測

防毒引擎檢測

已安裝的 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 虛擬機器檢測

下面的查詢示例試圖查詢 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 方法

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 作為 C2 通道

使用 WMI 作為一種來儲存和檢索資料的機制，同樣也可以使得 WMI 能作為一個純粹的 C2 通道。這種使用 WMI 的聰明想法是由 Andrei Dumitrescu 在他 WMI Shell 工具中被首次公開——利用建立和修改 WMI 的名稱空間作為 C2 的通道。

實際上還有很多 C2 暫存機制可以採用， 如剛才討論過的 WMI 類的建立。同樣也有可能使用登錄檔進行資料轉儲作為 WMI C2 的通道。下面的示例演示了一些利用 WMI 作為 C2 通道的 POC 程式碼。

“Push” 攻擊

圖 9 演示瞭如何遠端建立 WMI 類來儲存檔案資料。之後可以遠端使用 powershell.exe 將該檔案資料寫入到遠端檔案系統。

圖 9 ： 遠端建立 WMI 類並寫入到遠端檔案系統的 PowerShell 程式碼

“Pull” 攻擊

圖 10 演示瞭如何使用登錄檔來收取 PowerShell 命令的結果。此外，許多惡意工具試圖捕捉只是將輸出轉換為文字的 PowerShell 命令的輸出。本示例利用了 PowerShell 物件序列化和反序列化方法來保持目前在 PowerShell 物件中豐富的型別資訊。

圖 10 : 從 WMI 類屬性拉回命令資料的 PowerShell 程式碼

0x09 WMI 提供程式

---

提供程式是 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 提供程式就可以被攻擊者用於擴充套件 WMI 的功能。

Casey Smith 和 Jared Atkinson 兩人釋出了惡意的 WMI 提供程式的 POC ，這些惡意的提供程式能夠遠端執行 Shellcode 和 PowerShell 指令碼。惡意的 WMI 提供程式作為一種有效的永續性機制，它允許攻擊者遠端執行程式碼，只要攻擊者擁有有效的使用者憑據。