.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
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函數來查詢這個事件。
