Zimbraとバローダ銀行の事例に見る、2つの侵害と1つの根本原因：攻撃対象となるメールの脆弱性

ロシアの国家関与が疑われるハッキンググループと、インドの銀行の従業員1人のメールボックスに侵入した匿名の攻撃者は、特殊な手法を必要としませんでした。必要だったのはメールアカウントだけです。2026年7月下旬、世界の反対側で発生した2つの無関係なインシデントが、同じ不都合な事実を裏付けました。メールは依然として企業への最も簡単な侵入口であり、多くの組織がその扉を開けたままにしています。

7月23日、CISAおよび国際パートナー機関は勧告AA26-204Aを発表し、LAUNDRY BEAR（Void Blizzard、CL-STA-1114、TA488とも呼ばれる）と追跡されるグループが、少なくとも2025年7月以降、Zimbra Collaboration Suite Webメールのクロスサイトスクリプティング脆弱性（CVE-2025-66376）を悪用していることを詳述しました。セキュリティベンダーAttackIQは、この勧告への独自の見解を7月27日に公開しました。同時期、インド国営のBank of Barodaは、データ漏洩について調査中であることを認めており、研究者によれば、これは1人の従業員メールアカウントの侵害が発端だとされています。大陸も攻撃者も規模も異なりますが、仕組みは同じです。

どちらのインシデントもKiteworksが管理する環境には影響していません。Zimbraの被害者はネイティブのZimbra Webメールを使用しており、Bank of Barodaの露出は標準的な企業メールに起因しています。しかし、どちらのケースも、ガバナンスされたセキュアメールやコンテンツアクセスプラットフォームがリスク低減のために設計されたリスクの種類を示しています。すなわち、攻撃者が制御するコンテンツがメールプラットフォーム内で実行され、1つのメールボックスが数か月分のやり取りや認証情報、機密ファイルへの無防備なゲートウェイとなるリスクです。以下では、両ケースの事実と攻撃者の主張を分けて整理し、Kiteworksのセキュアデータ交換アプローチがどこで露出を変え、どこで変えないかを解説します。

主なポイント

1. Zimbra Webメールの単一CVEが12か月にわたるスパイ活動の窓口となった。 CISAの勧告AA26-204Aは、CVE-2025-66376がロシア国家関与の攻撃者と結びついており、少なくとも2025年7月以降、政府や民間の標的からメール、認証情報、MFAトークンを収集してきたとしています。
2. Bank of Barodaの侵害は、1人の従業員メールボックスの侵害に端を発している。 同銀行はコアバンキングシステムへのアクセスはなかったとしていますが、研究者は数百GBに及ぶローン記録、監査レポート、内部コミュニケーションの漏洩データセットが存在すると報告しており、これらの数字は攻撃者発表であり銀行は確認していません。
3. メールは単なるメッセージングツールではなくデータリポジトリであり、攻撃者はそれを理解している。 Zimbraの脆弱性は一度で90日分のメッセージ履歴を抜き取ったとされ、Barodaのメールボックスには保護されずにローン査定や内部監査が保存されていました。
4. すべてのメッセージに対する自動ポリシー適用が、どちらの被害者にもなかったギャップを埋める。 Kiteworks Email Protection Gatewayは、データ内容や分類に基づいて、すべての受信・送信メールに暗号化、ルーティング、隔離、拒否ポリシーを適用し、その結果を記録します。これらの組織がネイティブWebメールではなくKiteworksを経由していれば、これらの機能が適用されていたはずです。
5. ガバナンスされたプラットフォームでもWebメールを無敵にはできず、本稿もその主張はしていない。 どちらのインシデントにもKiteworksは関与しておらず、重要なのは注意点です。EPGはWebメールベンダーの基盤コードを修正できず、その価値は組織がどのようにポリシーや保持ルールを設定するかに依存します。

CISA勧告AA26-204Aの詳細：Zimbraキャンペーン

CISAの勧告は、国際パートナー機関と共同で発行され、防衛産業基盤（Defense Industrial Base (DIB)）、連邦・地方政府、教育、エネルギー、法執行、メディア、NGO、西側諸国のテクノロジー企業など、幅広い分野を標的とした持続的なスパイ活動を説明しています。LAUNDRY BEAR、Void Blizzard、CL-STA-1114、TA488など複数の名称で追跡される攻撃者は、少なくとも2025年7月以降活動していると報告されています。

