事件背景：老牌组件再遭毒手
近日，npm 生态中的知名包 node-ipc 再次曝出安全漏洞，研究人员在三个新发布的版本（9.1.6、9.2.3、12.0.1）中发现了恶意的后门代码。值得注意的是，这些恶意版本并非由原作者发布，而是由一个名为“atiertant”的账号在时隔 21 个月后突然更新上传。
从我们的应急响应经验来看，攻击者通过获取受信任维护者的账户权限或混入维护者名单，利用“合法包的恶意更新”这一手段，极大地降低了开发者的防范心理。这种供应链攻击模式往往比传统的 typosquatting（拼写抢注）更难被检测。
攻击链分析：隐蔽的执行与窃取
与以往常见的安装脚本植入不同，此次攻击者采用了更为隐蔽的 IIFE（立即执行函数表达式）方式，直接将恶意代码追加到 node-ipc.cjs 文件的末尾。这意味着只要项目在运行时调用了 require('node-ipc')，恶意代码就会立即触发，无需任何安装钩子。
攻击者在执行后门逻辑前，设置了严格的“防探测”门槛：
- 哈希校验：对于 12.0.1 版本，攻击者硬编码了一个 SHA-256 哈希值，只有当主模块路径的哈希值与预设值匹配时，木马才会激活。这表明攻击者极有可能在进行针对性的定向打击。
- 多通道外传：除了常规的 HTTPS POST 数据外，该木马还会通过 DNS TXT 记录进行数据外传。为了避开企业的 DNS 安全审计，它甚至会强制修改系统 DNS 解析器指向公共 DNS，绕过本地的安全监控策略。
技术手法：不仅是简单的窃密
该木马的危害性在于其广度与深度。它能够遍历并读取包括 AWS、Google Cloud、Azure、Kubernetes、GitHub CLI 等 90 多种类型的凭据及 SSH 密钥、Shell 历史记录等敏感信息。
这一环节是很多企业容易忽视的重点。由于开发者往往会在本地环境存储大量云服务凭据，一旦开发环境沦陷，攻击者便能迅速横向移动至企业的生产云环境，造成不可估量的损失。
Solar 应急响应建议
面对此类供应链投毒，单一的防病毒软件往往难以奏效。基于此次事件，Solar 应急响应团队建议企业采取以下行动：
- 立即排查与清理：强制检查项目中所有依赖项，若使用了上述三个版本的 node-ipc，请立即回退至已知的安全版本（如 9.2.1 或 12.0.0）。
- 默认凭据重置：一旦发现曾使用过上述版本的环境，必须假设相关凭据已泄露，立即轮换所有涉及的云凭据、SSH 密钥及令牌。
- 强化网络出口审计：企业应严格管控开发环境的出口流量，对于非必要的外部域名（如本次事件中的 sh.azurestaticprovider.net）进行阻断，并监控异常的 DNS 查询行为。
- 供应链安全治理：建立软件成分分析（SCA）机制，不仅要关注漏洞，更要关注依赖包维护者信息的变更及异常的发布行为。
类似攻击近年来明显增加，企业应将安全防线前移至开发环节。如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816
官网：www.solarsecurity.cn / www.sierting.com
