企业官网建设流程全解析

BlueHammer 批处理 Oplock 竞态攻击：FSCTL_REQUEST_BATCH_OPLOCK 如何冻结 Windows Defender（完整原理指南）

【免费下载链接】BlueHammerRepository hosting the bluehammer vulnerability项目地址: https://gitcode.com/gh_mirrors/bl/BlueHammer

BlueHammer 是针对 Windows Defender（WinDefend）服务的一个本地权限提升漏洞 PoC，仓库定位是 README.md 所说的 "hosting the bluehammer vulnerability"。它的核心武器是 Windows 文件系统控制码FSCTL_REQUEST_BATCH_OPLOCK——一个批处理 Oplock（机会锁）异步请求。本文用通俗的方式讲清楚：这个 API 在攻击链里扮演"时间控制器"，如何把 Defender 的文件操作精确卡住，最终让攻击者从系统保护最严的 VSS 快照里读走 SAM 账户数据库。

⚠️ 安全提示：本项目是漏洞研究代码，请只在授权的测试环境中分析，不要在生产机器上运行。

🔍 一分钟看懂 BlueHammer 做了什么

整个攻击可以拆成 4 步：

Oplock 是贯穿第 2、3 步的关键。下面先看它是什么。

🧩 什么是 Oplock？为什么偏偏选 Batch 类型？

Oplock（机会锁）是 NTFS 的缓存一致性协议：一个进程频繁读文件时，可以"申请独占缓存权"，其他进程再来碰这个文件时，系统会先通知（break）持锁者，保证数据不脏。

Windows 提供几种 Oplock 强度，BlueHammer 选的是最弱的Batch：

Batch Oplock 对攻击者最有价值的特性是：请求可以异步挂起。调用DeviceIoControl(handle, FSCTL_REQUEST_BATCH_OPLOCK, ..., &ovd)并传入OVERLAPPED结构后，线程会停在GetOverlappedResult上"休眠"，直到文件系统发出 break 通知才瞬间被唤醒。

换句话说：攻击者把 Oplock 当成一枚"信号枪"——Defender 一碰目标文件，攻击线程立刻醒来接管战场。这就是"竞态攻击"的精确计时器。

🎯 源码中的三处关键用法（按执行顺序）

1️⃣ 用 Oplock 冻结 Defender，锁住 VSS 快照

FreezeVSS线程（FunnyApp.cpp）先用 Cloud Files 接口注册一个同步根目录，然后等待 Defender 进程来访问它（系统会通知回调 FunnyApp.cpp）。确认是 Defender 进程后，攻击者才发出 Oplock 请求：

DeviceIoControl(hlock, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, &ovd); // 异步挂起

（FunnyApp.cpp）

Defender 一打开这个.lock文件，Oplock 就被 break，攻击线程打印WD is frozen and the new VSS can be used.（FunnyApp.cpp）。此时快照已就绪，Defender 被"钉"在快照创建的那个时间点上。

2️⃣ 在 RstrtMgr.dll 上埋一颗"监听器"

TriggerWDForVS（FunnyApp.cpp）还做了一次 Oplock 请求，但目标换成了系统目录下的RstrtMgr.dll（重启管理器组件，Defender 恢复更新流程会加载它）。攻击者以GENERIC_READ | SYNCHRONIZE打开该 DLL 并请求 Batch Oplock（FunnyApp.cpp），随后写一个 EICAR 测试文件诱导 Defender 开始扫描动作——Oplock break 的时刻，就是 Defender 状态机切换的确切时刻，攻击者借此把"创建快照、布置劫持"这些动作卡在对齐的时间点上。

3️⃣ 核心竞态：mpasbase.vdm 上的 Oplock 陷阱

这是整个漏洞的高潮（FunnyApp.cpp）：

1. 攻击者伪造一个"Defender 定义更新目录"，通过本地 RPC 端点（接口定义见 windefend.idl，桩代码生成在 windefend_c.c）诱骗 Defender 去加载更新库mpasbase.vdm；
2. 在 Defender 真正读取之前，攻击者先打开该文件并异步请求Batch Oplock——请求挂起等待；
3. Defender（SYSTEM 权限）打开mpasbase.vdm的瞬间，Oplock break 触发，攻击线程被唤醒；
4. 就在这条 I/O 流水线暂停的毫秒级窗口里，攻击者在命名对象目录里种下符号链接：mpasbase.vdm→ VSS 快照中的\Windows\System32\Config\SAM（FunnyApp.cpp）；
5. Defender 的读请求继续执行时，内核按新符号链接解析，它以为自己读的是病毒库，实际读出来的是 SAM 数据库；
6. 攻击者再用CreateFileTransacted事务句柄"扣押"这个文件（FunnyApp.cpp），阻止 VSS 快照回收，从容解析出 NTLM 哈希，最终改密码或为所有用户弹出 shell（DoSpawnShellAsAllUsers，FunnyApp.cpp）。

这是一个典型的TOCTOU（时间检查/时间使用）竞态：系统安全检查文件路径的那一刻，和 Defender 真正使用文件的那一刻之间，攻击者利用 Oplock 唤醒窗口悄悄替换了路径指向。

⏱️ 为什么这个竞态能赢？

• Batch Oplock 的唤醒是同步点：它不靠 sleep 猜时间，而是由内核在 Defender 发起打开动作的同一瞬间通知攻击者，窗口对齐精度极高；
• Defender 自身行为是触发源：更新检查、签名加载、EICAR 扫描都是 Defender 的"正常动作"，攻击只是顺势引导；
• 快照 + 符号链接 + 事务三件套：VSS 提供了"绕过独占锁读系统文件"的通道，符号链接完成目标替换，事务保证快照存活，每一步都精确衔接。

🛡️ 修复与防御启示

• 微软已随 2025 年的 Windows 安全更新修复该漏洞，普通用户最重要的一条防御就是保持系统补丁和 Defender 定义更新；
• 对安全工程师而言，这个案例提醒我们：任何"先校验路径、后打开文件"的 SYSTEM 级流程，都要考虑符号链接/对象链接劫持 + 异步 Oplock组合的竞态可能；
• 蓝队可关注：VSS 快照的创建时机、ProgramData下 Defender 更新目录的写入来源、以及命名对象目录中异常的符号链接对象。

📁 项目文件索引

一句话总结：FSCTL_REQUEST_BATCH_OPLOCK本身是 Windows 合法的缓存协议调用，但 BlueHammer 把它用成了竞态攻击的"节拍器"——谁先拿到 Oplock 唤醒信号，谁就能在 Defender 读文件的那一瞬间改写规则。

【免费下载链接】BlueHammerRepository hosting the bluehammer vulnerability项目地址: https://gitcode.com/gh_mirrors/bl/BlueHammer