事件點樣發生：由假截圖到支援入口

Help Net Security 將今次攻擊描述為針對 DigiCert 支援渠道嘅社交工程：攻擊者扮成客戶，送出一個似係截圖嘅 ZIP 檔，但實際內藏惡意 .scr 檔案 。

SecurityWeek 引述資料指，惡意程式感染咗兩個端點；其中一個喺4月3日被發現，另一個喺4月14日先被發現 。攻擊者其後由被攻陷系統轉入內部支援入口；該入口有一項有限功能，容許已驗證嘅 DigiCert 支援分析員切換到客戶帳戶視角，並接觸到部分功能，包括待處理憑證嘅初始化碼 。

BleepingComputer 對範圍嘅描述同樣偏向有限：受影響嘅係已批准、但尚未交付嘅 EV Code Signing 憑證初始化碼 。

點解 EV Code Signing 憑證咁吸引攻擊者

Code Signing 憑證可以理解為軟件發行入面嘅「身分證加防拆封標籤」：佢幫使用者、作業系統同保安產品判斷軟件來源同完整性。DigiCert 作為主要憑證簽發機構，喺互聯網通訊同軟件分發信任鏈入面有重要角色；其 Code Signing 憑證亦被軟件開發者使用 。

問題在於，攻擊者唔需要完全打爆整間憑證機構，都可以濫用呢種信任訊號。ThreatNoir 指，部分取得嘅 Code Signing 憑證被用嚟簽署惡意軟件 。CyberInsider 亦形容事件涉及被攻陷嘅內部支援系統同憑證簽發資料，攻擊者藉此取得有效 EV Code Signing 憑證，部分其後用於簽署惡意軟件 。

簽咗名嘅惡意軟件，第一眼可以顯得更似合法程式。Vectra 對同類手法嘅分析指出，攻擊者可以用 EV 憑證簽署惡意檔案，利用外界對 EV 簽署應用程式較高嘅信任；如果機構只靠簽名判斷可信與否，就會有缺口 。

要講清楚：目前唔係 Root 或 CA 密鑰失守

公開資料需要分清楚。現有來源講到嘅係：支援端點被攻陷、內部支援功能被濫用，以及初始化碼被接觸或取得 。呢啲資料並無顯示 DigiCert Root 密鑰或 CA 簽發密鑰被攻陷。

換句話講，事件唔可以輕描淡寫，但亦唔應該被講成整間憑證機構完全被接管。按目前報道，核心係 Code Signing 憑證支援與簽發流程被濫用，而唔係 Root/CA 層級嘅全面失守 。

影響有幾大？數字要分清楚

目前公開數字唔完全一致，主要因為唔同來源講緊唔同類別：

• ThreatNoir 指，攻擊者取得有限數量 Code Signing 憑證嘅初始化碼，其中部分被用嚟簽署惡意軟件 。
• Risky Business 報道指，有27張 Code Signing 憑證被盜，之後用於簽署惡意軟件 。
• ThreatLocker 則稱總共有60張 Code Signing 憑證被撤銷 。

所以，讀呢啲數字時要問清楚：係「取得」、「實際濫用」，定係「最終撤銷」？即使事件範圍被形容為有限，只要有少量看似有效嘅 Code Signing 憑證落入攻擊者手上，已經足夠用嚟提升惡意軟件嘅可信外觀 。

DigiCert 點樣止血：撤銷同取消待處理訂單

BleepingComputer 報道指，DigiCert 喺發現後24小時內撤銷已識別憑證，並將撤銷日期設為憑證簽發日期 。同一報道亦指，受影響時間窗內嘅待處理訂單已被預防性取消 。ThreatNoir 亦有相近描述：受影響憑證喺發現後24小時內被撤銷，相關時間窗嘅待處理訂單亦被取消 。

撤銷可以限制後續濫用，但唔代表防守工作即刻完結。保安團隊仍然要用憑證資料、檔案雜湊、行為分析同威脅情報一齊判斷，因為 EV 簽名本身可以被攻擊者當成繞過懷疑嘅工具 。

另一個麻煩：真警報同 Defender 誤報撞埋一齊

事件期間仲有一層混亂：Microsoft Defender 曾經誤將 DigiCert 憑證標記為 Trojan:Win32/Cerdigent.A!dha，BleepingComputer 有相關報道 。daily.dev 亦整理指，Defender 喺4月30日一次簽名更新後，錯誤標記合法 DigiCert Root 憑證；Microsoft 其後透過 Security Intelligence Update 1.449.430.0 修正，並恢復被移除嘅憑證 。

