BYOVD攻擊技術(shù)分析&防御指南

一、引言

近年來，隨著攻防對抗的升級，越來越多的APT組織、勒索軟件團伙采用BYOVD攻擊來繞過EDR檢測，達成致盲EDR、投放惡意軟件、進行勒索等目的。本文將深入剖析BYOVD的攻擊鏈路及其技術(shù)底層邏輯，并介紹防御指南。

二、BYOVD介紹

BYOVD（Bring Your Own Vulnerable Driver，自帶漏洞驅(qū)動）是一種利用帶有合法數(shù)字簽名但存在漏洞的驅(qū)動，來獲取內(nèi)核模式（Ring-0）的執(zhí)行權(quán)限的后滲透攻擊策略。

2.1 誕生背景

對于攻擊者來說，即便獲取了機器的SYSTEM管理員權(quán)限，其依然身處用戶態(tài)（Ring 3）中，一切行為與資源訪問均受到操作系統(tǒng)的嚴格審計與隔離。為了實現(xiàn)防御規(guī)避與隱蔽的持久化，攻擊者需要獲取內(nèi)核態(tài)（Ring 0）權(quán)限。

在早期的Windows系統(tǒng)中，攻擊者擁有管理員權(quán)限即可輕易加載自定義惡意驅(qū)動，獲得Ring 0權(quán)限，任意操控內(nèi)核數(shù)據(jù)、隱藏進程、植入rootkit、終止EDR進程等。

為了應(yīng)對該威脅，自 Windows Vista x64 起，微軟引入了DSE（Driver Signature Enforcement，驅(qū)動簽名強制執(zhí)行）技術(shù)，要求所有內(nèi)核驅(qū)動必須具備可信證書頒發(fā)機構(gòu)（CA）的簽名，此舉消滅了大部分自定義的惡意驅(qū)動。

自此，BYOVD技術(shù)應(yīng)運而生，攻擊者通過搜集帶有合法數(shù)字簽名但存在漏洞（例如：任意內(nèi)存讀寫、IOCTL處理函數(shù)校驗不足、特權(quán)API暴露等）的驅(qū)動，來獲取內(nèi)核執(zhí)行權(quán)限。加載的驅(qū)動來源合法，帶有官方數(shù)字簽名，能夠直接規(guī)避EDR檢測；同時，其存在已知漏洞，攻擊者可在用戶態(tài)發(fā)送指令與漏洞驅(qū)動交互，以內(nèi)核級權(quán)限執(zhí)行各類惡意操作。

2.2 BYOVD經(jīng)典攻擊過程

本節(jié)以一個典型的驅(qū)動漏洞為例，該漏洞源于IOCTL處理函數(shù)缺乏校驗，可導(dǎo)致任意進程終止，來描繪BYOVD的典型攻擊流程。

1）獲取管理員權(quán)限

加載內(nèi)核驅(qū)動需要目標(biāo)機器管理員權(quán)限，攻擊者往往通過網(wǎng)絡(luò)釣魚、Web漏洞、本地提權(quán)等方式獲取管理員權(quán)限。

2）投放漏洞驅(qū)動

攻擊者將帶有合法簽名但存在漏洞的.sys驅(qū)動文件投放到目標(biāo)機器中，由于該驅(qū)動文件本身來源可信且?guī)в泻戏〝?shù)字簽名，因此不會被殺軟或EDR攔截。

3）加載漏洞驅(qū)動

攻擊者使用Windows SCM（Service Control Manager，服務(wù)控制管理器）或調(diào)用NtLoadDriverAPI將漏洞驅(qū)動注冊為內(nèi)核服務(wù)并加載。Windows會驗證其數(shù)字簽名是否有效，并追溯到微軟信任的根證書。

然而，該簽名驗證流程存在缺陷，導(dǎo)致以下簽名均被視為有效簽名：

  • 2015.07.29之前的舊證書：自Windows 10起，微軟要求所有新的內(nèi)核驅(qū)動都必須通過HDC（Hardware Dev Center，硬件開發(fā)中心）進行簽名，而在此之前，開發(fā)者可以繞過微軟使用第三方交叉證書自行簽名。為了兼容，Windows將允許這些交叉簽名的驅(qū)動加載，只要該交叉簽名可追溯到可信CA。
  • 已吊銷的證書：由于驅(qū)動程序在系統(tǒng)啟動過程早期加載，此時網(wǎng)絡(luò)不可用，因此系統(tǒng)不會執(zhí)行CRL（Certificate Revocation Lists，證書吊銷列表）檢查，只要簽名時間戳（而非當(dāng)前時間戳）位于證書有效期即可。

