摘要 (Executive Summary)

2026年6月8日，[[1]]领域发生了一起教科书式的软件供应链攻击事件。专注于去中心化金融（DeFi）的基础设施提供商 Injective Labs，其官方发布的npm包@injectivelabs/sdk-ts（周下载量超过5万次）遭到恶意投毒。攻击者通过攻陷一名项目维护者的GitHub账户，成功向该软件包的v1.20.21版本中植入了窃取加密钱包私钥的恶意代码。此次攻击的复杂性与隐蔽性尤为突出：攻击者不仅精准地锁定了同一命名空间下的17个关联包以扩大影响并阻碍修复，其恶意负载更是在运行时（runtime）被动态触发，专门针对PrivateKey.fromMnemonic()等钱包密钥生成函数。一旦开发者调用这些函数，其BIP-39助记词和私钥便会被捕获、编码，并伪装成常规的遥测数据流量悄无声息地发送至攻击者控制的服务器。

尽管Injective Labs团队在49分钟内迅速响应，发布了修复版本v1.20.23并移除了恶意版本，但该恶意包在此期间已被下载超过310次，构成了严重的潜在资产安全威胁。尽管截至本报告发布之日，公开渠道（如Discord、Reddit）尚未出现经证实的、直接与此次事件相关的用户资金被盗报告 [[2]][[3]][[4]]但此次攻击的性质决定了其潜在危害的长期性和隐蔽性。

本报告将深度复盘此次攻击的全过程，从初始的GitHub账户凭证泄露，到精巧的运行时代码注入，再到高明的伪装数据外传技术。同时，报告将系统性地总结此次事件带来的三大核心安全启示：第一，维护者账户安全是开源供应链的第一道、也是最关键的防线；第二，相比于安装时脚本，运行时注入的恶意代码更难被传统的静态分析工具所察觉；第三，企业必须建立包括版本锁定、软件物料清单（SBOM）审计和CI/CD缓存扫描在内的纵深防御体系。最后，本报告将为开发者和企业提供一套可操作的排查与响应指南，以应对此类日益复杂的供应链威胁。

1. 引言：警钟长鸣——[[5]]时代的npm供应链安全危机

开源软件，特别是npm（Node Package Manager）生态系统，已成为现代软件开发的基石。然而，其开放、协作与相互依赖的特性也使其沦为网络攻击者的沃土 [[6]][[7]]。近年来，针对npm仓库的供应链攻击事件层出不穷，其频率、复杂性和破坏性均呈指数级增长 [[8]][[9]]。攻击者不再满足于制造混乱或进行简单的拒绝服务攻击，而是将目标瞄准了高价值数据，如服务器凭证、云服务API密钥，以及在[[10]]世界中等同于资产所有权的加密货币钱包私钥 [[11]][[12]]。

从2025年到2026年，安全社区已观察到多起大规模、有组织的供应链攻击活动，例如“沙虫（Shai-Hulud）”和“PhantomRaven”等攻击行动，这些攻击往往涉及数以百计的恶意软件包发布，旨在窃取敏感信息和数字资产 [[13]][[14]][[15]]。针对知名加密项目（如dYdX）的npm包攻击也时有发生，其目标明确指向钱包凭证和设备后门 [[16]][[17]][[18]]。这些攻击事件清晰地表明，npm生态已成为网络犯罪分子实现经济目的的关键战场。

在此背景下，Injective Labs@injectivelabs/sdk-ts包所遭受的攻击，并非一次孤立事件，而是这一严峻趋势下的一个典型缩影。@injectivelabs/sdk-ts是一个被广泛用于构建基于Injective协议的DeFi应用的TypeScript SDK [[19]][[20]]其用户群体直接与高价值的加密资产交互。攻击者选择这样一个目标，其意图昭然若揭：在开发者构建金融应用的最源头植入“特洛伊木马”，以期在神不知鬼不觉中收割终端用户的数字财富。本次事件的快速响应虽然在一定程度上控制了损失，但其暴露出的深层次问题，值得整个行业进行深刻反思。

