DigiCert 螢幕保護程式攻擊：EV 程式碼簽署憑證被濫用的警訊

一個看似普通的客服支援對話，最後碰到了軟體供應鏈裡非常敏感的一環：程式碼簽署。Mozilla Bugzilla 上的事件說明記載，2026 年 4 月 2 日，攻擊者透過客戶聊天管道聯絡 DigiCert 支援團隊，送出一個偽裝成客戶截圖的 ZIP 檔，裡面其實是帶有惡意酬載的 .scr 可執行檔 。後續報告指出，攻擊者透過遭入侵的支援系統取得有限數量程式碼簽署憑證的初始化碼，其中部分憑證被用來簽署惡意軟體 。

攻擊鏈：從「截圖」到支援入口

這次事件的起點不是高深的密碼學漏洞，而是針對支援人員的社交工程。Help Net Security 的描述與事件文件一致：攻擊者把惡意 ZIP 檔包裝成客戶提供的截圖，而檔案內含的是 Windows 螢幕保護程式格式的 .scr 檔 。

SecurityWeek 報導，惡意軟體感染了兩個端點，其中一個在 4 月 3 日被發現，另一個則在 4 月 14 日才被識別 。攻擊者據稱從受感染系統轉向內部支援入口；該入口有一項受限功能，可讓已驗證的 DigiCert 支援分析師切換到客戶帳戶視角，並存取特定功能，包括待處理憑證的初始化碼 。BleepingComputer 也將影響範圍描述為有限，但更具體指出，外洩內容涉及已核准、尚未交付的 EV 程式碼簽署憑證初始化碼 。

為什麼 EV 程式碼簽署憑證值得攻擊者下手

程式碼簽署憑證是軟體信任鏈的一部分，用來協助判斷軟體的來源與完整性。DigiCert 作為憑證授權機構，在網際網路通訊與軟體散布的信任基礎中扮演重要角色，其程式碼簽署憑證也被軟體開發者廣泛使用 。

因此，這起事件的重點不只是「支援系統被入侵」，而是攻擊者得以借用憑證帶來的信任效果。ThreatNoir 報導，部分取得的程式碼簽署憑證被用來簽署惡意軟體 。CyberInsider 也描述，攻擊者濫用遭入侵的內部支援系統與憑證簽發資料，以取得有效的 EV 程式碼簽署憑證，且部分憑證後續被用於簽署惡意軟體 。

這之所以危險，是因為帶有有效簽章的惡意檔案，在第一時間可能看起來更像合法軟體。Vectra 對這類手法的概括是：攻擊者可利用 EV 憑證簽署惡意檔案，借用 EV 簽署應用程式通常具備的較高信任度；若組織只依賴簽章式信任，仍會暴露在風險中 。

目前沒有證據顯示根金鑰或 CA 金鑰遭入侵

需要清楚區分的是：現有來源描述的是支援端點遭入侵、內部支援功能遭濫用，以及初始化碼被取得 。這些報導並未證明 DigiCert 的根金鑰或 CA 金鑰遭到攻破。

這不代表事件不嚴重。比較準確的說法是，依目前公開資料，這不是整個憑證授權機構被全面接管，而是圍繞支援與憑證交付流程的濫用事件；它的嚴重性在於攻擊者把程式碼簽署的信任訊號轉化成惡意軟體的掩護 。

影響規模：數字要看清楚分類

公開報導中的數字並不完全一致，原因之一是各來源談的可能不是同一類指標：

• ThreatNoir 稱，攻擊者取得的是有限數量的程式碼簽署憑證初始化碼，其中少數被用來簽署惡意軟體 。
• Risky Business 報導有 27 張遭竊的程式碼簽署憑證，後續被用來簽署惡意軟體 。
• ThreatLocker 則提到 DigiCert 總共撤銷了 60 張程式碼簽署憑證 。

因此，判讀事件規模時要分清楚：來源是在談「取得」、「遭濫用」還是「被撤銷」的憑證。即使整體範圍被描述為有限，少數看似有效的程式碼簽署憑證，也足以在惡意軟體活動中製造信任錯覺 。

應變：撤銷憑證、取消待處理訂單

BleepingComputer 報導，DigiCert 在發現後 24 小時內撤銷已識別的憑證，並將撤銷日期回溯設定為憑證簽發日期 。受影響時間窗內的待處理訂單，也被預防性取消 。ThreatNoir 同樣指出，受影響憑證在發現後 24 小時內撤銷，相關時間窗內的待處理訂單遭取消 。

撤銷可以限制後續濫用，但不代表防禦工作就此結束。資安團隊仍需要結合憑證資料、雜湊值、檔案行為與威脅情資脈絡來判斷可疑檔案，因為 EV 簽章本身可能被攻擊者刻意拿來當作信任包裝 。

另一個麻煩：Microsoft Defender 的誤報

事件前後還出現了額外混亂。BleepingComputer 報導，Microsoft Defender 曾將 DigiCert 憑證誤判為 Trojan:Win32/Cerdigent.A!dha 。daily.dev 則整理稱，Defender 在 2026 年 4 月 30 日的一次簽章更新後，錯誤標記合法的 DigiCert 根憑證；Microsoft 後續透過 Security Intelligence 更新 1.449.430.0 修正，並還原遭移除的憑證 。

對企業來說，這是很實際的事件應變難題：團隊必須同時分辨真正的憑證濫用、帶有可疑簽章的惡意軟體警報，以及針對合法憑證的誤報 。

資安團隊該記住的幾件事

這起事件並不代表程式碼簽署失去價值。真正的教訓是：程式碼簽章只能是信任訊號之一，不能是唯一判準。

• 驗證簽章，不要盲目信任。 有效簽章或 EV 簽章不應自動等於檔案安全；攻擊者確實會利用 EV 憑證簽署惡意檔案，來借用其較高信任度 。
• 看憑證細節。 發行者、序號、憑證鏈、時間戳與撤銷狀態都很重要；在 DigiCert 事件中，撤銷憑證並將撤銷日期回溯至簽發日，是關鍵的控管措施之一 。
• 把行為分析放在同等甚至更高的位置。 雜湊值、程序行為、網路連線、持久化機制與沙箱結果，應與簽章資訊一起評估；簽署過的惡意軟體本來就是要利用信任落差 。
• 把支援與管理入口視為高風險區。 這起事件顯示，即使是受限的支援功能，只要能接觸客戶帳戶或憑證初始化碼，也可能成為高價值攻擊面 。
• 處理憑證警報時保留誤報判斷。 Defender 事件提醒我們，憑證相關警報不一定等於真實感染；daily.dev 報導稱，合法 DigiCert 根憑證曾被錯誤偵測，並由 Microsoft 更新修正 。

結論

DigiCert 事件的資安意義，在於攻擊者把 EV 程式碼簽署憑證的信任效果反過來用在防禦者身上。現有報告指向的是支援系統、初始化碼與被濫用憑證所構成的有限事件，而不是根金鑰或 CA 金鑰被攻破 。但它傳達的訊息很明確：在現代惡意軟體防禦中，數位簽章很重要，卻永遠不該是最後一句話。