.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
與HTTP下載器的通信內核驅動程序能夠通過使用命名的Event和Section與HTTP下載器通信。所使用的命名對象的名稱是根據受害者的網絡適配器MAC地址（以太網）生成的。如果一個八位字節的值小於16，那麼將向其添加16。生成的對象名稱的格式可能在不同的示例中有所不同。例如，在我們分析的一個示例中，對於MAC地址00-1c-0b-cd-ef-34，生成的名稱為：
\BaseNamedObjects\101c1b：用於命名部分（僅使用MAC的前三個八位字節）；
\BaseNamedObjects\Z01c1b：用於命名事件，與Section相同，但MAC地址的第一個數字被替換為Z；
如果HTTP下載器想要將一些命令傳遞給內核驅動程序，它只需要創建一個命名的節，在其中寫入一個包含相關數據的命令，並通過創建一個指定事件等待驅動程序處理該命令，直到驅動程序觸發（或發出信號）該命令。
驅動程序支持以下一目了然的命令：
安裝內核驅動程序；
卸載BlackLotus；
細心的讀者可能會注意到這裡的BlackLotus弱點，即使bootkit保護其組件不被刪除，內核驅動程序也可以通過創建上述命名對象並向其發送卸載命令來完全卸載bootkit。
HTTP下載器最後一個組件負責與CC服務器通信，並執行從其接收的任何CC命令。我們能夠發現的所有有效載荷都包含三個命令。這些命令非常簡單，正如部分名稱所示，主要是使用各種技術下載和執行額外的有效載荷。
CC通信為了與其CC通信，HTTP加載器使用HTTPS協議。通信所需的所有信息都直接嵌入到下載器二進製文件中，包括使用的CC域和HTTP資源路徑。與CC服務器通信的默認間隔設置為一分鐘，但可以根據CC的數據進行更改。與CC的每個通信會話都從向其發送信標HTTP POST消息開始。在我們分析的示例中，可以在HTTP POST標頭中指定以下HTTP資源路徑：
/network/API/hpb_gate[.]php
/API/hpb_gate[.]php
/gate[.]php
/hpb_gate[.]php
信標消息數據以checkin=字符串開頭，包含有關受攻擊機器的基本信息，包括自定義設備標識符（稱為HWID）、UEFI Secure Boot狀態、各種硬件信息以及一個看起來是BlackLotus內部版本號的值。 HWID由設備MAC地址（以太網）和系統卷序列號生成。加密前的消息格式如下圖所示。
在向CC發送消息之前，首先使用嵌入的RSA密鑰對數據進行加密，然後使用URL安全的base64編碼。在分析過程中，我們發現樣本中使用了兩個不同的RSA密鑰。這種HTTP信標請求的示例如下圖所示。
信標HTTP POST消息示例（由VirusTotal中的示例生成——具有本地IP而非真實CC地址的示例）
作為對信標消息的響應，從CC接收的數據應以兩字節魔法值HP開頭；否則，不進一步處理響應。如果魔法值正確，則在CBC模式下使用256位AES對魔法值之後的數據進行解密，並使用上述HWID字符串作為密鑰。
解密後，該消息類似於信標，一個JSON格式的字符串，並指定命令標識符（稱為Type）和各種附加參數，例如：
CC通信間隔；
執行方法；
有效負載文件名；
基於文件擴展名的負載類型（支持.sys、exe或.dll）；
應該用於請求下載有效負載數據的身份驗證令牌；
用於解密有效負載數據的AES密鑰；
下表列出了所有支持的命令及其說明。
表2：CC命令
在這些命令中，CC可以指定是在執行負載之前先將其放到磁盤上，還是直接在內存中執行。在將文件放到磁盤的情況下，操作系統卷上的ProgramData文件夾將用作目標文件夾，文件名和擴展名由CC服務器指定。在直接在內存中執行文件的情況下，svchost.exe用作注入目標。當CC發送需要內核驅動程序協作的命令時，或者操作員希望以內核模式執行代碼時，將使用與HTTP下載器通信部分中描述的機制。
反分析技巧為了更難檢測和分析這一惡意軟件，其開發者試圖將標准文件工件（如文本字符串、導入或其他未加密的嵌入數據）的可見性限制在最低限度。以下是所用技術的摘要。
字符串和數據加密：示例中使用的所有字符串都使用簡單的密碼進行加密；
所有嵌入的文件都在CBC模式下使用256位AES加密；
各文件的加密密鑰可能因樣本而異；
除AES加密之外，一些文件還使用LZMS進行壓縮。
Runtime-onlyAPI解析：在所有示例中（如果適用），Windows API總是在運行時進行排他解析，並且使用函數哈希而不是函數名來查找內存中所需的API函數地址；
在某些情況下，直接syscall指令調用用於調用所需的系統函數；
網絡通信：使用HTTPS通信；
HTTP下載器發送到CC的所有消息都使用嵌入的RSA公鑰進行加密；
從CC發送到HTTP下載器的所有消息都使用來自受害者設備環境的密鑰或CC提供的AES密鑰進行加密；
反調試和反VM技巧：如果使用該方法，通常放在入口點的開頭，僅使用臨時沙盒或調試器檢測技巧。
緩解措施和補救措施首先，必須保持所使用的系統及其安全產品是最新的；
然後，要防止使用已知的易受攻擊UEFI二進製文件繞過UEFI Secure Boot，需要採取的關鍵步驟是在UEFI取消數據庫（dbx）中取消這些二進製文件，在Windows系統上，應使用Windows Update傳播dbx更新。
問題是，廣泛使用的Windows UEFI二進製文件的取消可能會導致數千個過時的系統、恢復映像或備份無法啟動，因此，取消通常需要很長時間。
請注意，BlackLotus使用的Windows應用程序的取消將阻止啟動工具包的安裝，但由於安裝程序將用已取消的啟動加載器替換受害者的啟動加載器，這可能會使系統無法啟動。要在這種情況下進行恢復，重新安裝操作系統或僅進行ESP恢復即可解決問題。
如果在設置BlackLotus持久性之後發生取消，則bootkit將保持正常運行，因為它使用具有自定義MOK密鑰的合法填充程序進行持久性。在這種情況下，最安全的緩解方案是重新安裝Windows，並使用mokutil實用程序刪除攻擊者註冊的MOK密鑰（由於在啟動過程中需要用戶與MOK管理器進行必要的交互，因此執行此操作需要實體存在）。
總結在過去幾年中，已經發現了許多影響UEFI系統安全的關鍵漏洞。不幸的是，由於整個UEFI生態系統的複雜性和相關的供應鏈問題，即使在漏洞修復後很長一段時間，或者至少在用戶被告知它們已修復後，這些漏洞中的許多漏洞仍會使許多系統處於易受攻擊狀態。下面是一些去年允許UEFI Secure Boot繞過的修復或取消失敗的示例：
首先，當然是CVE-2022-21894，這是一個被BlackLotus利用的漏洞。在修復該漏洞一年後，易受攻擊的UEFI二進製文件仍然沒有被取消，這使得BlackLotus等攻擊可以在啟用了UEFI Secure Boot的系統上秘密運行。
早在2022年，研究人員就披露了幾個允許禁用UEFI Secure Boot的UEFI漏洞。許多受影響的設備不再受到OEM的支持，但在聯想消費級筆記本電腦中發現高影響的UEFI漏洞。
在2022年晚些時候，研究人員發現了其他一些UEFI漏洞，這些漏洞也允許攻擊者很容易地禁用UEFI Secure Boot。正如Binarly的研究人員指出的那樣，在警告發布幾個月後，警告中列出的幾個設備都沒有被修復，或者沒有正確地被修復，這使得這些設備容易受到攻擊。與前面的情況類似，一些設備將永遠處於易受攻擊狀態，因為它們已經無法更新。在不遠的將來，有攻擊者會濫用這些漏洞，創建一個能夠在啟用UEFI Secure Boot的系統上運行的UEFIbootkit。