跳到主内容
返回博客供应链安全

Axios供应链投毒事件深度分析：朝鲜APT组织劫持亿级下载量npm包植入远控木马

2026/4/2·26 阅读·
供应链攻击npm投毒Axios远控木马朝鲜APT软件供应链安全

2026年3月31日，周下载量超1亿的JavaScript HTTP客户端库Axios遭遇供应链投毒攻击。攻击者劫持维护者npm账户，发布两个携带恶意依赖的版本（1.14.1和0.30.4），通过postinstall钩子静默部署跨平台远控木马（RAT）。事件已被Google和Microsoft威胁情报团队归因于朝鲜关联威胁组织。本文从攻击链、技术细节、IOC及防御加固角度进行全面分析。

事件概况

属性 信息
事件类型 npm供应链投毒（账户劫持）
受影响包 axios@1.14.1、axios@0.30.4
恶意依赖 plain-crypto-js@4.2.1
植入载荷 跨平台远控木马（WAVESHAPER.V2）
周下载量 ~1亿（npm生态 Top 10）
攻击时间 2026年3月31日 00:21 - 03:15 UTC
威胁归因 UNC1069 / Sapphire Sleet（朝鲜关联）
归因来源 Google Threat Intelligence、Microsoft Threat Intelligence

2026年3月31日，全球使用最广泛的JavaScript HTTP客户端库之一——Axios，遭遇了一次高度复杂的供应链投毒攻击。攻击者通过劫持Axios核心维护者jasonsaayman的npm账户，连续发布两个携带恶意依赖的版本，利用npm的postinstall钩子机制在开发者执行npm install时静默部署远控木马。

该事件的影响规模堪比2021年的ua-parser-js投毒事件和event-stream事件，是有史以来针对npm Top 10包的最复杂供应链攻击之一。

攻击时间线

时间 (UTC) 事件
3月30日 05:57 攻击者发布无害的 plain-crypto-js@4.2.0（伪装为crypto-js）
3月30日 23:59 发布恶意版本 plain-crypto-js@4.2.1（含RAT投放器）
3月31日 00:21 使用被劫持账户发布 axios@1.14.1（注入恶意依赖）
3月31日 01:00 发布 axios@0.30.4（同样注入恶意依赖）
3月31日 ~03:15 npm团队下架两个恶意版本
4月1日 Google/Microsoft公开威胁归因

从恶意版本发布到下架，窗口期约3小时。在此期间执行过npm install且项目依赖axios的开发者和CI/CD管道均面临感染风险。

攻击链分析

第一阶段：账户劫持

攻击者获取了Axios核心维护者jasonsaayman的npm账户凭据，并将账户关联邮箱修改为攻击者控制的ifstap@proton.me。这使攻击者获得了向axios包发布新版本的权限。

第二阶段：恶意依赖注入

攻击者没有直接修改axios的源码，而是采用了更隐蔽的方式——在package.json的dependencies中添加了一个看似无害的加密库依赖：

{
  "dependencies": {
    "plain-crypto-js": "^4.2.1"
  }
}

plain-crypto-js是攻击者预先注册的恶意包，名称模仿了广泛使用的crypto-js库。该包在4.2.0版本中不含恶意代码（用于规避npm审核），在4.2.1版本中才植入恶意载荷。

第三阶段：RAT投放

plain-crypto-js@4.2.1的package.json中包含postinstall钩子：

{
  "scripts": {
    "postinstall": "node setup.js"
  }
}

setup.js是一个4.2KB的混淆Node.js脚本，使用XOR加密（密钥：OrDeR_7077）隐藏真实逻辑。执行后根据操作系统类型下载并运行对应的远控载荷：

macOS：

  • 下载RAT到 /Library/Caches/com.apple.act.mond
  • 通过AppleScript和/bin/zsh执行
  • 伪装为macOS系统服务

Windows：

  • 复制PowerShell到 %PROGRAMDATA%\wt.exe
  • 释放.ps1和.vbs脚本到临时目录
  • 建立持久化机制

Linux：

  • 下载Python投放器到 /tmp/ld.py
  • 通过nohup python3后台执行

第四阶段：反取证

载荷部署完成后，投放器执行三步清理：

  1. 删除自身（setup.js）
  2. 删除恶意package.json
  3. 将预置的干净存根package.md重命名为package.json，其中版本号标记为4.2.0