2. 事件剖析：Injective Labs供应链攻击的五步复盘

为了全面理解此次攻击的精妙之处与巨大威胁，我们将其分解为五个环环相扣的阶段进行深度复盘。

第一阶段：初始入侵 —— 沦陷的GitHub账户 (The Initial Compromise: A Fallen GitHub Account)

攻击路径：攻击的核心起点是项目维护者GitHub账户的失陷。这是整个攻击链中最关键的一环，一旦成功，攻击者便获得了以合法身份进行恶意操作的“官方授权”。

分析：维护者账户是软件供应链中最具价值的“钥匙”。攻击者获取此类权限的手段多种多样，包括但不限于：

• 网络钓鱼与社会工程学：攻击者可能通过伪造的登录页面、紧急安全警报或合作请求，诱骗维护者输入其GitHub凭证 [[21]]。
• 凭证填充与密码破解：如果维护者在多个网站上使用相同的弱密码，攻击者可利用从其他数据泄露事件中获取的凭证进行尝试。
• 恶意软件感染：维护者设备若被植入信息窃取型恶意软件，其浏览器中保存的密码、会话cookie或SSH密钥都可能被盗取。
• 泄露的访问令牌（Token）：开发者有时会无意中将个人访问令牌（PAT）或OAuth令牌硬编码在公共代码库、配置文件或CI/CD日志中，攻击者通过自动化扫描即可发现并利用这些泄露的令牌 [[22]][[23]]。

安全 implications：这次事件再次凸显了GitHub账户安全的极端重要性。缺乏强制性的多因素认证（MFA）是导致此类账户被轻易接管的首要原因。组织应强制要求所有拥有代码提交权限的成员启用MFA，并优先使用更安全的物理安全密钥（如FIDO2/WebAuthn）而非基于短信或TOTP的认证方式。

事后追溯：尽管我们无法直接访问Injective Labs的内部日志，但在类似事件的调查中，GitHub审计日志（Audit Log）是关键的法证工具。安全团队可以通过API或UI审查特定时间段内（例如2026年6月8日前后）的所有活动，寻找异常的登录IP、未经授权的令牌创建、可疑的SSH密钥添加，以及最终导致恶意代码被推送的分支操作记录 [[24]][[25]][[26]]。这些日志能够帮助确定账户被盗的具体时间和方式，为后续的响应和加固提供依据 [[27]]。

第二阶段：恶意代码植入与横向移动 (Code Injection and Lateral Movement)

攻击路径：获得访问权限后，攻击者在2026年6月8日执行了两个关键操作：

1. 向@injectivelabs/sdk-ts推送了一个新的版本v1.20.21，其中包含了精心伪装的恶意代码。选择一个次要修订版本（patch version）发布，是一种常见的策略，因为它通常被认为只包含错误修复，更容易被开发者在未加审查的情况下自动更新。
2. 锁定（lock）了@injectivelabs命名空间下的17个其他关联包。这是一步非常老练的操作，其目的在于：
   • 增加修复难度：锁定其他包可以阻止维护者团队快速发布修复或回滚相关依赖，为恶意代码的传播争取更多时间。
   • 制造混乱：大量包被锁定会给开发者社区带来困惑，分散调查人员的注意力。
   • 潜在的组合攻击：攻击者可能计划利用这些被锁定的包进行更复杂的后续攻击。

分析：恶意代码本身极有可能经过了高度混淆，以逃避静态代码扫描工具的检测。安全研究人员在分析此类事件时，通常会对比恶意版本（v1.20.21）与修复版本（v1.20.23）或前一个干净版本（v1.20.20）之间的源代码差异（code diff）[[28]][[29]]。虽然我们没有获得本次事件的具体代码差异 (搜索结果未提供)，但通常会关注以下几点：

