攻擊：FSCTL_REQUEST_BATCH_OPLOCK 如何凍結(jié) Windows Defender（完整原理指南）)
BlueHammer 批處理 Oplock 競態(tài)攻擊FSCTL_REQUEST_BATCH_OPLOCK 如何凍結(jié) Windows Defender完整原理指南【免費(fèi)下載鏈接】BlueHammerRepository hosting the bluehammer vulnerability項(xiàng)目地址: https://gitcode.com/gh_mirrors/bl/BlueHammerBlueHammer 是針對 Windows DefenderWinDefend服務(wù)的一個本地權(quán)限提升漏洞 PoC倉庫定位是 README.md 所說的 hosting the bluehammer vulnerability。它的核心武器是 Windows 文件系統(tǒng)控制碼FSCTL_REQUEST_BATCH_OPLOCK——一個批處理 Oplock機(jī)會鎖異步請求。本文用通俗的方式講清楚這個 API 在攻擊鏈里扮演時間控制器如何把 Defender 的文件操作精確卡住最終讓攻擊者從系統(tǒng)保護(hù)最嚴(yán)的 VSS 快照里讀走 SAM 賬戶數(shù)據(jù)庫。?? 安全提示本項(xiàng)目是漏洞研究代碼請只在授權(quán)的測試環(huán)境中分析不要在生產(chǎn)機(jī)器上運(yùn)行。 一分鐘看懂 BlueHammer 做了什么整個攻擊可以拆成 4 步步驟動作用到的武器1等待 Defender 簽名更新窗口輪詢更新接口2凍結(jié) Defender制造一個可用的 VSS 卷影快照Batch Oplock Cloud Files 回調(diào)3用符號鏈接劫持 Defender 的讀請求Batch Oplock制造競態(tài)窗口4從 VSS 快照讀走 SAM、解析哈希、改密碼事務(wù)文件CreateFileTransactedOplock 是貫穿第 2、3 步的關(guān)鍵。下面先看它是什么。 什么是 Oplock為什么偏偏選 Batch 類型Oplock機(jī)會鎖是 NTFS 的緩存一致性協(xié)議一個進(jìn)程頻繁讀文件時可以申請獨(dú)占緩存權(quán)其他進(jìn)程再來碰這個文件時系統(tǒng)會先通知break持鎖者保證數(shù)據(jù)不臟。Windows 提供幾種 Oplock 強(qiáng)度BlueHammer 選的是最弱的Batch類型語義什么時候被打破Batch批處理最寬松我有讀緩存權(quán)只要別的進(jìn)程打開該文件哪怕只讀就 breakLevel-II無其他進(jìn)程打開時授予別的進(jìn)程以寫方式打開時 breakExclusive獨(dú)占完全獨(dú)占任何新打開都 breakBatch Oplock 對攻擊者最有價值的特性是請求可以異步掛起。調(diào)用DeviceIoControl(handle, FSCTL_REQUEST_BATCH_OPLOCK, ..., ovd)并傳入OVERLAPPED結(jié)構(gòu)后線程會停在GetOverlappedResult上休眠直到文件系統(tǒng)發(fā)出 break 通知才瞬間被喚醒。換句話說攻擊者把 Oplock 當(dāng)成一枚信號槍——Defender 一碰目標(biāo)文件攻擊線程立刻醒來接管戰(zhàn)場。這就是競態(tài)攻擊的精確計時器。 源碼中的三處關(guān)鍵用法按執(zhí)行順序1?? 用 Oplock 凍結(jié) Defender鎖住 VSS 快照FreezeVSS線程FunnyApp.cpp先用 Cloud Files 接口注冊一個同步根目錄然后等待 Defender 進(jìn)程來訪問它系統(tǒng)會通知回調(diào) FunnyApp.cpp。確認(rèn)是 Defender 進(jìn)程后攻擊者才發(fā)出 Oplock 請求DeviceIoControl(hlock, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, ovd); // 異步掛起FunnyApp.cppDefender 一打開這個.lock文件Oplock 就被 break攻擊線程打印WD is frozen and the new VSS can be used.FunnyApp.cpp。此時快照已就緒Defender 被釘在快照創(chuàng)建的那個時間點(diǎn)上。2?? 在 RstrtMgr.dll 上埋一顆監(jiān)聽器TriggerWDForVSFunnyApp.cpp還做了一次 Oplock 請求但目標(biāo)換成了系統(tǒng)目錄下的RstrtMgr.dll重啟管理器組件Defender 恢復(fù)更新流程會加載它。攻擊者以GENERIC_READ | SYNCHRONIZE打開該 DLL 并請求 Batch OplockFunnyApp.cpp隨后寫一個 EICAR 測試文件誘導(dǎo) Defender 開始掃描動作——Oplock break 的時刻就是 Defender 狀態(tài)機(jī)切換的確切時刻攻擊者借此把創(chuàng)建快照、布置劫持這些動作卡在對齊的時間點(diǎn)上。3?? 核心競態(tài)mpasbase.vdm 上的 Oplock 陷阱這是整個漏洞的高潮FunnyApp.cpp攻擊者偽造一個Defender 定義更新目錄通過本地 RPC 端點(diǎn)接口定義見 windefend.idl樁代碼生成在 windefend_c.c誘騙 Defender 去加載更新庫mpasbase.vdm在 Defender 真正讀取之前攻擊者先打開該文件并異步請求Batch Oplock——請求掛起等待DefenderSYSTEM 權(quán)限打開mpasbase.vdm的瞬間Oplock break 觸發(fā)攻擊線程被喚醒就在這條 I/O 流水線暫停的毫秒級窗口里攻擊者在命名對象目錄里種下符號鏈接mpasbase.vdm→ VSS 快照中的\Windows\System32\Config\SAMFunnyApp.cppDefender 的讀請求繼續(xù)執(zhí)行時內(nèi)核按新符號鏈接解析它以為自己讀的是病毒庫實(shí)際讀出來的是 SAM 數(shù)據(jù)庫攻擊者再用CreateFileTransacted事務(wù)句柄扣押這個文件FunnyApp.cpp阻止 VSS 快照回收從容解析出 NTLM 哈希最終改密碼或?yàn)樗杏脩魪棾?shellDoSpawnShellAsAllUsersFunnyApp.cpp。這是一個典型的TOCTOU時間檢查/時間使用競態(tài)系統(tǒng)安全檢查文件路徑的那一刻和 Defender 真正使用文件的那一刻之間攻擊者利用 Oplock 喚醒窗口悄悄替換了路徑指向。?? 為什么這個競態(tài)能贏Batch Oplock 的喚醒是同步點(diǎn)它不靠 sleep 猜時間而是由內(nèi)核在 Defender 發(fā)起打開動作的同一瞬間通知攻擊者窗口對齊精度極高Defender 自身行為是觸發(fā)源更新檢查、簽名加載、EICAR 掃描都是 Defender 的正常動作攻擊只是順勢引導(dǎo)快照 符號鏈接 事務(wù)三件套VSS 提供了繞過獨(dú)占鎖讀系統(tǒng)文件的通道符號鏈接完成目標(biāo)替換事務(wù)保證快照存活每一步都精確銜接。? 修復(fù)與防御啟示微軟已隨 2025 年的 Windows 安全更新修復(fù)該漏洞普通用戶最重要的一條防御就是保持系統(tǒng)補(bǔ)丁和 Defender 定義更新對安全工程師而言這個案例提醒我們?nèi)魏蜗刃ｒ?yàn)路徑、后打開文件的 SYSTEM 級流程都要考慮符號鏈接/對象鏈接劫持 異步 Oplock組合的競態(tài)可能藍(lán)隊(duì)可關(guān)注VSS 快照的創(chuàng)建時機(jī)、ProgramData下 Defender 更新目錄的寫入來源、以及命名對象目錄中異常的符號鏈接對象。 項(xiàng)目文件索引文件作用FunnyApp.cpp攻擊主程序Oplock、VSS、符號鏈接、SAM 解析全在此windefend.idlDefender 本地 RPC 接口的 IDL 定義windefend_c.c / windefend_s.c由 IDL 生成的客戶端樁 / 服務(wù)器骨架offreg.h offreg.lib離線注冊表offreg工具用于直接操作系統(tǒng) hiveFunnyApp.vcxprojVisual Studio 工程文件一句話總結(jié)FSCTL_REQUEST_BATCH_OPLOCK本身是 Windows 合法的緩存協(xié)議調(diào)用但 BlueHammer 把它用成了競態(tài)攻擊的節(jié)拍器——誰先拿到 Oplock 喚醒信號誰就能在 Defender 讀文件的那一瞬間改寫規(guī)則?！久赓M(fèi)下載鏈接】BlueHammerRepository hosting the bluehammer vulnerability項(xiàng)目地址: https://gitcode.com/gh_mirrors/bl/BlueHammer創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 BlueHammer 批處理 Oplock 競態(tài)攻擊：FSCTL_REQUEST_BATCH_OPLOCK 如何凍結(jié) Windows Defender（完整原理指南）
BlueHammer 批處理 Oplock 競態(tài)攻擊FSCTL_REQUEST_BATCH_OPLOCK 如何凍結(jié) Windows Defender完整原理指南【免費(fèi)下載鏈接】BlueHammerRepository hosting the bluehammer vulnerability項(xiàng)目地址: https://gitcode.com/gh_mirrors/bl/BlueHammerBlueHammer 是針對 Windows DefenderWinDefend服務(wù)的一個本地權(quán)限提升漏洞 PoC倉庫定位是 README.md 所說的 hosting the bluehammer vulnerability。它的核心武器是 Windows 文件系統(tǒng)控制碼FSCTL_REQUEST_BATCH_OPLOCK——一個批處理 Oplock機(jī)會鎖異步請求。本文用通俗的方式講清楚這個 API 在攻擊鏈里扮演時間控制器如何把 Defender 的文件操作精確卡住最終讓攻擊者從系統(tǒng)保護(hù)最嚴(yán)的 VSS 快照里讀走 SAM 賬戶數(shù)據(jù)庫。?? 安全提示本項(xiàng)目是漏洞研究代碼請只在授權(quán)的測試環(huán)境中分析不要在生產(chǎn)機(jī)器上運(yùn)行。 一分鐘看懂 BlueHammer 做了什么整個攻擊可以拆成 4 步步驟動作用到的武器1等待 Defender 簽名更新窗口輪詢更新接口2凍結(jié) Defender制造一個可用的 VSS 卷影快照Batch Oplock Cloud Files 回調(diào)3用符號鏈接劫持 Defender 的讀請求Batch Oplock制造競態(tài)窗口4從 VSS 快照讀走 SAM、解析哈希、改密碼事務(wù)文件CreateFileTransactedOplock 是貫穿第 2、3 步的關(guān)鍵。下面先看它是什么。 什么是 Oplock為什么偏偏選 Batch 類型Oplock機(jī)會鎖是 NTFS 的緩存一致性協(xié)議一個進(jìn)程頻繁讀文件時可以申請獨(dú)占緩存權(quán)其他進(jìn)程再來碰這個文件時系統(tǒng)會先通知break持鎖者保證數(shù)據(jù)不臟。Windows 提供幾種 Oplock 強(qiáng)度BlueHammer 選的是最弱的Batch類型語義什么時候被打破Batch批處理最寬松我有讀緩存權(quán)只要別的進(jìn)程打開該文件哪怕只讀就 breakLevel-II無其他進(jìn)程打開時授予別的進(jìn)程以寫方式打開時 breakExclusive獨(dú)占完全獨(dú)占任何新打開都 breakBatch Oplock 對攻擊者最有價值的特性是請求可以異步掛起。調(diào)用DeviceIoControl(handle, FSCTL_REQUEST_BATCH_OPLOCK, ..., ovd)并傳入OVERLAPPED結(jié)構(gòu)后線程會停在GetOverlappedResult上休眠直到文件系統(tǒng)發(fā)出 break 通知才瞬間被喚醒。換句話說攻擊者把 Oplock 當(dāng)成一枚信號槍——Defender 一碰目標(biāo)文件攻擊線程立刻醒來接管戰(zhàn)場。這就是競態(tài)攻擊的精確計時器。 源碼中的三處關(guān)鍵用法按執(zhí)行順序1?? 用 Oplock 凍結(jié) Defender鎖住 VSS 快照FreezeVSS線程FunnyApp.cpp先用 Cloud Files 接口注冊一個同步根目錄然后等待 Defender 進(jìn)程來訪問它系統(tǒng)會通知回調(diào) FunnyApp.cpp。確認(rèn)是 Defender 進(jìn)程后攻擊者才發(fā)出 Oplock 請求DeviceIoControl(hlock, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, ovd); // 異步掛起FunnyApp.cppDefender 一打開這個.lock文件Oplock 就被 break攻擊線程打印WD is frozen and the new VSS can be used.FunnyApp.cpp。此時快照已就緒Defender 被釘在快照創(chuàng)建的那個時間點(diǎn)上。2?? 在 RstrtMgr.dll 上埋一顆監(jiān)聽器TriggerWDForVSFunnyApp.cpp還做了一次 Oplock 請求但目標(biāo)換成了系統(tǒng)目錄下的RstrtMgr.dll重啟管理器組件Defender 恢復(fù)更新流程會加載它。攻擊者以GENERIC_READ | SYNCHRONIZE打開該 DLL 并請求 Batch OplockFunnyApp.cpp隨后寫一個 EICAR 測試文件誘導(dǎo) Defender 開始掃描動作——Oplock break 的時刻就是 Defender 狀態(tài)機(jī)切換的確切時刻攻擊者借此把創(chuàng)建快照、布置劫持這些動作卡在對齊的時間點(diǎn)上。3?? 核心競態(tài)mpasbase.vdm 上的 Oplock 陷阱這是整個漏洞的高潮FunnyApp.cpp攻擊者偽造一個Defender 定義更新目錄通過本地 RPC 端點(diǎn)接口定義見 windefend.idl樁代碼生成在 windefend_c.c誘騙 Defender 去加載更新庫mpasbase.vdm在 Defender 真正讀取之前攻擊者先打開該文件并異步請求Batch Oplock——請求掛起等待DefenderSYSTEM 權(quán)限打開mpasbase.vdm的瞬間Oplock break 觸發(fā)攻擊線程被喚醒就在這條 I/O 流水線暫停的毫秒級窗口里攻擊者在命名對象目錄里種下符號鏈接mpasbase.vdm→ VSS 快照中的\Windows\System32\Config\SAMFunnyApp.cppDefender 的讀請求繼續(xù)執(zhí)行時內(nèi)核按新符號鏈接解析它以為自己讀的是病毒庫實(shí)際讀出來的是 SAM 數(shù)據(jù)庫攻擊者再用CreateFileTransacted事務(wù)句柄扣押這個文件FunnyApp.cpp阻止 VSS 快照回收從容解析出 NTLM 哈希最終改密碼或?yàn)樗杏脩魪棾?shellDoSpawnShellAsAllUsersFunnyApp.cpp。這是一個典型的TOCTOU時間檢查/時間使用競態(tài)系統(tǒng)安全檢查文件路徑的那一刻和 Defender 真正使用文件的那一刻之間攻擊者利用 Oplock 喚醒窗口悄悄替換了路徑指向。?? 為什么這個競態(tài)能贏Batch Oplock 的喚醒是同步點(diǎn)它不靠 sleep 猜時間而是由內(nèi)核在 Defender 發(fā)起打開動作的同一瞬間通知攻擊者窗口對齊精度極高Defender 自身行為是觸發(fā)源更新檢查、簽名加載、EICAR 掃描都是 Defender 的正常動作攻擊只是順勢引導(dǎo)快照 符號鏈接 事務(wù)三件套VSS 提供了繞過獨(dú)占鎖讀系統(tǒng)文件的通道符號鏈接完成目標(biāo)替換事務(wù)保證快照存活每一步都精確銜接。? 修復(fù)與防御啟示微軟已隨 2025 年的 Windows 安全更新修復(fù)該漏洞普通用戶最重要的一條防御就是保持系統(tǒng)補(bǔ)丁和 Defender 定義更新對安全工程師而言這個案例提醒我們?nèi)魏蜗刃ｒ?yàn)路徑、后打開文件的 SYSTEM 級流程都要考慮符號鏈接/對象鏈接劫持 異步 Oplock組合的競態(tài)可能藍(lán)隊(duì)可關(guān)注VSS 快照的創(chuàng)建時機(jī)、ProgramData下 Defender 更新目錄的寫入來源、以及命名對象目錄中異常的符號鏈接對象。 項(xiàng)目文件索引文件作用FunnyApp.cpp攻擊主程序Oplock、VSS、符號鏈接、SAM 解析全在此windefend.idlDefender 本地 RPC 接口的 IDL 定義windefend_c.c / windefend_s.c由 IDL 生成的客戶端樁 / 服務(wù)器骨架offreg.h offreg.lib離線注冊表offreg工具用于直接操作系統(tǒng) hiveFunnyApp.vcxprojVisual Studio 工程文件一句話總結(jié)FSCTL_REQUEST_BATCH_OPLOCK本身是 Windows 合法的緩存協(xié)議調(diào)用但 BlueHammer 把它用成了競態(tài)攻擊的節(jié)拍器——誰先拿到 Oplock 喚醒信號誰就能在 Defender 讀文件的那一瞬間改寫規(guī)則?！久赓M(fèi)下載鏈接】BlueHammerRepository hosting the bluehammer vulnerability項(xiàng)目地址: https://gitcode.com/gh_mirrors/bl/BlueHammer創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考