WSUS 中的远程代码执行漏洞:CVE-2025-59287 的深入分析

最后更新: 12月5 2025
  • CVE-2025-59287 是 WSUS 中的一个严重 RCE 漏洞,它允许通过不安全的反序列化以系统权限远程执行代码。
  • 这些攻击利用在 8530/8531 端口上暴露的 WSUS 实例,使用 PowerShell 进行侦察,并将数据泄露到 webhook.site 等服务。
  • 缓解措施包括应用微软的带外补丁、限制 WSUS 的暴露以及监控 wsusservice.exe 和 w3wp.exe 等进程。
  • 缺乏分段和良好的安全实践会加剧漏洞的影响,并可能影响整个补丁供应链。

WSUS 中的远程代码执行漏洞

最近,WSUS 中发现的远程代码执行 (RCE) 漏洞(编号为 CVE-2025-59287)引起了 IT 部门、公共管理机构以及依赖微软生态系统进行补丁管理的企业的警觉。这并非小漏洞:这是一个不安全的序列化问题,允许未经身份验证的远程攻击者在关键服务器上以系统权限执行代码。

本文将对WSUS 中的 CVE-2025-59287 漏洞进行全面、实用且直接的解释,包括该漏洞的发现过程、第一个补丁为何不足以应对、现实世界中观察到的攻击技术、受影响的系统、应采取的紧急措施,以及如何依靠高级安全工具来检测和应对漏洞利用尝试。

WSUS 中远程代码执行漏洞 (CVE-2025-59287) 的背景和严重性

2025年10月14日,微软发布了例行的月度更新包,其中包含针对Windows Server Update Services (WSUS) 中一个严重远程代码执行 (RCE) 漏洞的部分修复。然而,该初始更新并未完全修复此漏洞,因此微软不得不于10月23日发布紧急带外 (OOB) 更新,专门用于缓解WSUS Web服务中的该漏洞。

紧急更新发布仅数小时后,包括 Palo Alto Networks 旗下 Unit 42 在内的多个研究团队以及其他安全厂商便开始在暴露的 WSUS 服务器上观察到实际的漏洞利用活动。美国网络安全和基础设施安全局 (CISA) 于 10 月 24 日将 CVE-2025-59287 添加到其已知已利用漏洞 (KEV) 目录中,确认这并非理论上的威胁,而是已被恶意攻击者利用的漏洞。

该漏洞的 CVSSv3 评分为 9,8,是严重漏洞的最高评分。它允许未经身份验证的远程攻击者在受影响的 WSUS 服务器上以 SYSTEM 权限执行任意代码,从而有效地将其变成企业网络中的特权入口。由此,攻击者可以大规模部署恶意软件、发起勒索软件攻击、窃取凭据或操纵更新周期。

WSUS是什么?为什么它如此敏感?

Windows Server Update Services (WSUS) 是一个组件,它允许组织集中管理 Microsoft 补丁的下载、审批和分发到客户端计算机的过程。实际上,它负责协调公司 Windows 基础架构的大部分补丁维护工作。

正是由于这种战略性作用,一旦 WSUS 服务器被攻破,就会成为攻击者将攻击扩展到整个网络的理想途径。控制 WSUS 的攻击者可以注入恶意更新、阻止安全补丁、修改部署节奏,或者利用该服务器作为跳板在域内横向移动。

值得注意的是,Windows Server 默认情况下并未启用WSUS 服务器角色。只有已安装并配置此角色的计算机才会面临直接风险。即便如此,像 Cortex Xpanse 这样的平台也已识别出约 5.500 个暴露在互联网上的 WSUS 实例,这让我们得以了解全球潜在攻击面的规模。

CVE-2025-59287 的技术细节:不安全的反序列化和远程代码执行

CVE-2025-59287 的核心问题在于WSUS Web 服务中对不受信任的数据进行不安全的反序列化。简而言之,WSUS 使用 .NET 序列化机制处理某些授权对象(客户端和报告服务中使用的 cookie 和结构),而这些机制无法正确验证反序列化数据的类型和内容。

