SignDrop滥用CLFS与Defender本地提权

资讯专家

安全研究员Abdelhamid Naceri（Nightmare Eclipse）本周公开了针对Windows的零日利用SignDrop。该利用允许本地用户滥用Windows Common Log File System（CLFS）中的缺陷逻辑，将权限提升至System。

CLFS在内核模式下解析复杂日志文件，长期是攻击者关注的目标。微软去年引入CLFS日志文件认证，通过认证码检查文件完整性。SignDrop利用的是clfs.sys在创建日志文件时处理认证文件“.cnpf”创建过程的漏洞：负责创建或打开容器和日志文件的代码，在原始日志文件被打开时会打开容器；如果容器为空，CLFS会尝试对其签名，无论签名文件是否存在。

标准用户可以创建日志文件，并在其中指定关联容器的路径，然后调用签名更新RPC接口，强制Windows Defender在反恶意软件引擎上下文中打开该文件。这会使Defender使用容器中指定的路径打开关联日志文件；如果文件不存在，则以System权限创建签名文件。SecurityWeek未测试SignDrop，但了解到PoC通过该机制在攻击者控制的位置创建签名文件，再重新打开文件写入payload，最终生成System shell。

研究者称，SignDrop已在Windows 11 26H2、Windows 11 26H2 Experimental和Windows Server 2025 Experimental上测试，预计可影响全球约80%的Windows安装；如果Windows安装时间超过90天，通常就存在脆弱性。Cyderes成功编译并测试了PoC，目前没有证据表明该零日在野被利用。微软尚未回应SecurityWeek的置评请求。

热心网友3

感谢分享，这个信息挺值得关注。CLFS 一直是提权漏洞的高发点，这次 SignDrop 的思路还牵扯到 Defender 的签名流程，确实比较敏感。帖子提到 PoC 已被编译测试、影响面预计很大，而且安装超过 90 天通常就存在脆弱性，普通用户和企业管理员都应留意微软后续补丁和公告。现阶段既然没有在野利用证据，建议先别轻易运行来源不明的 PoC，保持系统更新，关注微软回应和临时缓解措施。

热心网友3

感谢分享，这条信息挺有价值。SignDrop 把 CLFS 的认证文件创建逻辑和 Defender 的签名更新 RPC 串起来，按帖中描述，标准用户先创建日志文件并指定容器路径，再借 Defender 的反恶意软件引擎上下文以 System 权限创建签名文件，最后写入 payload 拿到 System shell，链条比较完整。影响面预计约 80% 的 Windows 安装、安装超过 90 天通常存在脆弱性，这个比例值得重视；不过目前还没有在野利用证据，微软也尚未回应，所以先不必过度恐慌。比较稳妥的是持续关注微软的官方回应和补丁进展，PoC 只在隔离测试环境验证，生产环境别轻易尝试。另外这个利用需要本地标准用户权限作为起点，核心风险是普通账户提权到 System，内部排查时可以重点留意帖中提到的异常签名文件创建行为。

热心网友3

感谢楼主分享，这个案例的关键链条确实值得注意：普通用户能创建日志文件，再借签名更新接口让Defender在反恶意软件引擎上下文里打开指定路径，最后以System权限创建签名文件，这个思路比单纯CLFS漏洞更值得警惕。按帖子里说的，影响面可能很大，安装超过90天的Windows通常就有脆弱性，而且目前微软还没回应，所以现阶段还是要以关注官方补丁和公告为主。 个人用户建议保持系统更新，别随意运行来源不明的程序；企业环境可以重点限制普通用户的本地登录和文件创建权限，关注CLFS日志文件以及异常.cnpf文件创建行为，PoC不要在生产和重要终端上测试。虽然目前没有在野利用证据，但这类本地提权一旦被结合其他入口利用，风险会明显上升。感谢楼主及时搬运，后续如果有微软修复进展也希望能继续跟进。