BeyondTrust 远程支持零日漏洞 CVE-2026-102764 遭在野利用：直取密凭据库的远程运维设备如何排查与加固

事件概述：一颗被提前用了一个半月的零日

2026 年 10 月 15 日，BeyondTrust 发布安全公告 BT26-05，披露其远程支持产品 Remote Support（原 Bomgar）存在一个严重漏洞 CVE-2026-102764。问题出在产品的内部消息组件：组件没有充分校验接收到的消息来源，在特定条件下，远程攻击者可以在这台设备上执行文件操作。公告按 CVSS v4.0 评定为 9.3 分（Critical），NVD 则按 CVSS 3.1 给出 9.8 分，属于无需认证、无需用户交互即可利用的高危缺陷。

真正让这起事件升级的是时间线：攻击者从 8 月 29 日就开始利用这个当时还没有补丁的零日，先后打进了 BeyondTrust 托管的一台实例和一台客户自托管设备。9 月 28 日厂商威胁狩猎团队发现托管实例并在 27 分钟内完成遏制，9 月 30 日 Mandiant 确认了自托管侧的失陷，10 月 8 日补丁发布，10 月 15 日协同披露，10 月 16 日被 CISA 列入在野利用（KEV）目录，联邦机构处置期限为 10 月 19 日。

影响范围：哪些版本和设备需要处理

根据官方公告，受影响的版本为 Remote Support 26.2.3 及更早的全部版本；修复补丁为 BT26-05-RS，覆盖 24.3.1 到 26.2.3 版本区间，低于 24.3.1 的老版本必须先升级到受支持版本才能打上补丁。SaaS 客户已在 10 月 9 日前由厂商自动完成修补。

另一个容易被忽略的点是：BeyondTrust 的特权远程访问产品 Privileged Remote Access（PRA）与受影响组件共用代码。厂商自测未找到 PRA 上的利用路径，但出于谨慎同样发布了补丁，并建议自托管 PRA 客户立即安装。

为什么这台"远程运维入口"被盯上

Remote Support 这类产品是 IT 部门和帮助台用来远程连接、修复终端设备的运维入口，它本身保存并代理大量特权凭据——服务器口令、API 密钥、终端凭据。攻破一台这样的设备，等于拿到了通往企业内部大量设备的"钥匙串"，这也是 Mandiant 明确将其后果描述为"可通向主机级控制，并触达设备存储或代理的每一份凭据"的原因。

Google 威胁情报团队与 Mandiant 把此次利用活动归因为 ARMORY CASTLE（此前的跟踪编号 UNC5221），一个疑似具有中国背景间谍动机的攻击集群，长期专打边界设备和远程运维类产品。厂商同时提醒：该集群惯于"零日选择性打击、公开后大规模收割未修补实例"，并且"一次入侵的失陷指标很少在下次重复出现"——这意味着靠封 IP、查哈希的传统方式效果有限，必须转向行为狩猎。

攻击者进去之后做了什么

根据 Mandiant 的披露，攻击链的后续动作指向性很强：提权到 root 后，尝试从设备自带的密凭据库中抽取口令、API 密钥与终端凭据；部署名为 BARECLAW 的 C 语言 SOCKS5 隧道工具（以 ingredi_ws 进程运行，通过 WebSocket 传输，监听 19800 端口，并改写 haproxy.conf 让隧道借正常 Web 端口可达）进入内网；篡改配置模板让站点服务账号获得免密 root；修改 Jump Item 与 Teams 权限；窃取内部文档与资产清单；最后删除系统、Web 服务器和应用日志。

早期载荷中还包括一个混淆的 PHP WebShell（SAWFLY，常见文件名 mangoapi.php，使用 Base32 加 RC4 的加密方式，不带特定参数时返回 404 掩盖自身）。另有一个细节值得所有安全团队警醒：BeyondTrust 的传感器其实在攻击者提权时触发过告警，但被第三方检测平台上的自动化分诊工具误判为假阳性而关闭——告警自动化不等于告警消失。

排查思路：指标会变，行为不会

截至披露时没有公开的概念验证代码，厂商也在客户打补丁前暂缓公开技术细节。对已经暴露在互联网上的自托管实例，Mandiant 的建议很直接：窗口期内运行受影响版本的设备，在复核完成前都应视为已失陷。排查时建议以行为为中心：

1. 登录每台自托管设备的 /appliance 界面，确认当前版本、是否已安装 BT26-05 补丁、是否订阅了自动更新；低于 24.3.1 的实例补丁装不上，需要先升级。

2. 日志回溯到 8 月 29 日：查找来自住宅宽带或商业 VPN、无法关联到已知管理员或工单的特权会话；Web 目录中不认识的脚本文件；Web 服务账号派生的 shell；未授权的账号、权限与会话策略变更（尤其是 Jump Item 与 Teams）。

3. 关注日志转发在同一会话内开始又结束的"断档"——攻击者会删本地日志，设备外的 syslog 和 SIEM 副本往往才是唯一可靠的记录。这也是为什么日志外发要做在平时，而不是出事之后再补。

修复与加固建议

1. 打补丁：24.3.1 及以上版本的自托管 Remote Support 立即应用 BT26-05-RS；自托管 PRA 同样建议安装对应补丁；低于 24.3.1 的实例先升级再修补。升级和重启前请按各自流程做好配置备份，并在维护窗口内验证业务会话恢复情况。

2. 收敛暴露面：管理界面限制在可信网络内访问，只开放最终用户和客户必须访问的端口；按需限制设备的外联目标。

3. 日志外发：把设备 syslog 与会话事件近实时转发到集中日志或 SIEM，确保本地日志被删后仍有据可查。

4. 怀疑失陷时的处置：先对设备做镜像留存证据，再用干净镜像重建，不要试图在原机器上"擦干净"；设备打过补丁或重建之后，再轮换它存储、注入过的全部凭据，并持续关注这些账号在受管会话之外的登录情况、特权账号上新增的 MFA 注册。客户可通过 trust portal 申请厂商针对该集群的威胁狩猎包，Mandiant 也已公开相关工具哈希与 YARA 规则。需要支持时可提交 Sev 1 工单并注明 "BT26-05"。

后续观察

这个案例再次说明，远程支持和特权访问类产品正在成为攻击者的重点目标——它们既是运维效率工具，也是凭据汇聚点。接下来值得关注三件事：厂商是否公开更多技术细节、已修补实例之外是否出现大规模扫描和利用尝试、以及 KEV 清单中同类"远程运维入口"产品的后续处置。对运维团队来说，把这类设备的版本、暴露面和日志外发纳入日常巡检，比出事后的应急响应要划算得多。

本文信息来自 BeyondTrust 官方公告 BT26-05、Mandiant/GTIG 分析、CISA KEV 目录及多家安全媒体披露，具体影响版本与操作步骤请以官方公告为准。