• 非预期的依赖项添加：引入一个看似无害但实际上是恶意软件的第三方库。
• 混淆的字符串与函数：使用Base64、Hex或其他编码方式隐藏恶意URL、IP地址或敏感函数名。
• 修改构建脚本：在package.json的scripts字段（如postinstall）或构建配置文件（如webpack.config.js）中注入恶意命令。
• 重载（Overriding）核心函数：偷偷替换合法函数实现，植入恶意逻辑，正如本次攻击中所做的。

第三阶段：潜伏与触发 —— 运行时注入的隐蔽艺术 (Dormancy and Trigger: The Stealth of Runtime Injection)

攻击路径：这是本次攻击最为精妙的部分。恶意代码并非在包安装时（install-time）就立即执行，而是在应用程序的运行时（run-time）潜伏，等待一个特定的触发条件：开发者调用PrivateKey.fromMnemonic()或其他相关的密钥生成函数。

分析：传统的npm供应链攻击常常利用postinstall脚本。这类脚本在npm install命令执行后自动运行，虽然有效，但其行为相对明显，更容易被沙箱环境、CI/CD安全扫描工具或警惕的开发者发现 [[30]]。

而运行时注入则要隐蔽得多。恶意代码被巧妙地编织进合法的库函数中。当开发者的应用程序正常运行时，调用到这个被“污染”的函数，恶意逻辑才会被激活。这种方式的优势在于：

• 高度隐蔽性：在安装和构建阶段，一切看起来都正常。静态分析很难发现这种上下文相关的恶意行为。
• 精准打击：攻击直接发生在最敏感的操作上——当用户的助记词或私钥在内存中以明文形式存在时。这确保了窃取到的是最高价值的信息。
• 绕过常规检测：许多安全工具专注于检测安装过程中的异常网络连接或文件系统操作，而对运行时合法的业务逻辑函数调用中的恶意行为监控不足。

这种技术是对BIP-39助记词安全的直接挑战。BIP-39标准的设计初衷是为了方便用户备份和恢复钱包，但它也创造了一个高价值的攻击目标。一旦助记词在前端或后端代码中被处理，任何对该代码执行环境的破坏都可能导致灾难性的后果。

第四阶段：数据窃取 —— 伪装成遥测流量 (Data Exfiltration: Disguised as Telemetry)

攻击路径：当恶意代码捕获到BIP-39助记词和私钥后，它需要将这些数据传回给攻击者。为了不引起怀疑，攻击者采用了高明的伪装术：

1. 数据编码：将窃取到的敏感信息（如"word1 word2 ... word12")进行Base64编码，使其看起来像一串无意义的随机字符，避免被简单的关键词过滤规则发现。
2. 伪造遥测流量：攻击者将编码后的数据包装在一个看似正常的网络请求中，该请求被伪造成发送给Injective官方遥测（telemetry）服务器的合法数据。遥测数据通常用于收集软件使用情况、性能指标或错误报告，是一种常见的、高频的网络通信，因此极易在大量的网络日志中被忽略。

分析：使用伪造遥测流量进行数据外泄是一种先进的攻击技术。攻击者会仔细研究目标软件的正常网络行为，模仿其API端点、请求头（Headers）、数据格式（如JSON结构）和用户代理（User-Agent），使得恶意请求与正常流量在外观上难以区分 [[31]][[32]]。这种方法有效地绕过了基于签名的网络入侵检测系统（NIDS）和简单的出站防火墙规则。

从MITRE ATT&CK框架的角度来看，这一行为可以映射到多个战术和技术：

• 初始访问 (Initial Access):T1195 - 供应链攻击 (Supply Chain Compromise) [[33]][[34]]。
• 凭证访问 (Credential Access):攻击直接目标是窃取私钥，这属于凭证访问的范畴。
• 数据外泄 (Exfiltration):T1048 - Exfiltration Over Alternative Protocol，攻击者利用了应用层协议（HTTP/S）作为非传统的C2通道 [[35]]。虽然“遥测”不是一个独立的协议，但其伪装思想与该技术的核心一致。
• 防御规避 (Defense Evasion):T1027 - Obfuscated Files or Information，通过Base64编码隐藏窃取的数据。

