💻 computer science

Beyond Takedown: Measuring Malicious Go Module Persistence in the Wild

本文揭示了一场大规模的 Go 供应链攻击，其中攻击者将经过混淆处理的恶意软件重新封装进合法的模块中，这表明仅依赖 GitHub 搜索无法检测到受损的全貌，因为超过 99% 被移除的恶意人工制品仍可通过 Go 代理进行检索。

原作者： Minjae Bae, Carter Yagemann

发布于 2026-06-26

📖 1 分钟阅读☕ 轻松阅读

原作者： Minjae Bae, Carter Yagemann

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，软件开发的世界就像一座巨大且繁忙的图书馆，程序员在这里“借阅”各种“模块”（预先写好的代码块）来构建他们自己的应用程序。在 Go 语言的世界里，这座图书馆有一位非常严格的管理员：Go Proxy（Go 代理）。

以下是关于这座图书馆近期发生的一场劫案的简单故事。

劫案：“虚假的读书会”

攻击者决定从图书馆中窃取东西，但他们并没有破门而入，而是玩了一场冒充的游戏。

准备阶段： 他们找到了大家都在使用的、正当且受信任的流行书籍（合法的代码模块）。
伪造阶段： 他们以自己的名义创建了这些书的假副本。在这些假书中，他们隐藏了一个微小的、隐形的陷阱。
陷阱： 在 Go 的世界里，当你“导入”（借阅）一本书时，图书馆会自动运行一些设置任务。攻击者将一条恶意指令隐藏在了这些设置任务中。这就像是一本书，你一打开它，它就会偷偷向你的电脑发出指令，下载并运行病毒。
造势： 为了让这些假书看起来真实可靠，攻击者使用“机器人军队”为它们在 GitHub 上骗取了数千个“星标”（点赞），从而误导开发者认为：“噢，这一定很受欢迎且安全。”

调查：两种观察方式

研究人员（Minjae Bae 和 Carter Yagemann）想要看看这个问题到底有多严重。他们使用了两把不同的手电筒来寻找窃贼。

手电筒 1：GitHub 搜索（“书架”视图）
他们手动搜索了主要的托管网站（GitHub），寻找可疑的模式，并追踪账号之间的“星标”关联。

发现： 他们发现了 2,113 个虚假仓库。
问题： 这种手电筒只有在假书还摆在书架上时才有效。如果图书馆工作人员移走了这本书，或者窃贼压根没把书放到主书架上，这把手电筒就什么也看不见。

手电筒 2：Proxy 扫描（“流通”视图）
他们构建了一个名为 GOAST 的特殊扫描器（一个只读代码而不运行代码的机器人）来扫描 Go Proxy。这是图书馆的备份系统。它保存着每一个被借阅过的模块的完美、不可更改的副本，即使原始书籍已从书架上移除，它依然存在。

发现： 他们发现了 2,289 个恶意版本。
惊喜： Proxy 手电筒发现的恶意书籍比 GitHub 手电筒多出了 83%。许多这些假书甚至从未出现在主书架上，或者已经被移除了，但 Proxy 依然保留着它们。

重大发现：“下架”并不意味着“修复”

这是故事中最重要的部分。

通常，当安全团队发现一本坏书时，他们会要求图书馆将其下架（Takedown）。他们删除 GitHub 上的仓库，并认为：“太好了，威胁已经消失了。”

研究人员证明这是错误的。

因为 Go Proxy 保留了每个模块永久且不可更改的副本，在 GitHub 上删除源文件并不会从生态系统中删除病毒。

研究人员发现，即使在攻击者的仓库被删除或停用（导致它们在 GitHub 上“隐身”）之后，99.4% 的恶意模块仍然可以通过 Go Proxy 进行获取和下载。
这就像图书馆工作人员把一本假书扔进了垃圾桶，但图书馆的自动化配送无人机（Proxy）仓库里依然存有一份完美的副本，并且会继续向索要它的客户进行派送。

结果

研究人员将这个问题告知了图书馆的管理方（GitHub 和 Google）。

GitHub 删除了 684 个恶意仓库。
Google（Proxy 团队）从其永久存储中清理了 1,377 个恶意模块版本。

教训

你不能仅仅通过清理“托管层”（GitHub）来解决软件供应链问题。如果“分发层”（Proxy）保留了坏代码，威胁就会持续存在。要真正解决问题，你必须同时清理“书架”和“仓库”。

技术摘要：超越下架：测量野外恶意 Go Module 的持久性

问题陈述

Go 生态系统作为现代软件基础设施的支柱，正日益成为供应链攻击的目标。与传统的生态系统（如 npm、PyPI）不同，Go 的攻击案例记录并不充分，这主要是由于其执行模型和分发基础设施的特殊性。攻击者通过受控账号重新包装合法的 Go module，并嵌入在导入时即触发的混淆代码。

在托管层下架（从 GitHub 移除仓库）与生态系统修复之间存在关键差距。Go 的分发模型依赖于 proxy.golang.org 和 index.golang.org 来确保可复现性。一旦恶意模块的版本被发布并被代理缓存，它就会变得不可变且可检索，即使原始源代码仓库已被删除或暂停，该模块依然存在。因此，仅依赖以 GitHub 为中心的可见性无法捕捉到受攻击的完整程度，也无法确保实现真正的修复。

