一見すると、よくあるサポート対応の一場面だった。顧客がチャットでスクリーンショットを送ってきたように見えたからだ。ところが、そのZIPファイルはDigiCertの中でも特に重要な信頼の層、つまりコード署名を揺さぶる入口になった。

MozillaのBugzillaに記録されたインシデント説明によると、攻撃者は2026年4月2日、顧客チャット経由でDigiCertのサポートチームに接触し、顧客のスクリーンショットを装ったZIPファイルを送付した。中には、Windowsのスクリーンセーバー形式として使われる.scr実行ファイルが含まれ、悪意あるペイロードを備えていた ^[12]。その後、侵害されたサポート関連システムを足がかりに、限られた数のコード署名証明書の初期化コードが取得され、その一部はマルウェアの署名に使われた ^[1]。

何が起きたのか

攻撃の起点は、DigiCertのサポートチャネルを狙ったソーシャルエンジニアリングだった。Help Net Securityも、顧客のスクリーンショットに見せかけたZIPファイルの中に、悪意あるWindowsスクリーンセーバー形式の.scrファイルが入っていたと説明している ^[2]。

SecurityWeekによれば、マルウェアは2台のエンドポイントに感染し、1台は4月3日に、もう1台は4月14日に検出された ^[10]。攻撃者は侵害した端末から内部サポートポータルへ移動したとされる ^[10]。このポータルでは、認証済みのサポート担当者が顧客アカウントに代理アクセスできる限定機能があり、その機能を通じて、保留中の証明書に関する初期化コードなど一部の機能へアクセスできたとSecurityWeekは報じている ^[10]。

BleepingComputerも影響範囲は限定的だったとしつつ、すでに承認済みで、まだ引き渡されていなかったEVコード署名証明書の初期化コードが露出したと具体的に説明している ^[5]。

なぜEVコード署名証明書が狙われるのか

コード署名証明書は、ソフトウェアの配布における信頼の仕組みの一部だ。利用者やOS、セキュリティ製品が、ファイルの発行元や改ざんの有無を判断する材料になる。DigiCertは、ブラウザやOSから信頼される主要な認証局、つまりCAの一つであり、同社のコード署名証明書はソフトウェア開発者に広く使われている ^[11]。

EVはExtended Validationの略で、通常より厳格な実在確認を伴う区分を指す。だからこそ攻撃者にとっては価値がある。問題は、サポートシステムへの侵入そのものだけではない。EVコード署名が持つ「信頼されやすさ」を、攻撃者が逆手に取った点にある。

ThreatNoirは、取得されたコード署名証明書の一部がマルウェアの署名に使われたと報じている ^[1]。CyberInsiderも、内部サポートシステムと証明書発行データが悪用され、有効なEVコード署名証明書の取得につながり、その一部が後にマルウェア署名に使われたと説明している ^[11]。

これは防御側にとって厄介だ。署名付きファイルは、見た目には正規ソフトウェアらしく振る舞える。Vectraは一般論として、攻撃者がEV証明書で悪意あるファイルに署名し、EV署名アプリケーションへの高い信頼を悪用する可能性を指摘している。署名ベースの信頼だけに依存する組織は、そのぶん脆弱になり得る ^[15]。

ただし、CA全体が乗っ取られた話ではない

ここは切り分けが重要だ。現時点で示されている資料が説明しているのは、サポート端末の侵害、内部サポート機能の悪用、証明書の初期化コードへのアクセスである ^{[1][5][10][12]}。DigiCertのルートキーやCA鍵が侵害されたとする根拠は、これらの報告からは確認できない。

もちろん、それで事案が軽くなるわけではない。だが、既知の情報に基づけば、この攻撃は認証局そのものの完全な乗っ取りではなく、コード署名証明書のサポート・発行プロセスを悪用した限定的な侵害として理解するのが適切だ ^[1][5][10]。

影響規模はどう見るべきか

公開情報の数字は、完全にはそろっていない。理由は、各報道が数えている対象が異なるためだ。

• ThreatNoirは、限られた数のコード署名証明書について初期化コードが取得され、その一部がマルウェア署名に使われたと説明している ^[1]。
• Risky Businessは、27件のコード署名証明書が盗まれ、後にマルウェア署名に使われたと報じている ^[8]。
• ThreatLockerは、合計60件のコード署名証明書が失効されたと伝えている ^[3]。