要检测此类攻击，需要更高级的威胁检测能力，例如行为分析和异常检测。EDR（端点检测与响应）解决方案或网络流量分析（NTA）工具，通过建立正常网络通信的基线，可能能够识别出发送到非标准遥测端点或携带异常数据负载的请求 [[36]][[37]][[38]]。然而，如果攻击者模仿得足够逼真，检测难度依然极大。

第五阶段：影响与响应 (Impact and Response)

影响评估：

• 下载量：恶意版本v1.20.21在被移除前的49分钟内，被下载了超过310次。这个数字虽然看似不大，但考虑到@injectivelabs/sdk-ts的开发者用户属性，每一次下载都可能代表一个正在开发或已经上线的DeFi项目、交易机器人或钱包应用。这个数字的来源通常是npm注册中心的下载计数器，但其精确验证有时较为困难 (搜索结果未确认此数据的来源)。
• 潜在损失：尽管目前没有公开确认的资金损失报告 [[39]][[40]]但这并不意味着威胁已经解除。攻击的潜伏期可能很长。开发者可能在本地环境、测试服务器或CI/CD系统中使用过该恶意版本，导致私钥泄露。攻击者可能会等待时机，在未来某个时间点集中对窃取到的钱包进行盗窃。因此，任何使用了该版本的项目都必须被视为已完全泄露。

响应行动：

• 快速回滚：Injective Labs团队在49分钟内发现问题并发布了修复版本v1.20.23，同时从npm注册表中撤销了v1.20.21。这种快速响应能力至关重要，极大地缩短了攻击窗口，限制了受影响用户的数量。
• 社区警报：及时向社区发布安全公告，通知用户风险，并提供升级指南。
• 移除恶意包：npm安全团队在接到报告后，通常会迅速将恶意包从公共注册表中移除 [[41]][[42]]。然而，需要注意的是，被移除的包可能仍然存在于各种缓存（本地、CI/CD、私有代理仓库）中，需要用户手动清理 [[43]][[44]]。我们无法通过公开的npm注册表元数据直接查询到v1.20.21确切的删除时间戳，因为这类信息通常不作为标准元数据字段对外暴露 [[45]][[46]]。
• 事后分析：虽然搜索结果中没有找到Injective Labs团队发布的官方事后分析报告（post-mortem） [[47]][[48]]但进行彻底的根本原因分析是防止未来事件的关键。这应包括对GitHub账户如何被盗的详细调查。

3. 安全启示与防御策略：构建纵深防御体系

此次Injective Labs事件为整个软件开发行业，特别是[[49]]领域，提供了宝贵的、代价高昂的教训。构建一个强大的供应链安全防御体系，需要从开发者个人到组织流程，再到技术工具的全面升级。以下是我们总结的“三道防线”加一道“运行时保障”的纵深防御模型。

第一道防线：强化开发者与仓库凭证安全 (The First Line: Hardening Credentials)

这是预防此类攻击的根本。如果攻击者无法获得发布权限，后续的一切都无从谈起。

• 强制MFA：对所有代码仓库（GitHub、GitLab等）和包管理器（npm、PyPI等）的账户强制启用多因素认证，并优先使用抗钓鱼的物理安全密钥。
• 最小权限原则：仅为需要发布软件包的少数核心成员或专用的自动化CI/CD服务账户授予发布权限。定期审查和清理不再需要的权限。
• 令牌安全管理：严禁在代码、配置文件或环境变量中硬编码访问令牌。使用专门的秘密管理工具（如HashiCorp Vault、AWS Secrets Manager）。对CI/CD环境中使用的令牌设置严格的范围（scope）和较短的生命周期 [[50]][[51]]。
• 监控与审计：持续监控GitHub审计日志，设置警报以应对异常活动，如从未知IP登录、安全设置变更、非工作时间的代码提交等 [[52]]。

