狩獵二進制重命名

ATT&CK 技術項編號爲 T1036 的二進制重命名技術，正在被越來越多的惡意軟件所採用，本文介紹如何使用多種方法對該技術進行監控與檢測。

背景

二進制重命名是一種逃避檢測的技術，用於繞過基於進程名與路徑的檢測方案。二進制重命名是 MITRE ATT&CK 框架中 T1036 Masquerading 技術的子類。在攻擊生命週期的各個階段都可以觀察到這項技術的應用，無論是商業惡意軟件開發者還是 APT 都有廣泛的使用。二進制重命名最有名的應用就是 NotPetya，NotPetya 重命名了 psexec 程序實現自動化、破壞性的橫向感染。

通過檢查已執行進程的二進制程序屬性、對比預期外進程的名稱與路徑的方式可以發現這種威脅。這是在對抗基於 JavaScript 的垃圾軟件時總結的方法，它們利用滲透工具、橫向平移與 APT 級的檢測逃避。

對於在攻擊生命週期早期發生的攻擊，通常涉及到尋找立足點，想要將受監控的二進制程序拷貝到不顯眼的路徑中。對於交互式攻擊或攻擊生命週期後期，攻擊者往往需要利用自己的黑客工具或者管理工具，而非本地環境中的程序，這些工具僅僅是看似“合法的”。要了解所使用的二進制程序的類型，例如 PE 文件的屬性可以和很多檢測的錨點相關，便於後續搜索。

考慮到並不是所有團隊都有功能強大的 EDR 能力，可以實現大規模的二進制程序屬性的可見性。據此，我想創造一個開源的解決方案解決這個問題。

解決方案

在沒有完善的日誌記錄 / EDR 的情況下，WMI 事件可以爲我們提供可見性。WMI 事件訂閱是通過觸發器和（EventFilter）和處理器（EventConsumer）處理某些系統事件的方法。WMI 事件幾乎可以對所有操作系統事件進行操作，例如：登錄事件、進程活動、註冊表或者文件更改情況。

WMI 提供的能力可以認爲是 EDR 用戶空間事件跟蹤的有限子集，但又無需安裝服務或者程序。WMI 事件並不是新鮮事物，早在 2016 年 Fireeye 就討論了 WMI 作爲端點入侵檢測系統的可行性。此前我已經構建了基於 WMI 事件的解決方案用於應急響應事件當中，彌補可見性的差距。WMI 與 WMI 事件的完整描述超出了本文所討論的範圍，若要詳細瞭解更多的知識可以查看擴展閱讀。

ActiveScript 事件處理器可以通過功能強大的 Windows Scripting Host 爲 WMI 事件觸發器添加、豐富事件處理邏輯。在此示例中，利用實時“外部” WMI 事件觸發器進行進程執行監控，從所有執行的進程中收集進程 ID。Win32_Process 的查詢可以進一步提供有關進程的元數據，收集 PE 屬性便於檢測。此示例中使用的 PE 屬性是原始名稱，查詢高優先級原始名稱列表並檢測報警。

在條件匹配時，示例程序支持寫入應用程序事件日誌。事件 ID 爲 4，包含相關告警的詳細信息。出於性能考慮，進程路徑和原始名稱都實時記錄在告警中，並沒有進行哈希計算。

類似的也可以輸出到日誌中。值得注意的是，可以方便地修改示例程序中關於寫入日誌文件、事件記錄函數與函數調用的部分。

侷限

使用 WMI 事件作爲事件來源的一個侷限是通常不能得到成熟的檢測用例需要的所有數據。爲了豐富數據，需要查詢 Win32_Process 類。獲取進程元數據會存在一些延遲，因此非常短暫的進程（幾分之一秒）可能會存在獲取不到的情況。在我自己的測試中，非常短暫的命令（如重命名命令 cdm /c echo <string> ）無法生成 WMI 數據，在本地 ping 事件記錄中稍有延遲。對於下載、訪問 Shell、或者其他常見的交互式命令沒有見到問題，但請記住這個侷限。

第二個侷限是性能，雖然我自己構建的測試中沒有資源密集的用例，但生產中可能存在其他限制。我過濾了進程事件，但希望你在部署的時候進行鍼對性的測試。考慮到性能，程序屬性匹配用例儘可能地保持簡單，這意味着準確度的降低。但是由於邏輯儘可能的簡單，修改、添加功能是很容易的。

另外，在某些環境中，某些目標的原始名稱可能存在合法的二進制重命名行爲。列出的程序列表可能需要對匹配邏輯進行一些調整來兼容不同的主機環境。

最後，WMI 事件處理器是衆所周知地難以管理。我提供了一個帶有卸載說明的 Powershell 安裝腳本，支持 Powershell 2.0 及以上。

關於項目

這是一個有趣的開源項目，當我發現 vbscript 具有查詢 PE 屬性的功能時，希望其他人也可以更好地利用這個功能。如果有任何反饋意見，請隨時與我聯繫。

示例程序的模板可以在這裏找到 WMIEvent-BinaryRename.ps1 。

Yara 檢測

Yara 是一個主要用於惡意軟件檢測的模式匹配工具。基於字符串或者二進制模式的規則，利用布爾、計數或者正則表達式之類的匹配邏輯。雖然傳統上仍然是基於模式的匹配，但是 Yara 是模塊化、可擴展的。例如 PE 模塊可用於查詢常見的二進制程序屬性，PE 模塊可以支持創建針對 PE 文件格式和文件頭的規則，提供了爲 PE 文件編寫更有效規則的函數。如正在使用的 pe.versioninfo 的 InternalName 屬性：

我們的 Yara 規則很有趣，因爲我們需要將預期的文件名與實際的文件名進行比較，但比較文件名並不是 Yara 設計的本意。Florian Roth 在 2014 年寫了一篇關於“inverse”技術的文章，文中闡述瞭如何利用 Powershell 腳本獲得所有需要掃描的文件，並將每個文件名作爲外部變量傳遞給 Yara 進行掃描。爲每個文件都創建一個新的 Yara 實例，傳入相關的文件名以進行比較。在下面的代碼中，擴展了該用例代碼支持 32 位與 64 位機器。

爲了保證正確執行，執行路徑下必須存在下列文件：

inverseYara.ps1

x86 或 x64 的 Yara 程序

rename.yar

通過 bat 腳本或命令執行如下：

從檢測的角度看，這種技術非常有效，但在我的測試中，由於爲每個文件都要生成新的 Yara 進程，性能開銷導致效率並不理想。值得注意的是，Yara 掃描可以針對沒有文件名匹配時聚焦於域內文件的意外位置，但這並不符合二進制重命名的需要。

Powershell 檢測

這種情況下，首選的方式變成了 Powershell。Windows API 通過 FileVersionInfo 類提供了對 PE 屬性的訪問，並且支持 Powershell 2.0 /.NET 2。輸出那些可以輔助分析的額外選項可以顯著提升速度並優化邏輯。在下面的腳本輸出中，可以看到輸出中已經添加了 SHA1 哈希。