攻撃の仕組みは、Zimbra Collaboration SuiteのWebメールインターフェースに存在するクロスサイトスクリプティング（XSS）脆弱性（CVE-2025-66376）で、メールコンテンツ内のCSS @importディレクティブのサニタイズ不備が根本原因です。クロスサイトスクリプティングの脆弱性は、攻撃者が正規Webアプリケーションのセッション内で自身のコードを実行できるようにします。今回の場合はWebメールクライアント自体です。CISAによれば、エクスプロイトが発動すると、被害者の過去90日分のメール、保存されたメールアドレスとパスワード、組織の内部メールディレクトリ、2要素認証トークン、新規生成されたアプリケーションパスコードが収集されました。盗まれた情報は、攻撃者が内部で「Flowerbed」と呼ぶバックエンドインフラに送信されたとされています。Zimbraは2025年11月にZCSバージョン10.0.18および10.1.13で修正をリリースしており、現在もこのキャンペーンに曝露している組織には数か月前からパッチが提供されています。

この勧告が注目される理由は、Webメールプラットフォームの単一の脆弱性がもたらす影響範囲の広さです。1通のメールや添付ファイルだけではありません。3か月分のやり取り、そのやり取りを守る認証情報、盗難パスワード対策のためのMFAトークンまで含まれます。AttackIQの対応は、防御側がこの挙動パターンを検知できるかどうかをテストするための敵対者エミュレーション演習であり、合理的かつ有用なステップです。ただし、これは検知のための演習であり、予防ではありません。攻撃を模倣することで気づけるかどうかは分かりますが、Webメールアプリケーションがそもそも悪意あるコンテンツを実行したかどうかまでは分かりません。Flowerbedへの情報流出パターン（異常な送信データ量、異常なセッショントークンの動き、地理的に不自然な認証イベントなど）に対して行動ベースのアラートを設定したSIEMプラットフォームは、AttackIQの演習を単なる時点テストから継続的な監視能力へと昇華させます。

Bank of Baroda：確認された事実と主張の違い

2つ目のインシデントは公開情報が限られていますが、1つのメールボックス侵害がどれほど急速に拡大するかを示す点で示唆に富みます。セキュリティ研究者Srikanth Lakshmananは、Bank of Barodaに関連するデータセットがダークウェブ上で流通しているのを最初に特定しました。Reutersはそのメタデータから700GB超と報じ、他のメディアは「ほぼ1テラバイト」と主張しています。これらの数字は研究者や攻撃者側の分析によるものであり、銀行が確認したものではありません。この違いは実際の露出範囲を評価する際に重要です。

漏洩したとされる情報には、顧客の本人確認書類、ローンや査定記録、内部監査レポート、支店書類、内部コミュニケーションが含まれます。さらに一部報道ではAadhaar番号やネットバンキングデータも流出したとされていますが、Bank of Barodaはこれらの具体的内容を確認しておらず、未確認情報として扱うべきです。

銀行が確認した内容はより限定的かつ示唆的です。侵害は従業員のメールアカウントが侵害されたことに起因し、コアバンキングシステムにはアクセスされておらず安全が保たれているとしています。ハッキンググループが公式に犯行声明を出したわけではありませんが、一部研究者はTripleXという脅威アクターとの関連を指摘しています。Bank of Barodaはフォレンジック調査を開始し、当局と連携しています。調査が完了するまで、漏洩した情報の正確な量や内容は暫定的なものとして扱うべきです。その単一メールボックスを通じてアクセス可能だった知的財産や顧客記録は、GDPR準拠や業界特有のデータ保護義務を負う金融機関が、従業員メールアカウントをガバナンスされたコンテンツ環境の範囲外とみなすことができない理由を示しています。

不確かな数字を除いても、1つの事実は揺るぎません。1人の従業員メールボックスが、銀行が公に流出させたくないローンファイル、監査レポート、内部コミュニケーションを保持またはアクセス経路として機能していたということです。これはZimbra CVEのような高度な技術的エクスプロイトチェーンではありません。むしろ、より一般的で危険なパターン、つまり機密ビジネスコンテンツが個人のメールボックスに蓄積され、そのアカウントのアクセス制御に依存しているという現象です。

なぜメールは攻撃ベクトルとして使われ続けるのか

セキュリティチームは20年以上にわたり、フィッシング対策訓練、アンチウイルススキャン、多要素認証に投資してきましたが、依然としてメールは多くのインシデントで初期侵入経路となっています。ZimbraとBank of Barodaのケースは、なぜ問題が解決しないのかを示しています。メールは単一のコントロールポイントではなく、保有する情報量に対して境界防御が弱いコンテンツリポジトリだからです。