在已识别的关键点中,与某些 SOAP 请求关联的AuthorizationCookie对象的处理方式尤为突出。当收到针对 WSUS 端点的特制请求时,服务器会尝试使用BinaryFormatter或SoapFormatter解密和反序列化攻击者控制的数据。这两个 .NET 组件多年来都因其在处理不受信任的数据时存在的危险性而臭名昭著。

典型的攻击场景是将恶意请求定向到诸如/ClientWebService/Client.asmx之类的端点或报告服务 (ReportingWebService)。当 WSUS 服务器处理 cookie 或 SOAP 有效负载并执行BinaryFormatter.Deserialize()或等效路由时,攻击者创建的一系列对象将被触发。该对象链利用合法构造函数和特殊方法(例如自定义反序列化器)最终以 WSUS 服务的权限(即系统级权限)执行任意命令。

该漏洞会影响已实施 WSUS 角色的 Windows Server 系统,包括Windows Server 2012、2012 R2、2016、2019、2022(包括 23H2 版本)和 2025。未公开 WSUS 或未启用此角色的服务器不受此特定漏洞的影响,但它们显然可能会受到其他安全问题的影响。

已检测到的攻击的实际范围和攻击者的方法

在CVE-2025-59287 的概念验证 (PoC) 漏洞利用程序发布后,多家厂商开始发现针对可通过互联网访问的 WSUS 实例的自动化扫描和攻击。这些攻击活动通常是更大规模入侵的初始阶段,常被归类为勒索软件攻击前期阶段,其目标是在发起大规模加密攻击之前获取访问权限、建立持久化控制并探索环境。

  如何在不丢失数据的情况下将 MBR 磁盘转换为 GPT 磁盘

在初始访问阶段,攻击者主要关注TCP 端口 8530(HTTP)和 8531(HTTPS),这些端口通常被 WSUS 使用,尽管在某些配置中也会使用端口 80 或 443。攻击者会执行大规模扫描,以识别哪些实例响应为 WSUS 服务器,然后启动旨在利用不安全反序列化漏洞的有效载荷。

一旦攻击者成功在服务器上执行代码,通常会看到cmd.exe 和 powershell.exe进程挂起,这些进程可能位于wsusservice.exe或w3wp.exe(IIS 进程)等进程中。已观察到类似wsusservice.exe → cmd.exe → cmd.exe → powershell.exe或w3wp.exe → cmd.exe → cmd.exe → powershell.exe这样的取证进程链,这强烈表明命令是在 WSUS 服务或其关联的应用程序池的上下文中执行的。

初始攻击载荷通常侧重于收集环境信息,执行诸如`whoami`、`net user /domain`或`ipconfig /all`之类的命令,以快速映射权限、域结构和网络拓扑。利用这些数据,攻击者可以评估潜在的横向移动、高价值目标以及升级入侵的可行性。

在许多案例中,攻击者利用看似无害的服务(例如webhook[.]site )窃取了收集到的信息。他们使用 PowerShell 命令(例如Invoke-WebRequest或curl.exe)将命令输出发送到该服务上的临时 URL,从而轻松验证攻击是否成功,并在不引起过多怀疑的情况下获取有价值的数据。

具体攻击场景和利用链

技术报告指出,CVE-2025-59287 存在几种反复出现的攻击场景。其中一种场景是,攻击者利用漏洞后,通过 IIS 进程 (w3wp.exe) 启动命令提示符,并从中执行 PowerShell 脚本下载两个文件:一个可执行文件(例如dcrsproxy.exe)和一个支持文件(例如rcpkg.db)。这些文件通常用作主要有效载荷和配置或打包组件。

在另一种情况下,攻击者的直接目标是验证权限以及特定环境中是否存在漏洞。为此,攻击者从受感染的进程执行`whoami` 命令,并使用`curl`命令将输出直接路由到 `webhook[.]site` URL 的 HTTP 请求,从而确认其是否拥有 SYSTEM 权限以及服务器是否按预期响应。

