MotW机制失效的深层原因是什么?

MotW（Mark of the Web）机制失效，表面看是一次补丁遗漏或校验缺陷，深层原因却指向这套安全设计在架构层面的结构性弱点。CVE-2026-96951 的触发路径很典型：攻击者构造特殊文件，通过邮件或即时通讯工具投递，当用户打开或调用时，Zone.Identifier 这个 NTFS 交换数据流里的安全标记没有正常传递或生效。问题不在标记本身，而在标记的传递链条上——Windows shell 在处理命令与特定元素时出现了校验缺陷，让攻击者有机会让文件在“无标记”状态下被系统处理。

这套机制的根本矛盾在于，MotW 本质上依赖“文件来源”这一元数据来建立信任边界，而元数据是可以被剥离、伪造或绕过的。它不像代码签名那样基于密码学强校验，只是一个附加在文件流上的属性。一旦某个处理环节没有严格遵循“先读标记、再决定策略”的顺序，攻击者就能找到缝隙。CVE-2026-96951 关联的 CWE-77（命令注入类问题）恰好说明，问题出在 shell 解析命令参数时的过滤逻辑上——不是标记丢失，而是标记被“无视”了。

更深一层看，这类漏洞的反复出现暴露了 MotW 机制的信任模型过于单一。它把安全决策押注在“文件是否来自互联网”这一个维度上，却没有充分考虑文件在传输、解压、重命名、容器嵌套等过程中的标记传播问题。攻击者利用的正是这种传播链上的断裂点：畸形快捷方式、嵌套压缩包、包含命令引用的脚本，都可能成为标记失效的载体。安全团队在排查时关注邮件网关里的嵌套压缩包和畸形文件，正是针对这一薄弱环节的补位。

对防御方而言，认清 MotW 的局限性比追逐单个补丁更重要。它应该被定位为“降低攻击面”的辅助层，而不是“阻断攻击”的边界。真正的安全基线仍要落在纵深防御上：网关层的文件解包检测、终端上对未签名可执行文件的启动限制、SmartScreen 的强制检查策略，这些措施组合起来才能弥补 MotW 单点失效带来的缺口。CVE-2026-96951 被 CISA 纳入 KEV 目录并确认在野利用，意味着这不是理论风险，而是已被实战验证的攻击路径。修复优先级上，外网接入、频繁收发邮件的办公终端和暴露远程桌面的管理节点应当最先处理，核心业务服务器则在窗口期内完成累积更新重启。对于暂时无法打补丁的系统，用组策略限制未签名文件启动、强化网关拦截，是当前最务实的临时缓解手段。