第二道防线：依赖项的精准管控与审计 (The Second Line: Dependency Scrutiny)

在开发和构建阶段，我们需要像审查自己代码一样，严格审查引入的第三方依赖。

• 锁定版本 (Version Pinning)：始终使用锁文件（package-lock.json,yarn.lock），并将其提交到版本控制系统中。这可以确保团队所有成员和CI/CD环境都使用经过验证的、完全相同的依赖版本，防止因依赖项的意外升级而引入恶意代码。
• 供应链投毒检测 (Supply Chain Poisoning Detection)：
  • 基础工具：定期运行npm audit[[53]] 来检查已知漏洞（CVEs）。但这不足以防御像本次事件这样的零日攻击。
  • 高级工具：采用更先进的供应链安全平台，如Socket.dev, Snyk, Mend.io, GuardDog等 [[54]][[55]][[56]]。这些工具不仅检查已知漏洞，还会通过静态和行为分析来检测可疑模式，例如：包在安装后执行网络请求、读取敏感文件（如/etc/passwd,~/.ssh）、包含混淆代码、或者新发布的包与维护者历史行为不符等。
• 软件物料清单 (SBOM) 审计：生成并维护项目的SBOM。SBOM提供了项目中所有组件、依赖项及其来源的详细清单。通过SBOM，组织可以快速确定自己是否受到新发现的漏洞或恶意软件包的影响，并对其软件供应链的健康状况进行持续审计。这是实现软件供应链透明化的关键一步。

第三道防线：CI/CD流水线的安全加固 (The Third Line: Securing the Pipeline)

CI/CD流水线是自动化构建、测试和部署软件的核心，也是供应链攻击的重要目标。

• CI/CD缓存扫描 (CI/CD Cache Scanning)：恶意软件包即使从npm官方源移除，也可能“存活”在CI/CD的缓存目录中。因此，必须将缓存目录纳入安全扫描范围。
  • 实施方案：在CI/CD流程中集成自动化扫描工具（如JFrog Xray, Snyk, Semgrep）[[57]][[58]][[59]]在每次构建开始时，或定期对依赖缓存、构建镜像和工件进行扫描，发现恶意或可疑组件立即中止构建并报警。
  • 定期清理：实施定期的缓存清理策略，以减少恶意代码的持久化风险。
• 构建过程隔离与监控：在隔离的环境（如容器）中执行构建，并限制其网络访问。只允许其访问必要的内部资源和受信任的软件包仓库。监控构建过程中的所有网络连接，对意料之外的出站连接进行告警 [[60]]。

第四道防线：运行时监控与威胁检测 (The Final Line: Runtime Protection)

鉴于本次攻击的运行时触发特性，仅在开发和构建阶段进行防御是远远不够的。

• 出站流量监控：在生产和测试环境中，部署能够监控应用程序出站网络连接的工具。
  • 命令行工具与脚本：对于调试和审计，可以使用如tcpconnect等工具来追踪出站连接 [[61]]。可以编写基于Falco等工具的规则，专门检测Node.js进程发起的到未知或可疑域名的连接 [[62]]。
  • EDR与NDR解决方案：企业级环境应部署端点检测与响应（EDR）或网络检测与响应（NDR）系统。这些系统通过收集详细的遥测数据（进程活动、网络流、文件访问），利用行为分析和机器学习来检测异常活动，例如一个本不应有网络行为的库函数突然发起了出站连接，或者与已知的恶意基础设施通信 [[63]][[64]]。
• 应用层安全：对于处理敏感数据（如私钥）的核心业务逻辑，实施更严格的代码审查和运行时保护。考虑使用代码加固或运行时应用自我保护（RASP）技术，以防止核心函数被篡改或hook。

4. 事件响应与排查指南 (Incident Response and Investigation Guide)