已有案例记录了使用内存内数据窃取程序的情况。攻击者不会在命令行留下明显的痕迹,而是执行一段硬编码的 PowerShell 脚本,该脚本会收集接口列表、网络配置、域名信息和其他敏感数据,并隐蔽地将其发送到 Webhook。这使得仅依靠传统的命令或日志分析难以检测。

第四种场景中,攻击者利用DNS信令和msiexec工具。攻击者利用IIS进程,向敌方控制的基础设施发出定向DNS查询,并使用msiexec下载和安装恶意MSI软件包。随后,攻击者收集系统和网络数据,建立持久的C2(命令与控制)通道,以开展长期攻击活动。

所有这些都符合这样一种观点:许多此类入侵都是人为操作的勒索软件攻击的前奏:首先,访问和侦察是自动化的,然后是远程管理工具、凭证窃取,最后,当攻击者知道这样做有利可图时,就会进行加密。

Microsoft 安全更新和 WSUS 的更改

为了解决 CVE-2025-59287 漏洞,微软发布了多个累积更新和服务堆栈更新 (SSU),其中包含了针对操作系统和 WSUS 本身的必要修复。例如,在 Windows Server 2022 中,该修复包含在一个质量更新中,该更新专门针对 WSUS 报告 Web 服务中的远程代码执行 (RCE) 漏洞。

除了十月份发布的补丁之外,微软还发布了一个带外更新 (OOB),强调 WSUS 报告服务中的问题已得到修复,并且该修复也适用于 Windows Server 容器镜像。由于 Windows 容器没有内部维护机制,镜像每月都会重新构建并发布,其中包含新的修复程序,因此必须重新构建基于 Windows Server 的容器镜像才能应用这些补丁。

作为缓解措施的一部分,微软还引入了一项重要的功能变更:WSUS 暂时停止在其报告中显示同步错误详情。移除此功能是为了防止继续利用相同的方法进行不安全的反序列化。虽然这可能会给诊断同步问题带来不便,但在开发永久解决方案期间,这是一项必要的措施。

为了查看更新中包含的具体文件,Microsoft为每个累积更新(例如,更新 5070892)和相应的系统更新 (SSU)(例如, Windows Server 2022 版本 20348.4285 中的KB5066781 )提供了文件列表。这些列表有助于验证补丁是否已正确安装,以及所有 WSUS 依赖项是否已更新。

  如何使用 PowerToys 查看任何应用程序的键盘快捷键

受影响的软件、版本及其与其他漏洞的关系

WSUS RCE 漏洞专门影响已启用并配置 WSUS 角色的 Windows 服务器。受影响的产品包括 Windows Server 2012、2012 R2、2016、2019、2022(包括 23H2)和 2025 等版本,前提是它们充当更新服务器。

虽然 CVE-2025-59287 是 WSUS 的主要关注点,但它并非微软生态系统近期唯一严重的安全问题。在桌面和远程服务层面,还报告了其他远程代码执行漏洞,例如 CVE-2025-30397、CVE-2025-29966 和 CVE-2025-29967,这些漏洞影响范围涵盖了从微软脚本引擎到远程桌面客户端和远程桌面网关的方方面面。

例如,CVE-2025-30397是脚本引擎中的一个混淆漏洞,目前已被积极利用;而CVE-2025-29966和CVE-2025-29967则描述了远程桌面组件中的堆缓冲区溢出漏洞,可能导致远程桌面加密 (RCE) 攻击。这些漏洞影响Windows 10、Windows 11 和 Windows Server 2008 R2 至 2022 版本,以及远程桌面网关服务。

整个事件印证了一个关键观点:微软的攻击面正在不断扩大,且日益复杂。据 BeyondTrust 的《微软漏洞报告》等分析显示,仅一年内,微软产品就报告了超过一千个漏洞。在这种情况下,如果不对 WSUS 进行分段或及时更新补丁,就将其暴露在互联网上,风险实在太大。

