文章总结： 该文档分析BlackHatUSA2026议题，指出WSUS应被视为高权限执行平面而非普通补丁服务器。攻击者可诱导上游WSUS机器账户进行NTLM认证并中继到外置SQLServer，利用多个存储过程的组合权限实现更新元数据导入、目标组创建和定向部署。防守方应核查资产、审计SQL会话并监控存储过程调用链。 综合评分： 85 文章分类： 漏洞分析,红队,内网渗透,安全运营

---

Black Hat USA 2026：WSUS后门信任链

原创

Max Luo Max Luo

白帽子罗棋琛

2026年9月4日 08:18 中国香港

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

企业更新服务器如何变成后门工厂：重新审视 WSUS 信任链

Black Hat USA 2026 议题笔记：Turning Enterprise Update Servers Into Backdoor Factories (0_o)

企业通常把 WSUS 视为补丁分发组件，却很少按高权限执行基础设施来建设它。事实上，WSUS 能决定哪些二进制文件进入终端、何时安装、下发给哪一组计算机。它不是普通的文件服务器，而是一条覆盖大量 Windows 主机的受信执行链。

公开课件分析了一条值得防守方关注的路径：攻击者不必先取得完整的 WSUS 管理员权限，也不必直接修改数据库表。如果能够诱导上游 WSUS 服务器进行 NTLM 认证，并把该认证中继到外置 SQL Server，就可能以 WSUS 服务器机器账户建立数据库会话。即使这个账户只有特定存储过程的 EXECUTE 权限，多个“合法能力”串联后仍可能完成更新元数据导入、目标组创建和定向部署。

图 1：议题课件封面，研究对象是企业内部的 WSUS 更新信任链

下面从防守视角拆解这条能力链，并给出可直接用于资产核查、SQL 审计和网络侧检测的实现。涉及攻击链的部分只保留理解检测逻辑所需的细节，不提供中继或恶意更新投递命令。

1、WSUS 应被归类为高权限执行平面

域控制器、证书服务和终端管理平台通常会进入 Tier 0 或关键基础设施清单，WSUS 却常被当成“补丁缓存服务器”。这种分类低估了它的实际权限。

一台受管客户端通过注册表或组策略获得 WSUS 地址，并主动向服务器查询适用更新。服务器从微软同步更新，管理员完成审批和分组，客户端再下载并安装。这里的关键不在“服务器能否远程登录客户端”，而在客户端主动信任服务器提供的更新决策。

图 2：WSUS 客户端由注册表或 GPO 配置，并主动发起更新检查

图 3：WSUS 服务端负责同步、审批和向客户端部署更新

图 4：更新元数据保存在 WID 或外置 SQL Server 中

因此，WSUS 的安全等级至少应与软件分发系统、EDR 管理端和配置管理平台一致。评估范围不能只看 IIS 和 WSUS 管理控制台，还要覆盖：

• 客户端的 WSUS GPO 与注册表配置；
• 上游、下游服务器之间的同步关系；
• SUSDB 使用 WID 还是远程 SQL；
• WSUS 服务器机器账户到数据库的认证方式；
• 更新内容目录、代理和边界防火墙；
• 审批、目标组创建和部署操作的审计记录。

可以先用只读 PowerShell 脚本盘点客户端策略。以下代码不会修改配置，适合作为 EDR 实时响应或配置基线脚本：

powershell

$wuPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'$auPath = Join-Path$wuPath'AU'$wu = Get-ItemProperty-Path$wuPath-ErrorAction SilentlyContinue $au = Get-ItemProperty-Path$auPath-ErrorAction SilentlyContinue  [pscustomobject]@{     ComputerName     = $env:COMPUTERNAME     WUServer         = $wu.WUServer     WUStatusServer   = $wu.WUStatusServer     TargetGroup      = $wu.TargetGroup     TargetGroupOn    = $wu.TargetGroupEnabled     UseWUServer      = $au.UseWUServer     NoAutoUpdate     = $au.NoAutoUpdate     DetectionFreqHrs = $au.DetectionFrequency } | ConvertTo-Json-Depth2

重点查找同一 OU 中指向不同 WSUS 地址、使用明文 HTTP、临时测试服务器残留、TargetGroup 异常变化等情况。资产台账还应明确谁能修改对应 GPO；只保护 WSUS 主机、不保护策略对象，信任链依然不完整。

2、上游、下游与数据库构成了可横向移动的信任图

