2026-10-22 13:24:21 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

备份软件更新了十分钟，电脑里就多了一个后门

原创

tcode
tcode

字节脉搏实验室

2026年10月19日 14:10
北京

去阅读

5月28日、7月16日和7月20日这三天里，装了傲梅轻松备份（AOMEI Backupper）的电脑中，有一小部分恰好在这三个时间点检查了更新，随后下载并自动运行了一个不属于厂商的程序。三段暴露时间分别只有10分钟、6分钟和5分钟，换成北京时间是5月28日13时40分到13时50分、7月16日16时33分到16时39分、7月20日18时35分到18时40分。

研究这件事的是三支团队：谷歌威胁情报组（GTIG）、Mandiant和ManageEngine威胁分析实验室。三家的材料在同一天公开，行动被跟踪为UNC7017，下载器叫CROSSROAD，后门叫SHINYROAD，AOMEI方面在7月29日回复称已对分发服务器做了加固。这次攻击没有利用任何漏洞，没有内存破坏，也没有未修补的组件：被改掉的只是这款备份软件从厂商自己服务器上取的两个配置文件。

第一个文件叫down\_html.ini，决定下载什么。程序从里面读出压缩包地址和校验值，下载后按这个校验值验证一遍，再解压进自己的资源目录。第二个文件叫Notifycfg.ini，决定弹什么、执行什么，它由另一个后台进程读取，被要求时会在应用内置的浏览器窗口里加载一段页面，页面再去触发执行。两个文件都没有签名校验，而用来证明下载包没被掉包的校验值，就写在这份没有签名的文件里，和包地址一起被替换。ManageEngine实验室的措辞是，攻击者完全按这个通道被设计出来的用法使用它，不需要任何漏洞，也不需要用户点任何东西。

三个窗口，最长十分钟

攻击者没有把改动长期留在服务器上。公开材料列出三段已确认的窗口，时间都用协调世界时：5月28日05时40分至05时50分，10分钟；7月16日08时33分至08时39分，6分钟；7月20日10时35分至10时40分，5分钟。每段窗口结束时，两个配置文件都被改回原样。

这带来两个后果。第一，窗口之外检查更新的机器拿到的是真正的官方文件，事后无论抽查服务器还是自动扫描爬虫，看到的都是干净内容。第二，已经被感染的机器，本地的更新配置也被下载器还原过，事后打开程序目录，看上去同样没有异常。三家团队都提到，正因为窗口被压到这么短，攻击者认定这能躲开传统的定点排查和自动文件扫描；GTIG也把这种手法称为它遇到的第一个用这么短窗口实现的软件供应链篡改。

窗口内被替换的压缩包里装着下载器CROSSROAD。它会先判断自己跑在什么样的环境里，再解压到本机用户目录下的Radmin文件夹，注册一个每三小时执行一次的计划任务，然后把自己从磁盘上删掉。ManageEngine的检测记录显示，CROSSROAD释放出的包里有正版且带签名的Radmin远程管理组件，但没有配置任何服务器地址或凭据；样本里并没有看到它真的被启用。

一条不需要漏洞的执行链

真正拿到控制权的是后面两步。计划任务每三小时启动一次带签名的正版Radmin主程序，主程序启动时会按系统的库搜索顺序加载同目录下的一个同名库文件，而这个文件是攻击者自己编译的，名叫BlkScrDl.dll，用来伪装成Radmin自带的驱动库。这个库从共享内存里读出配置，用ChaCha20解密一段编译过的Python字节码，交给内嵌的解释器执行，回连到地址8.218.65.184的443端口。这就是SHINYROAD框架的起点，它能开远程命令通道，也能按指令再拉新代码下来。

7月中旬之后，同一批人又在上面叠了第二套工具：把开源的Adaptix C2框架伪装成Nitro PDF的推广程序，注册成名为NitroRuntime的计划任务，用同样的库文件替换手法加载，每隔约两分钟回连一次8.210.84.56的6800端口。链条上真正能一击断掉的节点，是那个写死在样本里的回连地址；但地址换一个，这套判断就得重做一遍。

值得注意的是对象是谁。GTIG从自身遥测里识别出的受影响组织分布在11个国家，行业包括IT服务、电信和高等教育：澳大利亚、巴西、印度、巴基斯坦、葡萄牙、新加坡、南非、西班牙、瑞士、土耳其和美国。报告没有给出总数，并明确说受害者是随机撞上的——谁在窗口里轮询，谁就中招，实际范围很可能比识别到的更大。

7月20日那次，不用装程序也能拿走凭据

7月20日的窗口里还有第二个动作，它不需要运行任何程序。攻击者把Notifycfg.ini里的内容换成一段隐藏的单像素弹窗，指向攻击者服务器上的一个WebDAV地址。渲染这个弹窗会让Windows把当前登录用户的NetNTLMv2认证响应发到对方地址，用户屏幕上什么都不会出现。这条路径的价值在于，即使机器上的后门执行被拦住了，凭据仍然可能已经泄露出去，拿到响应的人可以离线尝试破解，或者在特定条件下直接复用。GTIG给出的应对是封掉对外部的SMB（445端口）和WebDAV流量。