4）提權(quán)

漏洞驅(qū)動加載到內(nèi)核后，該驅(qū)動即擁有內(nèi)核（Ring 0）級權(quán)限。

5）下發(fā)指令

攻擊者通過驅(qū)動的漏洞點，下發(fā)對應(yīng)的IOCTL指令，指示驅(qū)動終止EDR進程。由于IOCTL處理函數(shù)缺乏校驗，且此時EDR進程與漏洞驅(qū)動均位于Ring 0內(nèi)核態(tài)，因此，EDR進程被成功殺死。

6）執(zhí)行惡意操作

此時，免除于EDR的監(jiān)控與阻斷，攻擊者可以為所欲為，執(zhí)行任意操作，包括：投放病毒/勒索軟件、禁用ETW監(jiān)控、在內(nèi)核中運行rootkit等。

三、BYOVD技術(shù)分析

本節(jié)以開源項目BlackSnufkin/BYOVD中的漏洞驅(qū)動STProcessMonitor作為案例，復(fù)現(xiàn)BYOVD攻擊，并分析其技術(shù)原理。

注1：BlackSnufkin/BYOVD 是一個用于演示BYOVD攻擊的開源項目，提供了一組 PoC，展示了如何利用存在漏洞的驅(qū)動程序來禁用殺毒/EDR 程序。

注2：Safetica STProcessMonitor 驅(qū)動程序存在訪問控制漏洞CVE-2025-70795，其中進程終止功能在未進行適當(dāng)目標(biāo)驗證的情況下暴露給用戶模式。這使得攻擊者無需進行身份驗證或授權(quán)檢查即可在內(nèi)核模式下終止任意進程。該漏洞已被銀狐惡意組織利用。

3.1 環(huán)境搭建

該項目依賴Microsoft Visual Studio Build Tools中的Windows SDK構(gòu)建，需要安裝構(gòu)建環(huán)境（務(wù)必勾選圖中的“Windows 10/11 SDK ”和 “MSVC v143 - VS 2022 C++ x64/x86 生成工具”）：

同時，需要安裝Cargo，該軟件自行下載安裝即可，在此不贅述。

3.2 載荷準備&分析

使用命令編譯載荷：

cargo build --release -p STProcessMonitor-Killer

編譯后的載荷STProcessMonitor-Killer.exe在target/release目錄下，將其拷貝到目標(biāo)機器，并將.sys文件一并拷貝到同目錄（這里使用STProcessMonitor_v114.sys驅(qū)動）。

右鍵查看STProcessMonitor_v114.sys文件屬性，發(fā)現(xiàn)其攜帶Microsoft Windows Third Party Component CA 2012頒發(fā)的有效數(shù)字簽名證書，盡管有效期為2025.02.12 - 2026.02.19，但證書簽發(fā)時間戳為2025年5月9日 11:43:46，在有效期范圍內(nèi)，因此，仍然會被微軟認定為有效簽名。

3.3 載荷執(zhí)行

目標(biāo)機器上安裝并運行了火絨安全軟件，以此作為操作對象。

首先通過管理員權(quán)限啟動cmd窗口，嘗試直接殺進程，觀察是否可行，可以看到結(jié)果顯示失敗：

執(zhí)行命令嘗試殺掉火絨的HipsDaemon.exe進程：

STProcessMonitor-Killer.exe --version 114 -n HipsDaemon.exe

可以看到，執(zhí)行成功，該進程被成功殺掉：

點開火絨界面，可以看到其顯示安全服務(wù)異常：

如法炮制，使用命令殺掉火絨的HipsTray.exe進程，也成功了，此時火絨已經(jīng)成功退出：

STProcessMonitor-Killer.exe --version 114 -n HipsTray.exe

3.4 驅(qū)動文件逆向

通過Ghidra對STProcessMonitor_v114.sys文件進行逆向，從DriverEntry入口順著設(shè)備注冊邏輯入手，可以看到在處理IOCTL指令的fun_140001b70函數(shù)中，存在以下漏洞片段：

當(dāng)IOCTL設(shè)備控制碼為0xB822200C時，程序僅校驗了緩沖區(qū)大小是否大于7字節(jié)（近乎于無門檻），即進入了進程終止邏輯。從用戶緩沖區(qū)獲取進程ID，啟動ZwOpenProcess以最大權(quán)限訪問該進程，然后調(diào)用ZwTerminateProcess終止目標(biāo)進程。由于該驅(qū)動加載后位于Ring 0，為系統(tǒng)最大權(quán)限，使得其可以達成殺死任意進程的目的。