大型环境通常不会只有一台 WSUS。总部服务器作为上游，分支机构或隔离区服务器作为下游，各自连接客户端并可能使用独立 SUSDB。架构上的同步关系很容易被误解成单纯的数据复制，实际还伴随服务账户、机器账户、SQL 连接和网络放通。

应把它画成“身份访问资源”的图，而不是“服务器连接服务器”的拓扑：

text

上游 WSUS 机器账户   ├─ 可向下游发起哪些协议连接？   ├─ 可向哪台 SQL Server 发起 Windows 集成认证？   └─ 在 SUSDB 中属于哪个角色、可执行哪些存储过程？  下游 WSUS 机器账户   ├─ 能否访问上游内容目录？   ├─ 是否与其他管理系统共用服务账户？   └─ 客户端信任范围覆盖哪些安全域？

风险往往出现在跨层连接：例如 WSUS 位于管理网，外置数据库位于共享 SQL 区，防火墙允许 WSUS 到 SQL Server 的 1433/TCP，同时管理网中的 SMB 出站未受限制。一旦 WSUS 机器账户的认证可以被诱导并跨协议中继，“只允许受信服务器访问数据库”就不等于“只有受信进程能够使用该身份”。

网络策略应按精确的源、目的和协议配置，而不是给整段管理网放行。下面是厂商无关的策略示意：

yaml

policy:wsus-database-segmentationallow:-source:wsus-prod-01destination:susdb-prod-01protocol:tcpport:1433-source:sql-admin-jump-hostsdestination:susdb-prod-01protocol:tcpport:1433deny:-source:wsus-serversdestination:any-nonapproved-smb-serverprotocol:tcpport:445-source:user-and-application-networksdestination:susdb-prod-01protocol:tcpport:1433log:true

实际落地时不要把 DNS、Kerberos、CRL/OCSP 和备份流量误伤掉，但每一个例外都应能对应到明确的服务依赖和负责人。

3、传统 WSUS 滥用门槛高，不代表新的入口同样困难

既有 WSUS 滥用工具通常围绕管理员已有能力展开。课件把传统路径的主要前提归纳为三项：WSUS 管理员权限、WSUS 文件系统访问，以及满足客户端信任要求的数字签名载荷。

图 5：传统路径同时受管理权限、文件落地和数字签名约束

这三个条件叠加，确实提高了直接利用成本。但安全评估不能由此得出“非管理员无法影响更新”的结论。研究转而提出两个更具体的问题：

1. 上游 WSUS 的机器账户对下游服务器拥有什么权限？
2. 上游 WSUS 的机器账户对 WSUS 数据库拥有什么权限？

第一个问题关注 SMB 到 SMB 的认证中继；第二个问题关注 SMB 到 MSSQL 的跨协议中继。对防守方而言，真正的审计对象不是某个工具名称，而是三个条件是否同时成立：

• 某个高价值服务器能够被远程诱导发起 NTLM 认证；
• 认证目标未强制抵抗中继的通道绑定或扩展保护；
• 被中继身份在目标服务上拥有可组合成高影响操作的权限。

这种分析方法也适用于 AD CS、SCCM/MECM、备份系统和虚拟化管理平台。权限不一定以“本地管理员”出现，服务 API、数据库过程和部署工作流都可能成为能力载体。

4、机器账户中继到 MSSQL，改变的是会话位置而非账户权限

课件给出的关键场景是：攻击者诱导上游 WSUS 发起 SMB 认证，再把 NTLM 认证中继到承载 SUSDB 的 MSSQL 服务。成功后，数据库看到的是上游 WSUS 机器账户建立的 SQL 会话。

图 6：中继成功后，SQL 会话身份仍是上游 WSUS 服务器机器账户

需要准确理解这里的边界：中继不会凭空提升 AD 权限，也不会自动让机器账户变成 sysadmin。它利用的是“目标服务接受了一个攻击者能够实时转发、但无法解密或伪造的认证过程”。后续影响完全取决于该机器账户原本在 SQL Server 和 SUSDB 中被授予了什么能力。

防守上应同时切断认证路径和降低授权结果：

• 在支持的 SQL Server 与客户端组合上启用 Extended Protection for Authentication（EPA）；
• 优先使用 Kerberos，并持续检查 SPN、重复 SPN 和回落到 NTLM 的原因；
• 限制 WSUS 服务器向非必要主机发起 SMB；
• 阻断非 WSUS/管理主机访问 SUSDB 的数据库端口；
• 记录 SQL 登录的认证方案、客户端地址、应用名和登录名；
• 识别机器账户在异常源地址或异常时间建立的会话。

下面的查询用于查看当前连接画像。它是现场核查语句，不应替代持续审计：