研究方法

作者采用了两阶段、互补的测量方法，旨在同时捕捉该攻击活动在托管层和分发层的足迹。

第一阶段：人工发现 (数据集 M)

范围： 在 2025 年 3 月至 6 月期间进行的 GitHub 仓库人工搜索。
技术： 研究人员从一组已知的恶意仓库种子集开始，通过“基于关注者（stargazer）的跳转”进行扩展，识别出协同关注了多个恶意模块的账号。
验证： 通过基于关键词的预过滤器（例如 exec.Command、/bin/sh、.Start()）对候选对象进行筛选，并进行人工验证，以确保其包含用于重建“获取并执行”命令（例如 wget 或 curl 后接执行操作）的混淆字符串。
结果： 获得了一个高置信度的基准数据集，包含 2,113 个恶意仓库 ( $|M| = 2,113$ )。

第二阶段：自动化分发层测量 (数据集 G)

范围： 使用 index.golang.org 和 proxy.golang.org 对 Go 分发基础设施进行大规模扫描。
工具： 作者开发了 GOAST（基于 Go AST 的威胁扫描器），这是一个旨在检测特定攻击特征而非通用恶意软件的静态分析引擎。
- GOAST 将 Go 源代码解析为抽象语法树（AST）。
- 它识别进程生成调用（结合了 Start、Run 或 Output 的 exec.Command）。
- 它执行轻量级的过程内值传播，以重建混淆的字符串参数。
- 它仅在重建的执行调用与下载指令（例如指向 HTTP(S) URL 的 wget/curl）相匹配时，才将该模块标记为恶意。
数据收集： 团队收集了从 2024 年 7 月到 2025 年 7 月共 1,230 万条索引条目的时序数据。在去重并针对名称共享行为（克隆合法模块名称）进行过滤后，他们扫描了 60,232 个可疑候选对象。
结果： 确认了 2,289 个恶意模块版本 ( $|G| = 2,289$ )。

核心发现

1. 攻击活动特征 (RQ1)

该攻击活动通过一个严密的自动化流水线运行，分为两个明显的波次：

第一波 (2025 年 3 月)： 针对 Linux，使用切片索引（slice indexing）来重建命令。
第二波 (2025 年 5 月)： 扩展至 Windows，利用字面量拼接（literal concatenation）和切片索引的混合手段。
执行向量： 两波攻击都利用 Go 的全局变量初始化器，在包导入时立即执行恶意代码。
基础设施： 该攻击活动依赖于 20 个特定域名的狭窄足迹。Linux 载荷提供静态 ELF stager，而 Windows 载荷则遵循严格的 31 天周期轮换唯一的 PE 二进制文件。

2. 以 GitHub 为中心的视图局限性 (RQ2)

对比人工 GitHub 数据集 ( $M$ ) 与代理数据集 ( $G$ )，揭示了两个关键的盲点：

发现范围差距 (缺失 #1)： 在代理中发现的恶意模块中，有 83.0% ( $G \setminus M$ ) 未能在以 GitHub 为中心的人工发现流程中被发现。这些模块在代理中流通，但缺乏人工发现所需的社交信号（如 Star 数）。
托管层挥发性 (缺失 #2)： 在进行分析时，代理足迹 ( $G$ ) 中的 69.3% 已处于“GitHub 不可见”状态（仓库已被删除或暂停）。
双重缺失： 总计 64.3% 的代理足迹同时属于上述两类：它们既未被人工发现，其托管仓库也已消失。

3. 下架与修复之间的差距 (RQ3)

本研究量化了源代码移除后的威胁持久性：

证据 A (重叠)： 对于在 6 月快照期间被确认为 GitHub 端已失效的 74 个交集模块 ( $M \cap G$ )，100% 在 7 月仍可通过 Go 代理进行检索。
证据 B (规模)： 在 8 月份处于 GitHub 不可见状态的代理集合 ( $G$ ) 中，99.4%（1,577 个模块）在 7 月的日志中被证实仍可通过代理检索。
结论： 仅仅移除 GitHub 上的仓库并不能修复威胁；恶意模块版本会在分发层中持续存在。

贡献与意义

本文的主要贡献如下：

生态系统规模的测量： 提供了对一次活跃的 Go 供应链攻击活动的首次全面测量，并对其自动化特性、两波演进过程以及混淆结构的严密性进行了表征。
量化可见性差距： 证明了由于发现范围限制和托管层挥发性，以 GitHub 为中心的视图会系统性地低估实际的威胁足迹。
提供修复差距的证据： 实证证明了在 Go 生态系统中“下架 $\neq$ 修复”，表明代理缓存的模块在源代码仓库被移除后仍能长期存在。

意义：
作者认为，针对 Go 生态系统的事件响应和修复不能仅依赖于托管层的信号。由于代理基础设施确保了可复现性，它在无意中维持了恶意人工制品。有效的修复需要跨越托管层（GitHub）和分发层（Go Proxy/Index）的协同工作。在进行负责任的披露后，GitHub 移除了 684 个仓库，Google Go 团队修复了 1,377 个模块版本，这验证了这种跨层处理方法的必要性。