Axios 遭供应链攻击：不是简单版本问题，而是 npm 依赖注入恶意后门！开发者必看紧急提醒（新增 EDR & NIDS 检测策略）

大家好，最近前端和 Node.js 社区又炸锅了。

知名 HTTP 请求库 Axios（每周下载量超过 1 亿次）刚刚遭遇了一次严重的供应链攻击。这次攻击不是传统的 typosquatting 或普通账号劫持，而是攻击者通过注入一个看似无关的依赖包，在安装时悄悄植入远程访问木马（RAT）。

攻击细节曝光

攻击者没有直接修改 Axios 的核心代码，而是巧妙地在 axios@1.14.1 和 axios@0.30.4 这两个版本中，注入了一个从未被 Axios 实际使用的依赖包：

plain-crypto-js@4.2.1

这个包的唯一作用，就是在 postinstall 脚本中执行恶意操作：

  • 安装后立即向 C2 服务器（sfrclak[.]com / IP: 142.11.206.73，完整 URL：http://sfrclak.com:8000/6202033）发起请求，下载平台特定的第二阶段 payload。

  • 支持跨平台：macOS、Windows、Linux。

  • 执行完成后，恶意脚本会立刻覆盖自己的 package.json 为干净版本，抹除安装痕迹，让事后检查 node_modules 几乎看不出异常。

这意味着：即使你只看 Axios 的源码或 GitHub Tag，也很难发现问题。版本号本身不再是可靠的信号。

受影响版本

  • axios@1.14.1

  • axios@0.30.4

  • plain-crypto-js@4.2.1（恶意依赖）

需要检查的持久化痕迹（Persistence Artifacts）

如果你的机器可能已中招，请立刻排查以下路径：

  • macOS：/Library/Caches/com.apple.act.mond

  • Windows：%programdata%\wt.exe

  • Linux：/tmp/ld.py

同时，检查网络日志中是否有对 sfrclak[.]com 或 IP 142.11.206.73 的 outbound 连接（尤其是端口 8000）。

立即修复建议

  1. 降级 Axios：

    • 1.x 系列 → 使用 axios@1.14.0
    • 0.x 系列 → 使用 axios@0.30.3

    推荐在 package.json 中使用 overrides 或 resolutions 强制锁定安全版本。

  2. 旋转所有密钥：立即更换所有 Secrets、API Key、Token 等敏感凭证。

  3. CI/CD 加固：在 npm install、yarn install、pnpm install 时添加 --ignore-scripts 参数，阻断 postinstall 脚本执行。

  4. 加强依赖验证：单纯的版本 pinning 已不够用，建议引入 artifact hash 验证或开源工具（如 ReleaseGuard）。

新增：EDR 系统检测参考策略（适用于 CrowdStrike、SentinelOne、Microsoft Defender for Endpoint、Elastic EDR 等）

EDR 重点监控“行为”而非仅签名，针对本次攻击可快速配置以下规则：

  • 进程行为监控：
    检测 node / npm 进程在 postinstall 阶段发起外联（尤其是 child_process.exec 执行 curl、wget、powershell 或 python 下载 payload）。
    关键字：setup.js 执行 + HTTP 请求到未知域名。

  • 文件创建/修改规则（File Path Monitoring）：

    • macOS：创建或修改 /Library/Caches/com.apple.act.mond
    • Windows：创建 %PROGRAMDATA%\wt.exe（或 ProgramData 目录下以 .exe 结尾的可疑文件）
    • Linux：创建 /tmp/ld.py（或 /tmp 目录下以 .py 结尾的脚本）

  • 命令行异常检测：
    阻断来自 node_modules 目录下的 PowerShell / sh / python 进程执行 base64 解码或下载命令。
    常见 Sigma 规则关键词：npm postinstall + Invoke-WebRequest / curl -o。

  • 持久化行为：
    监控注册表（Windows）或 LaunchAgents（macOS）中出现 wt.exe / com.apple.act.mond 相关项。

大多数商用 EDR 已可通过“Living off the Land” + “Suspicious Script Execution” 策略自动告警，建议立即开启 npm 相关行为策略并回溯过去 24 小时安装记录。

新增：NIDS 检测参考策略（适用于 Suricata、Snort、Zeek、Wireshark 等）

NIDS 重点捕获网络层异常，推荐以下签名规则（可直接复制到规则文件中）：

  • DNS 查询规则（Suricata 示例）：

    alert dns any any -> any any (msg:"[Axios RAT] C2 DNS Query"; dns.query; content:"sfrclak.com"; nocase; sid:1000001; rev:1;)

  • HTTP/TCP 连接规则：

    alert tcp any any -> 142.11.206.73 8000 (msg:"[Axios RAT] C2 Connection"; flow:to_server,established; content:"6202033"; sid:1000002; rev:1;)

  • HTTP Payload 特征：
    匹配 POST/GET 请求中包含 packages.npm.org/product0/1/2 或特定 User-Agent（npm 相关），结合 C2 域名。
    Zeek 脚本可监控 http.log 中 host == "sfrclak.com" 的记录。

  • 异常流量：
    监控 CI/CD 服务器或开发者机器在 npm install 期间出现非 npm registry（registry.npmjs.org）的 outbound HTTP/HTTPS 流量。

建议将以上规则优先级调高，并对匹配流量进行包捕获（PCAP）留存取证。

这次事件再次敲响警钟

供应链攻击越来越隐蔽。攻击者可通过劫持 maintainer 账号，直接向 npm registry 推送带毒版本，而不走 GitHub Release 流程。

传统依赖锁定策略已无法完全防御这类“干净外表 + 隐藏后门”的攻击。

你所在的团队目前是如何应对 npm/PyPI 等供应链风险的呢？

  • 是单纯依赖 package-lock.json + 版本 pinning？

  • 还是已经引入 SBOM、hash 验证、EDR/NIDS 规则、或 --ignore-scripts？

  • 有没有在用 ReleaseGuard / Safe Chain / Aikido 等开源/商用工具？

欢迎在评论区分享你的做法，一起交流经验。安全从来不是一个人或一个工具的事，而是整个开发生态的共同责任。

行动起来：

  1. 立刻检查项目依赖，降级 Axios；

  2. 开启 EDR/NIDS 相关检测规则；

  3. 加强 CI 安全策略。

别让一次 npm install 就让整个生产环境沦陷。

安全第一，代码第二。保持警惕，保护好你的供应链！

（本文基于 StepSecurity、Socket.dev 等公开技术分析整理，2026年3月31日最新事件。如有最新进展会及时跟进。建议关注 Axios 官方仓库、npm 安全公告及 StepSecurity 博客。）

如果你正在用 Axios，赶紧去检查 + 配置 EDR/NIDS 吧！有任何疑问或补充检测规则，欢迎留言讨论～

#前端安全 #供应链攻击 #npm安全 #Axios #EDR #NIDS #Nodejs开发 #网络安全