對企業 IT 同保安團隊而言，呢種情況好棘手：一邊要處理真實嘅憑證濫用風險，一邊要分辨簽咗名嘅惡意軟件警報，仲要排除針對合法憑證嘅誤報 。

防守團隊應該學到啲乜

今次事件唔係話 Code Signing 無價值。相反，Code Signing 仍然係重要信任訊號；問題係，佢唔應該係唯一答案。

實務上可以咁做：

• 唔好見到簽名就自動放行。 有效簽名，甚至 EV 簽名，都唔等於檔案一定安全；攻擊者可以專登用 EV 憑證簽署惡意檔案，借信任外衣降低懷疑 。
• 查清楚憑證細節。 簽發者、序號、憑證鏈、時間戳、撤銷狀態都要一齊睇；喺 DigiCert 事件入面，撤銷同將撤銷日期回設至簽發日期，就係重要止血措施 。
• 將檔案行為放喺核心。 雜湊、程序行為、網絡連線、持久化手法、沙箱結果，應該同簽名狀態一齊評估；因為簽咗名嘅惡意軟件正正係利用防守方對簽名嘅信任 。
• 支援入口同管理入口要當高風險區處理。 今次事件反映，就算係有限支援功能，只要可以切入客戶帳戶或接觸憑證初始化碼，都可能變成攻擊鏈入面嘅關鍵一環 。
• 誤報要有受控流程處理。 Defender 相關報道顯示，憑證警報唔一定等於真感染；daily.dev 指合法 DigiCert Root 憑證曾被錯誤偵測，之後由 Microsoft 更新修復 。

結論

DigiCert 呢次事件嘅核心教訓好直接：數碼簽名係信任訊號，但唔係最終裁決。公開報道顯示，事件集中喺支援系統、初始化碼同被濫用嘅 Code Signing 憑證，唔係 Root 或 CA 密鑰被攻陷 。但只要攻擊者可以令惡意軟件披上有效簽名外衣，防守方就唔可以再用「有簽名＝可信」呢條單線規則處理現代惡意軟件。

事件點樣發生：由假截圖到支援入口

Help Net Security 將今次攻擊描述為針對 DigiCert 支援渠道嘅社交工程：攻擊者扮成客戶，送出一個似係截圖嘅 ZIP 檔，但實際內藏惡意 .scr 檔案 。

SecurityWeek 引述資料指，惡意程式感染咗兩個端點；其中一個喺4月3日被發現，另一個喺4月14日先被發現 。攻擊者其後由被攻陷系統轉入內部支援入口；該入口有一項有限功能，容許已驗證嘅 DigiCert 支援分析員切換到客戶帳戶視角，並接觸到部分功能，包括待處理憑證嘅初始化碼 。

BleepingComputer 對範圍嘅描述同樣偏向有限：受影響嘅係已批准、但尚未交付嘅 EV Code Signing 憑證初始化碼 。

點解 EV Code Signing 憑證咁吸引攻擊者

Code Signing 憑證可以理解為軟件發行入面嘅「身分證加防拆封標籤」：佢幫使用者、作業系統同保安產品判斷軟件來源同完整性。DigiCert 作為主要憑證簽發機構，喺互聯網通訊同軟件分發信任鏈入面有重要角色；其 Code Signing 憑證亦被軟件開發者使用 。

問題在於，攻擊者唔需要完全打爆整間憑證機構，都可以濫用呢種信任訊號。ThreatNoir 指，部分取得嘅 Code Signing 憑證被用嚟簽署惡意軟件 。CyberInsider 亦形容事件涉及被攻陷嘅內部支援系統同憑證簽發資料，攻擊者藉此取得有效 EV Code Signing 憑證，部分其後用於簽署惡意軟件 。

簽咗名嘅惡意軟件，第一眼可以顯得更似合法程式。Vectra 對同類手法嘅分析指出，攻擊者可以用 EV 憑證簽署惡意檔案，利用外界對 EV 簽署應用程式較高嘅信任；如果機構只靠簽名判斷可信與否，就會有缺口 。

要講清楚：目前唔係 Root 或 CA 密鑰失守

公開資料需要分清楚。現有來源講到嘅係：支援端點被攻陷、內部支援功能被濫用，以及初始化碼被接觸或取得 。呢啲資料並無顯示 DigiCert Root 密鑰或 CA 簽發密鑰被攻陷。

