RAT 使用 npm 上的恶意 Axios 版本进行分发

信息技术数字 » 资源 » RAT 使用 npm 上的恶意 Axios 版本进行分发

JavaScript 开发社区刚刚经历了一次令人担忧的事件，它迫使人们重新审视对依赖项的信任程度，库漏洞问题就是一个例证。Axios是生态系统中最广泛使用的 HTTP 库之一，它在 npm 上被篡改，通过看似合法的版本传播远程访问木马 (RAT)。虽然事件只持续了几个小时，但它清楚地表明，软件供应链的脆弱程度远超许多人的想象。

真正的问题不仅仅在于攻击者成功地将恶意软件偷偷植入每周下载量达数千万甚至数亿次的软件包中。更严重的是，他们通过劫持主要维护者的 npm 账户，发布了看似正常的“官方”版本，这些版本并未触及 Axios 源代码的任何一行。所有恶意行为都隐藏在一个专门为此次攻击设计的虚拟依赖项中。

Axios 是如何对 npm 做出承诺的？

要了解此次事件的严重性，我们需要从入口点说起。攻击者成功控制了 Axios 的主要维护者“jasonsaayman”的 npm 账户，并将关联的电子邮件地址更改为他们控制的、托管在 Proton Mail 上的邮箱地址。从那时起，他们就可以像维护者一样随意发布该软件包的新版本。

利用这些凭证，他上传了两个恶意版本的 Axios：1.14.1 和 0.30.4，涵盖了该项目的两个主要分支。两次上传仅相隔 39 分钟，根据 StepSecurity 的分析，这些上传是直接通过 npm 使用经典的长期有效令牌完成的，完全绕过了基于 GitHub Actions 的常规 CI/CD 流水线。

在最终攻击发生前18小时，攻击者已在npm注册表中发布了一个与恶意依赖项相关的“干净”版本。这一初步步骤旨在生成历史记录，并防止在攻击发生时出现全新软件包时触发某些自动检查。

令人惊讶的是，攻击者并未修改 Axios 的源代码，也没有对 GitHub 代码库进行任何可见的更改。事实上，1.14.1 和 0.30.4 版本在 GitHub 上没有任何对应的提交或标签；它们仅存在于 npm 上。关键区别在于软件包的依赖文件，该文件已发布在注册表中。

正常情况下，Axios 只声明了三个依赖项：follow-redirects、form-data 和 proxy-from-env。然而，在被入侵的版本中，出现了第四个依赖项，一个之前在项目中并不存在的东西：plain-crypto-js，版本 4.2.1。这个“幽灵”库在 Axios 代码库中任何地方都没有被使用，但它包含一个安装后脚本，该脚本会在使用 npm、pnpm 或类似工具安装该软件包时自动运行。

plain-crypto-js：远程访问木马部署的幽灵依赖项

此次攻击的关键在于这个额外的依赖项。plain -crypto-js 由名为“nrwise”的用户发布在 npm 上，该用户也使用 Proton Mail 邮箱地址。plain-crypto-js 的唯一目的是执行一个混淆的 Node.js 安装后脚本（setup.js）。该脚本充当投放器，即恶意软件第二阶段的初始安装程序。

当安装被篡改的 Axios 版本时，npm 的 post-install 生命周期会自动触发 plain-crypto-js 代码，无需开发者进行任何特殊操作。该投放器连接到 sfrclakcom 域中监听 8000 端口的命令与控制 (C2) 服务器，并下载针对受感染机器操作系统的特定有效载荷；这种行为可以通过网络流量分析来识别。

StepSecurity 和其他分析团队的研究人员描述了一种非常谨慎的行为。恶意程序执行完毕后，会清除自身痕迹：它删除了 postinstall 脚本，将 package.json 文件替换为“干净”的版本，并留下一个乍看之下无害的 node_modules 文件。这样一来，后续的人工检查就无法在 Axios 中直接发现恶意代码。

为了识别这种篡改，唯一可靠的线索在于锁定文件（package-lock.json、pnpm-lock.yaml、yarn.lock）以及特定版本的存在：axios 1.14.1 或 0.30.4 以及 plain-crypto-js 4.2.1，此外，一些分析中还链接到了该软件包的两个中间版本（4.2.0 和 4.2.2）。Socket 随后检测到，同样的恶意软件也通过 @shadanai/openclaw（2026.3.xx 等多个版本）和 @qqbrowser/openclaw-qbot（0.0.130）软件包进行传播，而蜜罐等安全技术也有助于识别类似的攻击活动。

跨平台远程访问木马：Windows、macOS 和 Linux 成为关注焦点

setup.js脚本一旦执行，便充当了协调器的角色，能够检测操作系统并遵循特定平台的攻击路径。此次攻击活动显然是预先准备的：据StepSecurity称，攻击者预先编译了三个不同的有效载荷，每个系统对应一个。

