56 秒内 634 个密码

一名开发者——安全意识强、经验丰富、平时会主动识别骗局的人——经历了一家虚假公司的多阶段面试流程。HR 初面。两名工程师参与的技术面试。配有团队照片的真实网站。真实的 LinkedIn 资料。数周的关系经营。

随后，对方要求他在共享屏幕时运行一个简短的编程测试。

56 秒后，攻击者拿到了 634 个保存在 Chrome 中的密码、macOS 钥匙串文件（其中包含解密这些密码的密钥），以及 MetaMask 钱包数据。

攻击是如何实施的

GitHub 仓库看起来很干净。几个后端文件，没有任何可疑之处。但其中一个依赖项——winston-middleware，一个听起来很普通的日志包——自身还带有一个依赖：next-runtimejs。

武器就藏在这里。

npm install 一运行，一段 shell 脚本便静默执行。没有提示，没有警告。它下载了一个用 Go 编写的后门，并将其注册为每次开机自动启动。

这不是脚本小子的工具。自定义 RC4 加密的 C2 协议。具备 shell 执行、文件窃取、Chrome 密码提取、钥匙串外传以及加密货币钱包定向窃取的命令。构建得相当专业。

后门在 16:16:37 启动。16:17:33，Chrome 密码被访问。开发者注意到 macOS 弹出了一条关于对外连接的提示，并在一分钟内关闭了 WiFi——但损失已经造成。

为什么这轮面试很关键

这种攻击如果以冷邮件形式发起，必然失败。陌生人说"运行这个仓库"，没人会理会。

但在两轮面试之后呢？在大家一起嘲笑针对开发者的虚假招聘骗局有多猖獗之后呢？在其中一位面试官笑着说"欢迎来找找有没有后门"之后呢？

这时您的戒备就放下了。信任才是可利用的漏洞，恶意软件只是载荷。

这位开发者说得最到位："如果发生在我身上，就可能发生在您团队的任何一个人身上。"

Chrome 保存的密码究竟意味着什么

Chrome 使用 AES 加密保存的密码。解密密钥存储在 macOS 钥匙串中。攻击者在不到一分钟内把这两个文件都偷走了。

每一个保存的密码——网银、邮箱、GitHub、云控制台——在他们那边都是可读的。钥匙串文件可以离线破解，且没有速率限制。开发者不得不把所有密码都轮换一遍。

这就是浏览器保存密码的暗面：它们是用一把同样存放在本机上的密钥加密的。机器一旦被攻破，"加密"就只是装饰。

朝鲜的攻击模式

这位开发者提到，他的上一家公司也在三个月前被朝鲜黑客攻破过。这就是"Contagious Interview"（传染式面试）行动——朝鲜国家背景的攻击者通过虚假招聘面试在开发者机器上植入恶意软件。

这不是随机行为。他们专门针对开发者，因为开发者手中有生产环境凭证、签名密钥、云基础设施，以及——越来越多的——能进一步访问更多资源的 AI agent 令牌。

其规模是工业化的。用生成人脸伪造公司。精心打磨的网站。持续数周的面试流程。他们愿意投入，因为回报足够高。

"密码管理器也没用"

这位开发者在讨论中提出了一个有意思的说法："如果他们通过这种后门拿到了你电脑的访问权，密码管理器也帮不上忙，因为他们之后可以传输任何文件，专门为你定制漏洞利用，还有键盘记录、截屏。"

这话一半对，一半不对。

对于把密码库存在本地磁盘、靠您手动输入主密码解锁的密码管理器——确实，一个具备键盘记录和文件访问能力的后门可以将其攻破。

但对于密钥与硬件绑定的密码管理器——解密密钥由实体认证器派生，且从不以文件形式存在于磁盘上——情况则有本质区别。后门可以窃取文件、记录击键、截屏。但它无法提取一把只在实体点按期间存在于硬件安全模块内部的密钥。

那 634 个 Chrome 密码之所以被窃取，是因为加密数据和解密密钥都是文件系统上的文件。如果解密密钥需要物理持有某个设备才能使用，窃取文件最多只会得到一堆密文，仅此而已。

该怎么做

• 永远不要在您的主力机器上运行面试代码。使用虚拟机或单独的设备。
• 对任何不熟悉的仓库，先运行 npm install --ignore-scripts，再决定是否执行
• 使用出站防火墙（Little Snitch、LuLu），在出现新连接时告警
• 停止在 Chrome 中保存密码。彻底停止。
• 加密货币放在硬件钱包里，不要放在浏览器扩展中
• 将招聘方发来的每一个编程测试都视为潜在敌意，无论此前已经通过多少次电话

这位开发者之所以幸免，是因为 macOS 的弹窗及时捕捉到了那条对外连接。大多数人会想都不想就点"允许"。

56 秒。仅此而已。