npm恶意软件警报:ethers-provider2与反向Shell攻击深度解析
近年来,开源软件供应链安全威胁持续升级。尽管2023至2024年间npm平台恶意软件数量有所下降,但最新发现的两款恶意包ethers-provider2与ethers-providerz再次敲响警钟。这些恶意包通过“补丁”本地安装的合法npm包ethers,植入反向Shell代码,攻击复杂度远超常规供应链攻击。本文将深入剖析其技术细节、攻击链及防御方案。
攻击概述:伪装与隐蔽性结合的新型威胁
恶意包伪装成合法依赖
ethers-provider2与ethers-providerz通过模仿高下载量的合法包ssh2(累计下载超3.5亿次)进行伪装。攻击者将ssh2的源码与恶意代码结合,使得恶意包在功能上与原始包完全一致,同时添加了隐蔽的攻击逻辑。
攻击链三阶段解析
- 
第一阶段(安装脚本注入)
恶意包中的install.js脚本在安装时自动执行,从攻击者控制的服务器hxxp[:]//5[.]199[.]166[.]1[:]31337/install下载第二阶段载荷,执行后立即删除临时文件,抹除痕迹。 - 
第二阶段(本地包篡改)
恶意代码通过无限循环检测本地是否安装ethers包。一旦发现,即替换其核心文件provider-jsonrpc.js,注入恶意代码。篡改后的文件会进一步下载第三阶段载荷(反向Shell)。 - 
第三阶段(持久化反向Shell)
篡改后的代码会建立与攻击者服务器5.199.166.1:31337的SSH连接。即使移除恶意包,反向Shell仍可通过loader.js保持持久化访问权限。 
技术细节:攻击者如何实现隐蔽性?
动态载荷加载与自毁机制
- 
动态加载:恶意代码通过 fetch和eval动态执行远程载荷,避免静态扫描。 - 
自毁设计:临时文件执行后立即删除,且篡改的 ethers包文件与原始文件功能一致,仅添加恶意代码片段,大幅降低人工审计发现概率。 
持久化策略
攻击者在node_modules目录下生成loader.js文件,持续监控ethers包的安装状态。即使开发者移除恶意包,只要ethers存在,篡改代码仍会重新注入。
图1:ethers-provider2的第二阶段恶意代码逻辑
关联攻击包分析:ethers-providerz的缺陷与演进
另一关联包ethers-providerz的早期版本(1.16.0)暴露了攻击者的测试痕迹:
- 
路径错误:尝试篡改 @ethersproject/providers包时,因路径定义错误导致部分功能失效。 - 
载荷混淆:通过 atob双重Base64解码隐藏下载URL,但仍未完全规避检测。 
图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官方下架,但攻击者可能持续更换名称与载荷分发策略。
开发者应对建议
- 
依赖包审计
- 
使用 npm audit或SCA(软件组成分析)工具定期扫描项目依赖。 - 
警惕名称近似高知名度的包(如ethers-provider2与官方ethers)。  
 - 
 - 
运行时监控
- 
部署EDR(终端检测与响应)工具,监控异常网络连接(如对5.199.166.1的访问)。  
 - 
 - 
应急响应
- 
若检测到ethers包被篡改,立即移除并重新安装官方版本。  - 
检查 node_modules目录下的loader.js等可疑文件。 
 - 
 
总结:供应链安全需持续警惕
尽管npm平台已下架部分恶意包,但攻击者通过篡改本地依赖实现持久化的手法,标志着供应链攻击进入新阶段。开发者需意识到:
- 
“一次性检测”不足:即使移除恶意包,残留代码仍可能潜伏。  - 
开源生态的双刃剑:便捷的依赖管理背后,隐藏着供应链投毒风险。  
ReversingLabs在《2025软件供应链安全报告》中指出,开源仓库的恶意包投递仍是企业安全的最大盲区之一。唯有通过自动化检测、开发者安全意识提升与社区协同响应,方能构建更健壮的软件供应链防线。
