备份服务器成了勒索软件的入口：AhsayCBS 两个在野利用漏洞该如何排查与修复

事件概述：备份服务器被攻破，两个漏洞组合出未认证远程执行

2026 年 10 月，多家安全厂商披露了一起针对备份服务器的在野攻击事件。攻击者利用 Ahsay 公司 AhsayCBS 备份管理平台的两个漏洞——CVE-2026-105133 与 CVE-2026-105134——在无需任何账号、无需用户交互的情况下，直接远程执行命令，并最终拿到 Windows 系统的 SYSTEM 最高权限。

事件的时间线很紧凑：10 月 4 日两个漏洞在国家漏洞库（NVD）登记，条目明确标注"存在公开利用"；10 月 7 日晚间，安全厂商 Huntress 首次观测到真实攻击，截至 10 月 8 日已发现至少 5 家机构被攻击；10 月 9 日起 Ahsay 陆续接到合作伙伴报告的未授权访问事件；10 月 12 日 Ahsay 发布紧急热修复，并承认此前的补丁（v10.3.4.0 与 v9.15.2.59）并没有完全修复问题；10 月 14 日，美国 CISA 将两个漏洞正式列入"已知在野利用漏洞"（KEV）目录，要求联邦机构在 10 月 17 日前完成修复。

从漏洞披露到被列入 KEV 只用了十天，而从首次被利用到厂商发布有效补丁只用了五天——这个速度本身就说明，公网暴露的备份管理界面正在被攻击者常态化扫描和利用。

影响范围：哪些版本中招，谁会用到它

受影响的是 AhsayCBS 的 v7、v8、v9 和 v10 多个大版本。按照厂商 10 月 12 日的公告，v10 线路需要升级到热修复版本 v10.3.4.45，v7/v8/v9 线路需要应用热修复 v9.15.2.70（v7 和 v8 还需先升级到 v9.15.0.0 基线）。此前安装过 10 月早期补丁的用户要特别注意：v10.3.4.0 和 v9.15.2.59 两个版本已被厂商确认"未完全修复"，装了也不等于安全。

AhsayCBS 是 Ahsay 云备份套件的服务器端管理平台，主要用户是托管服务提供商（MSP）、系统集成商，以及自建集中备份服务器的企业。它的定位很特殊：一边连接着海量备份数据和存储设备，一边管理着众多客户端备份任务。一台失陷的 AhsayCBS，既可能泄露备份内容本身，也可能成为攻击者进入下游客户环境的跳板。

为什么普通用户和运维都要关心：备份是勒索攻击的"最后一厘米"

勒索软件的经典打法从来不是"直接加密"，而是先找到备份系统、删除或加密备份，再对生产环境下手——没有备份，受害者才更可能支付赎金。备份服务器平时远离业务流量、补丁周期长、管理界面又常常为了方便运维而暴露在公网，这些特征叠在一起，使它成为勒索团伙和挖矿木马都偏爱的高价值目标。

本轮攻击中，Huntress 观测到的实际载荷是 XMRig 挖矿程序和 JSP 网页后门，尚未发现勒索软件或数据窃取案例。但这只是攻击者的"第一波收割"：一旦入口被稳定控制，后续投放什么载荷只取决于收益判断。对自建备份服务器的企业来说，把备份管理平台当作和生产系统同等级别的重要资产来对待，不是可选项，而是必选项。

攻击是怎么发生的：无需认证的组合链

两个漏洞的分工很清晰。CVE-2026-105133 是 checkSysPwd 接口的认证缺陷，攻击者可以绕过正常的身份校验，让服务器把一个未经认证的请求当作合法请求处理；CVE-2026-105134 则是 Replication Receiver 组件中的操作系统命令注入，可以把传入的参数直接当作系统命令执行，VulDB 对其给出了 CVSS 10.0 的评分（不同安全机构对两个漏洞的评分口径略有差异，但一致结论是：组合利用后可获得未认证的远程命令执行）。

链条走通之后，攻击行为有清晰的固定模式：先做系统侦察，然后在 AhsayCBS 的 webapps 目录投放随机文件名的 JSP 网页后门获取持久化访问，再投放伪装成 Microsoft Edge 的 XMRig 挖矿程序，并注册一个名为 MicrosoftEdgeUpdateSvc 的假冒 Windows 服务维持驻留，甚至用 Taskgmr.ps1 脚本在用户打开任务管理器时隐藏挖矿界面。整个利用链不需要任何凭据，唯一的前提是：AhsayCBS 的管理界面可以被攻击者访问到。

