SignDrop：Windows CLFS 权限提升至 SYSTEM

TL;DR

• 一个名为 SignDrop 的公开概念验证滥用 Windows Common Log File System 认证功能，在已修补的 Windows 11 和 Server 2025 上将标准用户变为 SYSTEM。研究人员 MSNightmare 于 2026 年 11 月 10 日发布。
• 受影响的是 CLFS 认证模式为 0 或 1 的 Windows 11 25H2、26H1、26H2 和 Windows Server 2025。公开利用链还需要启用 Windows Defender。
• 没有 CVE、Microsoft 公告或修复。独立测试确认该利用可用，但可靠性不足以用于实际运营。未报告攻击，截至 2026 年 11 月 13 日不在 CISA KEV 中。
• 不要为规避它而禁用 CLFS 认证：模式 2 或 3 会重新打开该缓解措施本应阻止的内存破坏缺陷。保持缓解开启，限制本地标准用户访问，并关注 Microsoft 是否发布公告。参见“如何修复？”。

我受影响吗？

以下条件全部成立时，你会受到影响：

• 设备运行 Windows 11 25H2、26H1 或 26H2，或 Windows Server 2025。研究人员测试了 Windows 11 26H2、26H2 实验版本和 Windows Server 2025 实验版本。
• CLFS 认证模式为 0（强制）或 1（学习）。Microsoft 默认启用该缓解措施，并在 90 天后将系统从学习切换到强制，因此两种模式都在范围内。
• 已启用 Windows Defender。公开利用链会强制 Defender 更新引擎打开攻击者准备的日志。
• 本地标准用户可以在设备上运行代码。该缺陷是本地权限提升，不是远程攻击。

较旧的 Windows 版本没有 CLFS 认证功能，因此 SignDrop 路径不适用。它们的 CLFS 驱动仍解析日志文件，而该缓解措施本应阻止的内存破坏缺陷仍是单独风险。

读取设备上的 CLFS 认证模式：

reg query "HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" /v Mode

PowerShell 读取相同的值：

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication' -Name Mode

Mode 为 0 或 1 属于研究人员声称的范围。Mode 为 2 表示管理员禁用了缓解措施，3 表示系统禁用了它。这两个值都不会让设备安全：它们都允许 CLFS 解析被篡改的日志，也就是该缓解措施本应减少的内存破坏暴露。

用 winver 或以下命令检查 Windows 构建：

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

如何修复？

没有修复。Microsoft 未分配 CVE、未发布公告、也未提供补丁，2026 年 11 月的安全更新也没有处理 SignDrop。

1. 保持 CLFS 认证启用。将 Mode 保留为 0 或 1。不要为了规避此缺陷而设为 2 或 3，因为那会重新打开 CLFS 内存破坏路径。
2. 将本地登录和标准用户账户限制为需要的人。公开链从标准用户会话开始。
3. 关注 Microsoft Security Update Guide 和 CLFS 认证支持文章，以获取 CVE、公告或修改后的缓解措施。
4. 在标准用户可以运行代码的设备上执行“如何检查是否已遭入侵？”中的检查。

没有经过验证的变通方法能在保持缓解开启的同时阻止公开链。Windows Defender 的篡改防护在公开路径中没有帮助，因为该链要求 Defender 自己的特权进程创建文件。消除本地代码执行，例如将不可信用户移到远程会话或另一台设备，可以消除前提，但并不总是可行。

Microsoft 的支持文章描述了缓解措施和注册表值。它还警告，禁用缓解措施会让 CLFS 解析未认证的日志，因此该设置必须保持开启。

根本原因是什么？

CLFS 驱动在打开日志的进程上下文中创建日志的认证文件，却给新文件赋予原始日志的权限，因此可以让特权打开者创建一个标准用户可写的 SYSTEM 所有文件。

CLFS 是 Common Log File System，Windows 的内核模式日志子系统。Microsoft 在 2025 年 10 月添加了认证缓解措施。驱动使用存储在注册表中、仅管理员和 SYSTEM 可读的密钥，将基于哈希的消息认证码附加到日志文件。