sql

SELECT     s.session_id,     s.login_name,     c.auth_scheme,     c.client_net_address,     s.host_name,     s.program_name,     s.login_time FROM sys.dm_exec_sessions AS s JOIN sys.dm_exec_connections AS c   ON c.session_id = s.session_id WHERE s.is_user_process =1AND (       s.login_name LIKE'%$'OR s.program_name LIKE'%Update Services%'   ) ORDERBY s.login_time DESC;

基线中应当同时保留 SQL Server 观察到的源 IP 和身份。若 WSUS-PROD-01$ 的会话来自渗透测试网、普通办公网或未知代理节点，身份本身再“合法”也不能放行。

5、只有 EXECUTE 权限，并不等于只能做低风险操作

研究遇到的第一个数据库阻碍看起来很强：webService 角色不能直接对 WSUS 表执行 SELECT、UPDATE 或 DELETE，只允许执行一组指定的存储过程。

图 7：数据库角色没有表级读写权限，但保留了特定存储过程的执行权限

问题在于，存储过程本来就是 WSUS 服务端完成业务操作的接口。数据库通过拒绝直接 DML 保护内部一致性，同时允许服务调用过程完成“导入更新”“保存 XML 片段”“创建目标组”“部署更新”等动作。单个过程符合最小权限设计，多个过程按正确顺序组合后却可能表达一条完整的高权限业务流程。

这类问题不能只用角色成员关系评估。应建立“身份—过程—副作用—前置条件”的能力清单：

sql

SELECT     USER_NAME(dp.grantee_principal_id) AS database_principal,     dp.permission_name,     dp.state_desc,     OBJECT_SCHEMA_NAME(dp.major_id) AS schema_name,     OBJECT_NAME(dp.major_id) AS object_name FROM sys.database_permissions AS dp WHERE dp.class_desc ='OBJECT_OR_COLUMN'AND dp.permission_name ='EXECUTE'ORDERBY database_principal, schema_name, object_name;

查询结果只是起点。对每个可执行过程还要回答：

• 是否写入更新或目标组相关表；
• 是否接受 URL、文件扩展名、目标计算机或 XML 元数据；
• 是否由签名模块或所有者链提升执行上下文；
• 是否能与同一角色可执行的其他过程组合；
• 正常情况下由哪个服务、以什么顺序、在什么频率调用。

在服务化系统里，“无表级写权限”常被误读成“无状态变更能力”。如果角色能够调用带写副作用的过程，它拥有的是受接口约束的写权限，而不是只读权限。

6、存储过程链把低层数据库能力还原成部署工作流

课件展示的调用链包含 spImportUpdate、spSaveXmlFragment、spSetBatchURL、spGetAllTargetGroups、spCreateTargetGroup、spGetComputerTargetByName 和 spDeployUpdate。它们分别涉及导入父子更新、保存元数据片段、设置批次 URL、获取或创建目标组、定位计算机和部署更新。

图 8：多个合法存储过程可以被编排成创建更新并定向部署的完整链条

这里最值得带回工程实践的不是过程名称，而是“组合权限”概念。权限评审通常逐项看：A 是否危险、B 是否危险、C 是否危险；攻击路径评审则要问 A+B+C 能否形成闭环。

防守侧可以把正常调用建模为有限状态序列。例如：

text

正常同步：保存 XML 片段 → 导入已知更新 → 关联微软同步批次 正常管理：查询目标组 → 查询计算机 → 管理员审批 → 部署更新  高风险组合： 新建目标组 → 查询单台计算机 → 设置异常下载 URL → 立即部署

不建议直接阻断任何单次 spCreateTargetGroup，否则正常运维可能受影响。更可靠的做法是对短时间内的过程序列、调用身份、源地址和参数特征做关联。Extended Events 可以从一小组高价值过程开始：

sql

CREATE EVENT SESSION [WSUS_HighRisk_Procedures] ON SERVER ADD EVENT sqlserver.rpc_completed(     ACTION(         sqlserver.client_app_name,         sqlserver.client_hostname,         sqlserver.client_pid,         sqlserver.database_name,         sqlserver.server_principal_name,         sqlserver.session_id,         sqlserver.sql_text     )     WHERE (         [object_name] = N'spCreateTargetGroup'OR [object_name] = N'spSetBatchURL'OR [object_name] = N'spDeployUpdate'     ) ) ADD TARGET package0.event_file(     SET filename = N'D:\SqlAudit\WSUS_HighRisk_Procedures.xel',         max_file_size =100,         max_rollover_files =20 );  ALTER EVENT SESSION [WSUS_HighRisk_Procedures] ON SERVER STATE =START;

