DigiCert 屏保文件攻击：EV 代码签名证书被滥用意味着什么

一次看似普通的客服聊天，把 DigiCert 的安全事件推到了软件供应链最敏感的信任层：代码签名。

Mozilla 记录的事件说明显示，2026年4月2日，攻击者通过客户聊天渠道联系 DigiCert 支持团队，提交了一个伪装成客户截图的 ZIP 文件；文件里不是图片，而是带有恶意载荷的 .scr 可执行文件 。随后，攻击者通过被攻陷的支持环境和内部支持功能，获得了有限数量代码签名证书的初始化码；其中一些证书被用于签署恶意软件 。

先厘清：这是信任流程被滥用，不是根密钥被攻破

这起事件的危险之处，在于攻击者把目标对准了软件签名的信任机制。但从现有公开资料看，报道指向的是支持端点、内部支持门户、客户账户代理访问功能以及证书初始化码被滥用 。

换句话说，目前这些资料并没有证明 DigiCert 的根密钥或 CA 私钥被攻破。这个边界很重要：它不能把事件变得无关紧要，但说明已知问题更像是围绕代码签名证书发放和支持流程的滥用，而不是整家证书颁发机构被完全接管 。

攻击是怎么发生的

攻击入口并不复杂：社工。Help Net Security 对事件的概括与 Mozilla 事件说明一致，攻击者把恶意 ZIP 文件伪装成客户截图，里面包含 Windows 屏幕保护程序格式的 .scr 文件 。在 Windows 里，.scr 本质上可以是可执行文件；如果它被当作普通截图处理，就容易给攻击者留下机会。

SecurityWeek 报道称，恶意软件感染了两个端点：一个在4月3日被发现，另一个在4月14日被发现 。攻击者随后从受感染系统转向 DigiCert 的内部支持门户 。该门户中有一项受限功能，允许已认证的支持分析师代理进入客户账户；据 SecurityWeek 报道，这种访问可触及特定功能，包括待处理证书的初始化码 。BleepingComputer 也将影响范围描述为有限，并指出暴露的是已批准但尚未交付的 EV 代码签名证书初始化码 。

为什么 EV 代码签名证书会成为高价值目标

DigiCert 是证书颁发机构，也就是 CA。它在浏览器、操作系统、互联网通信和软件分发的信任体系中扮演重要角色；其代码签名证书被软件开发者使用 。代码签名的作用，是帮助用户、系统和安全产品判断软件来自哪里、是否在发布后被篡改。

EV 是 Extended Validation，即扩展验证。对攻击者来说，EV 代码签名证书有吸引力，原因很直接：它能让恶意文件看起来更像来自可信软件发布者。ThreatNoir 报道称，部分被获得的代码签名证书被用于签署恶意软件 。CyberInsider 也称，攻击者滥用了被窃取的证书发放数据来获取有效 EV 代码签名证书，其中一些后来被用于签署恶意软件 。

这类风险并不限于 DigiCert 这一个事件。Vectra 在分析 EV 证书武器化时指出，攻击者可使用 EV 证书签署恶意文件，借助 EV 签名应用通常获得的更高信任度来规避防御；如果组织只依赖基于签名的信任判断，就会暴露在风险之下 。

影响范围：数字不一致，关键要看口径

公开报道中的数字并不完全相同，主要是因为各家说的类别不一样：

• ThreatNoir 称，攻击者获得了有限数量代码签名证书的初始化码，其中少数证书被用于签署恶意软件 。
• Risky Business 报道称，有 27 张代码签名证书被盗，并在之后被用于签署恶意软件 。
• ThreatLocker 则称，DigiCert 共吊销了 60 张代码签名证书 。

因此，不能把这些数字简单相加，也不能直接画等号。安全评估时应区分：哪些是被获得的证书或初始化码，哪些被实际用于签署恶意软件，哪些只是作为预防措施被吊销。即使范围有限，事件仍然严重，因为少量有效签名证书就足以让一批恶意软件在初筛阶段显得更可信 。

DigiCert 的处置：吊销证书，取消待处理订单

BleepingComputer 报道称，DigiCert 在发现后 24 小时内吊销了已识别的证书，并将吊销日期设为证书签发日期 。同一报道还称，受影响时间窗口内的待处理订单被作为预防措施取消 。ThreatNoir 也称，受影响证书在发现后 24 小时内被吊销，相关时间窗口内的待处理订单被取消 。

吊销可以限制后续滥用，但不等于安全团队可以停止分析。对于已经落地或已被传播的可疑文件，仍需要结合证书数据、文件哈希、运行行为和威胁情报来判断。原因很简单：攻击者使用 EV 签名，本来就是为了把恶意软件包装成更可信的样子 。

另一个麻烦：Microsoft Defender 的误报

事件期间还出现了一个让响应工作更复杂的问题：Microsoft Defender 误报。BleepingComputer 报道称，Microsoft Defender 曾将 DigiCert 证书错误识别为 Trojan:Win32/Cerdigent.A!dha 。

Daily.dev 的摘要称，在4月30日的一次签名更新后，Defender 错误标记了合法的 DigiCert 根证书；微软随后通过 Security Intelligence 更新 1.449.430.0 修复，并恢复了被移除的证书 。

这对企业安全团队意味着什么？同一时间段内，响应人员既要排查真实的证书滥用和被签名恶意软件，也要识别针对合法证书的误报。若没有清晰的分流流程，告警很容易互相干扰 。

安全团队应该吸取什么教训

最重要的结论不是代码签名没用，而是代码签名不能被当作唯一判断标准。它是信任信号之一，不是最终裁决。

实际工作中，可以重点调整几件事：

• 验证签名，但不要盲信签名。 有效签名或 EV 签名只能说明文件通过了某种签名链路，并不自动代表文件安全；攻击者确实会用 EV 证书签署恶意文件 。
• 把证书细节纳入检测规则。 对可疑二进制文件，应检查证书颁发者、序列号、证书链、时间戳和吊销状态。DigiCert 事件中，吊销证书并把吊销日期设为签发日期是关键处置动作 。
• 更重视行为证据。 哈希、进程树、网络连接、持久化方式、沙箱结果和终端遥测，应与签名状态一起评估。签名越可信，越不能忽视行为异常 。
• 把支持门户和管理员代理功能当作高风险区域。 这起事件说明，即使是受限的支持功能，只要能代理访问客户账户或触及证书初始化码，也可能成为关键攻击面 。
• 给证书类告警建立误报处理流程。 Defender 误报显示，证书告警不必然等于真实感染；合法 DigiCert 根证书曾被误标，后来由微软更新修复 。

结论

DigiCert 这起事件值得关注，不是因为现有资料显示根 CA 被攻破，而是因为攻击者成功绕到了信任链的业务流程层：支持系统、初始化码和 EV 代码签名证书 。一旦恶意软件披上有效签名的外衣，依赖单一签名判断的防御就会变脆弱。

对防守方来说，正确做法不是放弃代码签名，而是降低对单一信号的迷信。签名可以提高分析质量，但最后仍要回到证书上下文、文件行为、威胁情报和响应流程的综合判断。