メール 基盤に相次ぐ サイバー攻撃- KDDI・IIJ・TOKAIコミュニケーションズ・WebARENAの4事案を整理

セキュリティニュース

投稿日時: 更新日時:

日本のメール基盤に相次ぐ サイバー攻撃- KDDI・IIJ・TOKAIコミュニケーションズ・WebARENAの4事案を整理

2025年4月から2026年6月までのわずか14か月の間に、日本国内の主要なメールシステムが4件連続で不正アクセスを受けています。

  • IIJのセキュアMXサービス(確定586契約・311,288件)
  • TOKAIコミュニケーションズのOneOffice Mail Solution(メールアドレス約8万件・隔離メール約193万通)
  • NTTPCコミュニケーションズのWebARENA メールホスティング(メールアドレス7,446件)
  • そしてKDDIのISP事業者向けメールシステム(最大1,422万件)。

4件のうち、IIJとTOKAIはサードパーティ製品のゼロデイ脆弱性、KDDIは第三者製ソフトウェアの脆弱性が悪用されたと公表されています。

NTTPCは原因の詳細を公表していません。ただし、いずれの事案もメール基盤そのもの、またはメールに付随する機能が攻撃対象となっており、自社開発部分だけでなく、外部製品・付帯機能・委託先基盤を含めた管理が重要であることを示しています。本記事では4つの事例の整理し情シスが確認すべき点も記載しています。

この記事のサマリー

  • 2025年4月から2026年6月にかけて、国内の主要メール関連サービスで不正アクセスが相次いだ。
  • 対象はIIJ、TOKAIコミュニケーションズ、NTTPCコミュニケーションズ、KDDIの4事案。
  • 影響範囲は、法人メールセキュリティ、隔離メール、ファイル転送、ISP向けメール基盤まで広がっている。
  • IIJとTOKAIでは、メール基盤に組み込まれたサードパーティ製品のゼロデイ脆弱性が悪用された。
  • KDDIでは第三者製ソフトウェアの脆弱性が悪用されたが、製品名やCVEは公表されていない。
  • NTTPCは原因詳細を公表しておらず、システム全体の再構築を進めている。
  • 共通する課題は、メール基盤の集約、サードパーティ製品への依存、長期運用システムの複雑化、侵害後検知の難しさにある。
  • 情報システム部門は、自社メール基盤の委託先、再委託先、利用コンポーネント、パスワード保管方式、ログ監視体制を確認すべきである。

4事案の時系列整理

 

事案 発覚時期 対象サービス 運営企業 影響規模 原因 行政対応
IIJ セキュアMXサービス 2025年4月 法人向けメールセキュリティ IIJ 586契約(確定):アカウント・パスワード311,288件、メール本文6契約、クラウド認証情報488契約 Active! mailゼロデイ(CVE-2025-42599、CVSS 9.8) 総務省が行政指導
TOKAI OneOffice Mail Solution 2025年12月 法人向けメールサービス TOKAIコミュニケーションズ メールアドレス約8万件、隔離メール約193万通 Cisco Secure Email Gateway/Web Managerのゼロデイ
WebARENA SuiteX(NTTPC) 2026年4月〜5月 メールホスティング付帯機能 NTTPCコミュニケーションズ メールアドレス7,446件、ファイル4,463件 未公表(サービス全体の再構築を決定)
KDDI ISP向けメール 2026年6月 ISP事業者向けメール基盤 KDDI 最大1,422万件 第三者製ソフトウェアの脆弱性(具体名・CVE未公表) 個人情報保護委員会・総務省へ報告中

概要

最初にサイバー攻撃が発生したのは2025年4月のIIJです。

法人向けメールセキュリティサービスのIIJセキュアMXサービスが不正アクセスを受けました。

このサービスは企業や自治体のメールをクラウド上でフィルタリング・保護するもので、第一報では最大6,493契約・約407万件のメールアカウント情報が漏洩の可能性ありとして公表されました。その後の詳細調査によって漏洩の事実が確認されたのは、重複除外後で586契約です。

内訳は、メールアカウント・パスワードの漏洩が132契約・311,288件、メール本文・ヘッダ情報の漏洩が6契約、連携先クラウドサービスの認証情報漏洩が488契約でした。

IIJから約8か月後の2025年12月、今度はTOKAIコミュニケーションズが法人向けに提供するメールサービスOneOffice Mail Solutionで不正アクセスが検知されました。調査が進むにつれて影響範囲は徐々に広がり、2026年1月23日の第三報で確定値が出ています。

