供应链安全的新警钟：Axios 事件回顾
在开源生态中，信任是构建现代软件的基石。然而，当这一基石被恶意篡改时，后果往往是灾难性的。近日，全球知名的 HTTP 客户端库 Axios 的 npm 账号遭到劫持，攻击者利用这一高频使用的组件，向全球数百万下游项目投递了恶意代码。
Axios 每周下载量超过一亿次，是前端和后端开发中不可或缺的基石。攻击者通过劫持维护者 Jason Saayman 的 npm 账号，发布了版本号为 1.14.1 和 0.30.4 的恶意更新。这些恶意版本在极短的时间内上线，且没有经过正常的 OIDC（OpenID Connect）验证，也未在 GitHub 上留下对应的提交记录。这一异常行为迅速引发了安全研究人员的警觉。
从我们的应急响应经验来看，类似 Axios 这样拥有极高依赖度的库一旦“沦陷”，其影响范围往往呈现指数级扩散。攻击者并非直接攻击最终用户，而是通过“污染”上游，让恶意代码顺着依赖树自动流向无数的企业生产环境。
深度拆解：精心设计的攻击链条
此次攻击并非简单的代码注入，而是一场经过周密策划的供应链投毒行动。攻击者利用了开发者对知名开源库的盲目信任，以及自动化构建流程的隐蔽性。
攻击链的核心逻辑如下：
首先，攻击者通过某种手段（目前推测为账号凭据泄露或会话劫持）获取了 Axios 维护者的 npm 账号权限。随后，他们利用这一权限向 npm 仓库推送了包含恶意逻辑的“伪更新”版本。
其次，攻击者引入了一个名为 plain-crypto-js 的恶意依赖包。在 npm 生态中，依赖项的引入是极其常见的操作，开发者往往不会仔细审查每一个深层嵌套的依赖。这个恶意包被巧妙地植入到 Axios 的构建过程中，作为整个攻击的“特洛伊木马”。
最后，恶意代码通过 npm 的 post-install 脚本触发。在开发者执行 npm install 或项目触发自动部署流水线时，恶意脚本会自动运行。它会根据宿主机的操作系统类型（Windows、macOS 或 Linux），从远程服务器下载第二阶段的 payload，从而完成 RAT（远程访问木马）的植入。
技术手法解析：隐蔽的恶意行为
从技术层面分析，攻击者的手段极为老练，旨在实现长期驻留并逃避检测。
恶意代码在设计上充分利用了 obfuscation（混淆）技术。通过混淆代码逻辑，攻击者试图绕过静态扫描工具的检测。更值得注意的是，该 RAT 具备跨平台能力，能够根据检测到的操作系统环境，自动部署适配的恶意二进制文件。例如，在 macOS 环境下，研究人员捕获到了一个功能完备的 C++ 编写的远程访问木马。
该木马的功能非常全面，包括收集系统敏感信息、与 C2（命令与控制）服务器建立通信，以及执行任意远程指令。为了掩盖行踪，攻击者还设计了“自我清理”机制。在恶意负载成功运行并建立持久化连接后，脚本会自动删除安装痕迹，并将被篡改的库文件恢复为看似正常的版本。这种“打完就跑”的策略，给后期的溯源取证带来了极大的挑战。
此外，研究人员还发现，攻击者并未局限于 Axios 本身。他们还关联了其他恶意包，例如 @shadanai/openclaw 等，这些包采用了完全相同的混淆逻辑和 C2 基础设施，甚至通过捆绑篡改后的 Axios 版本来扩大感染面。这种多点开花的攻击模式，显示出这是一次有组织、有预谋的恶意行动。
从 Solar 视角看企业面临的风险
在应急响应一线，我们经常听到企业客户抱怨：“我们明明没有修改代码，为什么生产环境会被植入后门？”这就是供应链攻击最可怕的地方——防御者往往在不知不觉中引入了威胁。
这一环节是很多企业容易忽视的：自动化构建流水线。现代 CI/CD 流程追求速度，许多企业在构建过程中会自动拉取最新的依赖包，甚至配置了自动更新策略。如果上游库被投毒，企业的构建服务器就会直接成为恶意软件的“孵化器”。
类似攻击近年来明显增加，且呈现出自动化、隐蔽化的趋势。攻击者不再追求大规模的暴力攻击，而是更倾向于深耕开源生态，寻找拥有广泛用户群的“中间件”或“基础库”。一旦成功，受害者不仅仅是个人开发者，更包括那些依赖这些库构建业务系统的企业。
对于企业而言，单纯依赖代码仓库的防火墙已经不够了。如果你的项目依赖了 Axios，即便现在看起来没有异常，我们依然建议进行彻底的排查。因为恶意代码可能已经执行完毕并删除了痕迹，系统内可能留下了持久化的后门。
针对性安全建议与加固方案
面对供应链投毒，防御的核心在于“零信任”原则的落地。Solar 应急响应团队建议企业采取以下措施：
第一，严格锁定依赖版本。不要在 package.json 中使用过于宽松的版本范围（如 ^ 或 *）。请务必使用 lock 文件（如 package-lock.json 或 yarn.lock）锁定具体的版本哈希值，确保构建环境的一致性，防止自动拉取到被篡改的新版本。
第二，建立依赖审查机制。利用专业的软件成分分析（SCA）工具，对项目中的第三方依赖进行定期扫描。重点关注新增依赖、来源不明的依赖以及版本更新频率异常的库。如果发现类似 plain-crypto-js 这种可疑的、非预期的依赖，必须立即隔离。
第三，加强账号安全管理。对于开源维护者而言，强制启用多因素认证（MFA）和 OIDC 验证是防止账号被劫持的最有效手段。对于企业而言，如果内部开发使用私有 npm 镜像库，应建立严格的审核流程，对从公网同步的包进行安全预审。
第四，监控异常网络行为。RAT 运行离不开与 C2 服务器的通信。企业应在网络出口处部署流量分析和监测设备，及时发现服务器发出的异常外连请求，特别是那些指向未知 IP 或域名的流量。
最后，如果您在实际业务中发现项目依赖存在异常，或者怀疑系统已遭受此类供应链投毒，请务必立即封禁受感染的服务器，备份内存镜像进行深度取证，并及时更新相关依赖库至官方修复版本。
供应链安全是一场持久战，没有绝对的防线。保持警惕，落实最小权限原则，并建立完善的应急响应机制，是每一家技术企业必须面对的课题。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com