潜在影响:供应链、修补和业务连续性

如果攻击者成功利用 CVE-2025-59287 漏洞,其影响不仅限于 WSUS 服务器本身。通过获取系统特权代码执行权限,攻击者可以干扰该 WSUS 服务器管理的所有 Windows 计算机上的更新过程。这包括注入恶意二进制文件、阻止关键补丁的分发或传播篡改后的配置。

这使得漏洞直接成为内部数字供应链的安全问题。客户团队对 WSUS 作为合法更新来源的信任,反而成了攻击者手中的利器。正因如此,许多网络安全机构坚持将这些服务器视为关键资产,而不仅仅是辅助基础设施。

在企业和公共管理环境中,通过 WSUS 发起的入侵可能导致大规模服务中断、文件加密和敏感数据被盗。由于存在公开的概念验证和可重用脚本,利用漏洞进行自动化攻击非常容易,这意味着即使技术资源有限的团队也可以开始搜索存在漏洞的服务器。

此外,将 WSUS 不必要地暴露于互联网或管控不严的网络区域,被认为是一种糟糕的资产隔离和管理实践。原本应是内部服务的存在,却会成为网络上任何位置都可访问的主要攻击目标,从而增加了局部漏洞升级为组织层面系统性安全漏洞的风险。

微软的临时缓解措施和建议

微软和各应急响应团队针对因运营原因无法立即部署 10 月 23 日带外更新的组织发布了一系列临时措施。这些措施并不能替代补丁,但可以通过缩小最直接的攻击面来争取时间。

最有效的建议是禁用受影响计算机上的 WSUS 服务器角色。这样做可以消除攻击途径,但也会削弱服务器管理和分发客户端更新的能力。这是一个较为严厉的措施,适用于在补丁部署完成或迁移到另一台服务器期间可以暂时容忍其影响的环境。

另一项相关的缓解措施是在主机防火墙(或边界防火墙,具体取决于网络设计)上阻止所有流入 TCP 端口 8530 和 8531 的流量。通过切断对常用 WSUS 端口的访问,可以阻断远程攻击途径,但同时也会阻止正常的 WSUS 服务运行。因此,应根据补丁更新周期的紧迫性来评估此措施。

除了上述两项缓解措施外,至关重要的是尽可能限制 WSUS 对互联网的暴露,并将其访问权限从内部网络隔离到必要的网段(例如,特定的客户端子网、管理服务器等)。这样做的目的是,即使将来出现类似的漏洞,也不会存在互联网与 WSUS 之间的直接路径。

微软还坚持认为这些缓解措施是暂时的,最安全的做法是尽快应用相应的安全更新,并验证是否安装了最新的 SSU 和包含最终补丁的 LCU(累积更新)。

威胁检测与防御:XQL、SIEM 和高级工具

在应用补丁和缓解措施的同时,安全团队必须密切关注其环境中是否存在利用 CVE-2025-59287 漏洞的潜在迹象。一些供应商已发布了适用于 EDR、XDR 和 SIEM 平台的即用型查询和规则,用于识别与此漏洞相关的异常行为。

例如,Unit 42 的托管威胁搜索服务分享了一个用于 Cortex XDR 的 XQL 查询,该查询可以筛选 Windows 系统上的进程创建事件,并重点关注源自WSUS 应用程序池中的wsusservice.exe或w3wp.exe 的进程。该查询排除了合法且常用的进程(例如与 BITS 关联的 conhost.exe、vbc.exe、svchost.exe 等),从而专注于可能被可疑触发的 cmd.exe 或 powershell.exe 进程。

  如何使用 PowerToys 在 Windows 11 中保持窗口始终可见

这些规则背后的逻辑简单却有效:WSUS 服务器不应持续启动命令行 shell 或 PowerShell 实例。如果出现这种情况,并且还观察到与 webhook[.]site 等服务、异常域名建立出站连接,或从外部位置下载可执行文件,则应触发警报。