3.5 BlackSnufkin/BYOVD項目分析

接著再來看看BlackSnufkin/BYOVD項目做了什么，關(guān)鍵函數(shù)分析如下：

其byovd-lib/src/lib.rs文件中，定義了DriverManager，其new操作中使用SCM創(chuàng)建了一個服務(wù)，并注冊為內(nèi)核驅(qū)動，以此將漏洞驅(qū)動加載到內(nèi)核。該方法對應(yīng)BYOVD利用鏈中的驅(qū)動加載環(huán)節(jié)（如前文2.2.3一節(jié)所述）。

該操作類似命令行：

sc.exe create <driver_name> type=kernel binPath=<driver_path>
sc.exe start <driver_name>

并定義了send_ioctl函數(shù)，瞄準對應(yīng)的IOCTL控制碼，發(fā)送指令（該方法對應(yīng)BYOVD利用鏈中的發(fā)送IOCTL指令環(huán)節(jié)，如前文2.2.5一節(jié)所述）：

進入到STProcessMonitor-Killer/src/main.rs文件，可以看到這里定義的存在漏洞的IOCTL控制碼和前文3.4一節(jié)逆向分析的一致：

四、BYOVD檢測與防御

4.1 LoLDrivers

LoLDrivers（Living Off The Land Drivers）是一個安全社區(qū)維護的開源項目，持續(xù)收集并記錄已被證實存在漏洞、被APT組織或勒索軟件濫用的合法簽名驅(qū)動程序。

LoLDrivers數(shù)據(jù)庫提供了一系列驅(qū)動文件哈希（MD5/SHA1/SHA256），可借助以下工具對系統(tǒng)驅(qū)動進行掃描：

4.2 Windows事件日志

在BYOVD攻擊中，驅(qū)動釋放、服務(wù)注冊及模塊加載都會在Windows事件日志中存在相應(yīng)記錄，通過配置并收集特定的事件日志，可實現(xiàn)檢測：

  • Sysmon Event ID 11：文件創(chuàng)建事件日志，由Sysmon提供，監(jiān)控.sys驅(qū)動文件是否由異常進程（cmd.exe、powershell.exe、wcript.exe、Web進程等）釋放到磁盤。
  • System Event ID 7045：服務(wù)創(chuàng)建事件日志，當(dāng)驅(qū)動通過SCM注冊服務(wù)時會觸發(fā)該日志記錄。重點關(guān)注ImagePath字段指向非系統(tǒng)驅(qū)動C:\Windows\System32\drivers\目錄，且服務(wù)類型為Kernel Mode Driver 的異常日志。
  • Sysmon Event ID 6：驅(qū)動加載日志，由Sysmon提供，記錄了驅(qū)動加載的文件路徑、哈希和簽名等重要信息，可用于識別漏洞驅(qū)動加載。
  • CodeIntegrity Event ID 3004 / 3033：Windows代碼完整性日志。驅(qū)動因簽名無效或命中內(nèi)核黑名單被系統(tǒng)攔截或?qū)徲嫊r會觸發(fā)該日志，可據(jù)此檢測。

4.3 基于行為特征檢測

基于文件哈希識別的漏洞驅(qū)動靜態(tài)檢測存在滯后性，攻擊者可能使用尚未被記錄的0-day/1-day漏洞驅(qū)動，此時可使用基于行為特征的檢測方式：

  • 異常的IOCTL通信監(jiān)控：利用 EDR 的底層探針或ETW，監(jiān)控用戶態(tài)進程對驅(qū)動設(shè)備的CreateFile（打開設(shè)備句柄）和DeviceIoControl（發(fā)送控制碼）調(diào)用。若一個普通的非系統(tǒng)進程頻繁向冷門的硬件驅(qū)動（如網(wǎng)卡診斷驅(qū)動）發(fā)送IOCTL請求，視為可疑行為。
  • 行為關(guān)聯(lián)分析：監(jiān)控可疑的進程調(diào)用鏈，例如：普通Web進程調(diào)用sc.exe create或sc.exe start命令拉起一個內(nèi)核服務(wù)、用戶態(tài)進程發(fā)送IOCTL指令后安全軟件相關(guān)進程終止。
  • 敏感API調(diào)用與權(quán)限提升行為：監(jiān)控 NtLoadDriver或 ZwLoadDriver等底層 API 的直接調(diào)用。重點關(guān)注驅(qū)動加載后，是否出現(xiàn)了安全軟件PPL標(biāo)志位降級或token被篡改等提權(quán)行為。

4.4 啟用HVCI與WDAC