事件文件目录必须预先创建，并仅允许 SQL Server 服务账户写入、安全平台读取。不同 SQL Server 版本的事件字段可能有差异，应先在测试库验证，不要直接复制到生产。若参数中可能含敏感信息，还要控制审计平台的访问和保留周期。

7、数字签名验证的是发布者，不自动验证部署意图

传统路径受到“载荷必须具备可接受数字签名”的限制。公开课件随后讨论了下载障碍和签名验证绕过，并引用了利用微软签名二进制执行其他内容的思路。

图 9：传统滥用通常仍需可接受的签名二进制和 WSUS 内容目录访问

图 10：课件后半部分继续分析客户端签名验证边界

在没有完整复现实验、产品版本和补丁状态的情况下，不宜把课件中的页面概括成“任意未签名文件都能下发”。更稳妥的结论是：数字签名只回答文件由谁签发、签名是否完整；它不回答该文件为何在此时被部署到这台主机，也不保证签名程序的参数和后续加载内容符合企业意图。

因此，防守不能停在 Authenticode 验证。至少还要绑定以下上下文：

• 文件哈希是否属于已批准的微软更新目录；
• 更新 ID、修订号、下载 URL 和内容哈希是否与上游同步记录一致；
• 更新是否经过正常审批人和变更单；
• 目标组是否为长期存在的受管分组；
• 签名二进制是否从 WSUS 内容目录以异常参数启动；
• 安装后是否产生脚本解释器、构建工具或侧载 DLL 等子进程。

客户端可以把 Windows Update 事件、进程创建和文件签名信息关联起来。下面是一条偏行为侧的 Sigma 示例，字段名需要按实际 EDR 映射：

yaml

title:SuspiciousChildProcessSpawnedFromWindowsUpdateContextstatus:experimentallogsource:category:process_creationproduct:windowsdetection:update_parent:ParentImage|endswith:-'\\wuauclt.exe'-'\\MoUsoCoreWorker.exe'-'\\TiWorker.exe'-'\\TrustedInstaller.exe'suspicious_child:Image|endswith:-'\\powershell.exe'-'\\pwsh.exe'-'\\msbuild.exe'-'\\rundll32.exe'-'\\regsvr32.exe'condition:update_parentandsuspicious_childfalsepositives:-Vendorinstallerslegitimatelyinvokingsignedhelperutilitieslevel:high

这条规则不能单独定性。某些更新安装器会合法调用脚本或辅助程序，应结合补丁窗口、父进程命令行、文件来源、目标组变化和 SQL 审计事件判断。

8、检测重点是异常身份、异常过程和异常参数的交集

课件给出的数据库侧建议很具体：监控 spCreateTargetGroups；监控 spSetBatchURL 中以 .txt 或 .esd 结尾的更新文件；监控由非计算机账户执行的 spDeployUpdate。这些信号应组合成检测链，而不是拆成三个互不关联的告警。

图 11：EPA、网络限制和三类高价值存储过程审计是课件给出的核心建议

可以在 SIEM 中建立如下规范化字段：

json

{"event_category":"database_procedure","database":"SUSDB","procedure":"spDeployUpdate","principal":"CORP\\WSUS-PROD-01$","client_ip":"10.20.30.41","client_host":"WSUS-PROD-01","application":"Microsoft SQL Server Native Client","target_group":"Finance-Pilot","update_id":"redacted","observed_at":"2026-08-09T03:21:44Z"}

随后做序列关联：

sql

SELECT     principal,     client_ip,     MIN(observed_at) AS first_seen,     MAX(observed_at) AS last_seen,     COUNT(DISTINCTprocedure) AS procedure_count FROM siem_database_procedure WHERE database_name ='SUSDB'AND observed_at >=CURRENT_TIMESTAMP-INTERVAL'15'MINUTEANDprocedureIN (       'spCreateTargetGroup',       'spSetBatchURL',       'spDeployUpdate'   ) GROUPBY principal, client_ip HAVINGCOUNT(DISTINCTprocedure) >=2;

查询语法需按具体平台调整。生产规则建议至少加入以下增强条件：

• principal 与 client_ip 的历史映射不一致；
• 机器账户登录却来自非 WSUS 主机；
• 人员账户或服务账户直接调用 spDeployUpdate；
• 新目标组创建后数分钟内仅加入一台高价值终端；
• spSetBatchURL 指向非批准域名、IP Literal 或异常扩展名；
• 部署发生在补丁窗口之外，且没有对应变更单；
• 同期出现 WSUS 主机对陌生 SMB 目标的出站认证。