诸如SOC Prime Platform等平台已发布针对 CVE-2025-59287 的特定检测内容,这些内容兼容多种 SIEM、EDR 和数据湖格式,并映射到 MITRE ATT&CK 框架。这些规则包括技术映射(例如,用于攻击面向互联网应用程序的 T1190)、推荐的审计配置、CTI 链接以及其他元数据,以便于将其集成到各种防御环境中。

此外,像Uncoder AI这样的基于人工智能的工具能够将入侵指标 (IOC) 和威胁描述转换为 SIEM 或 XDR 兼容的查询,生成攻击流程图,并在不同平台之间转换内容。以 CVE-2025-59287 为例,这使得防御团队能够从技术报告入手,在极短时间内生成针对其技术栈量身定制的查询。

针对安全产品和事件响应的具体保护措施

多家制造商也已更新其产品,以检测和阻止利用CVE-2025-59287 的尝试。例如,Palo Alto Networks 的高级威胁防御模块集成了威胁防御签名(例如 96657 和 96684),旨在遵循最佳配置实践的情况下阻止与此漏洞相关的恶意流量。

Cortex XDR 和 XSIAM等解决方案通过多层防护方法帮助遏制攻击后的恶意活动:检测异常进程、分析行为、阻止可疑脚本以及自动响应。甚至还发布了针对 CVE-2025-59287 的特定操作手册,可自动执行诸如识别 WSUS 主机、执行 XQL 搜索查询、隔离受感染服务器(需事先获得分析师批准)以及阻止已识别的恶意指标等任务。

如果怀疑系统遭到入侵或发现明显的异常活动,建议联系专业的事件响应团队。像 Unit 42 这样的服务提供商提供针对不同地区(北美、英国、欧洲和中东、亚洲、日本、澳大利亚和印度)的联系电话,以便在情况升级之前提供紧急支持或进行主动风险评估。

在目前已公布的入侵指标中,URL webhook[.]site hxxp://webhook[.]site/22b6b8c8-2e07-4878-a681-b772e569aa6a尤为突出,它被用于某些攻击中以窃取信息或确认攻击是否成功。尽管攻击者可以轻易更改这些标识符,但它仍然是一个值得监控的出站流量日志模式示例。

良好的加固措施和经验教训

除了简单地应用补丁之外,CVE-2025-59287 造成的局面还带来了一些值得吸取的安全教训。首先,将 WSUS 等内部服务不必要地暴露在互联网上是毫无意义的。如果服务器旨在向内部网络上的计算机分发补丁,那么将其限制为仅可从该网络或特定网段访问才是合理的,并且需要通过防火墙和访问控制列表进行保护。

另一点也很重要,那就是糟糕的安全防护措施和缺乏网络分段会将技术漏洞演变成组织灾难。WSUS 故障本身就十分严重,但如果服务器处于高信任位置,可以直接访问大部分基础设施,且没有相应的控制措施来限制横向移动,那么其影响将会成倍增加。

在这方面,建议定期审查资产清单,识别哪些服务处于开放状态,并记录它们在内部供应链中的作用。这样,就更容易根据最小权限原则、功能分段以及在关键节点(例如 WSUS 服务器、域控制器或远程桌面网关)加强监控来实施策略。

最后,必须牢记的是,微软环境不断演变,新的漏洞层出不穷,包括脚本引擎、远程桌面协议 (RDP)、浏览器和服务器组件中的缺陷。优先修复已被实际利用的关键漏洞(例如 CVE-2025-59287),并结合先进的检测和自动化响应能力,如今已成为任何较为成熟的网络安全策略不可或缺的一部分。

WSUS 远程代码执行漏洞的种种迹象表明,一台配置错误或未打补丁的服务器就可能成为危及整个组织的薄弱环节。因此,为了确保安全,必须立即采取措施,包括审查 WSUS 的安全风险、部署安全更新、监控相关进程的活动以及加强网络分段。