事件の概要
KDDIがISP事業者向けに提供するメール基盤システムに対し、不正アクセスが行われ、複数のISP利用者のメールアドレスやメールパスワードが漏えいしました。
その後の調査により、第三者製ソフトウェアの未知の脆弱性（ゼロデイ）が悪用されていたことが判明しています。
KDDIは、メールサービスに対する不正アクセス事案について、その後の調査結果を公表しました。
当初は「情報漏えいの可能性」とされていましたが、調査の結果、メールアドレスやメールパスワードの一部について、実際に情報漏えいが発生していたことが確認されています。
また、原因は第三者製ソフトウェアに存在した**未知の脆弱性（ゼロデイ脆弱性）**が悪用されたことによるものと説明されています。
一方で、悪用された製品名や脆弱性番号（CVE）、攻撃グループ、具体的な侵入手法などについては現在も公表されておらず、詳細は調査中とされています。
現時点で判明しているポイント
- 情報漏えいの可能性から「漏えいを確認」へ更新
- メールアドレス約1,223万件、メールパスワード約761万件が漏えい
- 第三者製ソフトウェアの未知の脆弱性（ゼロデイ）が悪用された
- KDDIは影響を受けた利用者に対し、パスワードの変更・強制リセットを実施
- 攻撃者や侵入経路などの詳細は引き続き非公表
発覚から現在までの流れ
5月29日――利用者の不正ログインを疑う 「疑い・利用者対応」
ニフティは、一部の利用者についてメールへの不正ログインが疑われる状況を確認し、対象者へパスワード変更を求める案内を送りました。
この段階では、KDDIが提供するメール基盤そのものへの侵入が判明していたわけではありません。まずは、個々のメールアカウントに対する不正ログインの疑いとして対応が始まりました。
6月上旬――KDDIと連携して原因を調査 「疑い・調査」
その後もメールシステムの負荷増加などの異常が続いたことから、ニフティは単なる利用者アカウントへの不正ログインではなく、システム側に問題がある可能性を疑い、基盤提供元であるKDDIと連携して調査を進めました。
6月15日――IMAPの新規接続を制限 「疑い・予防行動」
ニフティは、メールシステムへの負荷を抑え、被害の拡大を防ぐため、IMAPによる新規接続を一時的に制限しました。ニフティのサポートページにも、同日付で接続制限に関する案内が掲載されています。
6月17日頃――メール基盤への不正アクセスを確認 「発覚・防衛行動」
KDDIとの共同調査により、ニフティが利用しているKDDI提供のメール基盤システムに対し、外部から不正アクセスが行われていたことが判明しました。
KDDIは被疑箇所を特定し、技術的な防御措置を実施しました。
6月23日――第一報を公表 「情報開示・社会との共有」
ニフティとKDDIは、メールアドレスおよびメールパスワードが第三者に漏えいした可能性があると公表しました。
この時点では、漏えいはまだ「可能性」とされていました。また、原因については、KDDIが提供するメール基盤システムに存在した脆弱性が悪用されたと説明されました。
6月23日以降――利用者へパスワード変更を要請 「利用者対応」
影響を受けた可能性のある利用者に対し、メールパスワードの変更が案内されました。変更が確認できない利用者については、被害拡大防止のためパスワードを無効化する措置も進められました。
7月6日――調査結果を更新 「事後検証・情報更新」
ニフティとKDDIは第二報を公表し、影響範囲や原因について調査結果を更新しました。
当初の「漏えいした可能性がある」という説明から、実際に情報が漏えいしたことを確認した段階へ進み、原因となった脆弱性についても、第三者製ソフトウェアに存在した未知の脆弱性だったことが明らかにされました。
時系列からの評価
公表されている事実から評価すると、KDDIとニフティは、異常を認知した後、状況に応じて必要な行動へ移しており、適切に対応していたのではないかと考えます。
そこで改めて今回の時系列を振り返ると、ニフティとKDDIは、状況の変化に応じて段階的に対応を強化していったことが分かります。
5月29日の段階では、利用者アカウントへの不正ログインの可能性を疑い、対象利用者へパスワード変更を案内しました。
その後、問題が利用者個人だけでは説明できないと判断すると、KDDIと共同で原因調査を開始し、さらに被害拡大を防ぐためIMAPの新規接続を制限しています。
そして、不正アクセスを確認した段階では、被疑箇所の遮断やシステム改修など、防衛行動へ速やかに移行しました。
重要なのは、「異常かもしれない」と考えていただけではなく、その都度、状況に応じた行動へ移していたことです。
もちろん、今後の検証によって改善点が示される可能性はあります。しかし、現時点で公表されている情報を見る限り、防御側は異変を認知してから、調査・予防措置・防衛行動・情報開示へと段階的に対応を進めていたと評価できます。
サイバー攻撃への対応では、最初からすべての状況が分かることはほとんどありません。
限られた情報の中で仮説を立て、その仮説を検証しながら、必要な対策を一つずつ積み重ねていく。その積み重ねこそが、インシデントレスポンスの本質であると私は考えています。
時系列から垣間見えるもう一つの視点
それは、「発覚」を攻撃側と防御側の主導権が切り替わる転換点にしたいこと。
- 疑い（Something is wrong）
- 調査（What is happening?）
- 予防行動（Limit the damage）
- 発覚（We are under attack）「転換点」
- 防衛行動（Stop the attacker）
- 公表（Inform stakeholders）
- 事後検証（Learn and improve）
考察 ここでも「発覚の経緯」から読み解くKDDI不正アクセス事案
私はサイバー攻撃を分析する際、「どのように侵入されたか」と同じくらい、「どのように発覚したのか」を重視しています。
今回のKDDI事案では、攻撃者がリークサイトや身代金要求によって存在を誇示した形跡は、現時点では確認されていません。つまり、この事案は攻撃者側ではなく、KDDI側の検知によって発覚した可能性が高い事例と考えられます。
この点は、ランサムウェアによるサイバー攻撃とは大きく異なります。
金銭目的のランサムウェア攻撃では、最終的に被害者へ攻撃を認識させ、交渉へ持ち込むことが犯罪ビジネスの成立条件になります。そのため、暗号化やリークサイトへの掲載、身代金要求など、「発覚させる仕組み」が攻撃の一部として組み込まれています。
一方、今回のKDDI事案では、そのような動きは確認されておらず、攻撃者はできるだけ長く気付かれずに活動を継続することを狙っていた可能性があります。
また、原因が未知の脆弱性（ゼロデイ）の悪用であったことも重要です。ゼロデイ攻撃は、防御側に修正プログラムが存在しない状態を狙うため、侵入そのものを防ぐことが極めて難しい攻撃手法です。
だからこそ、このような事案では「侵入されたかどうか」だけでなく、「どのように異常を検知し、どの段階で被害を把握したのか」という発覚のプロセス、侵入を許した後の侵出を許さない仕組みが、今後の防御力向上にとって大きな意味を持つと考えています。
今後、KDDIからさらに調査結果が公表されれば、攻撃の全体像だけでなく、「発覚の経緯」を軸に改めて分析していきたいと思います。
まとめ
発覚の経緯を探求する先には、多くの恩恵が待っていると私は考えています。
その一つが、「侵入を完全に防げなくても、情報の持ち出しを防ぐ仕組み」を磨き上げることです。
サイバー攻撃を100％防ぐことは容易ではありません。しかし、発覚の経緯を分析することで、攻撃者の行動や防御側の対応を振り返り、「どの段階で異常を検知できたのか」「どこで攻撃を止められたのか」という知見を積み重ねることができます。
その積み重ねが、侵入後の被害拡大を防ぎ、情報の流出を阻止する仕組みの構築につながると私は考えています。
① 金銭目的のサイバー犯罪（ランサムウェアなど）
攻撃者は最終的に利益を得る必要があります。
そのため、
- いつ発覚させるか
- どのように発覚させるか
- どのタイミングで交渉へ移るか
- どこまで情報を公開するか
といった点まで含めて、攻撃オペレーションを設計している可能性があります。
だからこそ、
「発覚の仕方」を見ることで、攻撃者がどのようなビジネスモデルや交渉戦略を採用しているのかを読み解く手掛かりになる。
② サイバースパイ・国家支援型攻撃
こちらは逆です。
目的は
- 情報収集
- 長期間の潜伏
- 将来の作戦準備
であり、
発覚は失敗です。
したがって、
- なぜ発覚したのか
- 何が検知できたのか
- どのログが役立ったのか
- どの運用が有効だったのか
を分析することは、
防御側が次の攻撃に備えるための知見
になります。
この二つを統一すると…
発覚とは、攻撃側と防御側の戦略が初めて交差する瞬間であり、攻守双方が初めて相まみえる「最初の会戦」である。
です。
コメント