这一手法造成版本号不匹配，使安全扫描工具误判为安全版本，显著增加了检测难度。

C2基础设施与IOC

网络指标

类型 值
C2 域名 sfrclak.com
C2 IP 142.11.206.73
C2 端口 8000
载荷URL http://sfrclak.com:8000/6202033
回连域名 packages.npm.org（伪装为npm官方）

回连路径（按平台）

  • macOS: packages.npm.org/product0
  • Windows: packages.npm.org/product1
  • Linux: packages.npm.org/product2

文件哈希

包名 SHA-1
axios@1.14.1 2553649f2322049666871cea80a5d0d6adc700ca
axios@0.30.4 d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
plain-crypto-js@4.2.1 07d889e2dadce6f3910dcbc253317d28ca61c766

本地感染痕迹

平台 路径
macOS /Library/Caches/com.apple.act.mond
Windows %PROGRAMDATA%\wt.exe
Linux /tmp/ld.py

威胁归因

Google Threat Intelligence Group将此次攻击归因于UNC1069，Microsoft Threat Intelligence将其归因于Sapphire Sleet，两者均指向朝鲜关联的以经济利益为动机的威胁组织。

该组织此前已有多次针对开发者和加密货币行业的供应链攻击记录。此次攻击中部署的后门被标记为WAVESHAPER.V2，是该组织已知工具集的升级版本。

检测与排查

快速自查

# 检查是否安装了恶意版本
npm ls axios | grep -E "1\.14\.1|0\.30\.4"

# 搜索恶意依赖（存在即确认感染）
find . -path "*/plain-crypto-js" -type d 2>/dev/null

# 检查lockfile
grep "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

感染痕迹扫描

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

# Linux
ls -la /tmp/ld.py 2>/dev/null

# Windows (PowerShell)
# Test-Path "$env:PROGRAMDATA\wt.exe"

网络层检测

在防火墙/SIEM中检查是否存在以下连接：

  • 出站连接到 142.11.206.73:8000
  • DNS解析 sfrclak.com
  • HTTP请求 packages.npm.org/product[0-2]

修复与加固

立即修复

# 降级到安全版本
npm install axios@1.14.0
# 或
npm install axios@0.30.3

# 在package.json中锁定版本，防止自动升级
# "axios": "1.14.0"  （去掉^前缀）

如已感染

  1. 假设完全沦陷 —— 开发机上的所有凭据、密钥、Token均应视为泄露
  2. 轮换所有密钥 —— 包括npm token、Git凭据、云服务密钥、数据库密码、API密钥
  3. 检查CI/CD —— 审查构建管道是否拉取过恶意版本，检查构建产物完整性
  4. 终端取证 —— 保留感染痕迹后重装系统

长期防御

依赖管理策略：

  • 使用lockfile锁定依赖版本，避免自动拉取最新版
  • 配置npm最小发布年龄策略（建议7天以上）
  • 使用npm install --ignore-scripts禁用postinstall钩子，再手动审查

供应链安全工具：

  • 部署Socket.dev、Snyk或Mend等SCA工具监控依赖变更
  • 在CI中集成依赖审计：npm audit
  • 启用npm的2FA强制策略

组织层面：

  • 建立关键依赖清单，监控其维护者账户异常
  • 制定供应链安全事件响应预案
  • 定期审计node_modules中的postinstall脚本

总结

Axios投毒事件再次印证了软件供应链安全的脆弱性：一个维护者账户的沦陷，就能影响全球数百万项目。攻击者选择在深夜发布、使用名称伪装、实施反取证清理，展现了国家级APT组织在供应链攻击中的高度专业化。

对于使用npm生态的开发团队，这不是"是否会遇到"的问题，而是"何时遇到"的问题。锁定依赖版本、禁用自动脚本执行、部署依赖监控，是当前最务实的防御策略。

参考链接

  • The Hacker News: Axios Supply Chain Attack Pushes Cross-Platform RAT
  • StepSecurity: axios Compromised on npm - Malicious Versions Drop RAT
  • Microsoft Security Blog: Mitigating the Axios npm supply chain compromise
  • Google Cloud Blog: North Korea-Nexus Threat Actor Compromises Axios NPM Package
  • SOCRadar: Axios npm Hijack 2026 - Everything You Need to Know
咨询相关安全服务