乾貨 | malware新姿勢：使用Windows管理規範逃避安全檢測

02-01

01 前言

最近，看到很多安全公司包括FireEye、TrendMicro報道了一系列的惡意軟體使用Windows管理規範(WMI)對系統環境進行掃描、躲避殺毒引擎，虛擬機/沙盒等安全工具的檢測。這讓我想起了在Black Hat 2015上針對WMI攻擊的演講AbusingWindows Management Instrumentation (WMI) to Build a Persistent, Asyncronous,and Fileless Backdoor，還有FireEye在今年8月份也對WMI的惡意活動進行了分析。當然如果想了解有關WMI更多的攻擊還可以參考TrendMicro在2010年的一篇PDF文章。

02 Windows管理規範(WMI)

本人雖然平時不怎麼上國內的烏雲，但是烏雲知識庫裡面還是很多乾貨的，所以首先要感謝烏雲知識庫的鏡像終於回歸了。烏雲知識庫中，有一篇是專門介紹WMI的——《WMI 的攻擊、防禦與取證分析技術之攻擊篇》，該文章詳細的介紹了WMI，以及惡意軟體如何使用WMI進行攻擊。

WMI的攻擊當然離不開Windwos腳本（即WSH，Windows腳本宿主）的支持，攻擊者通過使用腳本把獨立的程序、服務、控制項組合起來完成任務，腳本編程的技巧就是組合的技巧，而利用WMI服務的管理介面，腳本可以很方便的使用WMI的一系列功能，這也是造成攻擊的原因之一。

本文將通過2016年實際的在野樣本來分析WMI是如何躲避殺毒引擎、虛擬化技術、進程以及Widows服務的檢測的。

03 殺毒引擎檢測

已安裝的 AV 產品通常會將自己註冊在WMI AntiVirusProduct class 類中的rootSecurityCenter 或者是 rootSecurityCenter2 命名空間中，具體是哪一個命名空間則取決於操作系統的版本，因此可以通過WMI查詢語言進行檢索。我們分析的這個樣本首先檢查操作系統rootcimv2命名空間下的Win32_OperatingSystem類，如果操作系統的版本大於數字6（即Widows Vista以上的版本），緊接著進行AV的檢測。下圖顯示了VBScript代碼對AV的檢測。

AV以及其它的用戶信息將被發送到伺服器用於讀取正確的有效載荷或執行逃避，如下圖所示。

04 虛擬化檢測

在其中一個樣本中發現，使用了很多不同的技術監控系統安全產品，最流行的就是使用WMI查詢語句檢查虛擬化軟體（例如VMvare和VirtualBox）。通過檢索rootcimv2命名空間下的Win32_BIOS類的BIOS信息，具體的fields/columns類似於SQL的查詢語句。下圖是從惡意軟體中提取出來的虛擬化WMI SOL查詢語句。

我們可以驗證一下上述語句，在Bochs模擬器中的powershell里執行上述查詢語句，結果如下入所示。

在這個樣本中還可以看到它對整個的系統安全產品的檢測，其他服務可以通過枚舉運行的進程和Windows註冊表來檢測，如下圖所示。

在這裡使用Ollydbg來動態分析其中的一個樣本發現，惡意軟體使用Win32_DiskDrive分別檢測Virtual Box , Virtual Hard disk和 VMware ，當以上任何一個檢測到的時候，該進程將結束，這樣可以避免自身被安全人員分析。檢測過程如下圖所示。

05 進程檢測

我們分析的另一個樣本不僅檢查rootcimv2命名空間下Win32_Prcess的特定進程，而且還會終止這些進程。例如一旦檢查到Immunity debugger進程就會強制其終止，接著會通過Windows宿主腳本更改該文件夾下的許可權並刪除文件，具體代碼如下圖。

此外，國內的安全廠商，金山毒霸的殺毒引擎也會被強制終止，代碼如下圖所示。

06 Windows服務檢測

再一個類似MS Office的密鑰生成器的樣本中，發現其通過WMI查詢語句檢測Office軟體的保護服務，如下圖所示。這個保護服務為軟體供應商提供了安全許可服務。一旦Office軟體保護服務對象啟動時，用於安裝MS Office產品密鑰。

07 總結

在對這一系列的樣本進行分析的時候發現，絕大部分都是通過WMI的查詢來實現環境的檢測和躲避的，如下圖所示。

當然還有很多查詢的語句沒有完全列舉出來，我們可以想像的到，會有更多的惡意軟體作者會使用類似的攻擊方式進行攻擊，因此作為安全分析人員應該要注意新的WMI攻擊。目前，在BlueHat 2016 上，已經有人針對WMI的攻擊進行了檢測，源碼見GitHub，可以參考一下如何進行檢測。

註：本文屬原創獎勵計劃文章，未經許可禁止轉載