WDAC（Windows Defender Application Control）是微軟提供的原生應(yīng)用程序控制框架，可通過設(shè)置攔截策略，決定哪些驅(qū)動能夠被加載到內(nèi)核中。

  • 設(shè)置微軟漏洞驅(qū)動攔截列表（Vulnerable Driver Blocklist）：通過該名單，開啟策略后，系統(tǒng)會在加載驅(qū)動時對比文件哈希及特征，阻止攔截列表中的漏洞驅(qū)動加載。配置方法如下：
    1. 下載 應(yīng)用控制策略刷新工具
    2. 下載并提取 易受攻擊的驅(qū)動程序阻止列表二進制文件
    3. 選擇“僅審核版本”（會產(chǎn)生事件日志，可用于檢測）或“強制版本”（會直接阻斷驅(qū)動加載），并將文件重命名為 SiPolicy.p7b
    4. 將 SiPolicy.p7b 復(fù)制到 %windir%\system32\CodeIntegrity
    5. 運行在上述步驟 1 中下載的應(yīng)用控制策略刷新工具，以激活和刷新計算機上的所有應(yīng)用控制策略
  • 啟用HVCI（Hypervisor-protected Code Integrity，虛擬機監(jiān)控程序保護的代碼完整性）：其利用Windows虛擬化強制實施內(nèi)核代碼完整性。即使漏洞驅(qū)動被加載進內(nèi)核，也能在硬件層面阻止內(nèi)核內(nèi)存頁被標(biāo)記為“可寫可執(zhí)行”，導(dǎo)致惡意rootkit或shellcode注入內(nèi)核失敗，從而降低BYOVD攻擊的危害。配置方法如下：
    1. 同時按下win+R，打開運行對話框，輸入gpedit.msc回車，打開組策略編輯器
    2. 進入菜單：計算機配置 -> 管理模板 -> 系統(tǒng) -> Device Guard -> 打開基于虛擬化的安全，在彈出的對話框中選擇已啟用，在基于虛擬化的代碼完整性保護中選擇需要UEFI鎖啟用，點擊確定后重啟電腦即可啟用HVCI。

五、WDAC攔截策略實踐

針對上述4.4一節(jié)中的WDAC攔截策略設(shè)置，本節(jié)以漏洞驅(qū)動STProcessMonitor_v114.sys為例，說明如何添加WDAC規(guī)則。

5.1 環(huán)境準備

  1. 檢查當(dāng)前操作系統(tǒng)版本，是否為專業(yè)版pro（家庭版親測不支持；若為非專業(yè)版Pro，可執(zhí)行步驟2檢查）
  2. 檢查當(dāng)前系統(tǒng)是否支持代碼完整性策略模塊，打開Powershell，輸入New-CIPolicyRule -Level Publisher -DriverFilePath "D:\test\byovd\STProcessMonitor_v114.sys"命令，查看其是否報該函數(shù)/模塊找不到、不識別之類的錯誤，若無此類報錯，則表明系統(tǒng)支持后續(xù)操作
  3. 下載 應(yīng)用控制策略刷新工具
  4. 下載并提取 易受攻擊的驅(qū)動程序阻止列表二進制文件
  5. 下載微軟官方的可視化編輯工具WDAC Wizard

5.2 策略生成

5.2.1 基于黑名單的策略

可針對漏洞驅(qū)動/惡意驅(qū)動，在微軟官方提供的阻止列表基礎(chǔ)上添加針對性的黑名單策略。

  1. 雙擊下載的Wizard Installer安裝程序，安裝后啟動，選擇Policy Editor：
  1. 選取環(huán)境準備一節(jié)步驟2中下載的阻止列表文件中的SiPolicy_Audit.xml，保存的文件名填寫為SiPolicy.xml，然后點擊Next：
  1. 這一步為策略配置，注意最下方的Audit Mode選項，若該選項開啟，則規(guī)則生效后僅告警；若關(guān)閉，則還會在告警的基礎(chǔ)上，直接阻斷驅(qū)動加載，這里選擇關(guān)閉，以更直觀展示策略效果：

  1. 此時進入規(guī)則編輯界面，該列表內(nèi)置了許多微軟官方的規(guī)則，可在此基礎(chǔ)上添加針對漏洞驅(qū)動的規(guī)則。點擊右上角的Add Custom Rule，在彈出的對話框中，針對Rule Action選擇Deny（用于阻止），Rule Type支持多種模式，筆者探索了以下3種：

    • Provider：根據(jù)驅(qū)動的發(fā)行方信息進行匹配（每個條件之間以and連接），包括簽署的CA、發(fā)行商、產(chǎn)品名、原始文件名、最小版本號等信息。
    • File Hash：根據(jù)驅(qū)動文件的Hash（SHA1或SHA256）進行匹配，可直接選取文件識別，也可手動錄入hash值
    • File Attributes：根據(jù)驅(qū)動文件自身信息匹配（每個條件之間以and連接），包括：原始文件名、文件描述、產(chǎn)品名稱、內(nèi)部名稱（驅(qū)動加載后的設(shè)備名稱）等信息（此類型的規(guī)則添加，不受系統(tǒng)版本限制，Windows家庭版也可以操作成功）。

  2. 規(guī)則添加完畢后，點擊Next，等待片刻，即可看到策略生成成功界面：

  1. 此時查看對應(yīng)路徑下的文件，應(yīng)該能看到SiPolicy.xml和 SiPolicy.p7b 這兩個文件生成，若僅有SiPolicy.xml文件，則表明策略文件生成失敗（該工具不會有任何報錯，需要自行排查）
  2. 此時查看SiPolicy.xml文件內(nèi)容，應(yīng)能看到剛剛添加的規(guī)則（這里以File Hash類型的規(guī)則為例）：