网络侧还应为 NTLM 中继前置条件建规则：WSUS 服务器向从未通信的 445/TCP 目标发起连接，随后 SUSDB 收到同一机器账户的 NTLM 登录，而数据库连接的源地址又不是登记的 WSUS 地址。这种跨数据源关联比单看 NTLM 事件更有判别力。

9、加固顺序：先堵认证中继，再收紧业务能力

如果只能按优先级分阶段整改，建议使用下面的顺序。

第一层是认证完整性：

• 对 SUSDB 连接评估并启用 EPA，验证客户端兼容性；
• 修正 MSSQL SPN，减少因 Kerberos 配置错误导致的 NTLM 回落；
• 在域策略和主机策略中审计 NTLM 使用，再逐步限制；
• 关闭不需要的认证诱导面，修复相关服务配置；
• 不允许 WSUS 服务器向任意终端或服务器发起 SMB。

第二层是网络约束：

• SUSDB 只接受登记 WSUS 节点和管理跳板机的连接；
• WSUS 管理端口只向专用运维区开放；
• 上游与下游之间只开放文档化的同步协议；
• WSUS 内容目录不通过普通共享暴露；
• 防火墙保留允许和拒绝日志，并进入 SIEM。

第三层是业务授权与变更控制：

• 分离 WSUS 管理、数据库管理和 GPO 管理角色；
• 定期导出并复核 SUSDB 的数据库角色和过程执行权限；
• 对目标组创建、更新审批和紧急部署设置双人复核；
• 不让日常人员账户直接使用 WSUS 服务身份；
• 对更新目录做完整性监控，文件变更关联审批记录。

第四层是客户端约束：

• 统一通过 GPO 下发 WSUS 地址，监控策略漂移；
• 优先使用 TLS 保护客户端与 WSUS 的通信，并正确管理证书；
• 对 Windows Update 产生的异常子进程进行 EDR 监控；
• 对高价值服务器使用更小、更稳定的目标组；
• 保留 Windows Update、BITS、安装器和代码完整性日志。

加固后应进行回归验证。不要只确认“SQL 登录失败”，还要确认正常同步、审批和补丁安装不受影响，并核对是否出现悄然回落到另一条弱认证路径。

10、把更新链审计变成可重复的工程流程

这份材料最重要的提醒，是不要用单点权限判断一条管理链是否安全。机器账户不是天然可信来源，EXECUTE 不是只读权限，签名二进制也不是天然符合部署意图。真正的安全边界由认证协议、网络位置、数据库过程、更新元数据、审批流程和客户端执行上下文共同组成。

可以按季度执行一次最小审计闭环：

1. 导出全部 WSUS 节点、上下游关系、SUSDB 位置和受管客户端范围；
2. 验证 SQL 连接实际使用 Kerberos 还是 NTLM，检查 EPA 状态；
3. 从数据库枚举 WSUS 身份可执行的存储过程，并记录其副作用；
4. 回放正常同步和审批流程，建立过程调用顺序与频率基线；
5. 测试异常源 IP、非计算机账户和异常 URL 能否触发告警；
6. 在测试目标组完成一次合法更新，验证端到端日志关联；
7. 检查 WSUS 服务器的 SMB 出站和 SUSDB 入站白名单；
8. 抽查客户端 GPO、更新源、更新事件与进程树是否一致。

验收标准也应可计算：高风险过程审计覆盖率为 100%，WSUS—SUSDB 连接源与台账完全匹配，未解释的 NTLM 登录为 0，目标组与审批记录关联率为 100%，异常部署演练能够在一个补丁周期内被检测和处置。

原始资料：

• Black Hat 官方 Session 页面

公开材料没有替代特定版本环境中的验证。WSUS、SQL Server、Windows 客户端和认证策略的组合差异很大，整改前应在隔离实验环境复现正常业务路径；生产检测则优先从只读盘点和审计开始，逐步提升阻断强度。

原始会议材料（仓库内）

• 演讲课件 PDF

开源资料与原始议题 PDF

本文对应的 Markdown 原稿、Black Hat 原始议题 PDF 与配图已整理到 GitHub，可按文章编号查找和下载。

https://github.com/cybermaxluo/black-hat-usa-2026-talks

也可以点击文末“阅读原文”进入仓库。欢迎 Star、提交 Issue 或参与勘误。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：白帽子罗棋琛 Max Luo Max Luo《Black Hat USA 2026：WSUS后门信任链》