一条LinkedIn消息里的后门

上周我收到一条 LinkedIn 消息。一个自称加密货币初创公司招聘官的人，问我能不能帮他看看一个公开的 GitHub 仓库——“有个废弃的 Node 模块问题，我们团队搞不定”。

语气诚恳，项目看起来很普通，招聘官的身份信息也很完整。一切都正常——但这正是让我不舒服的地方。

不寻常的招聘#

我做安全这行有些年头了。这条消息本身没什么问题，LinkedIn 上每天都有招聘官发来类似的请求。但有两个细节让我警觉：第一，对方是一家很小的加密初创公司，却在为一个跟我专业方向八竿子打不着的 Node 模块问题专门找人；第二，他让我去看的那个 GitHub 仓库，README 写得条理分明，代码结构也相当规范，怎么看都不像”团队搞不定的烂摊子”。

我的直觉告诉我：这不正常。

这种”请帮忙检查代码”的借口在钓鱼攻击中太常见了。攻击者会把你引向一个看似无害的开源项目，然后等你 clone 下来，运行 npm install——后门就在那一刻被激活。

多疑的代价是五美元#

我没有直接在本地机器上碰那个仓库。我花了五美元，开了一台一次性 VPS——用完就销毁，跟它有关的所有东西都不会碰我的主力环境。

但我仍然不想亲手跑它的代码。我想到了一个更安全的办法：用一个只读的 AI Agent 来审查代码。我选了 Pi，一个没有代码执行能力的 AI 工具，只能读文件、分析文本，不会误触任何恶意脚本。

我把仓库拉下来，然后让 Pi 去检查。它只花了不到一秒。

“找到了，“Pi 说。

藏在测试文件里的 URL#

后门藏在一个看似无害的位置：app/test/index.js。

表面上这是一个测试文件，符合 Node 项目的标准结构。但 Pi 发现，这个文件里藏着一个用代码碎片拼接起来的 URL：

https://rest-icon-handler.store/icons/77

这串地址不是写死在字符串里的，而是被分割成了多个片段，在运行时拼接而成——这是典型的绕过代码审查的手段。任何人快速扫一眼只会看到一堆无关的字符碎片，但程序执行时会把这些碎片组合成一个完整的 URL，向远程服务器发请求。

一旦请求发出，攻击者的服务器可以返回任意指令。这个后门的工作方式很简单：你运行npm install，它立刻执行——因为package.json里配置了prepare脚本，这是 npm 的生命周期钩子，在包安装完成后自动触发。你甚至不需要运行项目，只需要安装依赖，后门就已经被激活了。

攻击者控制着那个远程服务器，任何时候都可以下发新的恶意负载。这台 VPS、这个 npm 包、整个项目，本质上是一个钓鱼陷阱，等着有人上钩。

被冒用的身份#

我决定演下去。我回复那位招聘官说”看起来没什么问题”，然后观察他的反应。

有意思的事情发生了。前几分钟他还在扮演一个不懂技术的招聘人员，聊着聊着，突然摇身一变，成了一个对 npm 和 Node 版本如数家珍的技术专家。身份切换之快，令人咋舌。

我顺着他的身份做了一些调查。LinkedIn 上的那个招聘官身份是伪造的——一个真实的艺术记者被冒用了身份。他和那家加密初创公司毫无关系，很可能连他自己都不知道自己的名字被挂在了 LinkedIn 上。

GitHub 仓库的历史记录显示有 39 次提交，被归到一个真实开发者的名下。但这名开发者已经不是第一次被冒充了——他的名字之前就被用在过类似的恶意仓库里。

攻击者精心准备了这一切：伪造的 LinkedIn 资料、盗用的真实身份、看上去完全正常的代码仓库。每一个环节都经得起粗略的检查。

我学到了什么#

截至我写下这篇文章时，那个仓库仍然在线，仍然可以通过npm install触发后门。没有任何人封锁它，GitHub 也没有标记它。

这件事让我确信两件事。

第一，疑心不是弱点。花五美元开一台一次性 VPS，花五分钟用 AI Agent 审查代码，这些看似”过度”的安全措施，恰恰是保护自己的最小成本。如果我在本地直接运行npm install，我的机器可能已经被控制了。

第二，AI Agent 在安全审计中的价值被严重低估了。一个只读的 AI 工具，没有执行权限，不会触发任何恶意代码，却能在一秒之内发现人类肉眼可能错过的东西。它不会累，不会被分心，不会对”看起来正常”的文件降低警惕。

这种攻击方式还会继续。LinkedIn 上的社会工程、经过伪装的 GitHub 仓库、藏在 npm 生命周期钩子里的后门——这些手段并不新颖，但它们组合在一起，仍然能够骗过大多数人。

下次有个招聘官让你帮忙看看代码——先假设它是有毒的。花几块钱开一台 VPS，用一个只读的 AI Agent 去看一眼。这个习惯，值得养成。

来源：Roman Imankulov | Hacker News