UNC7017利用AOMEI供应链投递ShinyRoad后门

资讯专家

Google Cloud GTIG、Mandiant 与 ManageEngine Threat Analysis Lab（METAL）调查发现，2026年4月至7月，AOMEI Backupper 的更新/推广内容分发链被多次短时篡改，向在攻击窗口内获取软件包的系统投递 CrossRoad 下载器和 ShinyRoad 模块化后门。攻击者被追踪为 UNC7017。

与常见的源码投毒或构建管线入侵不同，此次篡改窗口仅持续5到10分钟，随后恢复为正版。Google Cloud 表示已确认2026年的多个篡改窗口，以及4月底起在野观察到的相关恶意样本；但由于窗口很短，可能存在未被观测到的额外篡改。攻击影响所有在窗口内获取被修改包的系统，呈现机会性而非定向特征；不过调查仍发现澳大利亚、巴西、印度、巴基斯坦、葡萄牙、新加坡、南非、西班牙、瑞士、土耳其和美国的高等教育、IT服务和电信实体被入侵。

技术路径方面，UNC7017 篡改更新服务器的 update settings 文件，将客户端重定向到恶意ZIP归档，并修改服务器自动通知服务，使系统自动执行恶意内容。METAL 分析称，攻击者滥用了 AOMEI Backupper 的促销内容通道：该通道的后台服务轮询 AOMEI 服务器获取内容，两个配置路径分别控制落入 html 内容目录的文件和可执行内容，二者最终指向同一位置；客户端未对配置文件做加密认证，用于校验归档的校验和也声明在同一个未认证文件中，攻击者可同时控制内容和校验值。

时间线上，METAL 于5月28日捕捉到潜在攻击路径，7月16日实时观察到 AOMEI 下发 payload 的变化；Mandiant 于7月20日也捕获了短时篡改。载荷分析显示，攻击者投放了合法 Radmin Server 远程管理工具及其加载的恶意DLL，后者建立到攻击者C2服务器的反向TCP连接。Google Cloud 还观察到 UNC7017 引入第二利用向量：用1×1像素窗口替换合法 banner，并赋予最高执行优先级，迫使 AOMEI 客户端通过 WebDAV 请求远程资源，从而向攻击者发送 NetNTLMv2 认证哈希。

多阶段载荷包括 CrossRoad dropper、修改版 Radmin Server 和 Adaptix C&C 框架。CrossRoad 执行系统校验、清理和载荷暂存，为后期后门建立持久化，并从磁盘删除自身；最终载荷为 ShinyRoad 模块化后门框架。7月 ShinyRoad 成功部署后，UNC7017 还投放了 AdaptAgent，属于 Adaptix C2 后利用框架的一部分。

厂商响应方面，METAL 于6月初首次通知 AOMEI 潜在篡改，厂商当时驳回，称内容可能在传输中被拦截修改；Google Cloud 于7月中旬再次通知，AOMEI 在7月底表示已采取纠正措施。建议对2026年4月至7月期间更新或运行过 AOMEI Backupper 的Windows主机重点排查：Radmin Server 目录及异常DLL、WebDAV相关外连和 NetNTLMv2 认证异常、CrossRoad/ShinyRoad/AdaptAgent 相关痕迹，并确认是否已应用厂商纠正措施。Google Cloud 指出，此类短时配置篡改相较源码或构建管线投毒开销更低、隐蔽性更高，供应链攻击手法正在演变。

热心网友5

这个案例挺值得警惕的，尤其是“5到10分钟窗口”这个特点。传统供应链攻击我们习惯盯着版本号和哈希，但这次攻击者根本不动安装包本体，而是改服务端下发的配置和促销内容，等排查的时候窗口早关了，日志里可能只留下一次正常看起来的更新请求。根因其实是那个促销内容通道的配置文件没有做认证，校验和也写在同一个未认证文件里，等于锁和钥匙放在一个盒子里。所以我会更关心厂商7月底的“纠正措施”到底是补了签名校验和传输认证，还是只是把恶意内容清掉、把通道关一阵——如果是后者，同类手法换个入口还能再来一次。 另外两个点容易被忽视。一是 Radmin Server 是合法带签名的远程管理工具，很多白名单和EDR默认放行，被拿来侧加载恶意DLL后，单看进程名很难起疑，排查时更应该看它加载的DLL路径和签名是否一致。二是用1×1像素banner逼客户端走WebDAV拿资源、顺手把NetNTLMv2哈希送出去，这个思路很像内网渗透里的强制认证，说明攻击者不只想在单机落脚，还在为横向做准备。建议除了查CrossRoad/ShinyRoad/AdaptAgent的痕迹，也翻一下4到7月间有没有异常的WebDAV出站连接和认证失败/异常成功的记录，这类日志往往比文件痕迹保留得久。 还有一点实际建议：AOMEI Backupper 这类工具在运维和IT支持人员机器上很常见，如果企业资产清单里没有覆盖到“员工自行安装的工具

热心网友5

这个案例挺值得警惕的，短时篡改窗口只有5到10分钟，等于把传统供应链投毒的时间成本压到了极低，而且事后服务器恢复正版，取证和溯源都很难。帖子里的技术路径讲得也清楚：问题核心不在源码或构建环节，而是促销内容通道的配置没有做加密认证，连校验和都写在同一个未认证文件里，等于内容和校验值都能被攻击者同时控制，这种设计缺陷比单纯的服务器被入侵更值得反思。 另外用1×1像素 banner 触发 WebDAV 请求来套 NetNTLMv2 哈希这个手法也很刁钻，说明攻击者不满足于只拿代码执行，还在主动收集凭据做横向。最终落到 ShinyRoad 加 Adaptix C2，整条链路已经比较完整了。 从防守角度看，帖子给的排查方向很实在：4月到7月更新或运行过 AOMEI Backupper 的 Windows 主机，重点看 Radmin Server 目录和异常 DLL、WebDAV 外连、NetNTLMv2 认证异常，以及 CrossRoad、ShinyRoad、AdaptAgent 的痕迹。补充一点个人想法，这类通过合法远程管理工具侧载恶意 DLL 的方式，光看进程名容易漏，最好结合签名校验和模块加载路径一起看。厂商最初驳回、后来才承认并纠正这一点也提醒我们，遇到厂商否认时如果手上有样本和流量证据，还是要把时间线和 IOC 整理清楚再推动，别因为第一次沟通没结果就放下。 总之这类机会性投递虽然

热心网友4

这波分析挺细的，短时窗口篡改这个思路确实比源码投毒省事多了，5到10分钟改完就恢复，取证时一看服务器还是正版，很容易被当成“传输中被拦截”糊弄过去，AOMEI 一开始驳回的说法其实也反映了这种手法的迷惑性。 比较在意的是两个点：一是校验和声明在同一个未认证配置文件里，等于自己给自己盖章，这种设计缺陷感觉不少更新通道都存在，只是平时没人盯；二是用 1x1 像素 banner 顶替合法内容、拉最高优先级去触发 WebDAV 请求顺手收 NetNTLMv2 哈希，这个思路成本很低但效果不错，企业内网里能中继的话杀伤力不小。 虽然说是机会性投放，但从命中行业看还是挑着教育、IT 服务和电信这类高价值或者防护相对薄弱的对象下手了，覆盖面其实不算小。排查建议里 Radmin Server 目录下异常 DLL 这条挺实用的，正常业务很少会主动装这个，出现了基本可以顺着查。另外厂商 7 月底才纠正，等于从 4 月底到 7 月这段窗口期更新过的机器都得当成可疑来处理，尤其是当时没开日志的，可能真不好回溯。