Microsoft Defenderが、世界中で広く信頼されているDigiCertのルート証明書を「Trojan:Win32/Cerdigent.A!dha」として誤検知し、一部のシステムではWindowsの信頼ストアから証明書を削除するという事態が発生した。セキュリティ製品がむしろシステムを壊す側に回るという皮肉な状況は、エンタープライズ環境の管理者にとって決して他人事ではない。
何が起きたか
4月30日に配信されたDefenderのシグネチャ更新以降、以下の2つのDigiCertルート証明書が誤ってマルウェアと判定された。
0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
問題の深刻さは「アラートが出た」だけでは終わらなかった点にある。影響を受けたシステムでは、これらの証明書がWindowsの証明書ストア(HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\)から実際に削除されたのだ。
ルート証明書が消えると、そのCAが発行した証明書を信頼する経路が断ち切られる。TLS通信のエラー、コード署名の検証失敗、アプリケーションの起動拒否など、影響は連鎖的に広がりうる。一部のユーザーは「ウイルスに感染した」と誤解しOSを再インストールしたという報告もあり、混乱の大きさがうかがえる。
MicrosoftはSecurity Intelligence更新バージョン1.449.430.0で修正を適用しており、現時点での最新版は1.449.431.0。修正版では誤検知の解消に加え、削除された証明書の復元も行われると報告されている。
手動での更新確認手順
自動更新を待たずに対処したい場合は以下の手順で強制確認できる。
- 「Windowsセキュリティ」を開く
- 「ウイルスと脅威の防止」→「保護の更新」
- 「更新プログラムの確認」をクリック
エンタープライズ環境ではWSUS/Microsoft Updateのポリシーにより自動適用が遅延している場合もある。管理下のデバイスのシグネチャバージョンを一括確認し、影響範囲を把握することが急務だ。
背景:DigiCertで起きていたセキュリティインシデント
この誤検知騒動と時期を同じくして、DigiCert自身がセキュリティインシデントを公表している。4月初旬、攻撃者がサポート担当者にマルウェア入りZIPファイルを送付するソーシャルエンジニアリングを試み、複数回のブロックの末に1台の端末への侵入に成功。さらに別のシステムも一時的に侵害された。
侵害されたサポート環境では、承認済みのEVコード署名証明書の「初期化コード」へのアクセスが可能だったため、攻撃者は正規の証明書を取得し、マルウェアの署名に悪用した。DigiCertは60件のコード署名証明書を失効させており、うち27件は「Zhong Stealer」と呼ばれるマルウェアキャンペーンに関連するものだった。
今回のDefenderによる誤検知は、このインシデントへの対応としてMicrosoftが追加したシグネチャが、悪用された証明書と正規のルート証明書の指紋を取り違えたことが原因と見られる。
実務への影響——IT管理者が今すぐやるべきこと
1. シグネチャバージョンの確認
管理下の全Windowsデバイスのシグネチャバージョンを確認し、1.449.430.0以降に更新されているかをチェックする。Microsoft Defenderのバージョン情報はPowerShellで Get-MpComputerStatus コマンドから確認できる。
2. 証明書ストアの確認 影響を受けた可能性があるシステムでは、以下のサムプリントを持つ証明書がAuthRootストアに存在するか確認する。修正版適用後でも復元されていない場合は、certlm.mscやPowerShellで手動インポートが必要になりうる。
3. アプリケーション動作確認 TLS証明書の検証やコード署名に依存するアプリケーションの動作を確認する。特にDigiCertのルートCAを信頼チェーンの起点として使っているサービスは影響を受けている可能性がある。
4. WSUSポリシーの一時緩和を検討 今回のケースでは「すぐにシグネチャを当てる」よりも、逆に「修正版の展開を急ぐ」という状況になった。緊急時の展開パスが整備されているかを確認する良い機会でもある。
筆者の見解
セキュリティ製品がルート証明書を誤って削除するという今回の出来事は、「誤検知で済んだ」では片付けられない問題をはらんでいる。証明書の信頼チェーンは、TLS通信からコード署名まで、現代のWindowsエコシステムのあちこちに組み込まれたインフラの基盤だ。そこを守るはずのセキュリティ製品が、一度のシグネチャミスでその基盤を削り取りうるという構造的なリスクが今回はっきりと示された。
MicrosoftのDefenderチームが迅速に修正版を展開し、削除された証明書を復元する動きを取ったことは評価したい。しかし率直に言えば、AuthRootのような信頼ストアを管理するコンポーネントは、誤検知時の処理にもっと慎重さが必要だったはずだ。「削除」という不可逆な操作を伴う場合には、少なくとも管理者への確認プロセスや猶予期間が設けられていてよかった。
Defenderはエンタープライズにとって事実上必須のセキュリティ基盤になっている。それだけにシグネチャの品質管理と、万一の際のロールバック設計には一層の投資が求められる。こういった問題が繰り返されないよう、Microsoftにはシグネチャ更新のリグレッションテストプロセスを強化することを期待したい。
DigiCert側のインシデントも教訓が多い。サポートスタッフへのソーシャルエンジニアリング、エンドポイント保護の「センサーギャップ」、サポートポータルの過剰な権限付与——どれも日本のエンタープライズ環境で同様の問題が起きていないとは言い切れない。Just-In-Timeアクセスの考え方をサポートツールにも適用し、常時アクセス権を持つアカウントを極力排除することが、こうした侵害の被害を抑えることに直結する。
「今動いているから大丈夫」という現状維持バイアスがセキュリティ最大の敵だということを、今回の件は改めて思い知らせてくれた。
出典: この記事は Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha の内容をもとに、筆者の見解を加えて独自に執筆したものです。