eMudhraのCA秘密鍵8件が侵害：何が起き、組織は今何をすべきか

発生したこと

2026年10月17日、Wayneとのみ名乗る研究者が、eMudhraの中間CA証明書8件の秘密鍵を保有していると、ブラウザのルート証明書プログラムに報告しました。その証明として、各鍵を使って「We have a problem here - Wayne」というメッセージに署名しました。Chrome Root Programは18:05（UTC）に報告を受け、19:45（UTC）までに6件のTLS中間CAをブロックしました。Mozillaは20:06（UTC）に報告を受け、22:59（UTC）までに8件すべてをFirefoxでブロックしました。eMudhraは10月18日に8件の証明書を失効させ、Appleは10月19日、Microsoftは10月20日にブロックしました。

Mozillaは10月20日、影響を受ける証明書と修正版ソフトウェアの一覧を掲載した情報開示サイトとともに、この侵害をdev-security-policyフォーラムで公表しました。

影響を受ける中間CAは次のとおりです。

• EM DV TLS CA - G3BおよびEM DV TLS CA - G3C
• EM OV TLS CA - G3BおよびEM OV TLS CA - G3C
• EM EV TLS CA - G3BおよびEM EV TLS CA - G3C
• EM OV CS CA - G3BおよびEM OV CS CA - G3C（コード署名）

各中間CAには、同じ鍵を使用し、Sectigoが長年運用するAAA Certificate Servicesルートによってクロス署名された証明書も存在します。そのため、トラストストアからeMudhra独自のルート証明書を削除するだけでは不十分です。Sectigoのルート証明書を引き続き信頼するシステムでは、クロス署名版の証明書を有効と判定できます。

Mozillaのバグトラッカーに掲載された暫定報告で、eMudhraは、2025年4月30日のキーセレモニーで使用したスクリプトの不具合と人的ミスが重なり、脆弱な鍵が生成されたと説明しています。テスト工程で生成された2組目の脆弱な鍵が、誤って証明書の申請に使われたとのことです。eMudhraは、これらの中間CAから証明書が発行されたことはなく、コード署名CAも本番環境には投入されなかったとしています。MozillaとChromeは現在、eMudhraの「emSign ECC Root CA - G3」をルートストアから削除しています。

ブラウザだけの問題ではない理由

ブラウザは失効情報を直接受け取るため、迅速に対処できました。しかし、TLSに依存するソフトウェアの多くは、同じ仕組みを備えていません。コマンドラインツール、スクリプト、コンテナ、組み込みデバイス、Go、Python、Node.js、Rust、Electronで構築されたアプリケーションは、内包するルート証明書リストまたはOSのルート証明書リストに基づいて証明書を検証する一方、失効を確認しないことがあります。こうしたシステムはアップデートされるまで、侵害された鍵から発行された証明書を信頼し続けます。アップデートが長期間行われないものも少なくありません。

偽造TLS証明書を悪用するには、被害者が利用するネットワークの制御、侵害されたルータ、不正なWi-Fiアクセスポイント、インターネットサービスプロバイダーや政府機関のレベルでのアクセスなど、中間者攻撃が可能な位置を確保する必要があります。悪用できる攻撃者は限られますが、そのような能力を持つ集団こそ、多くの組織が警戒している相手です。VPNクライアント、アップデートエージェント、API、マシン間通信のトラフィックはブラウザを経由しないため、特に大きなリスクにさらされます。

コード署名のリスク

2件のコード署名鍵には、別途注意が必要です。いずれかの鍵から発行されたコード署名証明書があれば、攻撃者は通信を傍受することなく、信頼されるルート証明書につながる署名をマルウェアに付与できます。OS、アプリケーションの許可リスト、セキュリティツールは、検証済みの発行元が提供するソフトウェアをより信頼します。攻撃者が署名を求めるのは、まさにこのためです。

