CosmicStrand：發現復雜的 UEFI 固件 rootkit
Rootkit 是植入操作系統最深處的惡意軟件。盡管在紙面上它們似乎對攻擊者很有吸引力，但創建它們會帶來重大的技術挑戰，并且最輕微的編程錯誤都有可能使受害計算機完全崩潰。在對 2022 年的 APT 預測中，我們注意到盡管存在這些風險，但預計會有更多的攻擊者達到開發此類工具所需的復雜程度。嵌入在如此低級別的操作系統中的惡意軟件的主要吸引力之一是，它極難被檢測到，而且在固件rootkit的情況下，即使重新安裝操作系統或用戶完全更換了計算機的硬盤驅動器，也會確保計算機保持在感染狀態。
在本文中，我們會介紹一個名為 CosmicStrand 的 UEFI 固件 rootkit。
受影響的設備
雖然我們無法發現受害計算機最初是如何被感染的，但對其硬件的分析揭示了 CosmicStrand 可以感染的設備。rootkit 位于技嘉或華碩主板的固件映像中，我們注意到所有這些映像都與使用 H81 芯片組的設計有關。這表明可能存在允許攻擊者將其 rootkit 注入固件映像的常見漏洞。
在這些固件映像中，對 CSMCORE DXE 驅動程序進行了修改，其入口點已被修補以重定向到 .reloc 部分中添加的代碼。此代碼在系統啟動期間執行，會觸發一個長執行鏈，從而導致在 Windows 中下載和部署惡意組件。
查看我們能夠獲得的各種固件映像，我們評估這些修改可能是使用自動修補程序執行的。如果是這樣，則攻擊者可以事先訪問受害者的計算機，以提取、修改和覆蓋主板的固件。這可以通過已經部署在計算機或物理訪問上的預先植入的惡意軟件來實現。
感染過程概述
在深入了解組成這個 rootkit 的各種組件之前，我們想提供一個關于它試圖完成的任務的高級視圖。此執行鏈的目標是在每次啟動時從受感染的 UEFI 組件開始將內核級植入部署到 Windows 系統中。
UEFI 惡意軟件開發者面臨一個獨特的技術挑戰：他們的植入程序在啟動過程中很早就開始運行，以至于操作系統（在本例中為 Windows）甚至還沒有加載到內存中。到那時，UEFI執行上下文已經終止了。rootkit完成的主要任務是找到一種方法，將惡意代碼一路傳遞到各個啟動階段。
工作流程包括連續設置掛鉤，允許惡意代碼持續存在，直到操作系統啟動之后。所涉及的步驟是：
初始受感染的固件引導整個鏈。
該惡意軟件在啟動管理器中設置了一個惡意掛鉤，允許它在執行之前修改 Windows 的內核加載程序。
通過篡改操作系統加載程序，攻擊者能夠在 Windows 內核的功能中設置另一個掛鉤。
當稍后在操作系統的正常啟動過程中調用該函數時，惡意軟件最后一次控制了執行流程。
它在內存中部署一個 shellcode 并聯系 C2 服務器以檢索實際的惡意有效負載以在受害者的計算機上運行。
下圖中總結了這些步驟：
UEFI 植入
在確定了惡意軟件植入的目的之后，我們現在可以更詳細地了解這些步驟是如何執行的。
整個執行鏈從 EFI 驅動程序開始，它似乎是一個名為 CSMCORE 的合法版本的補丁版本（旨在促進通過 MBR 在傳統模式下啟動計算機），其中攻擊者修改了指向 HandleProtocol 啟動服務函數的指針。每次調用此函數時，都會將執行重定向到攻擊者提供的代碼，該代碼試圖確定調用它的組件（它正在尋找要感染的特定組件——efi）。通過檢查函數參數以及位于返回地址的字節，CosmicStrand 可以識別它正在尋找的確切“調用”。
之所以選擇執行中的這個特定點，是因為在這個階段，引導管理器已經加載到內存中，但還沒有運行。CosmicStrand抓住了這個機會來修補它的Archpx64TransferTo64BitApplicationAsm中的一些字節。
該函數稍后在正常的操作系統啟動過程中被調用也是在一個關鍵時刻：那時 Windows 操作系統加載程序也存在于內存中，并且可以反過來進行修改。
當它運行時，Archpx64TransferTo64BitApplicationAsm 通過查找特定的字節模式從 OS 加載器 (OslArchTransferToKernel) 中定位一個函數。然后CosmicStrand 在它的末端添加一個掛鉤。
OslArchTransferToKernel 在執行從 Windows 加載程序轉移到 Windows 內核之前被調用，這使其成為此類 rootkit 的傳統掛鉤點。
在 Windows 內核有機會運行之前，CosmicStrand 在 ZwCreateSection 中設置了另一個掛鉤。 惡意代碼被復制到內存中的ntoskrnl.exe的映像中，并且ZwCreateSection的第一個字節被重寫以重定向到它。我們注意到，攻擊者小心翼翼地將惡意代碼放在ntoskrnl.exe的.text部分的空閑空間中，這使得這種重定向在可能的安全產品眼中不那么顯眼。
此時，CosmicStrand 似乎還試圖禁用 PatchGuard，這是一種用于防止修改內存中 Windows 內核的關鍵結構的安全機制。為此，它會定位 ntoskrnl.exe 的 KiFilterFiberContext 函數并對其進行修改，使其無需執行任何工作即可返回。值得注意的是，該函數的本地化也是通過搜索硬編碼模式來實現的，非常詳盡，甚至包含與 2016 年 8 月發布的 Redstone 1 對應的模式。
然后，Windows內核啟動，并在正常運行時調用掛鉤的ZwCreateSection函數。當這種情況發生時，CosmicStrand會再次獲得執行的控制權，并在運行更多惡意代碼之前恢復原始代碼。
ZwCreateSection 掛鉤的主要目的是收集內核提供的 API 函數的地址，并為下一個組件創建一個導入表。通過使用解析函數，它還在內核地址空間中分配了一個緩沖區，在調用shell代碼之前，它在這個地址空間映射shell代碼。
內核shellcode
到目前為止描述的所有步驟僅用于將代碼執行從 UEFI 傳播到 Windows 內核。這個 shellcode 是迄今為止鏈中第一個真正的惡意組件。它設置了一個線程通知例程，每次創建新線程時都會調用該例程。CosmicStrand 一直等到 winlogon.exe 出現，然后在這個高權限上下文中執行回調。
這樣，CosmicStrand 會休眠 10 分鐘并測試受感染計算機的互聯網連接。CosmicStrand 不依賴高級 API 函數來生成網絡流量，而是直接與傳輸設備接口交互：它生成所需的 IRP（I/O 請求數據包）并通過將 IOCTL 發送到TCP 或 UDP 設備對象。DNS請求可以通過谷歌的DNS服務器(8.8.8[.]8)或自定義的DNS服務器(222.222.67[.]208)來實現。
CosmicStrand 通過向其 C2 服務器 update.bokts[.]com 發送自定義的 UDP或 TCP 數據包來檢索其最終有效負載。回復預計將返回一個或多個包含 528 字節塊的數據包，遵循以下結構：
各種數據塊被重新組裝成一家族字節，這些字節映射到內核空間并解釋為 shellcode。不幸的是，我們無法獲得來自 C2 服務器的數據副本。然而，我們確實在我們可以研究的一臺受感染計算機上找到了內存中的用戶模式樣本，并相信它與 CosmicStrand 相關聯。該示例是一個可執行文件，它運行命令行以便在受害者的計算機上創建一個用戶（“aaaabbbb”）并將其添加到本地管理員組。
我們可以由此推斷，從 C2 服務器接收到的 shellcode 可能是攻擊者提供的 PE 可執行文件的暫存器，而且很可能存在更多。
較舊的 CosmicStrand 變體
在調查過程中，我們還發現了這個 rootkit 的舊版本。它們具有相同的部署過程，它們的細微差別與內核 shellcode 有關。
它試圖從 exe 而不是 winlogon.exe 劫持線程。
為獲得額外的 shellcode 以運行而聯系的 C2 域是不同的 (erda158[.]to)。
每次在系統中創建新進程時，舊變體都會打印調試消息。
根據我們對這兩種變體使用的基礎設施的分析，我們估計舊的一種在 2016 年底至 2017 年中期之間使用，而當前的一種在 2020 年曾非常活躍。
基礎設施
我們知道有兩個C2服務器，每個變體對應一個。根據對他們可用的被動DNS數據，這些域有一個很長的生命周期，并在有限的時間內解析到IP地址，否則，rootkit 將無法運行。因此值得注意的是，雖然攻擊者選擇部署極其持久的植入程序，但對受害計算機的實際利用可能只有幾個月。但是，這些域可能偶爾會在很短的時間內被重新激活，并且此信息不會被被動 DNS 系統記錄。
細心的讀者會注意到這兩個域的活動期之間存在三年的差距。在此期間，攻擊者可能正在使用通過 CosmicStrand 部署的用戶模式組件控制受害者的計算機，或者更有可能我們還沒有發現的其他變體和C2服務器。
受害者
目前，研究人員在中國、越南、伊朗和俄羅斯發現CosmicStrand 的受害者。
總結
綜合分析， CosmicStrand 是由說中文的開發者開發的，或者是利用了講中文的攻擊者的資源。具體來說，CosmicStrand中的一些代碼模式也在另一個惡意軟件家族MyKings僵尸網絡中被觀察到(例如，MD5 E31C43DD8CB17E9D68C65E645FB3F6E8)。Sophos在2020年記錄了這個用于部署加密器的僵尸網絡。
與 CosmicStrand 的相似之處包括：
使用 MBR rootkit 在 MyKings 中建立隱秘持久性。
CosmicStrand 和 MyKings 在內核模式（Proc 和 GetM）中分配內存時使用相同的標簽。
兩個家族都以相同的方式生成網絡數據包，并直接利用 UDP 和 TCP 設備對象。
兩者使用的 API 哈希碼是相同的，如下面的截圖所示。據我們所知，這種算法只在另外兩個 rootkit 中被發現，即 MoonBounce 和 xTalker。
除了這種代碼相似性之外，CosmicStrand 使用的硬編碼后備 DNS 服務器位于 CHINANET-BACKBONE (AS4134) 這一事實可能被視為攻擊者屬于中文網絡的一個非常低的置信度的跡象。
CosmicStrand 是一個復雜的 UEFI 固件 rootkit，它允許其所有者實現持久性攻擊。
