我在 GitHub 上发现了 10,000 个分发特洛伊木马的仓库

背景

这一发现源于一次偶然的“搜索验证”。作者原本想检查自己的 GitHub 项目是否被搜索引擎收录，在 Google 搜索中顺利找到了自己的仓库。然而，当他使用相同的关键词在 Bing 搜索引擎中搜索时，却意外发现了一个名为“复制品”的仓库。

这个仓库不仅名称和描述与作者的项目完全一致，甚至连所有的提交记录（commits）都一模一样，作者本人也被列为贡献者。但诡异的是，就在作者发现它的一个小时前，该仓库推送了一次新的提交，修改了 README.md 文件，并添加了一个指向 ZIP 压缩包的链接。

类似的遭遇随后在另一个项目中再次发生。作者通过浏览 GitHub 标签页寻找类似项目时，发现另一个仓库也是其项目的完美克隆，且同样在近期添加了恶意链接。

经过监控，作者发现这些恶意仓库每隔几小时就会删除之前的提交，并重新推送包含恶意链接的相同提交。作者随即向 GitHub 支持团队提交请求要求删除这些仓库，但两周后石沉大海。在与 AI 讨论无果、在 GitHub 社区发帖也仅收到无效回复后，一个月后 GitHub 支持团队才发邮件告知已移除这些仓库。

这次经历让作者意识到，这并非孤立事件，而可能是一场有组织的、规模庞大的恶意活动。

核心内容

恶意载荷分析

作者深入分析了这些恶意仓库中的 ZIP 压缩包，发现其内部结构高度一致，通常包含以下四个文件：

• Application.cmd 或 Launcher.cmd：启动脚本。
• loader.exe、luajit.exe 或其他名称的 .exe 文件：加载器或主程序。
• random_name.cso 或 random_name.txt：随机命名的数据文件。
• lua51.dll：Lua 5.1 动态链接库。

值得注意的是，如果直接将 ZIP 包链接提交给 VirusTotal 扫描，它可能显示为“0 病毒”；但如果提交整个 ZIP 文件本身，则会检测到内部包含特洛伊木马。

自动化发现过程

作者决定编写脚本，寻找符合特定模式的恶意仓库。最初的筛选模式包括：

1. 每隔几小时删除旧提交并推送新提交。
2. 提交中仅更新 README.md 文件。
3. README.md 中包含 ZIP 包链接。
4. 提交记录是从其他仓库复制而来的。
5. 是新仓库，而非 Fork（分叉）。
6. 所有仓库拥有不同的贡献者和名称。

由于 GitHub 拥有约 5 亿个仓库，且 API 限制为每小时 5,000 次请求，直接全量扫描不现实。作者利用 gharchive 服务下载了过去几天的 GitHub 事件数据，筛选出在 10 小时内更新 2 到 10 次的仓库。

初步筛选出 1,600 万次提交推送中仅有 3,000 个符合“高频更新”特征的仓库。经过进一步过滤（排除机器人、贡献者间隔超过一个月、多贡献者），仅找到 14 个完全匹配的仓库。

算法修正与大规模发现

作者对这 14 个仓库进行人工复核时，发现了一个关键错误：这些仓库在 20 小时前被更新，这意味着“每隔几小时更新”的过滤条件过于严苛，导致大量低频更新的恶意仓库被遗漏。

此外，作者注意到：

• 许多恶意仓库的最新提交显示“零更改”，但实际包含恶意链接。
• 所有恶意仓库的最新提交名称均为 “Update README.md”。

作者随即调整算法，将搜索范围扩大为“在 24 小时内更新 1 到 24 次”的仓库。这一调整发现了 40,000 个可疑仓库。经过精确匹配，最终确认有 10,000 个 仓库完全符合恶意模式。

这意味着，在筛选出的 40,000 个高频更新仓库中，有 25% 确切包含特洛伊木马。这些仓库已存在数月甚至一年以上，且 GitHub 未能自动检测并删除它们。

关键要点

• 隐蔽的传播机制：攻击者通过克隆新创建的仓库，使其在搜索引擎中针对低频关键词排名靠前，从而诱导用户下载。同时，将仓库添加到热门 GitHub 标签中，增加被索引和发现的概率。
• 信任构建策略：攻击者复制整个提交历史和贡献者列表，而非仅复制源代码。这使得访问者看到真实的贡献者头像和长期的账户历史，从而降低警惕性，建立信任。
• 对抗检测手段：攻击者每隔几小时删除并重新推送提交，且统一使用 “Update README.md” 作为提交信息。这旨在绕过 GitHub 的安全算法，因为频繁的小幅更改可能被视为正常维护行为。
• 平台监管滞后：GitHub 支持团队对人工举报响应缓慢（长达一个月），且自动化系统未能识别这种长期存在的恶意活动。VirusTotal 等第三方工具对直接链接的扫描存在盲区。
• 规模惊人：仅通过调整更新频率的过滤条件，就发现了 10,000 个恶意仓库，表明这是一场大规模、持续性的运动。

意义与影响

对开源生态的警示

这一事件揭示了开源平台作为软件供应链上游的脆弱性。攻击者利用开发者对“克隆仓库”的信任，将恶意代码伪装成合法项目。由于 GitHub 上存在海量新仓库，攻击者可以轻易通过“撒网式”克隆来淹没正常内容，导致安全检测机制失效。

对安全检测的挑战

• 行为分析的重要性：传统的基于文件内容的静态扫描（如 VirusTotal 对链接的扫描）可能失效。必须结合行为模式分析，如提交频率、提交信息一致性、仓库克隆来源等。
• 搜索引擎优化（SEO）攻击：攻击者利用搜索引擎的索引机制，将恶意仓库推送到搜索结果前列。这要求开发者在搜索开源项目时，不仅要检查代码，还要验证仓库的创建时间、贡献者真实性和提交历史的一致性。

未解之谜与后续行动

作者提出了几个开放性问题：

1. 为何只克隆新仓库而非热门仓库？（推测是为了利用搜索引擎对新内容的偏好排名）。
2. 为何每隔几小时删除并重新推送提交？（推测是为了规避基于时间戳或提交频率的自动化检测）。
3. 可执行文件的具体功能是什么？（需进一步逆向工程分析）。
4. 该运动的实际规模是否更大？

作者已将这 10,000 个恶意仓库的完整列表发布在 GitHub 上，并开源了名为 Git Malware Finder 的检测脚本，供社区用于自查和防御。这一举动不仅提高了透明度，也为其他开发者和安全研究人员提供了对抗此类供应链攻击的工具。

对 GitHub 平台的压力

此次事件对 GitHub 的平台安全机制提出了严峻挑战。面对如此大规模、有组织的恶意活动，平台需要升级其自动化检测系统，不仅关注文件内容，更要分析仓库的行为模式、克隆来源和提交历史，以实现对恶意仓库的实时识别和清除。