loading...
开发者习惯性地执行 npm install，这一步在过去十年几乎等同于“正常流程”。但现在，这个动作正在变成攻击入口之一。
微软威胁情报团队披露的这次事件并不复杂，复杂的是它的隐藏方式。两个被污染的npm包（分别对应[email protected]与[email protected]）在公共仓库中看起来并无异常，但实际被嵌入远程访问木马（RAT）。安装之后，恶意代码会在本地静默运行，开始记录键盘输入、截取屏幕画面，并尝试抓取加密钱包凭证。
这一类攻击已经不是“传统木马”那种粗糙植入，更像是针对开发环境的长期潜伏。目标也很明确：不是破坏系统，而是等待敏感行为发生——比如钱包签名、助记词输入、交易授权。
比较值得注意的不是npm本身，而是数据外泄路径的选择。攻击者没有使用常见的自建服务器，而是将Hugging Face仓库当作中转基础设施。这个细节改变了整个攻击链的观感。
Hugging Face在开发者社区里是一个高度信任的平台，尤其在机器学习与AI模型分发领域，它的流量通常被安全系统默认归类为“正常通信”。攻击者正是利用这一点，把数据外泄伪装成普通的模型调用或资源访问请求。
换句话说，问题不再是“有没有加密传输”，而是“传输发生在什么地方”。当攻击流量嵌入一个被广泛信任的AI基础设施时，传统的安全过滤机制会变得迟钝。
npm生态本身对这类问题并不陌生。供应链攻击在JavaScript世界里已经反复出现过多次，从依赖劫持到恶意包伪装，每一次的模式都不太一样，但核心逻辑相似：攻击者不再直接攻击用户，而是攻击开发者的工具链。
这次的特殊之处在于目标群体变了。加密货币用户和开发者被同时纳入攻击范围，意味着攻击者关注的不是单一资产，而是“开发-部署-交易”这条完整路径。键盘记录、屏幕截图、钱包凭证，组合在一起已经足够重建一个用户的资产操作轨迹。
从行业角度看，这类攻击之所以持续存在，一个现实原因是依赖链太长。现代前端和后端开发往往依赖成百上千个开源包，而其中任何一个环节都可能成为入口。安全审计通常集中在核心代码，但供应链问题恰恰发生在边缘依赖。
微软在警告中提到的建议并不复杂：审计近期安装的包、移除可疑依赖、检查钱包活动。这些措施听上去基础，但在真实开发节奏里往往被忽略。尤其是快速迭代环境下，依赖更新频率高，安全检查容易被视为“延迟成本”。
更深一层的问题在于信任结构的外溢。Hugging Face这种平台在AI时代承担的是“模型分发基础设施”的角色，它本身并不等同于安全组件，但在开发者心智中却逐渐被默认安全化。这种心理预期反而给攻击者留下了可利用空间。
类似的路径在过去的云服务滥用案例中也出现过。攻击者不会去攻击防火墙，而是选择把恶意行为嵌入被默认放行的服务通道里。只要流量“看起来合理”，安全系统就很难触发警报。
加密行业在这一轮事件中再次成为高频目标并不意外。钱包凭证、签名行为、私钥相关输入，本质上都是高价值瞬时数据。一旦在开发端被捕获，后续链上再强的安全机制也无法逆转。
更现实的变化是，攻击已经不再发生在“链上”，而是提前到了“链前”。开发环境、依赖包、模型仓库，这些原本被视为基础设施的部分，现在正在成为新的攻击面。
npm只是入口之一，Hugging Face只是通道之一。真正发生变化的，是攻击者开始把注意力放在“开发者日常路径”上。代码还没运行到生产环境，风险已经提前埋进依赖树里。
103
105