TrendAI™が長年にわたって脅威研究を続ける間、攻撃者は一貫してこの信頼を狙ってきました。Forward-Looking Threat Researchチームが2018年に300万件のソフトウェアダウンロードを分析したところ、正規ソフトウェアと悪意のあるソフトウェアの双方で同じ証明書発行者が確認され、証明書は盗まれるか、アンダーグラウンド市場で転売されていました。2022年6月から7月にかけて、QAKBOTの運用者は少なくとも7件の正規コード署名証明書を次々と使い分けました。同年には、Purple Foxキャンペーンで使用されたカーネルドライバと、盗まれた3件のコード署名証明書との関連も確認しています。2023年には、BlackCatランサムウェアのアフィリエイトが、セキュリティエージェントを停止させるカーネルドライバに、盗難または漏洩したクロス署名証明書を使って署名していました。同年夏には、本人確認が最も厳格な種類のコード署名証明書であるExtended Validation（EV）署名が付いたRedLineおよびVidarのインフォスティーラーが、30件を超える検体で確認されました。2025年のEvilAIキャンペーンでは、偽のAIツールや生産性向上ツールが、2024年または2025年に登記された企業を通じて署名されていました。古い証明書が失効するたびに新たな証明書を取得するため、使い捨ての企業を設立していたとみられるパターンです。

これらの事例で問題となった証明書は、いずれも一度に1件でした。eMudhraの侵害は、それより上位の信頼階層に及びます。これらの鍵を保有する者は、任意の企業名を使って、望むだけ多くのコード署名証明書を発行できました。しかも鍵は、公開証明書から復元できるほど脆弱でした。

証明書を失効させても、リスクを完全には解消できない可能性があります。証明書失効リストには、コード署名中間CAの失効日として2026年10月18日と19日が記録されていますが、脆弱な鍵は2025年4月から存在しています。TrendAI™が2023年に実施したRedLineの調査から、この日付が重要な理由が分かります。問題が報告された日を失効日とした場合、それ以前のタイムスタンプが付いた署名は、引き続き有効と判定される可能性があります。この事例では、TrendAI™からの要請を受け、CAが失効日を過去にさかのぼって設定しました。

eMudhraによると、コード署名中間CAが本番運用されたことはないため、その配下で署名された正規ソフトウェアはほとんど、またはまったく存在しないはずです。したがって、これらの中間CAにつながるバイナリが見つかった場合は、調査する必要があります。

「この攻撃は、企業に長期的かつ構造的な影響を及ぼします。影響を受けるすべての企業は、直ちに脅威ハンティングを実施しなければなりません。今回の事案は、PKIセキュリティを強化し、エージェント型セキュリティを多層的に実装する必要性を浮き彫りにしています」
Tom Kellermann, VP of AI Security & Threat Research, TrendAI™

組織が今すぐ取るべき対応

