2026 年 4 月，安全社区披露了一起针对 Bitwarden CLI 的供应链攻击事件。恶意代码通过被篡改的 npm 包 @bitwarden/cli@2026.4.0 进行分发，在约 1 小时 33 分钟的时间窗口内影响了下游开发者。本文不重复攻击链条的完整叙事，而是聚焦于安全研究人员识别与检测该 compromise 的方法论，并提取可复用的特征签名与检测参数。
攻击概述与检测背景
本次攻击的核心特征在于攻击者并未直接篡改 Bitwarden 官方代码仓库，而是通过入侵 CI/CD 发布流程，将恶意加载器注入到合法的 npm 包分发路径中。受影响版本 2026.4.0 的包结构发生了两处关键变化：根目录 package.json 中的 preinstall 钩子被重新指向恶意加载器 bw_setup.js，而 bin 字段中的 bw 命令入口同样指向该加载器而非原有的 CLI 可执行文件。这种包级别的注入手法使得传统的源码审计难以发现异常，因为恶意代码并未存在于源代码仓库中。
攻击的检测背景值得注意：这是 Checkmarx 供应链攻击活动的最新演进。安全社区将此类使用 GitHub Actions 滥用、凭证窃取与蠕虫式传播的复合攻击手法统称为 Checkmarx 风格攻击。JFrog、Socket 与 OX Security 等多家安全厂商在攻击披露后进行了独立分析，形成了互补的检测视角。
静态分析驱动的包级别检测
安全研究人员首先通过静态分析发现了包结构异常。正常的 Bitwarden CLI 包在 package.json 中仅包含标准的发布脚本与依赖声明，而恶意版本显式定义了 preinstall 钩子来执行自定义加载逻辑。这种在生产包中引入额外安装时执行脚本的做法本身就是高度可疑的信号。
检测人员进一步对包内容进行哈希校验，发现根目录的元数据与内部 bundle 存在版本矛盾。包根目录声明为 2026.4.0，但嵌入的 build/bw.js 仍然指向 2026.3.0。这种版本不一致表明恶意层是在已有合法版本之上独立封装，而非通过正常构建流程产生。静态分析还提取了关键文件的 SHA-256 哈希值：加载器 bw_setup.js 的哈希为 18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb，恶意负载 bw1.js 的哈希为 8605e365edf11160aad517c7d79a3b26b62290e5072ef97b102a01ddbb343f14。这些哈希值可作为包完整性验证的即时检测签名。
静态分析的进阶应用包括对 JavaScript 代码的结构指纹识别。恶意加载器 bw_setup.js 包含一段固定模式的 Bun 运行时下载逻辑，版本硬编码为 1.3.13，从 github.com/oven-sh/bun/releases/download 获取平台特定的二进制文件。在面向 npm 包的静态扫描规则中，匹配以下模式组合可有效识别同类加载器：非预期存在的 preinstall 或 postinstall 脚本、指向非官方域名下载可执行文件的代码、以及与包声明功能不符的二进制运行时注入行为。
行为监控与动态分析特征
动态分析揭示了恶意负载的完整行为链。加载器 bw_setup.js 首先检查目标系统是否已安装 Bun 运行时，如未安装则从 GitHub 下载并解压到本地目录，随后以 Bun 解释器执行混淆的负载文件 bw1.js。这一设计具有双重 evasion 意图：既避免了受害者需要预先安装运行时环境的依赖，又将执行路径从常规的 Node.js 切换到相对小众的 Bun，使得基于 Node.js 行为签名的检测工具可能遗漏。
负载文件 bw1.js 解混淆后，安全研究人员识别出三个主要采集器模块。第一个是文件系统采集器，针对 SSH 私钥 (~/.ssh/id_、~/.ssh/id*)、Git 凭证 (.git/config、.git-credentials)、npm 凭证 (~/.npmrc)、环境变量文件 (.env)、Shell 历史记录 (~/.bash_history、~/.zsh_history)，以及云服务商凭证 (AWS ~/.aws/credentials、GCP ~/.config/gcloud/credentials.db)。值得注意的是，采集器还特别针对 AI 编码助手的配置文件，包括 Claude (~/.claude.json、.claude.json、.claude/mcp.json)、Kiro (.kiro/settings/mcp.json) 以及其他 MCP 相关配置。
第二个模块是 Shell 与环境采集器，其核心功能是执行 gh auth token 命令获取当前 GitHub CLI 的认证令牌，同时遍历 process.env 捕获所有环境变量并使用正则表达式筛选敏感凭证。GitHub 令牌匹配模式包括 ghp_ 前缀与 gho_ 前缀，npm 令牌则匹配 npm_ 前缀后跟 36 位以上字母数字字符。
第三个模块是 GitHub Actions Runner 采集器，它在获取有效 GitHub 令牌后执行自动化的凭证扩大化操作。具体步骤包括：枚举令牌可写入的仓库列表、读取每个仓库的 Actions Secrets、创建新分支、提交恶意 Workflow 文件、等待 Workflow 执行并下载产物 artifact、最后删除分支与 Workflow 痕迹以掩盖攻击路径。这一行为模式构成了典型的供应链横向移动，对于在 CI/CD 环境中部署了基于 GitHub Actions 自动化流程的组织而言具有极高的危害等级。
网络层面检测签名与威胁情报
网络层面的检测依赖于攻击者使用的固定基础设施。恶意负载的默认外传目标为 audit.checkmarx.cx，解析 IP 为 94.154.172.43，传输路径为 /v1/telemetry。组织可在网络出口层部署对以下域名的阻断规则或深度检测：主域名 audit.checkmarx.cx、及其解析 IP 94.154.172.43。
备用外传通道同样包含可检测的特征。恶意代码在 GitHub commit 消息中预设了两类标记用于备用指令与数据交换。第一类标记为 LongLiveTheResistanceAgainstMachines，用于在公开 commit 中隐式传输被窃取的 PAT（Personal Access Token）。第二类标记为 beautifulcastle，后跟 RSA 签名数据，用于在主外传通道失效时动态恢复备用控制域名。安全团队可在 GitHub Enterprise 或 GitHub.com 的审计日志中针对包含上述关键词的 commit 消息设置告警规则。
加密传输的特征同样提供了检测窗口。恶意负载使用混合加密方案：使用 AES-256-GCM 加密采集数据，使用 RSA-OAEP-SHA256 包装 AES 会话密钥。尽管加密本身难以直接检测，但外传数据包的 TLS 握手元数据、请求头特征（Content-Type: application/json）、以及固定的目的路径 /v1/telemetry 仍可作为网络层检测的触发条件。
供应链安全检测清单与工程化参数
针对此类 npm 包供应链攻击，组织可部署以下工程化检测措施。
在包摄入控制层面，启用 npm config set ignore-scripts true 以阻止自动执行安装钩子，或在私有 npm registry 层面配置安装前扫描策略。使用 JFrog Xray 或 Socket 的依赖扫描能力时，配置以下检测规则：检测非预期的 preinstall/postinstall 钩子、检测包版本号与内部元数据的版本不一致、检测指向非官方域名的可执行文件下载行为。
在 CI/CD 环境监控层面，GitHub Actions 工作流审计应重点关注以下异常模式：非由用户直接触发的 Workflow 运行、由新创建分支触发的 Workflow 実行、包含 pull_request_target 触发器的未知 Workflow、以及在 Workflow 产物下载后立即删除分支与文件的操作序列。建议为所有 CI/CD 管道配置令牌轮换策略，GitHub PAT 的有效期不超过 90 天，npm 发布令牌的生命周期应与发布窗口匹配。
在主机检测层面，可在终端防护策略中加入以下哈希值检测：18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb（加载器）与 8605e365edf11160aad517c7d79a3b26b62290e5072ef97b102a01ddbb343f14（负载）。文件系统扫描应覆盖工作目录是否存在 bw_setup.js、bw1.js 以及可疑的 bun 或 bun.exe 可执行文件。网络层面建议在 EDR 或网络检测系统中添加对 audit.checkmarx.cx 域名的出站连接告警。
总结与可操作建议
本次 Bitwarden CLI 供应链攻击的检测过程展示了多层防御的必要性。攻击者通过包层面的注入而非源码篡改实现了隐蔽性，利用合法包身份绕过初步信任，同时通过 Bun 运行时加载与混合加密外传实现了行为层面的 evasion。有效的检测依赖于包摄入时的静态特征校验、运行时行为监控、以及网络层与 GitHub 审计层面的异常检测联动。
对于已安装受影响版本的组织，安全社区建议的即时响应步骤包括：立即卸载 @bitwarden/cli@2026.4.0 并清理 npm 缓存、轮换所有在开发者工作站上可能暴露的凭证（包括 GitHub 令牌、npm 令牌、云服务商密钥）、检查 GitHub 账户中是否存在非授权创建的新仓库与 Workflow 文件。在检测能力建设方面，建议优先在 npm 包摄入控制与 CI/CD Workflow 审计环节引入自动化检测规则，这两处是此类供应链攻击的最有效阻断窗口。
参考资料
- JFrog Security Research: "TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI"
- The Hacker News: "Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign"
- OX Security: "Shai-Hulud: The Third Coming" Bitwarden CLI Supply Chain Attack Analysis