黑客劫持 AOMEI 更新服务器秘密传播恶意软件

据报道，黑客入侵了 AOMEI 的服务器，通过其备份软件内置的推广功能分发恶意软件，并在短暂篡改配置文件后将其恢复原状以隐藏攻击痕迹。

这起供应链攻击发生在 2026 年 4 月至 7 月之间，目标是 AOMEI Backupper（一款用于数据备份、磁盘克隆和系统还原的 Windows 应用）所使用的更新和通知系统。

ManageEngine 威胁分析实验室（METAL）的研究人员与 Google 威胁情报组（GTIG）及 Mandiant 合作发现并调查了这一攻击活动。

在 Google 和 ManageEngine 发布的报告中，该活动被归因于一个被追踪为 UNC7017 的威胁行为者，其利用被入侵的基础设施分发了一种此前未知的恶意软件下载器 CROSSROAD 和一个名为 SHINYROAD 的后门。

研究人员在美国、澳大利亚、印度、新加坡、西班牙和瑞士等多个国家发现了受影响组织，涉及 IT 服务、电信和高等教育等行业。

不过，Google 警告称，这些攻击是机会性的，在恶意文件分发的短暂窗口期内检查软件更新的其他组织也可能受到影响。

攻击最早于 5 月 28 日被发现，ManageEngine 表示其端点安全软件发现 AOMEI Backupper 突然在不同国家的两家不相关公司的计算机上安装了合法的远程管理工具 Radmin。

Radmin 的安装十分可疑，因为是 AOMEI 内置的推广进程启动了它，而这些进程通常负责下载和展示推广内容及通知。

然而，当研究人员尝试在自己的测试系统上复现该行为时，未发现任何恶意内容。该软件反而联系了 AOMEI 的服务器并下载了合法的配置文件。

进一步测试显示，攻击者并未永久替换 AOMEI 服务器上的文件，而是短暂修改了推广和通知系统使用的两个配置文件：

• https://www2.aomeisoftware.com/download/abpopup/down_html.ini
• https://account.aomeitech.com/Notifycfg.ini

第一个文件 down_html.ini 告诉 AOMEI Backupper 从何处下载更新包。第二个文件 Notifycfg.ini 控制通知，并可在计算机上触发内容运行。

通过修改这些文件，攻击者将软件重定向去下载一个恶意 ZIP 压缩包，随后利用通知机制在无需用户交互的情况下执行该恶意软件。

Google 的研究人员后来在自己的测试中确认了这一执行流程。

在未能复现原始攻击后，ManageEngine 开始持续监控 AOMEI 的服务器。

7 月 16 日，该监控终于实时捕获到恶意修改，证实 AOMEI 的系统正在提供恶意内容。

研究人员还发现，攻击者修改了更新配置中的预期校验和，使恶意压缩包能够通过软件的文件验证检查。

Google 和 ManageEngine 表示，他们确认了三个 AOMEI 服务器发送恶意配置文件的时间窗口：

• 5 月 28 日：10 分钟暴露窗口（05:40 – 05:50 UTC）
• 7 月 16 日：6 分钟暴露窗口（08:33 – 08:39 UTC）
• 7 月 20 日：5 分钟暴露窗口（10:35 – 10:40 UTC）

攻击者在几分钟内就将配置文件恢复原状，使得入侵难以被察觉。

在这些窗口期间，恶意配置文件被用于安装 CROSSROAD 和 SHINYROAD 恶意软件。

启动后，CROSSROAD 下载器会对受感染计算机进行侦察，下载其他组件，并通过计划任务建立持久性。

SHINYROAD 是一个后门，利用合法的 Radmin 组件加载恶意代码，并与攻击者控制的命令与控制服务器建立出站连接。

这使攻击者有可能在受感染计算机上执行更多命令和载荷。

在 7 月 20 日的攻击中，Google 还观察到第二种技术：通过不可见的弹窗强制软件的通知系统访问攻击者控制的 WebDAV 资源，试图窃取 Windows 身份验证哈希。

该技术可能暴露 NTLM 哈希，攻击者控制的服务器可收集这些哈希，随后使用各种工具进行破解。

研究人员还确定了攻击中使用的多个 IP 地址和主机名，包括 8.210.84[.]56、serv.oss-cn-hongkong[.]aliyuncs.com、storage-data[.]com 下的主机名，以及合法的 Google Cloud Storage 端点 storage.googleapis.com。

ManageEngine 告诉 BleepingComputer，其早在 6 月 7 日就首次向 AOMEI 通报了该可疑活动，比研究人员直接捕获其服务器提供恶意配置文件早了一个多月。

当时，AOMEI 最初表示这些内容可能在传输途中被拦截和修改，研究人员不同意这一解释。

"证据不支持 AOMEI 关于传输途中被拦截的解释，"ManageEngine 的报告中写道。

"两个端点均通过 HTTPS 从 AOMEI 自有的主机名获取内容，跨越不同国家和互不相关的网络路径，且可执行文件是通过应用程序自身的解压流程到达的，而非由外部进程直接写入磁盘。内容在到达任一端点之前、在厂商托管的分发路径之内就已被篡改。"

当 ManageEngine 在 7 月 16 日捕获另一次攻击时，立即向 AOMEI 提供了原始和被修改文件的哈希、文件差异及被篡改的文件。

"AOMEI 予以配合，进行了自己的审查，并告诉我们其初步检查未发现入侵证据，"ManageEngine 告诉 BleepingComputer。

研究人员表示，AOMEI 表示计划将受影响的配置文件迁移到具备更详细日志记录的新基础设施上。

ManageEngine 告诉 BleepingComputer，其建议 AOMEI 在进行这些更改之前保留现有证据，并引入事件响应专家，还将该公司与 Mandiant 对接以协助调查。

AOMEI 后来告知研究人员，其技术团队已升级服务器、修补潜在漏洞，并验证其基础设施上托管的文件是正确的。

Google 也在报告中确认，Mandiant 于 7 月 17 日将配置文件篡改事宜通知了 AOMEI，该公司于 7 月 29 日回复称已采取纠正措施。

当 BleepingComputer 就调查结果联系 AOMEI 时，AOMEI 表示正高度重视此事，其首席技术官正在主导内部调查。

"我们也在内部注意到了这份报告，并已将其列为高优先级事项。我们的 CTO 目前正在主导一项专项调查，以确保准确识别问题，"AOMEI 告诉 BleepingComputer。

该公司表示，其 CTO 将就事件和调查进展提供更详细的回复，若收到新信息，BleepingComputer 将更新本文。

AOMEI 未立即确认攻击者如何获取其更新基础设施的访问权限，或所报告的入侵是否已被完全解决。

尽管 AOMEI 表示已保护其服务器，但 ManageEngine 警告称，这些更改无法清除此前安装在客户计算机上的恶意软件。

"服务器端的修复只能阻止新的感染；它无法从在早前窗口期内收到后门的机器上移除后门，"ManageEngine 告诉 BleepingComputer。

建议使用 AOMEI Backupper 的组织查阅 Google 和 ManageEngine 发布的入侵指标，包括可疑的计划任务、AOMEI 安装目录中意外的可执行文件，以及与攻击者控制基础设施的连接。