換句話講，事件唔可以輕描淡寫，但亦唔應該被講成整間憑證機構完全被接管。按目前報道，核心係 Code Signing 憑證支援與簽發流程被濫用，而唔係 Root/CA 層級嘅全面失守 。

影響有幾大？數字要分清楚

目前公開數字唔完全一致，主要因為唔同來源講緊唔同類別：

• ThreatNoir 指，攻擊者取得有限數量 Code Signing 憑證嘅初始化碼，其中部分被用嚟簽署惡意軟件 。
• Risky Business 報道指，有27張 Code Signing 憑證被盜，之後用於簽署惡意軟件 。
• ThreatLocker 則稱總共有60張 Code Signing 憑證被撤銷 。

所以，讀呢啲數字時要問清楚：係「取得」、「實際濫用」，定係「最終撤銷」？即使事件範圍被形容為有限，只要有少量看似有效嘅 Code Signing 憑證落入攻擊者手上，已經足夠用嚟提升惡意軟件嘅可信外觀 。

DigiCert 點樣止血：撤銷同取消待處理訂單

BleepingComputer 報道指，DigiCert 喺發現後24小時內撤銷已識別憑證，並將撤銷日期設為憑證簽發日期 。同一報道亦指，受影響時間窗內嘅待處理訂單已被預防性取消 。ThreatNoir 亦有相近描述：受影響憑證喺發現後24小時內被撤銷，相關時間窗嘅待處理訂單亦被取消 。

撤銷可以限制後續濫用，但唔代表防守工作即刻完結。保安團隊仍然要用憑證資料、檔案雜湊、行為分析同威脅情報一齊判斷，因為 EV 簽名本身可以被攻擊者當成繞過懷疑嘅工具 。

另一個麻煩：真警報同 Defender 誤報撞埋一齊

事件期間仲有一層混亂：Microsoft Defender 曾經誤將 DigiCert 憑證標記為 Trojan:Win32/Cerdigent.A!dha，BleepingComputer 有相關報道 。daily.dev 亦整理指，Defender 喺4月30日一次簽名更新後，錯誤標記合法 DigiCert Root 憑證；Microsoft 其後透過 Security Intelligence Update 1.449.430.0 修正，並恢復被移除嘅憑證 。

對企業 IT 同保安團隊而言，呢種情況好棘手：一邊要處理真實嘅憑證濫用風險，一邊要分辨簽咗名嘅惡意軟件警報，仲要排除針對合法憑證嘅誤報 。

防守團隊應該學到啲乜

今次事件唔係話 Code Signing 無價值。相反，Code Signing 仍然係重要信任訊號；問題係，佢唔應該係唯一答案。

實務上可以咁做：

• 唔好見到簽名就自動放行。 有效簽名，甚至 EV 簽名，都唔等於檔案一定安全；攻擊者可以專登用 EV 憑證簽署惡意檔案，借信任外衣降低懷疑 。
• 查清楚憑證細節。 簽發者、序號、憑證鏈、時間戳、撤銷狀態都要一齊睇；喺 DigiCert 事件入面，撤銷同將撤銷日期回設至簽發日期，就係重要止血措施 。
• 將檔案行為放喺核心。 雜湊、程序行為、網絡連線、持久化手法、沙箱結果，應該同簽名狀態一齊評估；因為簽咗名嘅惡意軟件正正係利用防守方對簽名嘅信任 。
• 支援入口同管理入口要當高風險區處理。 今次事件反映，就算係有限支援功能，只要可以切入客戶帳戶或接觸憑證初始化碼，都可能變成攻擊鏈入面嘅關鍵一環 。
• 誤報要有受控流程處理。 Defender 相關報道顯示，憑證警報唔一定等於真感染；daily.dev 指合法 DigiCert Root 憑證曾被錯誤偵測，之後由 Microsoft 更新修復 。

結論

DigiCert 呢次事件嘅核心教訓好直接：數碼簽名係信任訊號，但唔係最終裁決。公開報道顯示，事件集中喺支援系統、初始化碼同被濫用嘅 Code Signing 憑證，唔係 Root 或 CA 密鑰被攻陷 。但只要攻擊者可以令惡意軟件披上有效簽名外衣，防守方就唔可以再用「有簽名＝可信」呢條單線規則處理現代惡意軟件。