在 macOS 系统中，安装后进程会启动一个 AppleScript 脚本，该脚本会从 sfrclakcom:8000 服务器下载一个被植入木马的二进制文件。该二进制文件被保存到 /Library/Caches/com.apple.act.mond 路径下，其权限被修改为可执行文件，最后使用 /bin/zsh 在后台启动。远程访问木马 (RAT) 运行后，AppleScript 脚本本身会被删除，以进一步增加取证分析的难度。

在 Windows 系统上，该恶意软件会找到系统中的 PowerShell 二进制文件，将其复制到 %PROGRAMDATA%\wt.exe 目录下，伪装成 Windows 终端，并生成一个临时 VBScript 脚本。该 VBScript 脚本随后会联系 C2 服务器下载另一个 PowerShell 远程访问木马 (RAT) 脚本，执行该脚本后，删除下载的文件。此外，Windows 变种还会创建 %PROGRAMDATA%\system.bat 文件，其中包含一个下载例程，使恶意软件能够在每次登录时自动恢复自身，并在 Windows 注册表中添加一个执行密钥以确保持久性。

在除 macOS 以外的 Linux 和其他类 Unix 系统上，该投放器使用 Node.js 的 execSync 函数启动一个 shell 命令，该命令从 sfrclakcom 下载一个 Python 脚本，将其保存为 /tmp/ld.py，并使用 nohup 指令执行该脚本以使其在后台运行。与 Windows 不同，该变种没有展现出强大的持久化机制，这表明其采用的是更注重快速数据泄露的方法，或者只是偶尔通过后续命令部署持久化机制。

SafeDep 和 Elastic Security Labs 分析了二级有效载荷，得出结论：macOS（C++ Mach-O 二进制文件）和 Linux（Python 脚本）的远程访问木马 (RAT) 共享相同的命令集、C2 协议、消息格式和运行行为。此类分析通常依赖于VirusTotal等扫描服务，这些服务有助于关联样本和入侵指标 (IOC)。

在所有案例中，每个被入侵的主机都会立即执行系统侦察：用户目录、驱动器根目录、活动进程和其他元数据。这些信息会被发送到命令与控制服务器，而代理程序会维持一个大约 60 秒的信标循环，等待新的指令，包括执行其他脚本或将二进制文件注入内存。

曝光窗口、目标以及对朝鲜的归因

恶意版本的 Axios 在 npm 上存在了大约三个小时，时间段经过精心选择。这些被入侵的软件包于周日午夜前发布（这个时间点最大限度地延长了防御者的反应时间），在安全公司向当局报告异常行为后，事件在周一清晨得到控制。

在相对较短的时间内，Huntress 检测到至少 135 个系统连接到攻击者的服务器。鉴于 Axios 每周记录的下载量超过 80 万至 100 亿次（据各种消息来源称，某些时期甚至超过 300 亿次），这个数字可能只是冰山一角，仅限于那些引起分析公司注意并公开数据的系统。

谷歌通过其威胁情报团队将此次攻击归咎于一个疑似朝鲜黑客组织，该组织被标记为 UNC1069。Elastic Security Labs 通过发现 macOS 上传播的远程访问木马 (RAT) 与 Mandiant 发现的 C++ 后门程序 WAVESHAPER 高度相似，进一步证实了这一假设。WAVESHAPER 也与同一威胁组织有关。

谷歌分析师强调，与朝鲜有关联的组织多年来一直专注于供应链攻击和加密货币盗窃活动。他们的作案手法一贯如此：先攻破开发基础设施、广泛使用的库或受信任的软件，然后横向转移目标，攻击那些管理高价值资产、私钥或凭证的组织。

多份报告还强调，此次攻击的组织结构和设计表明攻击者是一个配合默契的团队：同一远程访问木马（RAT）的三个并行实现（分别使用 PowerShell、C++ 和 Python 语言）、一致的 C2 协议、所有变种几乎相同的行为，以及清晰的自清理策略以避免留下痕迹。Elastic 强调，这种一致性表明攻击者是单个开发者或团队，他们基于共享的设计文档进行开发，而非临时拼凑。

针对 Axios 维护者的高级社会工程学

抛开纯粹的技术层面不谈，此案最令人不安的一点是主要维护者的 npm 账户是如何被盗用的。Axios的经理后来解释说，他几乎所有服务都启用了双因素身份验证，但最终还是在不知情的情况下授予了他人访问权限。

根据团队分享的分析报告，攻击者精心策划了一场社会工程攻击，并借助人工智能工具，成功获取了目标用户的信任。他们冒充公司创始人，复制了公司的视觉形象、照片，甚至连企业品牌标识都照搬不误。他们创建了一个带有公司标志的真实 Slack 空间，设置了看似与 LinkedIn 同步的频道，甚至还创建了员工和其他开源软件维护者的虚假个人资料。