如果您的项目依赖于@injectivelabs/sdk-ts，或希望排查类似风险，请立即遵循以下步骤：

1. 立即检查受影响版本：
   在您的项目根目录下运行以下命令，检查是否安装了v1.20.21版本：

   npmls@injectivelabs/sdk-ts

   如果输出中包含@injectivelabs/sdk-ts@1.20.21，则您的项目已受影响。

2. 升级并清理：

   • 立即将@injectivelabs/sdk-ts升级到v1.20.23或更高版本。

   • 删除node_modules目录和package-lock.json文件。

   • 强制清理本地npm缓存：

     npmcache clean--force

   • 重新运行npm install以安装干净的依赖。

3. 扫描CI/CD与构建环境：
   联系您的运维或DevSecOps团队，对所有CI/CD服务器、构建代理和部署环境执行上述依赖检查和缓存清理操作。使用您的安全扫描工具，对这些环境中的缓存目录进行彻底扫描。

4. 凭证轮换：假定最坏情况 (CRITICAL STEP)：
   这是最重要的一步。如果您的项目在任何环境（开发、测试、生产）中安装或运行了v1.20.21版本，并且调用了任何可能触发恶意代码的函数（特别是PrivateKey.fromMnemonic()），您必须立即假定相关的助记词和私钥已经泄露。

   • 立即转移资产：立即创建一个全新的、在安全环境中生成的钱包地址。将所有与泄露私钥相关的资产，全部转移到这个新钱包中。
   • 废弃旧密钥：永久停止使用所有可能已泄露的私钥和助记词。
   • 轮换所有相关凭证：检查代码中是否存在其他硬编码的API密钥或凭证，并立即进行轮换，因为恶意代码可能具有比已知功能更广泛的窃取能力 [[65]][[66]]。

5. 日志审查与IOCs搜索：
   虽然攻击者使用了伪装流量，但审查网络日志仍有价值。检查您的应用服务器、代理服务器和防火墙日志，寻找在受影响时间段内，由Node.js进程发起的、目的地看似Injective官方服务器但可能包含异常Base64编码数据的出站POST/GET请求。尽管具体的攻击指标（IoCs）未在公开信息中披露 (搜索结果未提供)，但任何非预期的出站流量都值得怀疑。

5. 结论：在信任与警惕中前行的开源生态

Injective Labs的@injectivelabs/sdk-ts供应链攻击事件，如同一面棱镜，折射出当前开源软件生态系统面临的多重安全挑战。它展示了攻击者如何利用生态中最薄弱的环节——人的信任与账户安全——来发起精准、隐蔽且极具破坏力的攻击。从攻陷GitHub账户，到植入运行时触发的恶意代码，再到利用伪装遥测流量窃取[[67]]核心资产（私钥），整个攻击链条一气呵成，体现了攻击手法的日趋成熟化和专业化。

此次事件的教训是深刻的。它告诉我们，npm供应链安全不再是一个可以被忽视的边缘问题，而是所有依赖开源软件的组织必须直面的核心风险。我们不能再盲目地信任npm install背后的代码。开发者和企业必须从被动响应转向主动防御，建立一个覆盖“人-流程-技术”的全方位、纵深防御体系。

这包括：以零信任原则加固GitHub账户安全和仓库凭证管理；通过版本锁定和SBOM审计实现对依赖项的透明化管控；利用先进的供应链投毒检测工具在开发早期发现威胁；以及通过CI/CD缓存扫描和运行时监控来封堵安全防御的最后缺口。

开源的本质是协作与信任，但这种信任必须建立在验证和警惕的基础之上。未来，软件供应链安全将继续成为攻击者与防御者之间激烈博弈的主战场。只有通过持续的技术创新、社区协作和安全意识教育，我们才能在享受开源带来便利的同时，有效抵御潜藏于代码海洋深处的巨大风险，共同守护数字世界的安全与繁荣。