每个日志可以有一个关联容器和一个保存恢复数据的 .cnpf 伴随文件。根据 Microsoft 文档，伴随文件使用与原始日志相同的安全属性创建。

公开分析描述了打开带有相关容器的日志时发生的情况。驱动也会打开关联容器。如果关联文件为空且其认证文件缺失，CLFS 会创建 .cnpf 文件。

创建在打开日志的进程上下文中运行，因此特权进程以 SYSTEM 创建该文件。新文件继承原始日志的自由访问控制列表，而该列表由标准用户控制。

第二部分是重定向。对象管理器符号链接可以将 .cnpf 路径指向攻击者选择的位置。当特权进程打开日志时，CLFS 跟随链接，在攻击者的路径创建文件，仍以 SYSTEM 身份并仍使用原始日志的权限。

研究人员的示例打开 \CLFS\??\C:\test\t，这会打开 t.blf 及其关联容器。

Microsoft 文档定义了模式值：

• 0：缓解措施强制执行。CLFS 拒绝认证码缺失或无效的日志文件。
• 1：学习模式。CLFS 打开日志文件，并在缺少认证码时写入。
• 2：管理员禁用了缓解措施。
• 3：系统禁用了缓解措施。

模式 0 和 1 是易受攻击的配置，因为两者都会创建认证文件。

如何被利用？

1. 标准用户使用自己控制的路径创建 CLFS 日志和关联容器，并让关联容器为空，使其认证文件缺失。
2. 用户创建对象管理器符号链接，将 .cnpf 创建重定向到自己可达的路径。
3. 用户强制特权进程打开日志。公开概念验证调用 Windows Defender 的更新接口 ServerMpUpdateEngineSignature。
4. CLFS 在特权进程的安全上下文中创建 .cnpf 文件，因此文件归 SYSTEM 所有。新文件继承原始日志的自由访问控制列表，用户可以写入。
5. 用户写入 SYSTEM 创建的文件，并将写入串联到 SYSTEM shell。

公开仓库包含概念验证代码和分析。研究人员在 Windows 11 26H2、Windows 11 26H2 实验版本和 Windows Server 2025 实验版本上测试。仓库称该技术可用于任何以特权进程运行的杀毒引擎；这一更广泛的主张尚未经过独立测试。

The Hacker News 报道的 78researchlab 独立评估发现，该利用可用，但可靠性不足以用于实际运营。运行它会把每个用户账户控制提示变成标准用户 shell 和 SYSTEM shell，使设备前的人容易察觉。

攻击如何展开？

标准用户准备 CLFS 日志和重定向的伴随路径，然后强制 Defender 打开日志，使 CLFS 创建一个用户可写的 SYSTEM 所有文件。

攻击者能做什么？

本地标准用户可以在受影响设备上获得 SYSTEM 权限。这是 Windows 工作站或服务器上的最高本地权限，允许攻击者读取其他用户的数据、更改系统配置、加载驱动并禁用安全软件。

条件也是影响的一部分：

• 攻击者需要标准用户会话，并能在设备上运行代码。
• CLFS 认证模式必须为 0 或 1。
• 公开链需要启用 Windows Defender，因为该链使用 Defender 的更新接口打开日志。
• 公开链是本地权限提升。它本身不提供远程访问，也不会传播到其他设备。

研究人员称该技术可用于任何运行特权进程的杀毒引擎。该主张比公开测试更广泛，后者在特定 Windows 构建上使用 Defender。独立测试确认了在测试构建上的 SYSTEM shell，而不是每种配置都能可靠利用。

为什么修复有效？

没有修复，因此本节描述补丁必须改变什么。完整修复必须阻止特权打开者创建权限不受其控制的文件。

三项更改可以关闭公开路径：

• 在原始日志所有者的安全上下文中创建认证文件，或在创建前重新检查打开者的身份。
• 在特权上下文中创建文件时，不继承日志创建者控制的自由访问控制列表。
• 根据日志目录验证关联容器路径，并拒绝特权创建时的对象管理器重定向。

Microsoft 尚未发布补丁或 CVE。在此之前，保持缓解开启是保留该功能引入时所要提供的保护的控制措施。禁用它等于用本地权限提升换取该缓解措施本应阻止的内存破坏缺陷。

