ShieldCrash：Defender 9月补丁下仍沦陷

导语：意大利安全研究员 YogSoth0 9月8日在 X 平台公布 Windows Defender 0day（未公开漏洞） ShieldCrash 的完整 PoC（Proof of Concept，概念验证利用代码）。这是 Nightmare Eclipse（INFINITE NIGHTMARE）组织继 ShieldBreak（CVE-2026-69414）之后再次锤穿 Defender 的核心防御层——微软修补了 N 处，却独独漏掉了一条。9月补丁下，所有支持 Windows 版本仍可被以 SYSTEM 身份任意读取文件，EDR/Defender 直接变成攻击者的文件读取代理。

---

一、漏洞速览

ShieldCrash 不是新洞，而是老洞补不干净。它的前任 ShieldBreak（盾破，CVE-2026-69414）微软修过一轮，修了 N 处。Nightmare Eclipse 组织回去翻补丁，把修补点逐一绕过，最后在一个微软”压根没当成漏洞”的位置重新构造了一条利用链，9月 Patch Tuesday 之后依然能跑。

按 PoC README 自述：

“Microsoft has failed to properly patch ShieldBreak [CVE-2026-69414], under specific conditions it is still possible to trigger the exact same problem that was caused by ShieldBreak. While Microsoft fixed several things to prevent re-exploiting the issue, they missed a spot where ShieldBreak can still be exploited.”

“This PoC demonstrates an arbitrary file read as SYSTEM with September 2026, all supported windows versions are affected.”

翻译成人话：9月打完补丁的 Windows，全部受影响。作者自己也写了”懒得写完整的 SYSTEM RCE（Remote Code Execution，远程代码执行） PoC，先把骨架发出来”。也就是说现在公开的版本只是任意文件读取，距离 SYSTEM 代码执行就差临门一脚。

---

二、下载

PoC 项目已在 GitHub 公开，按 MIT License 发布，作者署名 INFINITE NIGHTMARE。

GitHub 仓库地址：

https://github.com/MSNightmare/ShieldCrash

目录结构：

文件	大小	用途
ShieldCrash.cpp	52 KB	主 PoC 源码（VC++）
Warden.dll	107 KB	关键 DLL（PE32+ x86-64）
ShieldCrash.vcxproj	7 KB	Visual Studio 项目文件
ShieldCrash.aps	2.5 MB	资源文件
eicar_com.zip	2.4 MB	内置 EICAR（欧洲反病毒研究所测试文件）测试样本
LICENSE	1 KB	MIT License

GitHub 原始仓库：

https://github.com/MSNightmare/ShieldCrash

编译方法：

:: 需要 Visual Studio 2022 + Windows SDK
:: 打开 ShieldCrash.slnx 即可
:: Release | x64 编译
cl ShieldCrash.cpp /link /SUBSYSTEM:CONSOLE

注意：Warden.dll 与 eicar_com.zip 都作为资源内嵌在二进制里，资源 ID 分别是 IDR_DLL1 与 IDR_ZIP1，编译后单文件可独立运行。

---

三、技术原理：让 Defender 自己替你读文件

ShieldCrash 的核心思路异常优雅——它不去碰 Defender 的进程，不去拿 Defender 的 token，而是诱导 Defender 进程自己去读攻击者指定的文件。

3.1 三层桥接

PoC 用三个 API 把任意文件伪装成 Defender 会扫描的合法目标：

1. Cloud Files API（云文件 API）注册占位符根

通过 CfRegisterSyncRoot 在 C:ShieldCrash_ 注册一个云占位符同步根，再用 CfCreatePlaceholders 在里面建一个空的占位文件。这一步让操作系统认为这是一个 OneDrive 之类的云同步目录。

1. symlink（符号链接）桥接到 UNC（通用网络协议路径）

在 PoC 里我们能看到这条关键路径构造：

   std::wstring shlnktarget = L"\??\UNC\localhost\C$\ShieldCrash_" + std::wstring(mainguid);
   std::wstring mnlnktarget = L"\CLFS\??\UNC\localhost\C$\ShieldCrash_" + std::wstring(mainguid);

localhost 的 UNC 路径让 Defender 把这当成”本机网络共享”——这是一种用来绕过 Defender 自身路径检查的经典手法，路径加上 \??UNC 前缀让符号链接在设备对象层生效。

1. CfOpenFileWithOplock（带机会锁打开云占位符）+ CfHydratePlaceholder（填充占位符）

