SecurityWeek 報導,惡意軟體感染了兩個端點,其中一個在 4 月 3 日被發現,另一個則在 4 月 14 日才被識別 。攻擊者據稱從受感染系統轉向內部支援入口;該入口有一項受限功能,可讓已驗證的 DigiCert 支援分析師切換到客戶帳戶視角,並存取特定功能,包括待處理憑證的初始化碼 。BleepingComputer 也將影響範圍描述為有限,但更具體指出,外洩內容涉及已核准、尚未交付的 EV 程式碼簽署憑證初始化碼 。
程式碼簽署憑證是軟體信任鏈的一部分,用來協助判斷軟體的來源與完整性。DigiCert 作為憑證授權機構,在網際網路通訊與軟體散布的信任基礎中扮演重要角色,其程式碼簽署憑證也被軟體開發者廣泛使用 。
因此,這起事件的重點不只是「支援系統被入侵」,而是攻擊者得以借用憑證帶來的信任效果。ThreatNoir 報導,部分取得的程式碼簽署憑證被用來簽署惡意軟體 。CyberInsider 也描述,攻擊者濫用遭入侵的內部支援系統與憑證簽發資料,以取得有效的 EV 程式碼簽署憑證,且部分憑證後續被用於簽署惡意軟體 。
這之所以危險,是因為帶有有效簽章的惡意檔案,在第一時間可能看起來更像合法軟體。Vectra 對這類手法的概括是:攻擊者可利用 EV 憑證簽署惡意檔案,借用 EV 簽署應用程式通常具備的較高信任度;若組織只依賴簽章式信任,仍會暴露在風險中 。
需要清楚區分的是:現有來源描述的是支援端點遭入侵、內部支援功能遭濫用,以及初始化碼被取得 。這些報導並未證明 DigiCert 的根金鑰或 CA 金鑰遭到攻破。
這不代表事件不嚴重。比較準確的說法是,依目前公開資料,這不是整個憑證授權機構被全面接管,而是圍繞支援與憑證交付流程的濫用事件;它的嚴重性在於攻擊者把程式碼簽署的信任訊號轉化成惡意軟體的掩護 。
公開報導中的數字並不完全一致,原因之一是各來源談的可能不是同一類指標:
因此,判讀事件規模時要分清楚:來源是在談「取得」、「遭濫用」還是「被撤銷」的憑證。即使整體範圍被描述為有限,少數看似有效的程式碼簽署憑證,也足以在惡意軟體活動中製造信任錯覺 。
BleepingComputer 報導,DigiCert 在發現後 24 小時內撤銷已識別的憑證,並將撤銷日期回溯設定為憑證簽發日期 。受影響時間窗內的待處理訂單,也被預防性取消 。ThreatNoir 同樣指出,受影響憑證在發現後 24 小時內撤銷,相關時間窗內的待處理訂單遭取消 。
撤銷可以限制後續濫用,但不代表防禦工作就此結束。資安團隊仍需要結合憑證資料、雜湊值、檔案行為與威脅情資脈絡來判斷可疑檔案,因為 EV 簽章本身可能被攻擊者刻意拿來當作信任包裝 。
事件前後還出現了額外混亂。BleepingComputer 報導,Microsoft Defender 曾將 DigiCert 憑證誤判為 Trojan:Win32/Cerdigent.A!dha 。daily.dev 則整理稱,Defender 在 2026 年 4 月 30 日的一次簽章更新後,錯誤標記合法的 DigiCert 根憑證;Microsoft 後續透過 Security Intelligence 更新 1.449.430.0 修正,並還原遭移除的憑證 。
對企業來說,這是很實際的事件應變難題:團隊必須同時分辨真正的憑證濫用、帶有可疑簽章的惡意軟體警報,以及針對合法憑證的誤報 。
這起事件並不代表程式碼簽署失去價值。真正的教訓是:程式碼簽章只能是信任訊號之一,不能是唯一判準。
DigiCert 事件的資安意義,在於攻擊者把 EV 程式碼簽署憑證的信任效果反過來用在防禦者身上。現有報告指向的是支援系統、初始化碼與被濫用憑證所構成的有限事件,而不是根金鑰或 CA 金鑰被攻破 。但它傳達的訊息很明確:在現代惡意軟體防禦中,數位簽章很重要,卻永遠不該是最後一句話。