.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
繞過安全啟動並建立持久性在本部分中，我們將詳細了解BlackLotus如何在啟用UEFI Secure Boot的系統上實現持久性。由於我們將要描述的執行鏈非常複雜，我們將首先解釋基本原理，然後深入了解技術細節。
簡而言之，該過程包括兩個關鍵步驟：
利用CVE-2022-21894繞過安全啟動功能並安裝bootkit。這允許在早期啟動階段任意執行代碼，此時平台仍然由固件擁有，UEFI啟動服務功能仍然可用。這使得攻擊者可以在沒有物理訪問權限的情況下，在啟用了UEFI Secure Boot的設備上做許多不應該做的事情，例如修改僅用於啟動服務的NVRAM變量。這就是攻擊者在下一個步驟中為bootkit設置持久性所利用的。通過將自己的MOK寫入MokList來設置持久性，Boot僅服務NVRAM變量。這樣，它可以使用合法的Microsoft-signedshim加載其自簽名（由寫入MokList的密鑰的私鑰簽名）UEFIbootkit，而不是在每次啟動時利用該漏洞。有關這一點的更多信息，請參閱Bootkit持久性部分。
為了使下面兩部分的分析更容易，研究人員將遵循執行圖（下圖）中所示的步驟。
繞過安全啟動並使用MOK設置持久性
利用CVE-2022-21894為了繞過安全啟動，BlackLotus使用baton drop漏洞（CVE-2022-21894）：安全啟動安全功能繞過漏洞。儘管這個漏洞對系統安全影響很大，但它並沒有得到應有的重視。儘管微軟在2022年1月的更新中修復了該漏洞，但由於受影響的二進製文件仍未添加到UEFI取消列表中，因此攻擊者仍有可能利用該漏洞。因此，攻擊者可以將他們自己的易受攻擊的二進製文件副本帶到受害者的設備上，以利用此漏洞並繞過最新UEFI系統上的安全啟動。
此外，自2022年8月以來，針對該漏洞的概念證明（PoC）漏洞已公開可用。考慮到第一次BlackLotus VirusTotal提交的日期，惡意軟件開發人員可能只是根據他們的需要調整了可用的PoC，而不需要深入了解此漏洞的工作原理。
讓我們先簡單介紹一下該漏洞，主要是與PoC一起發佈在GitHub上的文章中的關鍵點：
受影響的Windows啟動應用程序（如bootmgr.efi、hvloader.efi、winload.efi…）允許在應用程序加載序列化安全啟動策略之前，使用truncatememory BCD啟動選項從內存中刪除該策略。
這允許攻擊者使用其他危險的BCD選項，如bootdebug、testsigning或nointegridchecks，從而破壞安全啟動。
有多種方法可以利用此漏洞——其中三種方法已發佈在PoC存儲庫中。
例如，其中一個PoC顯示瞭如何利用它使合法的hvloader.efi加載任意的自簽名mcupdate_
現在，我們繼續介紹BlackLotus如何利用此漏洞：
1.安裝程序重新啟動機器後，UEFI固件將繼續加載第一個啟動選項。對於Windows系統，默認情況下，第一個啟動選項是位於ESP上ESP:/efi/Microsoft/boot文件夾中的bootmgfw.efi。這一次，固件沒有執行原始受害者的bootmgfw.efi（安裝程序以前將其重命名為winload.efi），而是執行安裝程序部署的易受攻擊的啟動。
2.執行bootmgfw.efi後，它將加載BCD啟動選項，該選項先前由安裝程序修改。下圖顯示了合法BCD和修改後BCD的比較。
3.如下圖所示（路徑以綠色劃線），合法的Windows Boot Manager通常會將Windows OS加載程序（\Windows\system32\winload.efi）作為默認啟動應用程序加載。但這一次，使用修改後的BCD，它繼續加載易受攻擊的ESP:\system32\bootmgr.efi，避免內存BCD元素設置為值0x10000000，並且custom:22000023BCD指向另一個攻擊者存儲在ESP:\system32\BCD中的BCD。
合法BCD存儲（BEFORE）與BlackLotus安裝程序使用的存儲（AFTER）的比較
4.在下一步中，執行的ESP:\system32\bootmgr.efi加載位於ESP:\system32\BCD中的附加BCD。這個附加BCD的解析內容如下圖所示。
BlackLotus安裝程序釋放的第二個BCD——用於利用CVE-2022-21894
5.由於從上圖所示的BCD文件加載了選項，bootmgr.efi將繼續加載安裝程序部署的另一個易受攻擊的Windows啟動應用程序ESP:\system32\hvloader.efi，即Windows Hypervisor Loader。更重要的是，在同一BCD文件中指定了其他BCD選項：
值設置為0x10000000的truncatememory；
nointegridchecks設置為Yes；
testsigning也設置為Yes；
此時就會發生意想不到的事情，由於序列化的安全啟動策略應該在0x10000000以上的物理地址中加載（因為前面步驟中使用了avoidlowmemory），指定truncatmemory元素將有效地刪除它。因此，中斷安全啟動並允許使用危險的BCD選項，如nointegritychecks或testsigning。通過使用這些選項，攻擊者可以使hvloader.efi執行自己的自簽名代碼。
6.為此，使用此PoC中描述的技巧，即在執行過程中，合法的hvloader.efi從
從合法的hvloader.efi反編譯BtLoadUpdateDll函數，負責加載mcupdate_*.dll
7.現在，隨著攻擊者自己的自簽名mcupdate*.dll被加載和執行，它將繼續執行這個鏈中的最後一個組件——一個嵌入式MokInstaller （UEFI應用程序）——參見圖10了解它是如何完成的。
Hex-Rays反編譯惡意自簽名mcupdate*.dll二進制代碼
Bootkit持久性現在，MokInstaller可以繼續設置持久性，方法是將攻擊者的MOK註冊到NVRAM變量中，並將合法的Microsoft簽名的shim二進製文件設置為默認啟動加載程序來繼續設置持久性。
shim是由Linux開發人員開發的第一階段UEFI啟動加載程序，用於使各種Linux發行版與UEFI Secure Boot一起工作。它是一個簡單的應用程序，其目的是加載、驗證和執行另一個應用程序，在Linux系統中，它通常是GRUB啟動加載程序。它的工作方式是，微軟只簽署一個shim, shim負責其餘的工作，它可以通過使用db UEFI變量中的密鑰來驗證第二階段啟動加載器的完整性，還可以嵌入自己的“允許”或“取消”項或哈希列表，以確保平台和shim開發人員（例如Canonical, RedHat等）都信任的組件被允許執行。除了這些列表之外，shim還允許使用用戶管理的外部密鑰數據庫，即MOK列表。該MOK數據庫存儲在名為MokList的僅啟動NVRAM變量中。在不利用上述漏洞的情況下，需要物理訪問才能在啟用UEFI Secure Boot的系統上對其進行修改（僅在啟動期間，在系統加載程序調用UEFI啟動服務函數ExitBootServices之前可用）。然而，通過利用此漏洞，攻擊者能夠繞過UEFI Secure Boot並在調用ExitBootServices之前執行自己的自簽名代碼，因此他們可以輕鬆註冊自己的密鑰（通過修改MokList NVRAM變量），使填充程序執行任何應用程序（由該註冊密鑰簽名），而不會導致安全違規。
MOK啟動過程
8.MokInstaller UEFI應用程序繼續為BlackLotus UEFIbootkit設置持久性，並通過以下方式覆蓋利用痕跡：
8.1 從安裝程序創建的備份中恢復受害者的原始BCD存儲，並將efi替換為合法的microsoft簽名shim，該shim先前由安裝程序放置到ESP:\system32\bootload.efi中。
8.2創建包含攻擊者自簽名公鑰證書的MokList NVRAM變量。請注意，此變量的格式與任何其他UEFI簽名數據庫變量（如db或dbx）的格式相同，它可以由零個或多個EFI_signature_LIST類型的簽名列表組成，如UEFI規範中所定義。
8.3 從攻擊者的ESP:\system32\文件夾中刪除涉及攻擊的所有文件。
最後，它會重新啟動計算機，使部署的shim執行安裝程序從\EFI\Microsoft\Boot\grub64.EFI中刪除自簽名bootkit，grub64.EFI通常是x86-64系統上shim執行的默認第二階段啟動加載程序。
Hex Rays反編譯代碼——MokInstaller UEFI應用程序為BlackLotus bootkit設置持久性
BlackLotus UEFIbootkit一旦配置了持久性，就會在每次系統啟動時執行BlackLotusbootkit。 bootkit的目標是部署一個內核驅動程序和一個最終的用戶模式組件——HTTP下載器。在執行過程中，它試圖禁用其他Windows安全功能——基於虛擬化的安全（VBS）和Windows Defender——以提高成功部署和隱形操作的機會。在詳細介紹如何實現之前，讓我們先了解一下內核驅動程序和HTTP下載器的基本知識：
內核驅動程序負責：
部署鏈的下一個組件—HTTP下載器；
在被終止運行的情況下保持加載器不被關閉；
防止從ESP中刪除bootkit文件；
如果HTTP下載器指示的話，執行額外的內核有效負載；
根據HTTP下載器的指示，卸載bootkit。
HTTP下載器負責：
與CC通信；
執行從CC收到的命令；
下載並執行從CC接收到的有效負載（支持內核有效負載和用戶模式有效負載）。
從安裝程序到HTTP下載器的完整執行流程（簡化後）如下圖所示。我們將在下一節中更詳細地描述這些步驟。
BlackLotus UEFIbootkit執行示意圖
BlackLotus執行流程執行步驟如下（這些步驟如下圖所示）：
1.UEFI固件執行默認的Windows啟動選項，該選項通常存儲在\EFI\Microsoft\boot\bootmgfw.EFI中的文件。正上所述，MokInstaller二進製文件用一個合法的簽名shim替換了這個文件。
2.執行shim時，它讀取MokList NVRAM變量，並使用攻擊者先前存儲在其中的證書來驗證第二階段啟動加載程序——位於\EFI\Microsoft\Boot\grubx64.efi中的自簽名BlackLotus UEFI啟動程序。
3.驗證後，shim執行bootkit。
4.bootkit從創建僅啟動VbsPolicyDisable NVRAM變量開始。如本文所述，此變量在啟動期間由Windows OS加載程序評估，如果已定義，則不會初始化核心VBS功能，如HVCI和憑據保護。
5.在以下步驟中，bootkit繼續使用UEFIbootkit使用的通用模式。它攔截典型Windows啟動流中包含的組件的執行，例如Windows啟動管理器、Windows OS加載器和Windows OS內核，並將它們的一些功能掛鉤到內存中。另外，它還嘗試通過修復某些驅動程序來禁用Windows Defender。所有這些都是為了在系統啟動過程的早期階段實現有效負載的執行，並避免檢測。以下函數已掛鉤或修復：
5.1 bootmgfw.efi或bootmgr.efi中的ImgArchStartBootApplication：該函數通常由bootkit掛鉤，以捕捉Windows OS加載程序（winload.efi）加載到內存中但尚未執行的時刻——這是執行更多內存修復的正確時刻。
5.2 winload.efi中的BlImgAllocateImageBuffer：用於為惡意內核驅動程序分配額外的內存緩衝區。
5.3 winload.efi中的OslArchTransferToKernel：連接以捕捉系統內核和某些系統驅動程序已加載到內存中但尚未執行的時刻，這是執行更多內存修復的最佳時刻。下面提到的驅動程序在此掛鉤中進行了修復。下圖顯示了這個掛鉤中負責在內存中查找適當驅動程序的代碼。
5.4 WdBoot.sys和WdFilter.sys：BlackLotus修復了WdBoot.sys和WdFilter.sys（分別是Windows Defender ELAM驅動程序和Windows Defender文件系統篩選器驅動程序）的入口點，以立即返回。
5.5 disk.sys：bootkit將disk.sys驅動程序的入口點掛鉤，以便在系統初始化的早期階段執行BlackLotus內核驅動程序。
OslArchTransferToKernel掛鉤的反編譯代碼——修復Windows Defender驅動程序並蒐索disk.sys入口點
6.接下來，當系統內核執行disk.sys驅動程序的入口點時，已安裝的掛鉤會跳轉到惡意內核驅動程序入口點。惡意代碼反過來恢復原始disk.sys以使系統正常運行，並等待winlogon.exe進程啟動。
7.當惡意驅動程序檢測到winlogon.exe進程已啟動時，它會向其中註入並執行最終的用戶模式組件——HTTP下載器。
內核驅動程序內核驅動程序主要負責四個任務：
將HTTP下載器注入到winlogon.exe中，並在線程終止時重新註入它；
保護部署在ESP上的bootkit文件不被刪除；
解除用戶模式Windows Defender進程MsMpEngine.exe；
與HTTP下載器通信，並在必要時執行任何命令。
HTTP下載器持久性內核驅動程序負責部署HTTP下載程序。當驅動程序啟動時，它會等待名為winlogon.exe的進程啟動，然後再執行任何其他操作。進程啟動後，驅動程序解密HTTP下載程序二進製文件，將其註入winlogon.exe的地址空間，並在新線程中執行。然後，驅動程序會定期檢查線程是否仍在運行，並在必要時重複注入。如果驅動程序檢測到內核調試器，則不會部署HTTP下載程序。
保護ESP上的bootkit文件不被刪除為了保護ESP上的bootkit文件，內核驅動程序使用了一個簡單的技巧。它打開所有要保護的文件，複製並保存其句柄，並使用ObSetHandleAttributes內核函數將HandleFlags（OBJECT_HANDLE_flag_INFORMATION）參數內的ProtectFromClose標誌指定為1，從而保護句柄不被任何其他進程關閉。這將阻止任何刪除或修改受保護文件的嘗試。受保護的文件包括：
ESP:\EFI\Microsoft\Boot\winload.efiESP:\EFI\Microsoft\Boot\bootmgfw.efiESP:\EFI\Microsoft\Boot\grubx64.efi如果用戶試圖刪除這些受保護的文件，就會出現如下圖所示的情況。
試圖刪除受BlackLotus驅動程序保護的文件
作為另一層保護，如果用戶或安全軟件能夠取消設置保護標誌並關閉句柄，內核驅動程序將持續監視它們，如果句柄不再存在，則通過調用KeBugCheck（INVALID_kernel_HANDLE）函數來生成一個BSOD。
解除主Windows Defender進程內核驅動程序還試圖解除主Windows Defender進程MsMpEng.exe的防護。為此，它通過為每個進程設置SE_PRIVILEGE_REMOVED屬性來刪除所有進程的令牌權限。因此，Defender進程應該無法正確地完成其工作（例如掃描文件）。但是，由於該功能執行得很差，因此可以通過重新啟動MsMpEng.exe進程使其失效。