通常の業務を1〜2年続けた後のメールボックスの中身を考えてみてください。契約書、ローン査定、監査結果、共有ドライブが不便だったために添付で転送された顧客記録、パスワードリセットリンク、「今回だけ」と送られたMFAバックアップコード。これらのコンテンツは本来メールに永続的に残すべきものではありませんが、情報を人から人へ動かす最も手軽な手段としてメールに蓄積されていきます。攻撃者はこの点を防御側以上に理解しており、Webメールの脆弱性や1つの認証情報の盗難で、数か月分の機密情報を一度に取得できるのです。ガバナンスされた保持ポリシーがないまま、侵害されたメールアカウントを経由してデータ侵害が発生すると、組織は完全なアクセス履歴を再構築するまで通知範囲を正確に特定できません。

Zimbraの勧告はもう1つの側面を加えます。攻撃対象となるのはメッセージを読む人間だけでなく、Webメールアプリケーション自体も攻撃面となります。クロスサイトスクリプティングの脆弱性は、従来のフィッシングのようにユーザーが悪意のあるリンクをクリックする必要がありません。ブラウザがWebメールプラットフォームのコードを信頼することを悪用します。これにより、防御の一部はユーザー教育から、メールプラットフォームがコンテンツをどのようにスクリーニングし、隔離し、監査するか（保存データも通過データも含む）に移ります。

ガバナンスされたセキュアメールアプローチが露出をどう変えるか

Zimbraの被害者もBank of BarodaもKiteworksセキュアメール環境を利用していなかったため、「Kiteworksならどちらのインシデントも確実に防げた」とは言えません。ただし、両勧告が記述する仕組み、すなわち攻撃者が提供したコンテンツがWebメールプラットフォーム内で実行されることや、侵害されたメールボックスが機密ビジネスファイルの経路となることは、ガバナンスされたセキュアメールやゼロトラスト・アーキテクチャがまさに解決を目指す課題領域です。

Kiteworks Email Protection Gateway（EPG）は、Data Policy Engine上で動作し、データ内容、送信者・受信者、分類ラベルに基づき、すべての受信・送信メールに自動で暗号化、ルーティング、隔離、拒否を適用します。送信・受信者が特別な操作をする必要はありません。また、受信メールをスキャンし、防衛請負業者のCUIのような機密データを標準の受信箱からコンプライアンス経路へ自動で振り分け、すべての判断を統合・不変の監査ログに記録します。Zimbraのケースに適用すると、このポリシーレイヤーはメールフローの前段に配置され、Webメールクライアントのレンダリングエンジン内ではないため、Webメールアプリケーションが信頼すべきでないコンテンツを実行するタイプの攻撃への露出を減らします。Bank of Barodaのケースでは、ローン査定、監査レポート、顧客記録などの機密ファイルを、個人メールボックスにアドホックに保存するのではなく、ポリシーでルーティング・記録されたガバナンス対象コンテンツとして扱うことが重要です。メールゲートウェイ層でのデータ最小化ポリシー（定められた保持期間を超えた添付ファイルや機密コンテンツを自動削除）は、メールボックスが侵害された場合に攻撃者が取得できる回収可能データ量を減らし、両インシデントが示す被害範囲を直接的に限定します。

こうした制限は重要です。なぜなら、侵害後にベンダーの能力を過大評価することは、セキュリティマーケティングでよく見られる非生産的な習慣だからです。EPGはサードパーティWebメールベンダーのソースコードを修正できず、前段に配置されるプラットフォームのアプリケーションレベルの脆弱性をすべて排除することもできません。その有効性は、組織がどのようにポリシー、分類ラベル、保持ルールを設定するかに大きく依存します。設定が不十分なゲートウェイでは、本来の保護機能の一部しか発揮できません。正直な説明は「露出の低減と被害範囲の限定」であり、「完全な無敵」ではありません。同じ論理はBarodaのケースにも当てはまります。「従業員メールアカウントの侵害」と「ガバナンスされたセキュアメールでそのギャップが埋まる」との一対一の対応は、銀行が公表した内容からの合理的な推論であり、特定の技術的エクスプロイトチェーンの確認ではありません。なぜなら、銀行はその詳細を公開していないからです。

メールコンテンツを中心としたゼロトラスト体制の構築

両インシデントから得られる実践的な教訓は、メールを単なる通信ツールではなく、ファイルサーバーやデータベースと同等の厳格さで管理すべきコンテンツシステムとして扱う必要があるということです。

「侵害発覚後」ではなく「配信前」にスキャンを実施しましょう。Zimbraの脆弱性はWebメールセッション内で発動したため、メッセージ配信前にスキャン層を配置し、Webメールベンダーのパッチサイクルだけに頼らないことで、悪意あるコンテンツが実行されるウィンドウを短縮できます。