这两步把云占位符”喂饱”——向 Defender 谎报这个文件就是本地真实文件。

3.2 Defender 主动读取：钓鱼的反向利用

关键技巧在于 BERN:stream 这个文件名：

if (!CopyFile(L"C:\Windows\System32\ntdll.dll", 
              std::wstring(workdir + L"\BERN:stream").c_str(), FALSE))
{
    printf("[-] File copy failed.n");
    return 1;
}

PoC 在占位符目录里创建一个名叫 BERN:stream 的文件，先复制一份 ntdll.dll 占位。Defender 扫描到这个文件时，会进入”流式检测”（即流式读取文件内容做深度分析）。这一步相当于 Defender 自己主动去 OpenFile + ReadFile 这个目标文件，调用方身份就是 NT AUTHORITYSYSTEM。

3.3 通过 ReadDirectoryChangesW 收割扫描结果

PoC 启动了一个后台线程 WDStartScan 发起扫描请求，然后开 ReadDirectoryChangesW 监控 TEMPTMP 前缀的新增文件：

wchar_t preffix[] = { L"TEMP\TMP" };
do {
    if (ReadDirectoryChangesW(hmonitor, buff, sizeof(buff), TRUE, 
                              FILE_NOTIFY_CHANGE_FILE_NAME, &retb, NULL, NULL)) {
        FILE_NOTIFY_INFORMATION* fni = (FILE_NOTIFY_INFORMATION*)buff;
        if (fni->Action == FILE_ACTION_ADDED) {
            if (_wcsnicmp(preffix, &fni->FileName[0], ...) == 0) {
                printf("[*] File found : %wsn", &fni->FileName[0]);
                break;
            }
        }
    }
} while (1);

Defender 在 SYSTEM 身份下处理扫描结果时，会在 %TEMP% 下创建 TMP*.tmp 临时文件——这就是被读取文件的”复制结果”，攻击者直接从这些临时文件里读出 SYSTEM 身份下的任意文件内容。

整个流程没有任何权限提升动作、没有 token 窃取、没有进程注入。Defender 是被它自己的扫描逻辑带着走的——这就是这个漏洞最阴险的地方。

---

四、防御与影响

4.1 短期缓解

• 不要把 Defender 当唯一防线：EDR/XDR（端点检测与响应/扩展检测与响应）的双层叠加不能省，特别是云端行为日志
• 监控 Cloud Files API 异常注册：大量 PoC 在 C: 下创建 ShieldCrash_* 目录，明显的 IoC（入侵指标）
• 监控 UNC + localhost 路径访问：内部安全日志应当对 \localhostC$ 的非常规访问报警
• TEMPTMPxxx 文件大小异常：Defender 扫描临时文件不应超过 5MB，异常大小通常意味着被滥用了

4.2 为什么这是 EDR 的系统性问题

ShieldCrash 利用的不是 bug，是 Defender 的设计初衷——它就是为了读用户所有可疑文件。现在这个读取行为被反噬。这种”以子之矛攻子之盾”的思路去年也被 CrowdStrike 的内容更新推送机制坑过一次。EDR 厂商从产品设计第一天起就在和这个悖论博弈，Nightmare Eclipse 这帮人就是专门找这种悖论的。

4.3 系统级提权 RCE 倒计时

PoC 作者明说：”I’m feeling a bit lazy”，所以目前只到任意文件读取这一档。从任意文件读取到 SYSTEM 代码执行，对红队来说就是把 %WINDIR%System32configSAM（Windows 本地账户密码哈希数据库）或 NTDS.dit（域控数据库）这类敏感文件拖下来离线破解——这条路径已经可以做到”破坏性等同域控接管”了。完整的 SYSTEM RCE 估计过两周就会有人接龙发布。

---

五、总结

ShieldCrash 这条利用链的可怕之处不在技术难度，而在它利用的是 Defender 存在的根本目的。当一个安全产品本身被设计成”必须能读取所有文件”时，它就必然成为攻击者的代理人。

Nightmare Eclipse 这次的手法是教科书级别的：微软修补只盖住了其中一个角度，他们从侧面重新撞出一条路。等到 10月 Patch Tuesday 微软出补丁，11月多半会有 ShieldCrack 或者 ShieldBurn 跟进。这条漏洞线会一直演下去。

所以对防御方来说，Defender 不是护身符——它是一个需要被持续监控的特权进程。把它当成审计对象，而不是信任对象。