如何检查是否已遭入侵？

没有发布入侵指标，也没有报告攻击。公开利用很明显，因此这些检查寻找它创建的状态。

• 查找意外位置的 .cnpf 文件，尤其是用户可写目录中且归 SYSTEM 所有的文件。伴随文件通常位于其日志旁边。
• 查找从 CLFS 路径指向用户可写位置的对象管理器符号链接。WinObj 或类似查看器可显示 \CLFS 命名空间。
• 检查用户账户控制行为是否改变。公开利用会把 UAC 提示变成标准用户 shell 和 SYSTEM shell。
• 审查意外打开日志文件前后的 Defender 和系统事件，并查找标准用户会话后创建的本地账户或服务。
• 检查设备上是否有意外的 SYSTEM 进程或在维护窗口之外加载的驱动。

失败的尝试可能不留痕迹。如果检查命中，请保留磁盘镜像并重建设备，不要就地清理。

时间线

• 2025-10-28：Microsoft 在 Windows 11 25H2、26H1 和 Windows Server 2025 更新中提供 CLFS 认证缓解措施（KB 5056852）。
• 2026-11-10：MSNightmare 在 GitHub 发布 SignDrop 概念验证和分析。
• 2026-11-12：The Hacker News 报道该缺陷以及 78researchlab 的独立测试，后者认为利用可用但不可靠。
• 2026-11-13：没有 CVE、Microsoft 公告或修复。该缺陷不在 CISA KEV 中。

常见问题

SignDrop 有 CVE 吗？

没有。截至 2026 年 11 月 13 日，Microsoft 未分配 CVE、未发布公告、也未提供修复。研究人员称其为零日，公开仓库是唯一的技术记录。

它影响 Windows 10 吗？

CLFS 认证功能存在于 Windows 11 25H2、26H1、26H2 和 Windows Server 2025。较旧版本没有该功能，因此 SignDrop 路径不适用。它们的 CLFS 驱动仍有内存破坏缺陷，这是单独风险。

可以远程利用吗？

不能。公开链从设备上的标准用户会话开始，需要本地代码执行。它是本地权限提升，不是远程代码执行缺陷。

我应该禁用 CLFS 认证来防护吗？

不。将模式设为 2 或 3 会禁用缓解措施，让 CLFS 解析被篡改的日志，从而重新打开该功能本应阻止的内存破坏缺陷。请将模式保持为 0 或 1。

Defender 篡改防护能阻止该利用吗？

在公开链中不能。该链要求 Defender 自己的更新接口打开日志，因此文件创建发生在 Defender 的可信进程内。研究人员称这正是该技术能绕过自我防护的原因，独立测试也确认了在测试构建上的 SYSTEM shell。

它已在真实环境中被利用吗？

截至 2026 年 11 月 13 日没有攻击报告。利用是公开的，但独立测试认为它不可靠且容易察觉，CISA KEV 也未列出。

参考文献

• MSNightmare，SignDrop 概念验证和技术分析，2026-11-10 发布：https://github.com/MSNightmare/SignDrop（2026 年 11 月 13 日检查）
• Microsoft，“Common Log File System (CLFS) Authentication Mitigation”，KB 5056852，初始发布日期 2025-10-28，模式值和伴随文件的安全属性：https://support.microsoft.com/en-us/servicing/os/windows/2025/03/common-log-file-system-clfs-authentication-mitigation（2026 年 11 月 13 日检查）
• The Hacker News，“New SignDrop Zero-Day Exploit Turns Windows CLFS Security Feature Into SYSTEM Access”，2026-11-12，利用链、独立测试和受影响构建：https://thehackernews.com/2026/11/new-signdrop-zero-day-exploit-turns.html（2026 年 11 月 13 日检查）
• CISA 已知被利用漏洞目录 JSON 订阅源，2026 年 11 月 13 日检查 SignDrop（未列出）：https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json（2026 年 11 月 13 日检查）
• Microsoft Security Update Guide，2026 年 11 月 13 日检查 SignDrop 的 CVE 或公告（无）：https://msrc.microsoft.com/update-guide（2026 年 11 月 13 日检查）