一段看似普通嘅客戶支援 chat,最後打到軟件發行入面最敏感嘅一層:Code Signing。根據 Mozilla Bugzilla 上記錄嘅事件描述,2026年4月2日,攻擊者透過客戶聊天渠道聯絡 DigiCert 支援團隊,送出一個扮作客戶截圖嘅 ZIP 檔;入面其實有帶惡意 payload 嘅 .scr 可執行檔 [12]。
.scr 係 Windows 屏幕保護程式常見格式,亦可以被包裝成可執行攻擊載體 [2]。
之後,攻擊者經由被攻陷嘅支援系統,取得有限數量 Code Signing 憑證嘅初始化碼;其中部分憑證被用嚟簽署惡意軟件 [1]。所以,呢次事件真正危險之處唔只係「支援系統中招」,而係攻擊者借用咗憑證本身嘅信任效果。
事件點樣發生:由假截圖到支援入口
Help Net Security 將今次攻擊描述為針對 DigiCert 支援渠道嘅社交工程:攻擊者扮成客戶,送出一個似係截圖嘅 ZIP 檔,但實際內藏惡意 .scr 檔案 [2]。
SecurityWeek 引述資料指,惡意程式感染咗兩個端點;其中一個喺4月3日被發現,另一個喺4月14日先被發現 [10]。攻擊者其後由被攻陷系統轉入內部支援入口;該入口有一項有限功能,容許已驗證嘅 DigiCert 支援分析員切換到客戶帳戶視角,並接觸到部分功能,包括待處理憑證嘅初始化碼 [
10]。
BleepingComputer 對範圍嘅描述同樣偏向有限:受影響嘅係已批准、但尚未交付嘅 EV Code Signing 憑證初始化碼 [5]。
點解 EV Code Signing 憑證咁吸引攻擊者
Code Signing 憑證可以理解為軟件發行入面嘅「身分證加防拆封標籤」:佢幫使用者、作業系統同保安產品判斷軟件來源同完整性。DigiCert 作為主要憑證簽發機構,喺互聯網通訊同軟件分發信任鏈入面有重要角色;其 Code Signing 憑證亦被軟件開發者使用 [11]。
問題在於,攻擊者唔需要完全打爆整間憑證機構,都可以濫用呢種信任訊號。ThreatNoir 指,部分取得嘅 Code Signing 憑證被用嚟簽署惡意軟件 [1]。CyberInsider 亦形容事件涉及被攻陷嘅內部支援系統同憑證簽發資料,攻擊者藉此取得有效 EV Code Signing 憑證,部分其後用於簽署惡意軟件 [
11]。
簽咗名嘅惡意軟件,第一眼可以顯得更似合法程式。Vectra 對同類手法嘅分析指出,攻擊者可以用 EV 憑證簽署惡意檔案,利用外界對 EV 簽署應用程式較高嘅信任;如果機構只靠簽名判斷可信與否,就會有缺口 [15]。
要講清楚:目前唔係 Root 或 CA 密鑰失守
公開資料需要分清楚。現有來源講到嘅係:支援端點被攻陷、內部支援功能被濫用,以及初始化碼被接觸或取得 [1][
5][
10][
12]。呢啲資料並無顯示 DigiCert Root 密鑰或 CA 簽發密鑰被攻陷。
換句話講,事件唔可以輕描淡寫,但亦唔應該被講成整間憑證機構完全被接管。按目前報道,核心係 Code Signing 憑證支援與簽發流程被濫用,而唔係 Root/CA 層級嘅全面失守 [1][
5][
10]。
影響有幾大?數字要分清楚
目前公開數字唔完全一致,主要因為唔同來源講緊唔同類別:
- ThreatNoir 指,攻擊者取得有限數量 Code Signing 憑證嘅初始化碼,其中部分被用嚟簽署惡意軟件 [
1]。
- Risky Business 報道指,有27張 Code Signing 憑證被盜,之後用於簽署惡意軟件 [
8]。
- ThreatLocker 則稱總共有60張 Code Signing 憑證被撤銷 [
3]。
所以,讀呢啲數字時要問清楚:係「取得」、「實際濫用」,定係「最終撤銷」?即使事件範圍被形容為有限,只要有少量看似有效嘅 Code Signing 憑證落入攻擊者手上,已經足夠用嚟提升惡意軟件嘅可信外觀 [1][
15]。
DigiCert 點樣止血:撤銷同取消待處理訂單
BleepingComputer 報道指,DigiCert 喺發現後24小時內撤銷已識別憑證,並將撤銷日期設為憑證簽發日期 [5]。同一報道亦指,受影響時間窗內嘅待處理訂單已被預防性取消 [
5]。ThreatNoir 亦有相近描述:受影響憑證喺發現後24小時內被撤銷,相關時間窗嘅待處理訂單亦被取消 [
1]。
撤銷可以限制後續濫用,但唔代表防守工作即刻完結。保安團隊仍然要用憑證資料、檔案雜湊、行為分析同威脅情報一齊判斷,因為 EV 簽名本身可以被攻擊者當成繞過懷疑嘅工具 [15]。
另一個麻煩:真警報同 Defender 誤報撞埋一齊
事件期間仲有一層混亂:Microsoft Defender 曾經誤將 DigiCert 憑證標記為 Trojan:Win32/Cerdigent.A!dha,BleepingComputer 有相關報道 [5]。daily.dev 亦整理指,Defender 喺4月30日一次簽名更新後,錯誤標記合法 DigiCert Root 憑證;Microsoft 其後透過 Security Intelligence Update 1.449.430.0 修正,並恢復被移除嘅憑證 [
7]。
對企業 IT 同保安團隊而言,呢種情況好棘手:一邊要處理真實嘅憑證濫用風險,一邊要分辨簽咗名嘅惡意軟件警報,仲要排除針對合法憑證嘅誤報 [5][
7]。
防守團隊應該學到啲乜
今次事件唔係話 Code Signing 無價值。相反,Code Signing 仍然係重要信任訊號;問題係,佢唔應該係唯一答案。
實務上可以咁做:
- 唔好見到簽名就自動放行。 有效簽名,甚至 EV 簽名,都唔等於檔案一定安全;攻擊者可以專登用 EV 憑證簽署惡意檔案,借信任外衣降低懷疑 [
15]。
- 查清楚憑證細節。 簽發者、序號、憑證鏈、時間戳、撤銷狀態都要一齊睇;喺 DigiCert 事件入面,撤銷同將撤銷日期回設至簽發日期,就係重要止血措施 [
5]。
- 將檔案行為放喺核心。 雜湊、程序行為、網絡連線、持久化手法、沙箱結果,應該同簽名狀態一齊評估;因為簽咗名嘅惡意軟件正正係利用防守方對簽名嘅信任 [
15]。
- 支援入口同管理入口要當高風險區處理。 今次事件反映,就算係有限支援功能,只要可以切入客戶帳戶或接觸憑證初始化碼,都可能變成攻擊鏈入面嘅關鍵一環 [
10]。
- 誤報要有受控流程處理。 Defender 相關報道顯示,憑證警報唔一定等於真感染;daily.dev 指合法 DigiCert Root 憑證曾被錯誤偵測,之後由 Microsoft 更新修復 [
7]。
結論
DigiCert 呢次事件嘅核心教訓好直接:數碼簽名係信任訊號,但唔係最終裁決。公開報道顯示,事件集中喺支援系統、初始化碼同被濫用嘅 Code Signing 憑證,唔係 Root 或 CA 密鑰被攻陷 [1][
5][
10][
12]。但只要攻擊者可以令惡意軟件披上有效簽名外衣,防守方就唔可以再用「有簽名=可信」呢條單線規則處理現代惡意軟件。