排查思路：对照官方失陷指标逐项检查

如果你或你的服务商在运行 AhsayCBS，可以按照 Ahsay 10 月 13 日发布的官方指引逐项排查，出现任意一条即应按"已失陷"处理：

一是检查硬盘根目录是否出现同一天批量创建的异常文件夹，例如 ahsay_ts、ahsay_t8、ahsay_t9、ahsay_t20、ahsay_t21、srv、user、opt 等陌生目录；二是检查 AhsayCBS 安装目录下的 webapps 文件夹，是否存在大量随机命名的 .jsp 文件（如 75bc584d292933ad.jsp）或随机字母数字组成的短文件夹；三是检查管理后台是否被添加了未经授权的 RPS 接收端（replication receiver）；四是检查用户列表里是否混入了未经授权、但拥有 Admin 权限的账号；五是检查 Windows 服务列表和进程树中是否有 MicrosoftEdgeUpdateSvc 之类的可疑服务，以及 cbssvcX64.exe 进程下是否派生了异常子进程。

需要提醒的是，排查前建议先留存日志和现场证据，不要在没确认失陷范围前直接清理，否则可能破坏后续溯源。Huntress 也公开了 4 条 Sigma 检测规则，有 SIEM 或日志平台的运维团队可以直接参考使用。

修复与缓解建议：打补丁、收暴露面、失陷就重建

针对不同状态，建议按以下顺序处理：

尚未中招的服务器，第一件事是从合作伙伴门户获取对应线路的热修复（v10 用 v10.3.4.45，v7/v8/v9 用 v9.15.2.70，v7/v8 先升级 v9.15.0.0），安装完成后按厂商要求重启服务器，并在管理界面确认当前构建号确实已升级——早期补丁不修复问题是本次事件最大的教训，只"装过补丁"不算数。热修复仅通过合作伙伴门户提供，需要有效的合作伙伴账号，请通过官方渠道获取，不要使用来路不明的安装包。

与此同时收敛暴露面：检查 AhsayCBS 管理界面是否监听在公网地址上，如非必要应通过防火墙或安全组限制为仅内网或可信 IP 访问，远程运维统一走 VPN；确认服务器所在网络与生产网络之间的访问控制策略，备份平台不应成为横渡到生产环境的通道。修改管理口令、检查备份任务配置和存储目标是否被篡改，也是补丁之外应该同步做的动作。

已经出现上述任一失陷指标的服务器，厂商的建议是整机重建，而不是"杀了木马继续用"：重装 Windows 或 Linux 操作系统，安装最新版 AhsayCBS（v9.15.0.0 或 v10.3.4.0）并应用对应热修复，然后通过 Auto Save 功能恢复一个时间戳早于失陷（建议至少提前一天）的服务器配置版本。重建前先备份好现有配置和数据以便取证，重建后轮换所有可能暴露过的凭据，并检查备份数据的完整性和一致性。

对于使用 MSP 托管备份服务的企业客户，还应主动向服务商确认：对方是否已应用有效热修复、是否完成失陷排查、自己的备份数据是否可能被波及。备份外包不等于风险外包。

后续观察

截至本文发布时，两个漏洞的利用活动仍在持续，CISA 给出的联邦修复期限（10 月 17 日）已过，但大量非联邦机构和中小企业客户的修复进度仍不明朗。Ahsay 已表示两个热修复"完全解决"对应漏洞，Huntress 也独立验证了 v10.3.4.45 可以阻断初始入口，但 v9.15.2.70 尚缺同等程度的独立验证，使用 v7/v8/v9 线路的用户需要保持关注。

另一个值得留意的方向是载荷升级：挖矿只是攻击者对失陷备份服务器最"温和"的用法，备份数据集中、恢复能力关键的特性，决定了它随时可能被勒索团伙盯上。建议持续关注 Ahsay 官方公告和 CISA KEV 目录的更新，一切修复动作以厂商官方公告为准。

总结一下：这次事件再次验证了备份安全的两条老原则——备份系统必须和生产系统同等加固，以及"打过补丁"和"修好了"是两回事。对依赖备份作为最后防线的企业来说，现在就去确认备份管理平台的版本和暴露面，是最划算的一次安全检查。