Megalodon 攻击者滥用 GitHub Actions，向 5500 个代码仓库注入恶意提交

凌晨三点的监控告警往往最让人头皮发麻。SafeDep 安全团队在那个寻常的五月夜晚目睹了一场堪称教科书级别的 CI/CD 管道渗透——攻击者没有暴力破解没有钓鱼邮件只是优雅地利用了几枚被遗忘的访问令牌便在六个小时内将恶意工作流注入了五千多个公共仓库。当 CI/CD 维护变成特洛伊木马这场被命名为 Megalodon 的攻击活动核心手法堪称灯下黑。攻击者没有直接上传可疑文件而是伪装成再普通不过的构建优化提交。那个看似无害的提交哈希acac5a9作者署名为build-bot build-systemnoreply.dev提交信息写着ci: 添加构建优化步骤——对于每天处理数百次自动化提交的 DevOps 工程师来说这几乎是隐形 camouflage。研究人员在复盘时发现恶意提交直接推送到主分支全程没有 Pull Request 流程也没有合并记录。这种直球操作背后暴露的是被盗用的个人访问令牌PAT和部署密钥的滥用。更棘手的是截至报告发布时部分恶意提交仍然堂而皇之地躺在主分支上仿佛从未有人察觉。双载荷架构SysDiag 与 Optimize-Build 的协同狩猎Megalodon 并非单一武器出击而是精心设计了两种互补的攻击载荷。第一种载荷 SysDiag 走的是常驻路线。它将混淆后的 Bash 脚本直接嵌入 GitHub Actions 工作流伪装成环境诊断步骤。每当开发者推送代码或发起 PR这个诊断工具便会悄然启动像吸尘器一样收集 CI 执行环境中的敏感信息——AWS 凭证、GCP 服务账户、SSH 私钥、Kubernetes 配置甚至是 Shell 历史记录无一幸免。第二种载荷 Optimize-Build 则玩的是按需触发的游击战术。它利用workflow_dispatch事件类型平时潜伏不动只有在攻击者远程触发时才会苏醒。Tiledesk 仓库的入侵正是这一手法的典型案例。虽然运行痕迹相对明显但正因为触发频率低反而更容易被淹没在海量的 Actions 日志中。两种载荷最终都会将窃取的密钥外泄到位于216.126.225.129:8443的 C2 服务器。这个 IP 像是一个黑洞无声地吞噬着全球开发者的数字资产。伪造时间戳从 TeamPCP 继承的祖传手艺OX Security 的后续分析揭示了一个耐人寻味的细节。攻击者在提交记录中使用了硬编码的历史日期试图让恶意提交看起来像是几个月前的正常维护操作。这种时间旅行手法并非 Megalodon 首创——它与此前广泛传播的 TeamPCP 攻击活动存在明显的技术同源性。这种伎俩之所以阴险是因为它直接攻击了开发者的认知盲区。当我们查看 Git 历史时往往默认时间戳是可信的很少会怀疑一个三个月前的构建优化提交实际上是在上周偷偷塞进来的。重灾区扫描从 Wiznet 到 Persian-tools 的连锁反应受影响的项目名单读起来像是一份开源世界的名人录。Wiznet 的ioLibrary_Driver仓库首当其冲这个被广泛使用的物联网驱动库累计收到了超过两千次恶意提交。Tiledesk 的四个相关仓库和 Persian-tools 的四个代码库同样未能幸免恶意版本从2.18.6一路蔓延到2.18.12横跨整整三天。对于依赖这些项目的下游开发者而言风险是指数级扩散的。一次npm install或git clone可能就会将带有后门的 CI 配置引入自己的构建管道形成典型的供应链污染。如何在你的仓库里捉鬼SafeDep 在报告中给出了几个实用的排查信号。如果你发现仓库的 Actions 选项卡里突然冒出了陌生的workflow_dispatch运行记录或者云端的审计日志里出现了来自未知工作流的 OIDC 令牌请求——这些就是红得发紫的警报。具体自查清单可以围绕以下几个维度展开定期扫描 Git 历史中的异常作者信息。除了build-bot攻击者还使用了auto-ci、ci-bot等伪造身份这些命名刻意模仿主流 CI 平台的默认机器人账户极具迷惑性。审查所有直接推送到主分支的提交特别是那些绕过了 PR 流程的幽灵提交。在现代化的协作流程中这本身就是反模式。对于使用云厂商 OIDC 联合身份验证的团队务必开启云审计日志的异常检测。当 GitHub Actions 工作流突然向 AWS 或 GCP 请求临时凭证时任何不符合预期的工作流名称都值得深挖。令牌泄露背后的系统性脆弱Megalodon 事件最深刻的教训或许不在于攻击技术有多精妙而在于它暴露了一个长期被忽视的软肋访问令牌的生命周期管理。被盗用的 PAT 和部署密钥往往是某个离职工程师的测试凭证或是某个被遗忘的自动化脚本留下的数字遗产。这些令牌一旦泄露攻击者获得的不是某个文件的读取权限而是对整个仓库配置的直接改写权。在 GitHub Actions 的语境下这意味着他们可以修改.github/workflows目录下的 YAML 文件将任意代码注入 CI 执行环境——而 CI 环境通常持有比生产环境更广泛的密钥和权限。写在最后供应链安全的零信任觉醒这场六小时五千库的闪电战给开源社区敲响了警钟。当我们越来越依赖自动化工作流来构建、测试和部署软件时CI/CD 管道本身已经成为攻击者的首选跳板。Megalodon 不是第一个利用 GitHub Actions 的攻击活动也绝不会是最后一个。对于项目维护者现在或许是重新审视令牌策略的最佳时机启用最小权限原则、定期轮换部署密钥、强制要求所有提交必须经过 PR 审查。对于普通开发者在引入依赖时多留一个心眼——那个看起来人畜无害的构建优化提交背后可能藏着一头饥饿的巨齿鲨。