メールアドレス815件、メーリングリスト名3,503件、スパムフィルタリング利用者のメールアドレス約8万件、隔離メール約193万通が漏洩対象として特定されました。静岡県内の自治体をはじめとする複数の委託先企業にも影響が及んでおり、自治体のメール情報が民間事業者の基盤経由で漏洩するという形になりました。

2026年に入ると攻撃のペースが上がります。

4月末にはNTTPCコミュニケーションズが運営するWebARENA SuiteXの付帯機能である大容量ファイル転送機能のサーバーで外部からの攻撃が検知されました。さらに5月10日にはSuiteXの収容サーバーdc70.etius.jpが別の攻撃を受けた可能性が公表され、1か月以内に2度のサイバー攻撃という異常な事態になりました。6月23日の調査完了報告で、4月21日から不正アクセスの痕跡があったことが判明し、ユニークメールアドレス7,446件(2019年3月から2026年4月までの約7年分)とアップロードファイル4,463件が対象範囲として確定しています。

ダウンロード用パスワードもサーバー上に格納されていた点は、ファイル転送サービス特有のリスクとして見逃せません。サービスの再開はシステム全体の再構築を経て2026年12月頃の見通しです。

そして2026年6月17日、KDDIがISP事業者向けに提供するメールシステムで不正アクセスが確認されました。

このシステムはKDDIが裏側のインフラを運営し、@nifty・BIGLOBE・J:COM・コミュファ光・ピカラ・CPIの6社がその上でエンドユーザー向けメールサービスを提供しています。エンドユーザーから見れば自分が契約しているのは@niftyやBIGLOBEですが、メールの実体はKDDIの基盤の上で動いています。

この基盤が1つ侵害されたことで、漏洩の可能性があるメールアドレスとパスワードは最大1,422万件という4件中最大の規模に達しました。

メールシステムへのサイバー攻撃は影響範囲が広い

メールシステムはインフラ提供者がプラットフォームを運営し、その上に複数の事業者やエンドユーザーが載っています。1つの基盤が侵害されると、その上にいるすべての事業者と利用者に被害が広がります。KDDIでは6社・最大1,422万件、IIJでは第一報時点で最大6,493契約・約407万件が漏洩の可能性ありとされ、最終的に586契約で漏洩が確定しました。

エンドユーザーにとっては自分が契約している事業者のブランド名しか見えていないので、その裏でどこの基盤が動いているかは意識していません。委託先の基盤が侵害されたことで自社の顧客情報が影響を受けるという構造は、自組織の努力だけでは防げない部分を含んでいます。

そしてメールシステム特有の攻撃面の広さがあります。

メールはSMTP・IMAP・POP3・Webメール・API連携と、業務上の必要性から複数のプロトコルをインターネットに対して公開せざるを得ません。ファイルサーバーやグループウェアであればVPNやゼロトラストで外部アクセスを遮断できますが、メールは外部との通信がそもそもの機能なので、攻撃面を縮小する余地が構造的に限られます。

サードパーティー機能へのサイバー攻撃

4件中3件はメールシステムの付帯機能に組み込まれたサードパーティ製ソフトウェアの問題を突かれています。自社で開発した部分ではなく、他社から調達して組み込んでいる製品の脆弱性が攻撃の起点になっています。メールシステムの運営事業者がどれだけ自社のネットワークを堅牢にしていても、組み込んでいるサードパーティ製品に穴があれば、そこから侵入されてしまいます。

原因 ─ ゼロデイを突かれた2件と、原因が見えない2件

4件の原因は大きく2つに分かれます。

IIJとTOKAIの2件は、いずれもゼロデイ脆弱性が悪用されたことが判明しています。

IIJの事案ではクオリティア社のWebメールソフトActive! mailにスタックベースのバッファオーバーフローの脆弱性(CVE-2025-42599、CVSS 9.8)が存在しており、攻撃時点ではクオリティア側もこの脆弱性を認識しておらず、パッチは存在しませんでした。

TOKAIの事案ではシスコシステムズのCisco Secure Email GatewayおよびCisco Secure Email & Web Managerに未知の脆弱性があり、シスコが修正済みソフトウェアを公開したのは2026年1月15日でした。つまりどちらの事案でも、攻撃が行われた時点ではベンダー自身がバグの存在を把握していなかったため、いくらパッチ管理を徹底していても防げなかったということになります。

ゼロデイである以上、事前にパッチを当てて防ぐという選択肢は存在しません。

できるのは侵害されたことを早く検知し、被害を最小化する方向の対策です。

ネットワーク監視・ログ分析・異常検知の体制がどこまで整備されていたかが、漏洩規模の差につながっています。IIJのケースでは確定586契約まで絞り込まれましたが、TOKAIでは隔離メール約193万通が対象に入っており、検知から遮断までの時間差が影響した可能性があります。

