企业官网建设流程全解析

终极解析：BlueHammer 的 VSS 卷影复制技巧——FreezeVSS 如何用 HarddiskVolumeShadowCopy 冻结 Defender

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

🔍BlueHammer 是一款研究 Windows Defender 防御机制的开源漏洞 PoC 项目。它的核心看点是FreezeVSS函数：通过监听HarddiskVolumeShadowCopy卷影复制对象，配合云文件同步根与批量 oplock 锁，在 Defender 更新签名前将其"冻结"，从而劫持其签名更新流程。本文将用小白也能懂的方式，完整拆解这套 VSS 卷影复制技巧的实现思路。

一、BlueHammer 是什么？30 秒看懂项目背景

BlueHammer 仓库（见 README.md）自述为 "Repository hosting the bluehammer vulnerability"（托管 bluehammer 漏洞的仓库）。作者以一种调侃的语气写道：

"I'm just really wondering what was the math behind their decision..."

这说明它针对的是 Windows Defender 签名更新流程中的一个设计缺陷：Defender 在应用新引擎签名前会创建卷影副本（VSS），而这个环节可以被攻击者卡住，使 Defender 长时间处于半冻结状态，并被迫从攻击者指定的目录加载签名。

仓库结构非常精简，核心文件一览：

📌 下文聚焦主角：VSS 卷影复制相关的四段代码，全部位于 FunnyApp.cpp 中标注为 "Volume shadow copy functions" 的区块。

二、核心概念：VSS 卷影复制与 HarddiskVolumeShadowCopy 速成

在深入代码前，先补齐两个必备知识点 👇

1️⃣ 什么是 VSS 卷影复制？Windows 的 Volume Shadow Copy Service（卷影复制服务）能在不中断系统运行的前提下，为卷上的文件拍一张"快照"。Defender 更新引擎签名时会先做快照，确保更新失败可以回滚。

2️⃣ HarddiskVolumeShadowCopy 又是什么？每个 VSS 快照在 Windows 内核的设备命名空间中都会注册一个设备对象，名字固定形如：

\Device\HarddiskVolumeShadowCopy0、\Device\HarddiskVolumeShadowCopy1……

也就是说：只要枚举\Device目录，就能实时发现系统里新出现的卷影副本——这正是 BlueHammer 抓住 Defender 更新时机的"雷达"。

三、整体链路：从检查更新到冻结 Defender 的 4 步流程

BlueHammer 的主流程可以概括为一条流水线：

CheckForWDUpdates → GetUpdateFiles → TriggerWDForVS → RPC 调用 ServerMpUpdateEngineSignature (发现新签名) (下载解包) (冻结+等快照) (骗 Defender 加载假签名)

• 第 1 步：检查更新— CheckForWDUpdates() 调用 Windows Update 组件查询是否存在 "Microsoft Defender Antivirus" 分类的 "Definition Updates"，没有就每 30 秒轮询一次。
• 第 2 步：下载解包— GetUpdateFiles() 通过 WinInet 下载 Defender 官方更新包，解析 PE 的.rsrc资源段抽出update.cab，再用 FDI 库解包成签名文件列表。
• 第 3 步：冻结 + 捕获快照— TriggerWDForVS() 是本文主角，内部调度下面两个线程。
• 第 4 步：RPC 劫持— 通过逆向出的私有接口（windefend.idl，UUIDc503f532-443a-4c69-8300-ccd1fbdb3839，接口名IMpService77BDAF73）调用Proc42_ServerMpUpdateEngineSignature，把签名目录指向攻击者构造的路径，Defender 便会加载伪造签名。

下面逐个拆解 VSS 相关的两大技巧。

四、技巧一：用 NtQueryDirectoryObject 监听新的 HarddiskVolumeShadowCopy

💡 目标：一旦 Defender 为更新创建了新快照，立刻拿到它的设备路径。

实现位于 ShadowCopyFinderThread()，思路分三层：

1. 快照"基线"枚举辅助函数 RetrieveCurrentVSSList() 先用NtOpenDirectoryObject打开\Device对象目录，再用NtQueryDirectoryObject遍历其中所有对象，筛选出TypeName为Device且名字以HarddiskVolumeShadowCopy开头（见 第 1093-1098 行）的条目，形成一份"运行前已有快照"的基线链表LLShadowVolumeNames。

2. 轮询发现"新面孔"主循环反复枚举\Device目录，把当前枚举到的HarddiskVolumeShadowCopy*与基线对比（第 1272-1296 行）：

• 名字在基线里出现过 →continue，跳过；
• 出现了基线之外的新名字→ 判定为新创建的快照，拼出完整路径\Device\HarddiskVolumeShadowCopyN，跳出循环。

3. 验证快照可用拿到新路径后追加\Windows子路径，用NtCreateFile尝试打开（第 1323-1336 行），如果返回STATUS_NO_SUCH_DEVICE就重试，直到能成功打开——这说明快照已完成挂载，可以安全使用。

为什么用 NT 原生 API 而不是 Win32？因为HarddiskVolumeShadowCopy对象位于内核对象命名空间，Win32 的卷影 API（如IVssCreateSnapshot）无法直接枚举"谁刚生成了新快照"，只能靠对象目录轮询这种"硬桥硬上"的方式。

五、技巧二：FreezeVSS 如何用云文件同步根冻结 Defender

⭐ 这是 BlueHammer 最精妙的部分——FreezeVSS() 线程（由 第 1723 行 创建）。它的武器不是杀进程，而是让 Defender 主动卡死在文件操作上。

5.1 布下陷阱：注册 Cloud Files 同步根

