2026 年 4 月 9 日至 10 日，知名硬件检测工具 CPU-Z 与 HWMonitor 的开发商 CPUID 遭遇供应链攻击。攻击者入侵了 CPUID 的分发 API 约六小时，将官方下载链接重定向至托管在 Cloudflare R2 上的恶意安装包。这次事件与传统的签名二进制篡改不同 —— 原始签名文件完好无损，但分发链路被投毒，导致数百万用户可能下载到伪装成 HWiNFO 的木马程序。本文从工程视角复盘此次攻击的技术细节，探讨签名校验失效的深层原因、依赖链渗透的隐蔽性，以及企业如何通过二进制审计自动化降低供应链风险。

签名校验的盲区：从信任模型失效说起

在软件供应链安全领域，代码签名通常被视为最后一道防线。开发者使用私钥对二进制文件进行数字签名，操作系统和终端安全软件在执行前验证签名完整性与签发者身份。CPUID 在事件声明中明确指出 “我们的签名原始文件未被篡改”，这在技术层面确实成立 —— 攻击者并未直接修改 CPU-Z 或 HWMonitor 的可执行文件，而是攻击了更上游的分发环节。这种攻击模式暴露了签名校验体系的核心盲区：签名只能保证 “文件本身未被修改”，无法保证 “用户最终收到的文件与签名文件一致”。

从工程角度来看，签名校验的信任链条包含多个环节 —— 构建环境、签名私钥、签名服务、分发管道、终端验证。传统安全实践倾向于在终端部署签名校验机制，例如 Windows 的 Authenticode 或 macOS 的 Gatekeeper，但这些机制仅在文件写入磁盘后触发校验。如果攻击者能够在签名验证之前就已经完成文件替换，那么终端的校验机制形同虚设。CPUID 事件中，攻击者正是利用了这一点：通过篡改下载链接，让用户在毫秒级别的时间内被重定向到恶意服务器，而整个过程发生在 TLS 加密通道之内，终端安全软件难以区分合法下载与恶意重定向。

这给工程团队带来的直接启示是：签名校验不应作为唯一的信任锚点。在 CI/CD 流程中，应当对每一次构建产出的二进制文件计算哈希值并将哈希摘要登记到可信账本中，例如使用 Sigstore 的 rekor 透明日志服务或自建的二进制指纹数据库。下载端在获取文件后，不仅验证签名，还应比对预先登记的哈希摘要，确保分发的二进制与构建产出的指纹完全一致。这种 “双重校验” 机制能够在签名私钥泄露或分发链路被篡改时提供额外的防护层。

依赖链渗透：被忽视的攻击面

CPUID 事件中，攻击者入侵的目标并非核心代码仓库，而是一个 “次要功能（辅助 API）”。根据 BleepingComputer 的报道，这个 API 负责动态生成分发链接，在用户访问下载页面时将请求重定向至 Cloudflare R2 存储。攻击者获得该 API 的访问权限后，修改了链接生成逻辑，使得特定时间段内的下载请求被路由至攻击者控制的 R2 存储桶。这个案例揭示了现代软件供应链中一个常被忽视的问题：依赖链渗透的攻击成本与收益严重不对等。

现代软件项目的依赖链往往极其复杂。一个典型的 Web 应用可能直接依赖数十个开源库，而这些库又各自依赖数十个传递依赖，形成一个深达十层以上的依赖图。CPUID 的情况类似 —— 官方网站的下载功能可能依赖内容管理系统、存储服务 SDK、CDN 配置接口等多个外部组件。攻击者无需攻破核心代码仓库或签名私钥，只要能够渗透任意一个下游依赖项，就能在用户无感知的情况下完成恶意 payload 的投递。这种 “攻其一点、全线渗透” 的攻击模式，正在成为供应链攻击的主流趋势。

从工程防御的角度看，依赖链安全的核心挑战在于可见性。大多数组织能够清晰地掌握直接依赖项的版本信息，但对于传递依赖项的构成往往缺乏完整的视图。工具如 Trivy、Dependabot 能够在一定程度上检测已知漏洞，但对于依赖项的可信性问题 —— 即某个依赖项是否会在特定条件下表现出恶意行为 —— 缺乏有效的检测手段。本次事件中，攻击者使用的恶意安装包使用了常见的 Inno Setup 打包工具，文件名为 HWiNFO_Monitor_Setup，这种伪装策略利用了用户对硬件工具的信任习惯，而非依赖项本身的漏洞。工程团队需要建立依赖项的信任评估机制，包括对第三方组件的来源审查、版本锁定以及运行时行为监控。

