200个GitHub仓库藏毒，一个假DNS扫描工具如何污染Go供应链？

一个表面无害的DNS与子域名扫描工具，如何能在GitHub上裂变出222个恶意仓库，短期内迭代出700多个带毒版本？这并非演习，而是Socket安全团队近期揭露的一场名为“Operation Muck and Load”的供应链污染行动。该行动从今年1月24日发布首个版本至今，已累计产生超过1200个模块版本，其中至少有700个版本捆绑了Windows恶意软件下载器。尽管Go安全团队接到报告后已将该模块从Go模块代理中屏蔽，但攻击者留下的自动化投毒流水线，仍足以让整个开发者社区重新审视开源依赖的真实风险。

正方观点一针见血：这种利用GitHub Actions自动产生伪版本、并将恶意代码夹带在看似正常的扫描工具中的手法，彻底击穿了常规代码审查的防线。攻击者通过每分钟一次的强制推送，制造出海量的提交记录，让一个简单的扫描器版本历史膨胀到数百个，普通维护者根本无从逐一核对。更隐蔽的是，攻击者所创建的190个一次性账户中，都嵌入了同一个指纹邮箱ischhfd83@rambler.ru，却把Git提交的用户名设置为对应仓库的主人。这样一来，每个仓库的活动记录看起来就像是不同作者的正常更新，而私底下的控制者却始终只有一个。Socket凭借这一对邮箱和工作流的同时出现，才完成了对222个恶意仓库的最低数量确认。

反方意见则认为，这次攻击虽然手法新颖，但并非无解。其一，恶意代码的最终载荷并非在模块本身，而是通过一个多层加载器从公开平台动态拉取。主程序main.go只执行一句隐藏的PowerShell命令，从muckcoding.com下载加密内容，经certutil解码后绕过执行策略去运行。其二，这个脚本被设计成Base64与XOR解密的多层结构，里面甚至还有一句土耳其语注释：“直接运行，无需其他步骤”。但最关键的载荷地址并没有硬编码在程序中，而是由一个解析器去读取Pastebin、Rlim乃至YouTube、Instagram、Telegram、Google Docs、GitCode等公开平台上的文本，搜索标记字符串“LastW”，再用内置密钥解密出真实的下载地址。只要防守方清理掉对应的粘贴内容，或封堵最终的压缩包URL，攻击者就必须同时更新这些公开投放点的内容。这意味着，攻击链条的末端其实相当脆弱，依赖大量可以被外部干预的第三方服务。

我的判断是，冷静拆解这次行动的技术骨架，会发现攻击者的狡猾与局限同样明显。局限在于，所有的后门入口都寄存在公众可编辑或可投诉的平台上，甚至最终释放的远控木马（AsyncRAT、Quasar、Remcos等）和信息窃取程序，也被打包成一个带有密码的7-Zip压缩包，存放在某个GitHub Release资产里。解压后，加载器会把文件释放到一个伪装成“Microsoft Photos”安装目录的路径下，然后以隐藏窗口启动其中的Microsoft.exe。一旦这个Release被标记并删除，整条链就会断掉。但狡猾之处就在于，攻击者根本不靠单点存活。他们准备了包括Pastebin、Rlim在内的主要投放点，以及YouTube、Instagram、Telegram等至少五六个备用渠道。无论哪一条被阻断，都只需在别处粘贴新的加密块，就能让已经在开发者电脑上潜伏的第一阶段加载器重新活跃起来。

那么，这场供应链污染的源头到底在哪里？回溯整个版本生成机制，答案指向Go语言的伪版本号设计。对于任何没有语义版本标签的提交，Go会根据提交时间戳和哈希值自动生成伪版本号。攻击者正是滥用了这一特性，通过自定义的GitHub Actions工作流，每隔一分钟就改写并强制推送一次日志文件。每一次推送，在Go模块代理看来都是一个全新的版本。于是，同一个功能简陋的扫描器，在极短时间内凭空拥有了数百个带编号的版本，极大地掩护了那些真正携带恶意代码的迭代。这种被Socket称为“版本膨胀”的技术，把传统的“查最新版本就行”的安全惯例变得几乎失效。

值得开发者警醒的是，这次被污染的模块并非无名之辈或无人问津的三无项目，而是一个具备实际网络管理功能的DNS与子域名扫描工具。正因为其表面有用，才可能被搜索、被推荐、被列入依赖清单。一旦某个开发者在本地运行了这样的工具，隐藏在PowerShell命令行里的下载器就会悄悄地开始工作，后续无论是远控木马建立持久化通道，还是窃取浏览器凭据，都只是时间问题。Socket在深度分析中已经确认，解码出的载荷同时包含了AsyncRAT、Quasar和Remcos风格的远控行为，以及普遍的信息窃取特征。

目前，这一名为“Operation Muck and Load”的行动已被报告给Go安全团队，相关模块从官方代理中移除。然而，在GitHub上是否还存在其他类似的自动化投毒项目，仍然是一个未知数。对于日常依赖开源组件的团队来说，这次事件至少给出了三点提醒：第一，不能仅凭模块的版本数量和近期提交活跃度来判断其可信度，自动化工作流完全可以批量伪造；第二，对任何执行外部命令或联网下载的依赖，都需要做更细粒度的行为审计；第三，要