我发现有1万个GitHub仓库在传播特洛伊木马

# 我是如何找到 10,000 个在 GitHub 上传播木马病毒的仓库的 来源：https://orchidfiles.com/github-repositories-distributing-malware/ 2026年6月18日 这是一个关于我如何在 GitHub 上发现 10,000 个传播木马病毒仓库的故事。这些仓库来自不同的贡献者，有着不同的名称，也不是其他仓库的分支。但它们有一个共同的模式，正是这个模式让我能够编写一个脚本来找到这些仓库。 ### 引言 我在 GitHub 上有一个项目，我想检查一下搜索引擎是否已经索引了它。我把项目名称输入 Google，我的仓库出现在搜索结果中。我在 Bing 中输入同样的查询，结果却出现了别人的仓库，有着完全相同的名称和描述。它是我仓库的一个副本，包含了所有提交记录，而我也被列为贡献者之一。但在一小时前，有人推送了一个新提交，修改了 README 文件。文件中添加了一个指向 ZIP 归档文件的链接。 我当时正在为 GitHub 上的另一个项目选择合适的标签。我点击这些标签以查看类似的项目。在列表中，我发现了一个仓库，其名称和描述与列表中的另一个仓库完全匹配。结果发现，这个仓库也包含了那个仓库的所有提交副本，而且两小时前，README 文件中也被添加了一个指向 ZIP 归档的链接。 在监控这两个仓库后，我发现每隔几小时，它们就会删除之前的提交，然后推送完全相同的提交。这个提交只包含一个更改：在 README 文件中添加一个归档文件的链接。 我向 GitHub 支持提交了请求，要求删除这些仓库。两周过去了，什么也没改变；GitHub 支持没有回复。我和 AI 讨论了还能做些什么，但它没有提供任何有用的建议。我在 GitHub 上开了一个帖子，有三个人回复了，但都是些毫无用处的 AI 废话。 又过了一个月，GitHub 支持给我发了一封邮件，说他们已经删除了这些仓库。 你可以打开其他类似的仓库，查看最新的提交，会发现几小时前 README 中又添加了一个 ZIP 归档的链接：https://github.com/neiljrunde/AI-Face-Changer-Real-Time?ref=orchidfiles.com https://github.com/edvardmunchartfulness745/vitalgaurd-2?ref=orchidfiles.com https://github.com/Guillen01/laravel-user-management?ref=orchidfiles.com **这个 ZIP 归档包含 4 个文件：** - Application.cmd 或 Launcher.cmd - loader.exe 或 luajit.exe 或 another_name.exe - random_name.cso 或 random_name.txt - lua51.dll 如果你将归档文件的链接提交给 VirusTotal，它会显示 0 个病毒。但如果你直接提交 ZIP 文件本身，它会检测到里面的木马。 ### 后续 我似乎已经忘记了这件事，但我的潜意识并没有。我的潜意识经常在我睡觉或醒来时给我抛出有趣的想法。最近，我醒来时，一瞬间就意识到我需要做什么了。我需要想出一个通用模式，然后编写一个脚本，分析所有 GitHub 仓库，找出符合该模式的仓库。 **搜索模式：** - 每隔几小时删除之前的提交并推送一个新提交 - 提交中只更新了 README 文件 - README 文件中包含指向 ZIP 归档文件的链接 - 提交是从另一个仓库复制过来的 - 这是一个新仓库，不是分支 - 所有仓库都有不同的贡献者和不同的名称 从最后两点可以看出，即使我们找到了一个这样的仓库，也无法用它来找到其他类似的仓库。但 GitHub 上有 5 亿个仓库。我们如何分析所有这些仓库？GitHub 允许单个令牌每小时 5000 次请求。对于每个仓库，我们需要多次请求来获取提交列表、修改的文件以及 README 文件的内容。我可不想等上一年让脚本分析完所有仓库。 但我们不需要所有仓库，只需要那些每隔几小时更新一次的仓库。我找到一个名为 gharchive 的服务（https://www.gharchive.org/?ref=orchidfiles.com），它可以下载任意一天的 GitHub 所有事件。所以我们只需要下载最近几天的事件归档，筛选出只包含提交推送事件，并找出那些每隔 10 小时更新 2 到 10 次的仓库。 在过去 5 天里，有 1600 万次提交推送。其中只有 3000 个仓库是每隔几小时更新一次的。 然而，事件并不包含具体修改了哪些文件的信息。这意味着对于每个相关的仓库，我们还需要向 GitHub API 发送额外的请求。 脚本运行后，返回了大量仓库。我向筛选条件中添加了几个参数： - 提交必须来自用户，而不是机器人 - 最后一次提交与上一次提交之间相隔超过一个月 - 仓库有多个贡献者 之后，完全匹配模式的仓库只剩下 14 个。我忍不住想：为什么仓库这么少？两个月前我偶然发现这些仓库的几率有多大，而整个 GitHub 上只有 14 个？应该多得多的。想象一下，如果我找到了一百万个这样的仓库，甚至只是一千个，这篇文章的标题会是什么样子。 但我接受了只有 14 个的事实，开始写这篇文章。我决定再手动检查一遍，以免不小心把无关的仓库写进文章。想象一下，当我看到它们都在 20 小时前被更新时，该有多惊讶。所以“每隔几小时更新”这个参数完全错了。这个过滤器筛选掉了所有更新不频繁的仓库。 在手动检查过程中，我还注意到一些仓库包含指向 ZIP 归档的链接，并且有最近的提交，但那次提交没有更改任何内容。而过滤器只考虑了那些在最新提交中只修改了一个 README 文件的仓库。 我还注意到，所有这些仓库的最新提交都有相同的名称：“Update README.md”。 我更改了过滤器。现在，脚本搜索的是每 24 小时更新 1 到 24 次的仓库。它找到了 40,000 个这样的仓库。 其中有 10,000 个仓库完全匹配该模式。这占了总数的 25%。 这些仓库中的每一个都包含一个带有木马的 ZIP 归档。 这些仓库已经存在了好几个月，有些甚至超过一年，而 GitHub 并没有自动检测并删除它们。 我已经在 GitHub 上发布了这些仓库的完整列表（https://github.com/orchidfiles/git-malware-finder/blob/main/full-list.txt?ref=orchidfiles.com）。用于查找此类仓库的脚本：Git Malware Finder（https://github.com/orchidfiles/git-malware-finder/?ref=orchidfiles.com） ### 未解问题 1. 为什么他们只克隆新仓库，而不是流行仓库？ 2. 为什么他们每隔几小时就删除一个提交然后推送一个新提交？ 3. 为什么 GitHub 不自动检测此类仓库？ 4. 归档中的可执行 exe 文件究竟做了什么？ 5. 这次行动的实际规模有多大？ ### 我的假设 黑客们的目标是了解系统的工作原理，找到其局限性和漏洞，并利用这些信息。如果覆盖提交有助于绕过 GitHub 的安全算法，那么他们就是这么做的。也许这也是为什么每个提交都被命名为“Update README.md”的原因。 第二个目标是传播病毒。他们是如何让人们找到并下载它的呢？我认为他们只克隆新仓库，这样新仓库就会立即出现在低搜索量关键词的搜索引擎结果顶部。他们还把这些仓库添加到流行的 GitHub 标签中，以增加被索引的机会，并帮助人们通过这些标签找到它们。 但是为什么他们要复制所有的提交和贡献者呢？毕竟，他们可以直接复制整个源代码。这样做很可能是为了建立信任。当有人访问一个仓库时，他们会看到贡献者，可以点击进入他们的个人资料，看到这些不是一天就创建的账号。而提交历史也被保留下来，这样就能清楚地表明这个仓库不是昨天才出现的。但也许这也是为了绕过 GitHub 的算法。 这些只是我的假设，实际情况可能完全不同。 ### 结论 我受到了 GitHub API 每小时 5000 次请求的限制。我优化了脚本，只搜索相关的仓库，但我认为由于过滤器的原因，脚本只找到了很小一部分仓库。GitHub 团队没有这样的限制。他们可以分析所有 5 亿个仓库，找到其中的任何归档或可执行文件，并对它们进行病毒扫描。 这次，我不会再向 GitHub 发送请求了。仓库数量实在太多了。如果你们中有人直接认识 GitHub 安全团队的人，请把这篇文章的链接发给他们。 **\* 更新** 我发现了一篇 4 月 18 日的文章：109 个虚假 GitHub 仓库如何传播 SmartLoader 和 StealC（https://hexastrike.com/resources/blog/threat-intelligence/cloned-loaded-and-stolen-how-109-fake-github-repositories-delivered-smartloader-and-stealc/?ref=orchidfiles.com）这篇文章详细解释了这种木马病毒的工作原理。当时，作者找到了 109 个这样的仓库。