1. デスクトップに限らず、あらゆる環境のトラストストアを更新する。 まずOSとブラウザにパッチを適用し、次にLinuxサーバおよびコンテナのベースイメージに含まれるca-certificatesパッケージ、言語ランタイムとライブラリ、独自のルート証明書を内包するアプリケーションを更新します。現時点で修正版が提供されているのは、Go 1.27.3および1.26.10（CVE-2026-111943）、Nodejs 22.23.4および22.23.1、Python certifi 2026.10.19、NSS 3.131.1、Rust webpki-roots 1.0.10、Electron 44.9.1、43.8.1、42.11.16、curl CA bundle、Ubuntu、Debian、Arch、Gentoo、Alpine、Chainguard、Homebrew向けのca-certificatesパッケージです。執筆時点では、BunとFreeBSDの修正はまだ提供されていません。Mac OSでは、curl -get Python3 OpenSSLのビルドが、OS本体とは別の/etc/ssl/cert.pemを使って証明書を検証します。OS自体は対象の中間CAをブロックしていますが、このファイルはまだ更新されていません。情報開示サイトでは、修正版の最新一覧とLinuxおよびMacOS向けの回避策を公開しています。
2. 古いルート証明書を使ってビルドしたものを再ビルドする。 Goは各プログラムにトラスト処理を組み込んでコンパイルするため、Goアプリケーションは修正版で再コンパイルする必要があります。コンテナイメージには、ビルド時点のトラストストアが保持されています。更新済みのベースイメージから再ビルドし、再展開してください。どちらの場合も、ホストを更新するだけでは不十分です。Electronアプリなど、独自のルート証明書を内包するサードパーティ製アプリケーションについては、ベンダーによる修正が必要です。
3. 侵害された鍵をまだ信頼するシステムをテストする。 情報開示サイトでは、6件のTLS中間CAから発行された証明書を配信する12台のテストホストを、eMudhraとSectigoの両方の証明書チェーンで運用しています。確認対象の各サーバ、コンテナ、デバイスから両方のチェーンをテストしてください。たとえば、curl https://dv-g3b-emudhra.we-have-a-problem.com/とcurl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/を実行します。望ましい結果は証明書エラーです。一方のテストだけが成功し、もう一方が失敗する場合、修正は半分しか適用されていません。直接テストできないシステム向けに、同サイトではオフライン確認用の証明書チェーンも公開しています。
4. TLSインスペクションゲートウェイで対象の中間CAを信頼しないよう設定する。 トラフィックを復号するゲートウェイは、ユーザに代わってWebサイトの証明書を検証し、ゲートウェイ自身が署名した証明書をブラウザに提示します。ゲートウェイが対象の中間CAを信頼したままだと、偽造証明書も信頼済みとしてユーザに渡され、ブラウザ側の保護は機能しません。各デバイスへのパッチ適用を進めている間も、ゲートウェイを修正すれば、その配下にいるすべてのユーザを保護できます。情報開示サイトのimpacted-intermediates.jsonに記載された16件の証明書（8件の中間CAそれぞれについて、eMudhra版とSectigo版の両方）をインポートし、明示的に「Untrusted」に設定します。8件だけを信頼対象から外しても、Sectigo経由のパスが残ります。次に、検証に失敗した証明書に対するゲートウェイの動作を「Warn」ではなく「Block」に設定してください。無効な証明書をブロックする一般設定だけでは不十分です。ゲートウェイが対象の中間CAを信頼しないよう設定するまで、これらの鍵から発行された証明書は検証を通過するためです。最後に、ゲートウェイ経由でテストホストへ接続し、結果をゲートウェイ自身のログで確認します。いずれの場合もユーザにはゲートウェイの証明書が表示されるため、ブラウザだけでは修正の成否を確認できません。
5. 侵害された場合の被害が最も大きいシステムから、不正利用を調査する。 すべてのシステムを一度に調査できる組織はほとんどありませんが、その必要もありません。インターネット公開資産を含む最新の資産・IDインベントリを起点に、偽造証明書や署名付きの悪意あるバイナリによって壊滅的な被害が生じるシステムを優先します。IDと権限に関しては、Active DirectoryとMicrosoft Entra IDのドメインコントローラ、特権アクセス管理（PAM）の踏み台ホスト、管理者権限を持つクラウドIAMロールが該当します。最重要データに関しては、個人情報や医療情報を保持する本番データベース、金融処理パイプライン、中核的なソースコードリポジトリ、CI/CDビルドランナーが対象です。インフラストラクチャの基盤としては、DNSインフラストラクチャ、ハイパーバイザ、Kubernetesコントロールプレーン、鍵管理システムが該当します。これらのグループでは、パッチ未適用のトラストストア、古いランタイム、組み込みデバイス、更新済みのブラウザやゲートウェイを経由せずにネットワーク外へ出るトラフィックなど、侵害された中間CAを引き続き信頼するシステムから確認します。TLSインスペクション、プロキシ、ネットワークセンサのログを検索し、8件の中間CAのいずれかを含む証明書チェーンを探してください。TLS 1.3では証明書自体が暗号化されるため、パッシブセンサで証明書を確認できるのは、TLS 1.2接続または復号されたトラフィックに限られます。エンドポイントとファイルインベントリを検索し、いずれかのルート証明書を経由してEM OV CS CA - G3BまたはG3Cにつながるバイナリがないか確認します。有効な署名は、ファイルの安全性を証明するものではなく、複数の判断材料の一つとして扱ってください。公開鍵ハッシュで照合すれば、各中間CAの2種類の証明書をともに検出できます。ハッシュ値は付録に記載しています。自社ドメイン向けに予期しない証明書が発行されていないか、証明書透明性ログも確認してください。ただし、偽造証明書を使う攻撃者がその証明書をログへ登録する理由はない点に注意が必要です。
6. デフォルトで信頼する対象を見直す。 管理対象システムが、Webサイト用途でSectigoのAAA Certificate Servicesルートを引き続き信頼していないか確認してください。ChromeとFirefoxは2025年4月にこの用途での信頼を終了しましたが、ほかのトラストストアでは現在も信頼されている場合があります。