二进制审计自动化：从响应式到预防式

在 CPUID 事件曝光后，安全研究人员通过 VirusTotal 分析发现恶意样本被至少 20 个杀毒引擎标记为 Trojan（特洛伊木马），部分厂商将其识别为 Tedy Trojan 或 Artemis Trojan。更值得关注的是，安全研究人员 vxunderground 在分析后指出，该恶意软件 “使用了高级 loader 技术，采用多阶段攻击策略，几乎完全在内存中运行，并使用代理 NTDLL 功能来规避 EDR 和杀软的检测”。这种高级威胁特征意味着传统的静态扫描可能无法有效捕获攻击，而需要更细粒度的二进制审计能力。

二进制审计自动化的目标是在恶意代码进入生产环境之前将其拦截。对于 CPU-Z 这类分发量极大的工具软件，每一次版本发布都可能被数以百万计的用户直接执行，容不得半点闪失。工程团队应当在构建流程中嵌入多层审计环节：第一层是基于哈希的完整性校验，确保构建产出的文件与源码仓库的提交记录一致；第二层是基于 YARA 规则或 Sigma 规则的静态特征匹配，能够识别已知恶意代码模式；第三层是基于动态行为分析的沙箱检测，在受控环境中执行样本并监控其文件系统操作、注册表访问、网络通信等行为；第四层是基于机器学习的异常检测，通过分析 PE/ELF 结构的熵值、节区分布、导入表特征等维度识别加壳或混淆恶意软件。

对于资源有限的团队，可以从以下几个可落地的参数开始构建基础能力。首先，在 CI/CD 管道中集成文件哈希校验步骤，使用 SHA-256 计算构建产物的指纹，并将指纹以加密方式登记到版本控制系统中，每次发布前自动比对历史指纹。其次，部署开源的恶意软件检测工具如 ClamAV 或 LOKI 作为构建门禁，对所有产出的可执行文件进行基线扫描。再次，为关键软件包启用代码签名并配置强签名策略 —— 例如要求签名证书来自受信任的根 CA、证书链完整、签名时间戳有效。最后，建立分发链路的完整性监控机制，对 CDN 存储桶、下载服务器、API 端点进行定期巡检，检测异常的配置文件修改或未经授权的访问日志。

供应链安全的工程度量：从清单到度量体系

将供应链安全从口号转化为可执行的工程实践，需要建立一套可度量的指标体系。以下是建议的核心度量维度，可供安全团队在内部推行时参考。

在供应链可见性维度，应当统计并持续更新直接依赖项数量、传递依赖项总数、依赖项的平均维护活跃度（如最近一次提交距今的天数）、以及依赖项中已知漏洞的数量与等级分布。CPUID 事件中，如果其依赖的 API 服务有完整的依赖清单和安全审计记录，攻击者试图通过辅助 API 入侵时更容易被异常检测机制捕获。

在完整性验证维度，建议追踪以下指标：已签名的二进制文件占比、构建流程中哈希校验的覆盖率、分发链路的完整性检测频率、签名验证失败的累计次数。这些指标能够帮助团队量化 “签名校验是否真正生效” 这一关键问题。

在响应效率维度，需要度量从漏洞披露到修复完成的平均时间（MTTR）、从异常检测到事件确认的平均时间、以及从事件确认到用户通知的平均时间。CPUID 在事件发生后约 6 小时内完成修复并恢复服务，这个响应速度值得肯定，但事件发现到完全修复之间的时间窗口 —— 也就是用户暴露在风险中的时间段 —— 仍然值得深入复盘。

供应链安全不是一次性的项目，而是需要持续投入的工程能力。通过在构建、分发、部署全流程中嵌入自动化审计机制，配合可度量的安全指标体系，组织能够在攻击者之前发现供应链薄弱环节，将被动响应转化为主动防御。

参考资料

  • BleepingComputer: "Supply chain attack at CPUID pushes malware with CPU-Z/HWMonitor" (2026-04-10)
  • Igor’s Labs: "Warning: CPUID suspected of being a virus, suspicious HWMonitor downloads"
  • vxunderground (Twitter/X): Technical analysis of the trojanized loader TTPs