Defender 引擎（MsMpEng.exe，即 WinDefend 服务进程）在扫描和更新时会对临时目录做目录级访问，而 Windows 的云文件（Cloud Files / CF）框架允许任何程序把目录注册为"同步根"，并在有进程访问时收到回调。FreezeVSS做了如下准备：

1. 以 PoC 自身所在目录为同步根调用CfRegisterSyncRoot，ProviderName填了句大实话L"IHATEMICROSOFT"（第 1473 行）；
2. 创建带FILE_FLAG_DELETE_ON_CLOSE的 GUID 命名锁文件；
3. 通过CfConnectSyncRoot注册CF_CALLBACK_TYPE_FETCH_PLACEHOLDERS回调（第 1533 行）。

5.2 精准识别：只冻结 Defender 进程

回调函数 CfCallbackFetchPlaceHolders() 里有一处关键判断：先用 GetWDPID() 打开服务控制管理器查出WinDefend服务的进程 ID，再与回调上下文里的ProcessInfo->ProcessId比对（第 1388 行）。

• 是 Defender 在访问→ 打印 "Defender flagged."，先等一个"锁文件就绪"事件（见下），再回复一个占位文件（placeholder）并故意挂起回调，让 Defender 的文件操作阻塞在半路；
• 是其他进程→ 回复空占位数组，快速放行，避免误伤系统。

5.3 双锁齐下：批量 oplock 完成"冻结"

在回调等待期间，FreezeVSS主线程对锁文件发起FSCTL_REQUEST_BATCH_OPLOCK异步请求（第 1556 行），拿到ERROR_IO_PENDING后才SetEvent(hnotifylockcreated)唤醒回调。

此时形成一道双重死锁：

• Defender 的目录访问被 CF 回调卡住，回调又在等 oplock 建立；
• 一旦 Defender（或其更新流程）触碰锁文件，批量 oplock 请求会被打破。

等到GetOverlappedResult返回，FreezeVSS打印出标志性语句（第 1570 行）：

"WD is frozen and the new VSS can be used."

随后置位hvssready事件，主线程就知道：Defender 已被冻结，新卷影快照可以安全利用了。

六、技巧三：EICAR 诱饵文件——如何让 Defender 乖乖创建快照

光有雷达和锁还不够，得让 Defender主动开始一次签名更新（它会为更新创建 VSS 快照）。TriggerWDForVS() 用了一个经典诱饵：

1. 写 EICAR 测试文件（第 1620-1665 行）：代码里把标准 EICAR 字符串反着存储，用 rev() 函数运行时还原——既保证功能，又避免静态字符串被扫描器直接命中；
2. 抢占 RstrtMgr.dll 的批量 oplock（第 1668-1693 行）：对%windir%\System32\RstrtMgr.dll独占打开并发起FSCTL_REQUEST_BATCH_OPLOCK，把 oplock 当作"Defender 动了"的信号量；
3. 再开一次 EICAR 文件（第 1696-1698 行）触发 Defender 检测行为，oplock 随之打破，PoC 确认 Defender 已上钩；
4. 确认新快照：等ShadowCopyFinderThread线程返回，拿到新HarddiskVolumeShadowCopy路径；
5. 启动 FreezeVSS，用WaitForMultipleObjects同时等待线程退出和hvssready事件，确保冻结成功才继续（第 1732-1740 行）。

至此，"诱饵 → 快照 → 冻结"三件套闭环完成。

七、配套能力：私有 RPC 接口与离线注册表

VSS 技巧只是前半程，冻结 Defender 后的后半程依赖两个配套模块：

🔌 私有 RPC 接口windefend.idl 是逆向出的 Defender 内部 RPC 接口定义，windefend_h.h 等由 MIDL 生成。PoC 在 CallWD() 中用RpcStringBindingComposeW以ncalrpc方式绑定接口IMpService77BDAF73，调用Proc42_ServerMpUpdateEngineSignature把签名目录替换为\??\GLOBALROOT\Sessions\N\BaseNamedObjects\{GUID}\WDUpdateDirectory这类命名对象符号链接（由 NtCreateSymbolicLinkObject 创建），从而让 Defender 加载攻击者投放的"新签名"。

🗝 离线注册表工具offreg.h + offreg.lib 提供离线注册表访问能力，配合 FunnyApp.cpp 中的 SAM 解析逻辑（bootkey 重排、AES-CBC 解密 LSA 密钥、SAM 库偏移解析），可在获取 VSS 快照后直接对离线系统画像做密码哈希提取——这也是 BlueHammer 选择 VSS 路线的终极目的：卷影副本 = 一个不受内存保护机制约束的离线系统镜像。

八、安全启示：普通用户与运维该如何防范

虽然 BlueHammer 只是研究 PoC（README 中作者还承认 "There are few bugs in the PoC"），但它暴露的弱点值得警惕：

• ✅监控 VSS 异常活动：定期用vssadmin list shadows或审计日志关注非系统组件创建的卷影副本；
• ✅保护 WinDefend 服务与关键 DLL：利用 WDAC/AppLocker 限制对RstrtMgr.dll等系统文件的独占打开与 oplock 抢占；
• ✅审计云文件同步根注册：CfRegisterSyncRoot是合法 API，但恶意进程注册同步根并长期阻塞回调属于异常行为，可通过进程回调检测；
• ✅及时更新 Defender 与系统：本漏洞依赖"Defender 会响应更新并创建快照"这一行为链路，官方修复后链路即失效。

九、相关文件索引

⚠️ 本文为安全研究科普，所有技术细节仅供理解 Windows Defender 防御机制与 VSS 卷影复制原理之用，请勿将相关技术用于非法用途。

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