機密ファイルは個人メールボックスに恒久的に保存すべきではありません。Bank of Barodaのローン査定、監査レポート、支店書類は、1人の従業員の受信箱に保存または経由していたと報じられています。データ分類とガバナンスされたセキュアなファイル共有により、こうしたコンテンツに独立したアクセス境界を設け、個人の認証情報に依存しない管理が可能です。個人メールボックスへの機密ビジネス記録の長期保存を明確に禁止し、ガバナンスされたファイル共有環境でファイル単位のアクセス制御を実施するデータガバナンスフレームワークは、認証情報の盗難が大規模なコンテンツ露出に発展する蓄積パターンを断ち切ります。

MFAトークンやアプリケーションパスコードも、認証情報としてだけでなく、転送中の機密コンテンツと同様に扱うべきです。Zimbraキャンペーンは、特にメール経由でやり取りされる新規アプリケーションパスコードを標的にしていました。防御側は、これらのトークンの生成方法だけでなく、配信・保存方法にも注意を払う必要があります。

さらに、機密コンテンツがメールに触れるすべてのポイントで監査証跡の可視性を確保しましょう。インシデント発生時には、断片的なログから後追いで再構築するのではなく、あらかじめフォレンジックタイムラインが存在している必要があります。Bank of Barodaの継続中のフォレンジック調査や、漏洩範囲が未確認である現状は、最初から可視性を確保していない場合、インシデント対応がいかに困難になるかを示しています。「機密コンテンツが蓄積された従業員メールボックスの侵害」シナリオに特化した即時アクセス停止、監査ログ抽出、範囲評価、規制当局への通知手順を含むインシデント対応計画を文書化しておくことで、事後の即席対応から、訓練された時間制限付きの対応へと転換できます。

どれも特殊なことではありません。これはゼロトラスト・データ保護の運用表現です。メールを通過するすべてのコンテンツを、組織内外の出所を問わず検証し、信頼できる従業員のメールボックスだからといって安全だと決めつけないことが重要です。

この2つのインシデントを超えた規制・業界リスク

CISAの勧告で名指しされた防衛、政府、エネルギー、法執行、教育分野は、機密コンテンツの取り扱いに関して最も厳しく規制されている分野でもあります。CMMCコンプライアンスの対象組織や、CUIを扱う組織には、こうした制御情報が通信チャネルを通過する際の具体的な義務が課せられていますが、コンテンツ実行型攻撃に脆弱なWebメールプラットフォームではこれらの義務を果たすことが困難になります。Bank of Barodaのような金融機関も、独自のデータ保護・漏洩通知に関する規制要件下で運用しており、従業員メールボックスの侵害によるローンや監査記録の漏洩は、規制当局が事後に必ず問う内容（どのようなアクセス制御があったか、何が記録されていたか、どれだけ早く露出が特定されたか）に直結します。CISA勧告で標的となった分野の組織は、サプライチェーンリスク管理プログラムの一環として、サプライヤーやパートナーがCUIや規制対象の金融データをガバナンスされていないメールチャネルでやり取りしていないかを明示的に評価すべきです。LAUNDRY BEARが悪用した脆弱性クラスは、プライムコントラクターや金融機関が依存する拡張サプライチェーンにも同様に適用されます。

これら2つの勧告は、主にコンプライアンスの話ではありません。どちらも運用上のセキュリティ失敗であり、調査が終わればコンプライアンス上の影響が後からついてくるでしょう。それでも、規制フレームワークは、組織がメール経由のコンテンツについて基本的な質問（何が、いつ、誰のアクセスで組織を離れたか）に答えられることを前提とする傾向が強まっていることを思い出させてくれます。規制コンプライアンスとガバナンスされたコンテンツ交換を軸にしたプラットフォームは、こうした質問に即座に答えられる状態を実現するために存在します。CISOダッシュボードは、すべてのメールおよびコンテンツ交換チャネルをリアルタイムで可視化し、この即時回答性を「理想」ではなく「現実の運用」として提供します。

ガバナンスされたスキャン、アクセス制御、監査可視性によってメール経由の露出を減らす方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事 メールセキュリティで機密コンテンツを守る
• ブログ記事 メールガバナンス・コンプライアンス・コンテンツ保護の最適化方法
• ブリーフ すべての機密メールの可視化拡大と自動保護
• ブリーフ Email Protection Gateway（EPG）でKiteworksセキュアメールを強化