このため、単に数字だけを横並びにするのは危うい。入手された証明書なのか、実際に悪用された証明書なのか、あるいは予防的に失効された証明書なのかを分けて読む必要がある。報道上の範囲は限定的だが、数が少なくても影響は小さいとは限らない。正規に見えるコード署名証明書が数件あるだけでも、攻撃者はマルウェアを信頼されやすく見せることができるからだ ^[1][15]。

封じ込め：失効と保留注文の取り消し

BleepingComputerによれば、DigiCertは特定された証明書を発見から24時間以内に失効し、失効日を発行日に設定した ^[5]。また、影響が疑われる期間の保留中注文は予防措置としてキャンセルされた ^[5]。ThreatNoirも、影響を受けた証明書が24時間以内に失効され、該当期間の未処理注文が取り消されたと報じている ^[1]。

失効は、さらなる悪用を抑えるための重要な措置だ。ただし、防御側の仕事はそこで終わらない。セキュリティチームは、署名の有無だけでなく、証明書情報、ファイルハッシュ、挙動、脅威インテリジェンス上の文脈を合わせて評価する必要がある。EV署名そのものが、攻撃者にとって信頼を装う道具になり得るためだ ^[15]。

Defenderの誤検知が現場をさらに混乱させた

この事案の周辺では、Microsoft Defenderによる誤検知も混乱を招いた。BleepingComputerは、Microsoft DefenderがDigiCertの証明書をTrojan:Win32/Cerdigent.A!dhaとして誤って検出したと報じている ^[5]。

daily.devのまとめによると、Defenderは4月30日のシグネチャ更新後、正規のDigiCertルート証明書を誤って検出し、一部のシステムではWindowsの信頼ストアから証明書が削除された。その後Microsoftは、Security Intelligence update 1.449.430.0で修正し、削除された証明書も復元したとされる ^[7]。

企業のインシデント対応では、これは現実的な悩みになる。実際の証明書悪用、署名付きマルウェアへの警告、そして正規証明書への誤検知を、同じタイミングで切り分けなければならないからだ ^[5][7]。

セキュリティチームが学ぶべきこと

今回の教訓は、コード署名が無意味だという話ではない。むしろ逆で、コード署名は重要だからこそ、攻撃者にも狙われる。大切なのは、署名を最終判断ではなく、複数ある判断材料の一つとして扱うことだ。

• 署名済み＝安全、と短絡しない。 有効な署名やEV署名があっても、それだけでファイルを信頼すべきではない。攻撃者はEV証明書を使って悪意あるファイルに署名し、信頼を悪用できる ^[15]。
• 証明書の詳細を見る。 発行者、シリアル番号、証明書チェーン、タイムスタンプ、失効状態は、署名付きバイナリを調査するうえで重要だ。今回のDigiCert事案では、失効と失効日の発行日への設定が主要な封じ込め策だった ^[5]。
• ファイルの挙動を重く見る。 ハッシュ、プロセスの動き、ネットワーク接続、永続化の仕組み、サンドボックス結果を署名情報と合わせて判断する必要がある。署名付きマルウェアは、まさにその信頼を利用するために署名される ^[15]。
• サポートポータルや管理ポータルを高リスク領域として扱う。 顧客アカウントへの代理アクセスや証明書の初期化コードに触れられる限定機能でも、侵害されれば重大な影響を持ち得る ^[10]。
• 誤検知にも手順で対応する。 Defenderの事例は、証明書関連のアラートが必ずしも感染を意味しないことを示した。daily.devによれば、正規のDigiCertルート証明書が誤検出され、Microsoftの更新で復元された ^[7]。

結論

DigiCertの事案が重いのは、攻撃者がEVコード署名証明書の信頼効果を、防御側に対して利用できたからだ。公開されている報告は、サポートシステム、初期化コード、悪用された証明書をめぐる限定的な侵害を示しており、ルートキーやCA鍵の侵害を示すものではない ^{[1][5][10][12]}。

それでも結論ははっきりしている。現代のマルウェア防御において、デジタル署名は重要な証拠の一つであって、最後の答えではない。