从发现到加固，隔了两个多月

把时间线摊开，能看清这件事的处理节奏。5月28日，ManageEngine的端点软件在两个互不相关、且在不同国家的客户机器上记录了傲梅轻松备份安装Radmin的动作；6月7日有客户提出疑问，实验室当天通知了AOMEI。AOMEI最初的解释是内容在传输途中被拦截替换。实验室认为证据不支持这个说法：两台机器都是透过HTTPS从AOMEI自己的服务器上取到文件，跨了不同国家和不同网络，走的是程序正常的更新流程；到7月中旬，实验室的监控在现场抓到了其中一段窗口，确认被改的内容是从AOMEI这一侧发出去的。

7月17日，Mandiant通知AOMEI并提供了指标；7月29日，AOMEI回复称已采取加固措施。ManageEngine表示，到报告发布时，它尚未独立确认这次入侵已被收拢。两份报告都没有说明攻击者最初是怎么拿到修改服务器文件的权限的。另一个细节同样重要：The Hacker News在10月16日核对了傲梅轻松备份的更新日志，一直到10月9日发布的8.5.0版本，都没有出现改变更新校验方式的条目。

现在该查什么

第一步是查机器，而不是查服务器。在Windows上按名字找两类计划任务：RadminComponentRuntime（公开描述里写的是“Radmin Component runtime checkable.”）和NitroRuntime。再打开本机用户目录下的Radmin文件夹，看是否存在BlkScrDl.dll、csvc\RuntimeComponent.dll、config.zip、metadata.dat，以及一个带厂商发布者信息、却没有有效签名的upgrade-now.exe。这里有一个必须说清的分界：同一个目录里带签名的FamItrfc.exe、FamItrf2.exe、WinLpcDl.dll是正版Radmin自带的组件，单看文件名不能定性，要看是否与上述文件同时出现、以及是否有计划任务在调用它。

第二步是查网络记录，并且要按窗口去查。把4月到7月的出站日志、代理日志和时间服务器校准后，比对三段窗口：5月28日05时40分至05时50分、7月16日08时33分至08时39分、7月20日10时35分至10时40分（均为协调世界时，对应北京时间加8小时）。要看的线索包括对promotion.storage-data.com的请求、User-Agent里带Anyviewer-loader或Anyviewer-ipcheck的流量、以及访问阿里云香港对象存储的请求。GTIG同时建议封掉对外的SMB（445端口）与WebDAV流量，理由是7月20日那条不需要执行代码的凭据泄露路径。

第三步是别用错了证据。现在打开厂商的下载页，看到的是正常文件；打开被感染机器的程序目录，也可能什么都看不到。公开报告专门点了这个坑：因为改动只持续几分钟，事后验证服务器几乎总是干净的，很多分析人员因此把真实的告警当成误报。正确的做法是保留程序自己缓存和暂存的更新文件，并回到告警发生的那一分钟，看当时服务器实际发出了什么。

如果一台机器同时出现RadminComponentRuntime计划任务、Radmin目录下的未签名动态库，以及某段窗口时间里对promotion.storage-data.com的出站请求，应合并研判，而不是各自当成工具残留或误报。

边界

这份材料里有几处需要如实说明。攻击者如何取得修改厂商服务器文件的权限，两份报告都没有给出；AOMEI称已加固服务器，但第三方尚未独立确认。受影响组织名单里没有中国大陆，且GTIG记录了一个细节：下载器会通过外部地址查询自己的出口国家代码，一旦返回CN就中止主载荷的执行，发现特定安全软件时也会停止。这不等于国内机器天然安全：这个判断基于出口IP的国家代码，而企业网络经常经由境外出口或代理访问互联网，条件本身并不牢靠；更关键的是，更新通道缺少独立性校验这件事并没有因为这次加固而改变，同样的替换手法以后仍然可以复用。

来源

Google Threat Intelligence Group / Mandiant，《Investigating ephemeral supply chain tampering》，2026-10-16（页面未标注时区），https://cloud.google.com/blog/topics/threat-intelligence/investigating-ephemeral-supply-chain-tampering

ManageEngine Threat Analysis Lab，《AOMEI Backupper supply-chain compromise: Investigation and analysis》，2026-10-16（页面标注日期，未标注时区），https://www.manageengine.com/threat-analysis-lab/aomei-backupper-supply-chain-compromise.html

The Hacker News，Swati Khandelwal，《Attackers Tampered with AOMEI Backupper's Update Servers for Minutes to Deliver a Backdoor》，2026-10-16（页面标注 Oct 16, 2026），https://thehackernews.com/2026/10/attackers-tampered-with-aomei.html