5.2.2 基于白名單的策略

微軟還支持基于白名單的策略，但需注意：若白名單設(shè)置不合理，可造成系統(tǒng)藍屏！建議謹慎操作。

  1. 前期步驟參見基于黑名單的策略一節(jié)，直到規(guī)則設(shè)定這一步驟
  2. 在規(guī)則設(shè)定界面的列表中，找到以下兩條規(guī)則：Action為Allow、Level為FileAttributes、Name為空、Associated Files為*FileName: *、Rule ID分別為ID_ALLOW_ALL_1和ID_ALLOW_ALL_2，選擇右下角的Remove Rule刪掉這兩條規(guī)則：
  1. 在此基礎(chǔ)上，添加白名單規(guī)則，Rule Action選擇Allow，選取各個合法且安全的驅(qū)動（務(wù)必包含系統(tǒng)運行必備驅(qū)動）以允許其加載
  2. 后續(xù)步驟參照黑名單策略

注意：若白名單設(shè)置不合理，遺漏了部分系統(tǒng)驅(qū)動，可能造成系統(tǒng)下一次重啟后藍屏，無法正常開機！此時，開機會報錯（例如：網(wǎng)絡(luò)連接失敗等），可進入系統(tǒng)安全模式，將%windir%\system32\CodeIntegrity\SiPolicy.p7b策略文件刪掉，再次重啟，即可正常開機

5.3 激活規(guī)則

  1. 將 SiPolicy.p7b 復(fù)制到 %windir%\system32\CodeIntegrity（這一步需要管理員權(quán)限）
  2. 運行環(huán)境準備一節(jié)步驟 3 中下載的應(yīng)用控制策略刷新工具，以激活和刷新計算機上的所有應(yīng)用控制策略

5.4 測試規(guī)則

進行規(guī)則測試，驗證策略是否生效。

  1. 按下win+R快捷鍵，輸入eventvwr.msc打開事件管理器，在應(yīng)用程序和服務(wù)日志 - Microsoft - Windows - CodeIntegrity中，查看是否存在事件ID為3099的日志（其中的PolicyGUID應(yīng)和上述查看的SiPolicy.xml文件內(nèi)容中PolicyTypeID一致，PolicyHash應(yīng)和策略文件 SiPolicy.p7b 的SHA256 hash值一致），若存在，則表明策略加載成功：
  1. 使用管理員權(quán)限打開cmd命令窗口，執(zhí)行以下命令，驗證策略是否成功阻斷驅(qū)動加載：
sc.exe create vuln_driver type=kernel binPath="D:\test\byovd\STProcessMonitor_v114.sys"
sc.exe start vuln_driver

應(yīng)看到如圖所示的攔截結(jié)果：

注： 若在策略生效前成功加載過該驅(qū)動，可能會存在緩存（偶現(xiàn)），導(dǎo)致攔截失敗。此時可嘗試復(fù)制/刪除該驅(qū)動（達到切換/清除磁盤中的文件句柄的目的），使用復(fù)制/重新拷貝的驅(qū)動再次嘗試，即可成功

  1. 查看事件管理器，應(yīng)能看到事件ID為3077（策略生成時選取了Deny模式）或3076（策略生成時選取了Audit模式）的日志：

其中，可通過PolicyHash和PolicyGUID字段確認生效的策略為剛剛添加的策略。

  1. 此時，再次執(zhí)行byovd攻擊，可以看到攻擊失敗：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容