文章总结： 本文揭露Go生态圈供应链投毒事件，黑客利用命名空间混淆伪造github.com/xinfeisoft/crypto模块，通过劫持ReadPassword函数窃取密码并植入Rekoobe后门。文章详细解析了从窃密到持久化控制的攻击链，并给出代码审计、版本锁定及权限控制等具体防御建议，提醒开发者警惕依赖引入风险。 综合评分： 90 文章分类： 供应链安全,恶意软件,威胁情报,安全建设

Go 开发者警惕：GitHub 惊现“套壳”代码投毒，不仅偷密码还留后门！

原创

Kit Chung Kit Chung

安全圈动向

2026年3月3日 08:06 广东

最近 Go 生态圈不太太平。作为一名在后端滚打多年的老兵，我一直觉得 Go 的依赖管理比 npm 强不少，但这次爆出的供应链投毒事件，真的给我上了一课。

如果你平时习惯在项目中直接引入 crypto 相关的库，或者正在维护涉及 SSH、密码校验的 CLI 工具，请务必花几分钟把这篇深度复盘看完。这不只是一个新闻，这是一场针对开发者“心理盲点”的精准狙击。

一、 “李鬼”出没：玩的就是命名空间混淆

这次出事的恶意模块路径是 github[.]com/xinfeisoft/crypto。乍一看，是不是觉得有点眼熟？

没错，它在深度模仿 Go 官方的加密子库镜像 github.com/golang/crypto。黑客极其聪明地利用了命名空间混淆 手法。在复杂的项目依赖树中，开发者往往只关注最后的 /crypto，而忽略了前面的组织名称。

技术槽点： Go 官方库的规范地址本应是 go.googlesource.com/crypto，但为了方便大家，GitHub 上保留了官方镜像。黑客正是利用了这种“镜像习惯”，在 GitHub 上注册了一个看起来非常正规的组织，完成了从“李鬼”到“李逵”的伪装。

二、 核心杀招：在“凭证边界”精准钩子

这个恶意模块最阴险的地方在于，它并没有改动那些复杂的算法实现，而是潜伏在了 ssh/terminal/terminal.go 文件里。它盯上了一个所有开发者都信任的函数：ReadPassword()。

1. 劫持原理解析

当你的应用（比如一个运维自动化工具）需要用户输入 SSH 密码或 API Key 时，通常会调用这个函数来读取终端输入。黑客在里面注入了以下逻辑：

• 镜像读取：

  在保证用户正常输入的同时，恶意代码会将缓冲区里的 plaintext（明文）截获。

• 实时外泄：

  截获到的敏感数据会立刻通过一个 HTTP Post 请求发送到黑客的控制端。

• 动态反弹：

  更有趣的是，控制端在接收到密码后，会即时返回一个 Base64 编码的 Shell 脚本。

  

实现难点： 黑客必须保证劫持逻辑是异步且非阻塞的，否则一旦网络波动导致终端卡顿，有经验的开发者立刻就会察觉不对劲。

三、 深度溯源：从“点火”到“屠城”的攻击链

如果说偷密码只是第一步，那后续的 Payload 展示了什么叫“专业黑产”。

第一阶段：环境“洗白”

下载回来的 Shell 脚本首先会执行“洗白”操作：

• 修改防火墙：

  将 iptables 的默认策略全部设为 ACCEPT，把服务器的“大门”直接焊死在打开状态。

• 持久化后门：

  将黑客的公钥写入 /home/ubuntu/.ssh/authorized_keys。

第二阶段：Payload 伪装术

黑客从外部服务器抓取了两个关键文件，后缀名居然是 .mp5。别误会，这不是什么新音频格式，而是为了绕过 SOC（安全运营中心）的静态文件扫描。很多防火墙会放行多媒体格式，黑客正是钻了这个空子。

Payload A： 一个轻量级的 Recon（侦察）工具，用于测试服务器的出海能力，并向 154.84.63[.]184 发起心跳。 Payload B： 名声在外的 Rekoobe 后门。

第三阶段：Rekoobe 的恐怖统治

Rekoobe 是一款非常成熟的 Linux 木马（最早可追溯到 2015 年）。它支持：

• 反弹 Shell：

  让黑客像在本地终端一样操作你的服务器。

• 文件窃取：

  自动搜索并上传服务器上的配置文件、数据库备份等。

• APT 背景：

  历史上，这款工具常被与某些高级持续性威胁（APT）组织联系在一起，足见其破坏力。

四、 避坑指南：我们该如何处理？

说实话，供应链攻击最恶心的地方就在于“失信”。但作为工程师，我们还是有几道防线可以守住：

1. 严格的代码审计

不要只看 go.mod 里的直接依赖，一定要用 go mod graph 定期巡检。一旦发现路径中出现非官方组织的 crypto、ssh 等字眼，不要客气，格杀勿论。

2. 锁定版本与校验

利用好 go.sum 文件。如果发现某个依赖的版本哈希值在没升级的情况下发生了变动，那绝对是有猫腻。同时，建议在 CI/CD 环节加入静态扫描工具。

3. 最小权限原则

为什么黑客能改你的 SSH key？因为很多项目是直接以 root 或具有 sudo 权限的用户运行的。永远不要给生产环境的 Service Account 过大的权限。

最后我想说：

在这个 AI 辅助编程的时代，我们引包的速度越来越快，但看源码的时间却越来越少。黑客利用的正是这份“快”。

你现在的项目中，有没有这种“李鬼”库？

赶紧执行一下 go list -m all | grep -i "xinfeisoft" 检查一下吧！

如果你觉得这篇文章对你有帮助，请点“赞”并转发到你的技术群里。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈动向 Kit Chung Kit Chung《Go 开发者警惕：GitHub 惊现“套壳”代码投毒，不仅偷密码还留后门！》