TrendAI™による支援

多くの組織が行うべき作業は、前述の推奨事項と同じ順序になります。まず露出している対象を特定し、そこで脅威を調査して、セキュリティ上の穴をふさぎます。TrendAI Vision One™は、各段階を支援します。

調査対象を決める： TrendAI Vision One™ Cyber Risk Exposure Management（CREM）は、組織のデバイス、アカウント、アプリケーション、クラウド資産、インターネット公開資産を含むアタックサーフェスを可視化します。各資産に重要度を割り当てるほか、ドメインコントローラ、鍵管理システム、ビルドサーバなど、特に重要であることが分かっているシステムについて、セキュリティチームが重要度を引き上げることもできます。これにより、ID、データ、インフラストラクチャの各システムを順位付けし、優先度の高いものから調査できます。

重要な場所を調査する： TrendAI Vision One™ Agentic SIEM & XDRのXDR Data Explorerでは、この調査の両面に必要なフィールドをクエリできます。Network Sensor、Virtual Network Sensor、Deep Discovery Inspectorは、確認可能なTLSトラフィックについて証明書発行者名とフィンガープリントを記録します。これにより、アナリストは6件のTLS中間CAのいずれかから発行された証明書を検索できます。Endpoint Sensorは各プロセスとファイルの署名者を記録するため、EM OV CS CA - G3BまたはG3Cの配下で署名されたバイナリを検索できます。Internet Accessは、信頼されていないサーバ証明書を理由にブロックした接続を独立したイベント種別として記録します。このため、中間CAを「Untrusted」に設定した後、ゲートウェイまで到達した試行を確認できます。

ネットワーク上で検知する： Deep Discovery InspectorのルールFAR584は、SHA-1ハッシュに基づいて侵害された証明書を検知します。Deep Discovery Inspectorの内蔵CAストアには、MozillaとChromeが現在削除を進めているeMudhraのルート証明書「emSign ECC Root CA-G3」が含まれています。このCAストアを更新する緊急パッチは、10月22日のリリースに向けて準備されています。

ゲートウェイでセキュリティ上の穴をふさぐ： TrendAI Vision One™ Internet AccessでTLSインスペクションを使用している組織は、ルートCAおよび中間CA証明書の設定から16件すべての証明書をアップロードして「Untrusted」に設定し、証明書の検証に失敗した場合の動作を、デフォルトの「Warn」から「Block」に変更できます。SSLインスペクションを使用するTipping Point Threat Protection System（TPS）のお客さまは、ファームウェアアップデートによって対象のデフォルトCAが内蔵ストアとインストール可能なCAバンドルから削除されるまで、CLIを使ってそのCAを信頼しないよう設定してください。それまでは偽造証明書も検証を通過するため、有効なサーバ証明書をブロックするオプションは作動しません。また、インスペクション対象外のドメイン用に偽造された証明書は検査されません。TLS経由でリモートsyslogサーバへログを送信しているお客さまは、対象CAのいずれかを使ってサーバが検証されていないことを確認し、デフォルトのCAリストに基づく受信保護対象サーバの証明書チェーン検証を無効のままにしてください。

専門チームに任せる： 自組織で対応する余力がない場合は、TrendAI Vision One™ Services – Managed Detection and Response（MDR）を利用できます。TrendAI™のアナリストが、同じVision Oneのテレメトリを横断して24時間365日の検知、調査、対応を行います。攻撃対象になった可能性を確認したい組織はTrendAI™の侵害評価を依頼できます。すでに侵害された可能性がある場合は、TrendAI™のインシデントレスポンス部門にご連絡ください。

付録：脅威ハンティング用の識別子

各中間CAには、同じ公開鍵を持つ証明書が2件ずつ存在します。一方はeMudhraのemSignルート配下、もう一方はSectigoのAAA Certificate Servicesルート配下です。公開鍵ハッシュで照合すれば、両方を検出できます。各値は、2026年10月20日に取得した情報開示サイトのimpacted-intermediates.jsonファイルに基づいています。

参考記事：

Eight Compromised eMudhra CA Keys: What Happened and What Organizations Should Do Now

By: TrendAI™ Research

翻訳：与那城 務（Platform Marketing, TrendAI™ Research）