一方、WebARENA(NTTPC)とKDDIの2件は、原因の詳細が公表されていません。

NTTPCはサービス全体の再構築を決定し、再開を2026年12月頃としていることから、根本的な設計レベルの問題が見つかった可能性があります。部分的なパッチ適用で済む問題であれば、8か月近くかけてシステムを一から作り直す判断にはならないはずです。

KDDIは第三者製ソフトウェアの脆弱性を悪用されたと説明していますが、ソフトウェア名やCVE番号は公表されていません。

メールインフラが繰り返し狙われる構造的な背景

なぜメールシステムばかりが標的になるのか。その背景には日本のメールインフラに固有の事情も含めた複合的な要因があります。

ひとつはメールインフラの老朽化です。

日本のISPメールサービスの多くは2000年代初頭に構築された基盤の延長線上で運用されてきました。

長年にわたって機能追加とパッチ適用を重ねた結果、構成が複雑化しています。どのサードパーティ製品がどのバージョンで動いているかを正確に把握すること自体が難しくなっている現場もあります。長期運用のシステムほど依存関係の全容把握が困難で、1つのコンポーネントを更新すると別の箇所に影響が出るという問題が避けられません。WebARENA SuiteXがシステム全体の再構築に踏み切ったのは、この種の技術的負債がもはや部分修正では対処しきれない水準に達していたことを意味していると思われます

もうひとつは基盤の集約構造がリスクを増幅しているという問題です。コスト効率や運用効率の観点から、複数のISPが同一のメール基盤を共用する構造は事業的には合理的な判断です。しかしセキュリティの観点では、集約された基盤がSingle Point of Failureになります。KDDIの事案では1つの基盤への侵害で6社・最大1,422万件に影響が及びました。

情報システム部門がチェックするポイント

4件の連続する事案から情シス部門は以下を確認する事をお勧めします。

確認項目 確認内容
メール基盤の提供元 自社が直接契約している事業者と、その裏側の基盤提供者を確認
サードパーティ製品 Webメール、スパム対策、隔離メール、ファイル転送、アーカイブ製品を棚卸し
パスワード保管方式 平文保存の有無、ハッシュ方式、暗号化方式、ソルト有無を確認
ログ保全期間 不正アクセス発覚後に過去ログを調査できる期間を確保
休眠アカウント 解約済み、退職者、未使用メールボックスを削除または無効化
管理画面の公開範囲 管理画面やWebメール管理機能をインターネットへ広く公開していないか確認
委託先の初動体制 侵害時の連絡、調査、通知、パスワードリセット手順を確認
パスワード使い回し対策 メールパスワードと他サービスのパスワードを分離
MFA 管理画面、Webメール、クラウド連携で多要素認証を適用
代替連絡手段 メール停止時に利用者へ通知できる手段を確保

FAQ

Q. 4件の攻撃は同一の攻撃者によるものですか?

A. 公表情報からはそれを示す証拠は出ていません。IIJではActive! mailのゼロデイ、TOKAIではCisco製品のゼロデイと、悪用された脆弱性自体が異なります。ただし、日本のメールインフラが攻撃者にとって効率的な標的として認識されている可能性は高く、複数の攻撃者が同種のターゲットを並行して狙っている可能性もあります

Q. 自社がIIJ・TOKAI・NTTPC・KDDIのサービスを利用していない場合は関係ありませんか?

A. 直接的な影響は受けません。ただし4件が示した構造的な問題、つまりサードパーティ製品の脆弱性がメールシステム全体の侵入口になること、基盤の集約が大規模漏洩を招くことは、あらゆるメールサービスに共通する課題です。自社が利用しているメールサービスの基盤がどこにあるかを確認し、委託先のセキュリティ体制を把握しておくことを推奨します。

Q. メール本文は漏洩していますか?

A. 事案ごとに異なります。IIJでは6契約でメール本文・ヘッダ情報の漏洩が確認されています。TOKAIでは隔離メール約193万通が漏洩対象です。KDDIでは現時点でメール本文への言及はなく調査継続中です。WebARENA では大容量ファイル転送機能に格納されていたアップロードファイル4,463件が対象範囲に含まれています。

Q. ゼロデイが原因ならパッチ管理をしていても防げなかったのですか?

A. ゼロデイ脆弱性は、攻撃時点で修正パッチが存在しないため、通常のパッチ管理だけで完全に防ぐことは困難です。
ただし、WAF、IPS、EDR、ログ監視、外部通信監視、管理画面のアクセス制限、権限分離が整備されていれば、悪用の成功確率を下げたり、侵害後の被害拡大を抑えたりすることはできます。


出典

当サイト関連記事