npm恶意软件警报：ethers-provider2与反向Shell攻击深度解析

恶意npm补丁传播反向Shell
近年来，开源软件供应链安全威胁持续升级。尽管2023至2024年间npm平台恶意软件数量有所下降，但最新发现的两款恶意包ethers-provider2与ethers-providerz再次敲响警钟。这些恶意包通过“补丁”本地安装的合法npm包ethers，植入反向Shell代码，攻击复杂度远超常规供应链攻击。本文将深入剖析其技术细节、攻击链及防御方案。

攻击概述：伪装与隐蔽性结合的新型威胁

恶意包伪装成合法依赖

ethers-provider2与ethers-providerz通过模仿高下载量的合法包ssh2（累计下载超3.5亿次）进行伪装。攻击者将ssh2的源码与恶意代码结合，使得恶意包在功能上与原始包完全一致，同时添加了隐蔽的攻击逻辑。

攻击链三阶段解析

  1. 第一阶段（安装脚本注入）
    恶意包中的install.js脚本在安装时自动执行，从攻击者控制的服务器hxxp[:]//5[.]199[.]166[.]1[:]31337/install下载第二阶段载荷，执行后立即删除临时文件，抹除痕迹。

  2. 第二阶段（本地包篡改）
    恶意代码通过无限循环检测本地是否安装ethers包。一旦发现，即替换其核心文件provider-jsonrpc.js，注入恶意代码。篡改后的文件会进一步下载第三阶段载荷（反向Shell）。

  3. 第三阶段（持久化反向Shell）
    篡改后的代码会建立与攻击者服务器5.199.166.1:31337的SSH连接。即使移除恶意包，反向Shell仍可通过loader.js保持持久化访问权限。

技术细节：攻击者如何实现隐蔽性？

动态载荷加载与自毁机制

  • 动态加载：恶意代码通过fetch和eval动态执行远程载荷，避免静态扫描。
  • 自毁设计：临时文件执行后立即删除，且篡改的ethers包文件与原始文件功能一致，仅添加恶意代码片段，大幅降低人工审计发现概率。

持久化策略

攻击者在node_modules目录下生成loader.js文件，持续监控ethers包的安装状态。即使开发者移除恶意包，只要ethers存在，篡改代码仍会重新注入。

ethers-provider2第二阶段代码结构
图1：ethers-provider2的第二阶段恶意代码逻辑

关联攻击包分析：ethers-providerz的缺陷与演进

另一关联包ethers-providerz的早期版本（1.16.0）暴露了攻击者的测试痕迹：

  • 路径错误：尝试篡改@ethersproject/providers包时，因路径定义错误导致部分功能失效。
  • 载荷混淆：通过atob双重Base64解码隐藏下载URL，但仍未完全规避检测。

install.js中的恶意载荷
图2：ethers-providerz的install.js脚本恶意代码片段

检测与防御：YARA规则与应急响应

关键检测指标（IoC）

类型 值
第二阶段载荷URL hxxp[:]//5[.]199[.]166[.]1[:]31337/install
第三阶段载荷URL hxxp[:]//5[.]199[.]166[.]1[:]31337/config

自定义YARA规则

ReversingLabs团队提供的YARA规则可检测被篡改的ethers包文件：

rule npm_Downloader_InjectedMaliciousCode  
{  
    meta:
        author              = "ReversingLabs"
        source              = "ReversingLabs"  
        category            = "MALWARE"  
        description         = "检测本地ethers包是否被注入恶意代码"

    strings:
        $decode_payload_url = "atob(atob(\"YUhSMGNEb3ZMelV1TVRrNUxqRTJOaTR4T2pNeE16TTNMMk52Ym1acFp3PT0=\"))"  
        $fetch_payload = "fetch("                 
        $execute_payload = "eval("

    condition:  
        all of them  
}

篡改文件中的恶意代码片段
图3：被篡改的provider-jsonrpc.js文件代码对比

扩展攻击：更多关联恶意包浮出水面

研究团队后续发现另两个关联包：

  • reproduction-hardhat：直接连接攻击者IP的反向Shell。
  • @theoretical123/providers：伪装成@ethersproject/providers的恶意包，下载相同第二阶段载荷。

上述包已被npm官方下架，但攻击者可能持续更换名称与载荷分发策略。

开发者应对建议

  1. 依赖包审计

    • 使用npm audit或SCA（软件组成分析）工具定期扫描项目依赖。
    • 警惕名称近似高知名度的包（如ethers-provider2与官方ethers）。

  2. 运行时监控

    • 部署EDR（终端检测与响应）工具，监控异常网络连接（如对5.199.166.1的访问）。

  3. 应急响应

    • 若检测到ethers包被篡改，立即移除并重新安装官方版本。
    • 检查node_modules目录下的loader.js等可疑文件。

总结：供应链安全需持续警惕

尽管npm平台已下架部分恶意包，但攻击者通过篡改本地依赖实现持久化的手法，标志着供应链攻击进入新阶段。开发者需意识到：

  • “一次性检测”不足：即使移除恶意包，残留代码仍可能潜伏。
  • 开源生态的双刃剑：便捷的依赖管理背后，隐藏着供应链投毒风险。

ReversingLabs在《2025软件供应链安全报告》中指出，开源仓库的恶意包投递仍是企业安全的最大盲区之一。唯有通过自动化检测、开发者安全意识提升与社区协同响应，方能构建更健壮的软件供应链防线。