在这种情况下，他们通过 Microsoft Teams 安排了一场会议，看起来所有专业人士都参与了会议。会议期间，他们模拟了一个技术问题，并指出系统的一个组件已过时。维护技术人员以为这是视频会议工具本身的合理要求，于是下载并安装了建议的文件。

事实上，该文件正是远程访问木马，攻击者利用它获取受害者的凭据，最终控制了用于发布 Axios 的 npm 帐户。整个过程精心策划，细节逼真，以至于受害者将其描述为“完美协调、专业且极具说服力”。

此次事件中的人为因素表明，即使是双因素认证等技术措施，在高级社会工程技术与视觉冒充、深度伪造或对组织的精细克隆相结合时，也远远不够。最薄弱的环节，再次是人为因素。

对使用 Axios 的组织和开发人员的影响

从实际角度来看，主要问题在于确定哪些组织真正受到了影响。任何在[email protected]或[email protected]可用期间安装了这些程序的组织都应该假定执行安装的机器或管道可能已被入侵。

StepSecurity、Aikido、Huntress 和 Elastic 等公司的建议非常明确。一旦怀疑存在安全隐患，必须采取积极主动的措施，而不仅仅是“删除并重新安装 node_modules ”。明智的做法是使用可信镜像重建受影响的机器或环境，并仔细检查 CI/CD 日志，以确定哪些作业或流水线可能执行了被入侵的版本。

此外，必须轮换 RAT 可能从这些节点访问的所有凭证和密钥：npm 令牌、云提供商密钥、管道密钥、数据库凭证、SSH 密钥等。在此类攻击后，如果这些凭证仍然流通，就会为悄无声息的横向移动敞开大门。

在技​​术层面，团队应检查其锁定文件（package-lock.json、pnpm-lock.yaml、yarn.lock），查找对已入侵版本的 Axios 和 plain-crypto-js 的引用。如果发现这些元素，下一步是检查受影响的系统是否存在潜在的远程访问木马 (RAT) 痕迹：macOS 上的 /Library/Caches/com.apple.act.mond，Windows 上的 %PROGRAMDATA%\wt.exe 和 %PROGRAMDATA%\system.bat，或 Linux 上的 /tmp/ld.py。

同时，建议显式设置安全的 Axios 版本，例如 1.14.0 和 0.30.3，并使用覆盖或解析来防止传递依赖项解析到不期望的版本。阻止出站流量访问 sfrclakcom 域也是一项合理的遏制措施，至少在分析攻击的全部范围期间应如此。

软件供应链的安全教训

Axios事件并非孤立事件，而是供应链攻击链条中的又一环，这条链条还包括SolarWinds、Kaseya、3CX、Polyfill.io以及Log4j漏洞利用等案例。其核心思路始终如一：攻击广泛使用且受信任的组件以扩大攻击范围，而不是逐个攻击目标机器。

专家们反复强调的一点是，信任不能仅仅依赖于库的流行度或维护者的声誉。如果发布渠道（npm 账户、CI/CD 流水线、构建基础设施）遭到入侵，那么通过该渠道发布的所有内容都会面临同样的风险。如果恶意软件隐藏在传递依赖项中并在执行后自行删除，那么人工代码审查也无济于事。

此外，研究还指出，依赖项更新的“默认速度”会增加攻击面。始终自动采用最新版本固然极其便捷，但也为恶意更新在几分钟内传播打开了方便之门。一些组织已经在考虑采取相关策略，例如要求新版本在生态系统中运行一段时间后才能采用，或者要求对关键软件包的更改进行额外的人工审核。

在开发基础设施方面，CI/CD 环境必须被视为高度敏感资产。任何在依赖项安装过程中执行的远程访问木马 (RAT) 几乎肯定会试图获取管道密钥并访问其他环境。因此，对这些节点进行隔离、加强监控并定期轮换密钥不再是“理想”建议，而是必须采取的措施。

最后，检测这类攻击需要结合来自多个来源的信息：已安装版本、锁定文件、操作系统入侵指标和网络遥测数据。生成和管理软件物料清单 (SBOM) 的工具有助于快速追踪哪些项目使用了哪些软件包，这在触发此类大规模警报时至关重要。

与 Axios 的这次事件充分说明了依赖生态系统——无论它看起来多么成熟和完善——仍然高度依赖信任和持续的警惕。一个看似无害的库，如果由一个人维护，却不幸成为精心策划的社会工程攻击的受害者，那么短短几个小时内，它就可能成为全球范围内部署跨平台远程访问木马 (RAT) 的入口，攻击对象涵盖各种规模的公司、自由职业者和组织。加强对发布账户、管道和关键依赖项的控制不再是可有可无的最佳实践，而是在攻击者越来越耐心、手段越来越高明、工具越来越强大的环境下，持续开发的先决条件。