← 記事一覧へ

IDCフロンティア:ランサムウェアでIDCFクラウドの4ゾーンが停止。495の顧客に「自社のバックアップから再構築を」。

2026年10月7日、IDCFクラウドがランサムウェア攻撃を受けました。10月14日の第5報では194顧客のバックアップが取り出し可能、サーバー内データの流出の痕跡なし、ポータルで48社の情報照会。マウス、イズミ、JR東海も公表しました。

事案の発生時期: 2026年10月7日午前3時40分頃から障害、継続中出典確認日: 2026/10/15更新日: 2026/10/15

30秒でわかる要点

要点
2026年10月7日午前3時40分頃から、ランサムウェアによりIDCFクラウド東日本リージョン1の4ゾーンで仮想サーバーが停止し、495の企業・自治体に影響しました。ソフトバンクのクラウド子会社IDCフロンティアは10月14日、うち194の顧客でバックアップを取り出せること、顧客のサーバー内のデータが照会・持ち出された痕跡はないことを公表しました。
対応するチーム
IT運用、EDR、SIEM、委託先リスク、メールセキュリティ、法務・プライバシー
最初のアクション
すべての委託先に、サービスの一部でもIDCFクラウド上で動いているかを確認し、自社の利用状況も調べてください。そのうえで、重要システムのバックアップが、守る対象と同じ基盤や管理者アカウントの外にあること、ESXiのSSHとシェルが無効であることを確かめてください。
不確実性・注意点
侵入経路は分かっておらず、攻撃者の数字も未確認です。流出がなかったという判断は4ゾーンの顧客のサーバー内のデータが対象で、ほかのゾーンは確認中です。各社の件数は重複する調査上の上限で、漏えいの確定件数ではありません。
ヘッダー画像。IDCFクラウドでランサムウェアにより4ゾーンが停止し、495の企業・自治体が自社のバックアップからの再構築を求められたという見出し。横に、IDCフロンティアが確認した内容と、「239台のハイパーバイザーを7分で暗号化」という未確認の攻撃者の主張。
実務への示唆

今夜、クラウド事業者から「復元できるのは御社自身のバックアップだけです」と言われたら、どのシステムが、どこから、どれだけ古いデータで戻ってくるでしょうか。頼っている委託先にも同じことを聞いてください。

ランサムウェアの公表の多くは、1社のデータの話です。今回はプラットフォームの話です。 IDCFクラウドの基盤となるハイパーバイザーへの攻撃で、495の企業・自治体の仮想サーバーが一度に止まりました。IDCフロンティアは当初、影響を受けた4ゾーンのデータを取り戻すのは難しいと伝えました。10月14日には、うち194の顧客でバックアップを取り出せるとしています。どれだけ早く戻れるかは、各顧客がプラットフォームの外に何を残していたかで決まります。2日以内に、JR東日本、ビューカード、JR九州が、この基盤上のメール配信サービスにあった会員のメールアドレスが見られた可能性を公表しました。

10月15日の更新:194顧客のバックアップ、流出の痕跡なし、3社が新たに公表

IDCフロンティアは10月14日、外部のセキュリティ専門企業との調査に基づく第5報を公表しました。状況は3つの点で変わりました。第5報

  • 一部のデータは戻る。 10月8日の時点では、4ゾーンのデータの取り出しや復元は困難な見通しとしていました。第5報では、スナップショット機能を使っていた194の顧客について、バックアップデータを取り出せることを確認したとしています。取り出したデータから実際にシステムを復元できるかは確認中で、復元や提供の方法は顧客ごとに連絡しています。495すべてが復旧したわけではありません。
  • 顧客のサーバーからデータが出た痕跡はない。 4ゾーン(tesla、henry、pascal、joule)について、顧客の仮想サーバー内に保存されたデータが照会されたり外部へ持ち出されたりした痕跡も、それを裏付ける事実も確認されなかったとしています。IDCフロンティアは、このデータの外部流出はなかったと判断しました。ほかのゾーンとリージョンの安全性の確認は続いています。INTERNET Watch · Impress Watch
  • 顧客ポータルで情報が照会された。 IDCFクラウドポータルで、48社の登録情報が不正に照会されました。企業名、ログインID、ハッシュ化されたパスワード、通知先メールアドレス、月額利用料金の合計額などです。うち2社では、担当者の個人名を含む可能性があるメールアドレスが各1件含まれます。外部へ持ち出された痕跡は確認されていないとしています。セキュリティ対策Lab

顧客側の公表は続いています。 IDCフロンティアの判断は、顧客の仮想サーバー内のデータについてのものです。メール配信の委託先がこの基盤を使っていた企業は、漏えいの可能性を公表し続けています。

企業とサービス 公表日 対象件数 対象の情報 公表時の状況
JR東海:通販サイト「JR東海MARKET」「いいもの探訪」 10月13日 約1万5,000件 メールアドレスと、メール本文に記載された氏名、住所、電話番号、注文内容、配送先など 閲覧された可能性を否定できない。漏えいは未確認。個人情報保護委員会に報告し、別の環境でのメール配信に切り替え
マウスコンピューター:メールマガジン 10月14日 約42万件 メールアドレスと配信記録 調査中。漏えいは未確認
イズミ:「ゆめオンライン」「ゆめデリバリー」の会員 10月14日 最大約40万件 氏名とメールアドレス 漏えいや不正利用は未確認。住所、電話番号、カード番号は含まない

JR東海は、クレジットカード情報とログインパスワードは対象外としています。10月9日の各社の公表と同じく、これらは調査上の上限で、漏えいの確定件数ではありません。

読者にとっての意味。 IDCFクラウドの利用者なら、自社が194の顧客と48社に含まれるかをIDCフロンティアに確認してください(下の防御側の視点を参照)。委託先が自社の顧客にメールを送っているなら、問うべきは「IDCFクラウドを使っていたか」だけではありません。「配信サーバーに何を、どれだけの期間残していたか」です。

IDCフロンティアが公表した内容

IDCフロンティアは、ソフトバンクのクラウド・データセンター子会社です。これまでに5回の報告を公表しています。第3報

  • 10月7日午前3時40分頃。 東日本リージョン1で障害が発生しました。毎日新聞によると、監視アラートで検知しています。毎日新聞 IDCフロンティアは第4報で、9時に緊急対策本部を設置したとしています。同日、障害について最初の報告を出しました。第1報
  • 10月7日、第2報。 原因は第三者による不正アクセス、ランサムウェア攻撃と判明しました。第2報 同日、東日本リージョン1をネットワークから遮断し、顧客向けの管理コンソールを停止しました。
  • 10月8日、第3報。 東日本リージョン1の4ゾーン(tesla、henry、pascal、joule)で仮想サーバーが停止し、再起動できない状態です。影響は495の企業・自治体です。IDCフロンティアは、これらのゾーンに保管された顧客データの取り出しや復元は困難な見通しだとしています。現時点の見解では、復元できるのは顧客自身が保持するバックアップからのみで、別環境での再構築を案内しています。侵入経路は、外部のセキュリティ専門企業と東日本・西日本の両リージョンにわたって調査中です。監督省庁と警視庁に報告しています。
  • 10月9日、第4報。 顧客の窓口はソフトバンクの法人部門に移り、ソフトバンクの技術部門がIDCフロンティアの技術部門と共同で対応しています。第4報
  • 10月14日、第5報。 スナップショットを使っていた194の顧客でバックアップデータを取り出せる、4ゾーンの顧客のサーバー内のデータが照会・持ち出された痕跡はない、ポータルで48社の登録情報が照会された、という内容です。上の10月15日の更新を参照してください。第5報
サーバーの場所 第3報での状況 顧客への案内
東日本リージョン1:tesla、henry、pascal、jouleゾーン 仮想サーバーが停止し再起動不可。データの取り出し・復元は困難 別環境で再構築し、自社のバックアップから復元
東日本リージョン1:radian、newtonゾーン、東日本リージョン2・3、西日本リージョン1 不正アクセスは未確認。顧客向けコンソールは停止 今すぐ自社でバックアップを取得。仮想サーバーの起動・停止はIDCフロンティアが代行
IDCFクラウド TypeS(旧ホワイトクラウド ASPIRE)、IDCF プライベートクラウド 本事象の対象外 案内なし

日本経済新聞によると、影響を受けたのは福島県白河市のデータセンターで、茨城県のホームページなども閲覧できなくなりました。日本経済新聞

2026年10月7日から14日までを2段で示した時系列。IDCフロンティア側:7日午前3時40分頃に障害発生、9時に緊急対策本部、第2報でランサムウェアと判明、東日本リージョン1を遮断しコンソールを停止。8日の第3報でtesla、henry、pascal、jouleの4ゾーン、495の顧客、データ復元は困難と公表。9日の第4報でソフトバンクの支援を追加し、ITmediaが管理コンソールに表示された攻撃者のメッセージを報道。10日、VMware ESXiが被害を受けたこと、バックアップデータは残るがまだ使えないことを説明。14日の第5報で、194の顧客のバックアップを取り出せること、顧客のサーバー内のデータが照会・持ち出された痕跡がないこと、ポータルで48社の登録情報が照会されたことを公表。顧客側:7日に日水物流が入出荷を停止。8日21時までにMovable Type クラウド版が31台を別のクラウドへ移行。9日にJR東日本、ビューカード、JR九州、Peach、高島屋がメール配信に関する公表。13日と14日にJR東海、マウスコンピューター、イズミが続いた。

図1:8日間の公表の流れ(10月15日に更新)。この記事のために作成した図です。

攻撃者の主張

ITmediaは10月9日、東日本リージョンの管理コンソールに攻撃者のメッセージが表示されたと報じました。ITmedia NEWS その中で攻撃者は、次のように主張しています。

  • 東日本リージョン1全体を7分で暗号化し、7時間たっても運用者は気づいていなかった。
  • 239台のハイパーバイザー、225のデータストア、1万6,600以上の仮想マシンのディスク、計3.6PBを暗号化した。
  • 55万4,153個のスナップショットと41.5PBのバックアップ容量を破壊した。

メッセージは運用者に、VMware ESXiのホストに接続してファイルを読むよう指示しています。IDCフロンティアはITmediaに対し、コンソールに表示されたものと一致する画像を複数確認しており、内容と数字を調査中だと説明しています。

これらの数字はどれも確認されていません。ランサムウェアの攻撃者は、圧力を強めるために主張を誇張します。 IDCフロンティア自身の説明とも1点で食い違います。同社は、Yahoo!ニュースに寄稿する山口健太氏に対し、VMware ESXi上の仮想マシンが被害を受けたが、リージョン全体ではなく一部だと説明しました。また、同社のバックアップサービスには改ざんできないストレージのオプションがあり、バックアップデータは残っているものの、管理クラスターが停止しているため現在は使えないとしています。攻撃者が示したファイルを開いて安全かも確認中で、データ漏えいの可能性は完全には否定できないとしています。Yahoo!ニュース

「7分」が意味すること

数字が誇張だとしても、主張の形には意味があります。数百台のハイパーバイザーを数分で暗号化することは、1台ずつの手作業ではできません。管理基盤を一元的に握っている必要があります。vCenter、自動化用のアカウント、あるいはホスト間で共通のrootパスワードです。そのうえで、暗号化プログラムを一斉に動かします。つまりこれは、個々のサーバーのパッチの問題ではなく、インフラへの特権アクセスの問題です。

2023年以降に報告されてきたESXiを狙うランサムウェアも、同じ流れをたどっています。ドメインやvCenterの管理者アカウントを奪い、SSHを有効にし、仮想マシンを止め、スナップショットを消し、データストアを暗号化します。Microsoft:ESXiの脆弱性を悪用した大量暗号化(英語) バックアップを同じドメインから管理していれば、それも手の届く範囲にあります。

続いた各社の公表

495は影響を受けたIDCFクラウドの契約先の数で、データを失った組織の数ではありません。この節は10月7日から12日までの公表を扱います。10月13日と14日にはJR東海、マウスコンピューター、イズミが続きました(10月15日の更新を参照)。顧客の多くは他社向けのサービスを運営しているため、障害とデータの問題はもう一段先まで広がりました。

メール配信サービス。 10月9日、複数の大手消費者向けブランドが、会員へのメール配信に使う外部サービスがIDCFクラウド上にあり、メールアドレスを含むメールログが閲覧または取得された可能性があると公表しました。

2026年10月9日に公表された、IDCFクラウド上のメール配信サービスに関する5件の対象件数を示す横棒グラフ。ビューカード(VIEW's NET):メールアドレス約403万件。Peach Aviation(旅程表メール):約189万件を調査中、外部流出は未確認。JR東日本(えきねっと):メールアドレス最大約167万件。JR九州(Web会員):メールアドレス最大約130万件。JR東日本(大人の休日倶楽部):メールアドレス、会員番号、カード有効期限、生年月日の最大約39万件。Peachの棒は漏えいを記載していないため斜線、ほかは漏えいの可能性を否定できないとしているもの。件数は重複があり合算できない。

図2:5つのメール配信サービスの対象件数。この記事のために作成した図です。

会社とサービス 対象件数 記載された情報 公表時点の状況
ビューカード:VIEW's NET 約403万件 メールアドレス 閲覧・取得の可能性
Peach Aviation:旅程表メール 約189万件 メールアドレス、氏名(アルファベット)、電話番号、予約番号、旅程 調査中、外部流出は未確認
JR東日本:えきねっと 最大約167万件 メールアドレス 閲覧・取得の可能性
JR九州:Web会員 最大約130万件 メールアドレス 閲覧・取得の可能性
JR東日本:大人の休日倶楽部 最大約39万件 メールアドレス、会員番号、クレジットカード有効期限、生年月日 閲覧・取得の可能性
高島屋:3つの通販サイトのメールマガジン 記載なし メールアドレス、氏名、生年月日、郵便番号、市区郡までの住所 メルマガを停止、流出は未確認

JR東日本、ビューカード、JR九州は、氏名、住所、電話番号、クレジットカード番号は対象外で、対象の会員にはメールで知らせるとしています。Peachは、カード情報とパスポート情報はサーバーに保存していなかったとしています。これらは各社が別々に示した調査上の上限です。1人が複数に含まれることがあるため、合算はできません。

EC基盤のフューチャーショップは、送信サーバーに何があるかを説明しています。IDCFクラウド上の同社のメール送信サーバーには、宛先のメールアドレス、送信元の情報、メール本文の一部が保存されており、本文には氏名、誕生日、会員IDが含まれることがあります。データは保存時に暗号化され、送信から14日で自動削除される設計だとしています。自社のメール配信事業者にも、同じことを確認すべきです。セキュリティ対策Lab(まとめ)

業務。 データではなくサービスを失った組織もあります。どれだけ早く戻れたかは、バックアップがどこにあったかで決まりました。

組織 止まったもの 報じられた復旧状況
日水物流(ニッスイグループ) 商品の入出荷システム 10月9日に一部再開。ニッスイは、被害サーバーに個人情報や顧客情報はなかったとしています
Movable Type クラウド版 31台の管理画面と公開サイト 10月8日21時までに全31台をさくらのクラウドへ移行。Google Cloudに保管していた10月7日1時時点のバックアップを使用
グリニッジ(らくらく在庫) 在庫管理や価格更新のツール 10月9日に別のクラウドで再開。復旧したデータは8月30日時点
Soliton SecureDesktop サービスの一部 同じ基盤上のバックアップサーバーも使えず、別環境で再構築中
UDトーク トークの公開機能や管理ツール 公開トークのQRコード情報と管理ツールの設定を喪失
THE SURF NEWS ニュースサイト 10月9日に閲覧を再開したが、直近の記事が欠損
サイバー大学 履修登録や授業料の支払い 退避していたバックアップからの別基盤での再構築を検討

ほかにIDCFクラウドとの関係を明らかにした組織には、ポピンズ、ファイバーゲート、ノバシステムの顔認証入退室管理、メディアリンクのクラウド電話サービス、SKE48 MailとNMB48 Mail、メディウェル、ブロッコリー、ジェイック、オートサーバーのコーポレートサイト、滋賀県(委託先経由)、湖西市立図書館があります。はてなは予防措置としてMackerelのIDCFクラウド連携を一時停止しました。小平市は、ホームページの保守委託先が使うクラウド基盤へのランサムウェア攻撃を公表しましたが、事業者名は明らかにしていません。セキュリティ対策Lab(まとめ)

構図ははっきりしています。Movable Typeは、バックアップを別の事業者に置いていたので1日で戻れました。Solitonは、バックアップサーバーが同じ基盤にあったので戻れませんでした。グリニッジは、5週間前のデータで戻りました。

攻撃者の視点:この事案で何ができるか

攻撃者は特定されておらず、侵入経路も公表されていません。以下は、ホスティング基盤のハイパーバイザーを止めるためにレッドチームが取る手順で、MITRE ATT&CKに対応づけています。今回の攻撃を再現したものではありません。

段階 考えられること ATT&CK
侵入する 盗んだ認証情報でVPNやリモートアクセス機器に入る。vCenterなどの機器の脆弱性を突く。委託先のアクセスを使う T1133 External Remote Services; T1190 Exploit Public-Facing Application; T1078 Valid Accounts
管理基盤を握る ドメイン管理者からvCenter管理者へ。ドメイン参加したESXiが管理者として信頼するディレクトリのグループを使う。ホスト間で使い回されたrootパスワードを使う T1078.002 Domain Accounts; T1098 Account Manipulation
ハイパーバイザーに入る SSHやESXi Shellを有効にし、全ホストに一斉にログインする T1021.004 SSH; T1059.004 Unix Shell
防御側の目をふさぐ execInstalledOnlyを無効にし、syslogの転送先を変えるか止め、ホストのファイアウォールを開ける T1562.001 Disable or Modify Tools; T1562.004 Disable or Modify System Firewall
仮想マシンを止める ディスクファイルを暗号化できるよう、仮想マシンのプロセスを強制終了する T1489 Service Stop
復旧手段を消す スナップショットを削除し、同じドメインから管理するバックアップを消すか暗号化する T1490 Inhibit System Recovery
暗号化する すべてのデータストアのディスクファイルに対し、暗号化プログラムを並行して動かす T1486 Data Encrypted for Impact
知らせる 管理コンソールやホストのウェルカム画面に身代金のメッセージを出す T1491.001 Internal Defacement
圧力を加える 暗号化の前に仮想マシンやメールサーバーからデータを持ち出し、公開をちらつかせる T1005 Data from Local System; T1567 Exfiltration Over Web Service

損得は攻撃者に有利です。管理基盤を1度破れば数百の利用者に届き、各利用者の復旧は、事業者が代わりに決められない選択にかかっています。

二次的なリスクもあります。各社の公表に出てくるメールアドレスは、毎週使う鉄道、カード、航空のブランドに結びついています。「ご予約について」「カードご利用明細」「旅程が変更されました」は今月なら信じられやすい誘い文句で、しかも同じブランドから本物の案内が同時期に届きます(T1566 Phishing)。

防御側の視点

1. IDCFクラウドを使っているなら

  • IDCフロンティアから別の案内がない限り、4ゾーンのサーバーは失われたものとして扱う。 IDCフロンティアの案内どおり、別環境でクリーンなイメージから再構築してください。スナップショットのデータを取り出せる194の顧客に含まれる場合も、そのデータは信頼できないものとして扱い、取得日時を確かめ、スキャンし、まず隔離したネットワークに戻してください。
  • それでも、そのサーバー上の秘密情報は変更する。 IDCフロンティアはサーバー内のデータが照会・持ち出された痕跡はないとしていますが、攻撃者はサーバーが動くハイパーバイザーを掌握していました。そこにあったものはすべて変更してください。データベースのパスワード、APIキー、クラウドのアクセスキー、SSH鍵、TLSの秘密鍵、自社に接続するサービスアカウントです。
  • 個人データの判断を早めに。 個人情報保護法の規則では、攻撃による漏えい、滅失、毀損は、確定していなくても、そのおそれがあれば個人情報保護委員会への報告が求められます。サーバー上にあったものに当てはまるかは、専門家に確認してください。
  • ほかのゾーンやリージョンでは、 今すぐデータを基盤の外にコピーし、コンソールがしばらく使えない前提で計画してください。
  • IDCフロンティアに具体的に確認する。 自社のサーバーのディスクが暗号化されたか、スナップショットを取り出せる194の顧客に含まれるか、データへのアクセスの兆候、時間帯を尋ね、記録を残してください。
  • ポータルのアカウントは漏れた前提に立つ。 登録情報を照会された48社に含まれるかを確認してください。いずれにしても、ポータルのパスワードと、同じパスワードを使い回した箇所を変更し、通知先メールアドレスへのフィッシングに備えてください。

2. 委託先がIDCFクラウドを使っているなら

  • すべての委託先に直接聞く。 SaaS事業者、メール配信サービス、Web制作会社、ホスティング事業者は、どこで動いているかを伝えていないことがあります。下の質問を使ってください。
  • メール配信から始める。 送信サーバーとログには、自社の顧客のアドレスとメール本文の一部があります。何を、どれだけの期間、どう暗号化して保存しているかを確認してください。
  • サービスの再開だけでなく、中身を確認する。 グリニッジとTHE SURF NEWSは、古いデータや欠けたデータで戻りました。最後のバックアップから障害までに失われたものを委託先に確認してください。
  • 委託先の侵害対応プレイブックで、委託先が被害を受けたときの契約、通知、証拠の手順をまとめています。

3. 自社でVMware ESXiとvCenterを運用しているなら

多くの読者に当てはまる教訓はここにあります。

  • 管理基盤を分ける。 ESXiの管理インターフェースとvCenterは専用のネットワークに置き、多要素認証付きの管理用踏み台サーバーからのみ到達できるようにしてください。現在どの端末が接続しているかは、下のクエリ2で分かります。
  • ロックダウンモードを有効にし、SSHとESXi Shellは無効のままにする。 承認された作業のときだけ起動し、起動したら警報を出してください。
  • execInstalledOnlyを強制する。 ホストがインストール済みの署名付きコードしか実行しないようにします。TPMのあるホストでは、ホストの暗号化設定で強制し、シェルから簡単に無効にできないようにしてください。
  • ディレクトリにハイパーバイザーを握らせない。 できる限りESXiをActive Directoryから外してください。外せない場合は、CVE-2024-37085で悪用された既定の管理者グループの動作を変えてください。rootパスワードはホストごとに変え、パスワード保管庫で管理してください。
  • vCenterとESXiのパッチを早く当てる。 攻撃者はこれらの機器の脆弱性を探しています。
  • ESXiとvCenterのログはホストの外のSIEMへ送る。 証拠がホストにしかなければ、ホストと一緒に暗号化されます。
  • バックアップを1つは被害範囲の外に置く。 別の事業者かリージョン、別の管理者ID、改ざん不可またはオフラインで保管してください。全体の復元を試し、時間を測ってください。Movable TypeとSolitonの差がそれを示しています。

4. 暗号化だけでなく、その前段を見つける

  • 各段階で警報を出す。 SSHやESXi Shellの有効化、execInstalledOnlyの変更、syslog設定の変更、ホストのファイアウォールの変更、新しいローカルアカウント、/tmpやデータストア上のファイルへの実行権限の付与、ウェルカムメッセージの変更です。
  • 1台ではなく全体を見る。 10分以内に多数のホストで同じ破壊的なコマンドが出たら、保守作業ではなくランサムウェアの実行です。クエリ1は時間帯ごとのホスト数を数えます。
  • 数分で多数の仮想マシンが停止・強制終了されたこと、 スナップショットがまとめて削除されたことにも注意してください。

5. これらのブランドを装うフィッシングに従業員を備えさせる

  • ルールを1つ伝える。 JR東日本、ビューカード、JR九州は、対象の会員にメールで知らせるとしています。それでも、この件に関するメッセージのリンクには従わず、公式アプリを開くかアドレスを自分で入力してください。
  • 下のメールのクエリを実行し、 確認できたなりすましドメインは見直し日を決めて遮断してください。
  • クリックしてしまった場合の対応はフィッシング対応プレイブックに、自社での封じ込めと復旧の判断はランサムウェア対応プレイブックにまとめています。

6. 対応すべきチーム

チーム 確認する範囲 次の一手 必要な証跡
IT運用 自社のESXiとvCenter、IDCFクラウドの利用 下のインフラ確認を実施し、データを基盤の外にコピー ホストごとの確認結果、バックアップの場所と復元時間
EDR / SOC 管理基盤に到達できる端末 クエリ1と2を実行し、SSHの有効化と仮想マシンの一斉停止に警報 クエリの実行計画、警報の通知先
SIEM ESXiとvCenterのログ ログが届いていることを確認し、ハイパーバイザーのクエリを定期実行 ログソースの一覧、保存期間
委託先管理 委託先のホスティング事業者 委託先への質問を送り、IDCFクラウド上にある委託先を記録 書面の回答、影響を受けたサービス
メールセキュリティ 鉄道、カード、航空のブランドを装う誘い文句 メールのクエリを実行し、確認できたなりすましを遮断 メッセージの一覧、受信者、クリックの記録
法務 / プライバシー 影響を受けたサーバー上の個人データ(自社・委託先) 報告の要否を判断し、委託先から事実を集める データの一覧、判断の記録

ハンティング:自社のハイパーバイザーで何か動いていないか

侵害の痕跡(IOC)は公表されていません。 IDCフロンティアは、攻撃者のアドレス、ファイル名、ハッシュ値を公表していません。以下のクエリは、ハイパーバイザーを狙うランサムウェアに必要な手順を自社の環境で探し、影響を受けたブランドを装う誘い文句をメールで探します。

いずれも例示であり、実データでは実行していません。 テーブル名とフィールド名は、2026年10月12日(日本時間)に各社のドキュメントで確認しました。ノイズに注意してください。保守作業でもSSHを有効にし、仮想マシンを停止するため、一致したものは変更記録と照らし合わせてください。

1. ESXiホスト:シェルの有効化、保護の変更、仮想マシンの強制終了、スナップショットの削除。 Microsoft Sentinelで、ESXiホストのsyslogをSyslogテーブルに送っている前提です。

// Illustrative; not run against live data. Microsoft Sentinel, Syslog table fed by your ESXi hosts.
// Shell access switched on, protections changed, VMs killed and snapshots removed: the steps hypervisor ransomware needs.
// HostsInWindow counts how many hosts did any of this in the same 10 minutes. Many hosts at once is a ransomware run, not maintenance.
let Since = ago(14d);
let EsxiHosts = @"(?i)REPLACE_WITH_ESXI_HOSTNAME_PATTERN";
let Risky = @"(?i)(execInstalledOnly|esxcli\s+vm\s+process\s+(list|kill)|vim-cmd\s+vmsvc/(getallvms|power\.off|power\.shutdown|snapshot\.removeall|snapshot\.remove)|vim-cmd\s+hostsvc/(enable_ssh|start_ssh|enable_esx_shell|start_esx_shell)|esxcli\s+system\s+(syslog\s+config\s+set|account\s+(add|set)|permission\s+set|welcomemsg\s+set)|esxcli\s+network\s+firewall\s+set|chmod\s+\+?[0-7x]+\s+/(tmp|vmfs/volumes)/|SSH access has been enabled|ESXi Shell access has been enabled)";
let Hits = Syslog
    | where TimeGenerated > Since
    | extend Host = coalesce(HostName, Computer)
    | where Host matches regex EsxiHosts
    | where SyslogMessage matches regex Risky
    | extend Window = bin(TimeGenerated, 10m), Action = tolower(extract(Risky, 1, SyslogMessage));
Hits
| summarize Events = count(), Actions = make_set(Action, 20), Samples = make_set(SyslogMessage, 5),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Host, Window
| join kind=inner (Hits | summarize HostsInWindow = dcount(Host) by Window) on Window
| project-away Window1
| order by HostsInWindow desc, FirstSeen asc
| take 500

2. ハイパーバイザーの管理インターフェースに到達している端末。 Microsoft Defender XDRの高度なハンティング。管理用踏み台サーバー以外で、SSH、Web、コンソールのポートでESXiやvCenterに接続している端末を探します。

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Which devices open SSH, web-client or console sessions to your ESXi hosts and vCenter?
// Only admin jump hosts should. Every other device in the result is a path an attacker could use to reach the hypervisors.
let Since = ago(30d);
let ManagementSubnet = "REPLACE_WITH_MANAGEMENT_SUBNET_CIDR";
let JumpHosts = dynamic(["REPLACE_WITH_ADMIN_JUMP_HOST_1", "REPLACE_WITH_ADMIN_JUMP_HOST_2"]);
DeviceNetworkEvents
| where Timestamp > Since
| where ActionType in ("ConnectionSuccess", "ConnectionAttempt")
| where RemotePort in (22, 443, 902, 5480, 9443)
| where ipv4_is_in_range(RemoteIP, ManagementSubnet)
| where not(DeviceName in~ (JumpHosts))
| summarize Connections = count(), Ports = make_set(RemotePort), Processes = make_set(InitiatingProcessFileName, 10),
    Accounts = make_set(InitiatingProcessAccountName, 10), FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by DeviceName, RemoteIP
| order by Connections desc
| take 500

3. 影響を受けたブランドを名乗る他ドメインからの受信メール。 Microsoft Defender XDRの高度なハンティング。Defender for Office 365が必要です。

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Inbound mail since 9 Oct 2026 that names the brands whose mail-delivery services were affected, but was not sent from their domains.
// JR East, View Card and JR Kyushu say they will email affected members, so genuine notices will arrive too. Check a genuine message's headers before adding a sender domain.
let Since = datetime(2026-10-09T00:00:00Z);
let LurePattern = @"(?i)えきねっと|大人の休日倶楽部|ビューカード|view'?s ?net|jr東日本|jr九州|peach aviation|ピーチ|高島屋|takashimaya|idcf|idcフロンティア";
let OfficialDomains = @"(?i)(^|\.)(jreast\.co\.jp|eki-net\.com|jrkyushu\.co\.jp|flypeach\.com|takashimaya\.co\.jp|idcf\.jp|REPLACE_WITH_OTHER_VERIFIED_SENDER_DOMAIN)$";
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where Subject matches regex LurePattern or SenderDisplayName matches regex LurePattern
| where not(SenderFromDomain matches regex OfficialDomains)
| join kind=leftouter (
    EmailUrlInfo
    | where Timestamp > Since
    | project NetworkMessageId, UrlDomain
    ) on NetworkMessageId
| summarize Recipients = dcount(RecipientEmailAddress), UrlDomains = make_set(UrlDomain, 10),
    FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| order by FirstSeen asc
| take 500

4. ハイパーバイザーの確認をSplunkで。 ESXiのsyslogが前提です。インデックスとホスト名のパターンを置き換えてください。

index="REPLACE_WITH_ESXI_SYSLOG_INDEX" host="REPLACE_WITH_ESXI_HOSTNAME_PATTERN" earliest=-14d
| regex _raw="(?i)(execInstalledOnly|esxcli\s+vm\s+process\s+(list|kill)|vim-cmd\s+vmsvc/(getallvms|power\.off|power\.shutdown|snapshot\.removeall|snapshot\.remove)|vim-cmd\s+hostsvc/(enable_ssh|start_ssh|enable_esx_shell|start_esx_shell)|esxcli\s+system\s+(syslog\s+config\s+set|account\s+(add|set)|permission\s+set|welcomemsg\s+set)|esxcli\s+network\s+firewall\s+set|chmod\s+\+?[0-7x]+\s+/(tmp|vmfs/volumes)/|SSH access has been enabled|ESXi Shell access has been enabled)"
| rex field=_raw "(?i)(?<action>execInstalledOnly|esxcli\s+\S+\s+\S+\s+\S+|vim-cmd\s+\S+|chmod\s+\S+\s+\S+|SSH access has been enabled|ESXi Shell access has been enabled)"
| bin _time span=10m
| stats count AS events values(action) AS actions BY _time host
| eventstats dc(host) AS hosts_in_window BY _time
| sort 0 - hosts_in_window _time

ダウンロード:ハイパーバイザーのKQL · 管理アクセスのKQL · メールのKQL · ハイパーバイザーのSPL

その他のプラットフォーム。 Sumo Logicで、ESXiのsyslogから同じ破壊的な手順を、ホストごと10分単位で数えます。

_sourceCategory="REPLACE_WITH_ESXI_SYSLOG_SOURCE_CATEGORY" ("esxcli" OR "vim-cmd" OR "execInstalledOnly" OR "SSH access has been enabled" OR "ESXi Shell access has been enabled")
| parse regex "(?i)(?<action>execInstalledOnly|esxcli\s+vm\s+process\s+kill|vim-cmd\s+vmsvc/(?:power\.off|snapshot\.removeall|getallvms)|vim-cmd\s+hostsvc/(?:enable_ssh|enable_esx_shell)|esxcli\s+system\s+(?:syslog\s+config\s+set|welcomemsg\s+set|account\s+add)|esxcli\s+network\s+firewall\s+set|SSH access has been enabled|ESXi Shell access has been enabled)"
| timeslice 10m
| count by _timeslice, _sourceHost, action
| sort by _timeslice asc

CrowdStrike Falcon(LogScale / Next-Gen SIEM)で、管理用サブネットにSSH、Web、コンソールの接続をしている端末を見ます。踏み台サーバーのエージェントIDは除外してください。

#event_simpleName=NetworkConnectIP4
| in(field="RemotePort", values=["22", "443", "902", "5480", "9443"])
| cidr(field="RemoteAddressIP4", subnet="REPLACE_WITH_MANAGEMENT_SUBNET_CIDR")
| groupBy([aid, RemoteAddressIP4, RemotePort], function=count())

結果がなくても、何も起きていない証明にはなりません。ESXiホストがログを転送していなければ、証拠は暗号化されるホストの上にしかなく、個人アドレスへのメールは会社のツールからは見えません。Syslogテーブル(英語) · DeviceNetworkEvents(英語) · EmailEvents(英語)

コピーして使えるテンプレート

[ ]内をすべて置き換えてください。社外に出すものは、法務またはプライバシー担当の確認を受けてください。

委託先への質問

件名:[会社名]―貴社サービスのIDCFクラウド利用の有無について

[ご担当者様]
IDCフロンティアは2026年10月8日、ランサムウェアによりIDCFクラウド東日本リージョン1の4ゾーンで仮想サーバーが停止し、データの復元が困難な見通しだと公表しました。以下について[期日]までに書面でご回答ください。
1. 当社に提供いただいているサービス(アプリケーション、データベース、メール配信、バックアップ、ログ、DNS、Webホスティング)の一部でも、IDCFクラウド上で動いていますか。その場合、どのリージョンとゾーンですか。
2. 当社のデータ、または当社の顧客のデータのうち、ログやメールの送信待ちを含め、どれがそこに保存されていますか。
3. そのうちtesla、henry、pascal、jouleの各ゾーンにあったものはありますか。現在サービスに影響はありますか。
4. そのデータのバックアップはどこにありますか。同じ事業者、同じリージョン、同じ管理者アカウントの下ですか。全体の復元を最後に試したのはいつで、何時間かかりましたか。
5. 貴社またはIDCフロンティアの調査で、データが閲覧またはコピーされた証拠は見つかっていますか。いつ判明する見込みですか。
6. メール配信について:送信サーバーとログには何(アドレス、送信元、件名、本文)を、どれだけの期間、どのように暗号化して保存していますか。
7. 当社のシステムに接続する認証情報や鍵のうち、影響を受けたサーバーに保存されていたものはどれで、変更は済んでいますか。
8. 復旧計画と見込みの日付を教えてください。最後のバックアップから10月7日までの間で、欠けるデータは何ですか。
9. 当社がお預けした個人データが漏えいした可能性がある場合、個人情報保護委員会への報告に必要な情報を、いつ、どの確認済みの経路でいただけますか。
よろしくお願いいたします。
[氏名、役職、部署]

インフラ担当への確認依頼

件名:ハイパーバイザーを狙うランサムウェアへの備え―ESXiとvCenterの確認(IDCFクラウドの事案を受けて)

背景:2026年10月7日、ランサムウェアによりIDCFクラウド(VMware ESXi)の仮想サーバーが停止し、495の顧客に影響しました。攻撃者は239台のホストを7分で暗号化したと主張しています。未確認ですが、管理基盤を一元的に握られた状態を示しています。[期日]までに当社の環境を確認し、項目ごとに証跡を残してください。
1. 一覧:すべてのESXiホストとvCenterの、バージョン、ビルド、最後にパッチを当てた日。
2. 管理ネットワーク:管理インターフェースとvCenterに到達できるのは管理用ネットワークか踏み台サーバーだけか。過去30日にそれ以外から接続した端末の一覧(クエリ2)。
3. ロックダウンモードが有効で、SSHとESXi Shellは停止かつ手動起動の設定。どちらかが起動したら警報。
4. すべてのホストでexecInstalledOnlyを強制。TPMがあるホストは暗号化設定で強制。
5. Active Directory:ドメイン参加しているホスト、完全な管理者権限を与えるグループ、CVE-2024-37085の動作への対策の有無。
6. rootパスワードはホストごとに異なり、パスワード保管庫で管理。vCenterの管理者は多要素認証で保護。
7. ESXiとvCenterのログをSIEMへ転送し、クエリ1と4を定期実行。
8. バックアップ:少なくとも1つは、このvCenterの管理範囲の外に、改ざん不可またはオフラインで、別の認証情報の下に保管。全体の復元を最後に試した日と所要時間。
9. スナップショット:スナップショットを唯一のバックアップにしているシステムがないこと。
担当:[氏名] 期日:[日付] 報告先:[セキュリティ担当]

従業員への案内

件名:JR東日本、ビューカード、JR九州、Peachを装う偽の連絡にご注意ください

クラウドサービスへのサイバー攻撃を受け、JR東日本(えきねっと、大人の休日倶楽部)、ビューカード(VIEW's NET)、JR九州は2026年10月9日、会員のメールアドレスが見られた可能性があると公表しました。Peachは旅程表メールに関連する約189万件を調査しています。
・各社は対象の会員にメールで知らせるとしています。それでも、この件に関するメッセージのリンクはクリックせず、公式アプリを開くかアドレスを自分で入力してください。
・予約、返金、カードの利用明細、ポイント、「アカウントの確認」などを名乗る偽のメッセージが予想されます。これらの会社がメールでパスワードやカード番号を尋ねることはありません。
・会社のメールボックスに届いた場合は、[報告ボタンまたは報告先]で報告してください。同僚に転送しないでください。
・これらのサービスに会社のメールアドレスを登録している場合、本物の案内が会社に届くことがあります。
問い合わせ先:[セキュリティ担当]

経営層向け5行報告

1. 何が起きたか:2026年10月7日、ランサムウェアによりIDCFクラウド(IDCフロンティア、ソフトバンクグループ)の4ゾーンで仮想サーバーが停止し、495の企業・自治体に影響。10月14日、IDCフロンティアは194の顧客でバックアップを取り出せること、顧客のサーバー内のデータが外部に出た痕跡はないことを公表。ポータルでは48社の登録情報が照会された。基盤上のメール配信サービスを通じ、JR東日本、ビューカード、JR九州、JR東海、マウスコンピューター、イズミが顧客情報が見られた可能性を公表。
2. 当社への直接の影響:IDCFクラウドを[利用している/利用していない]。[システム、リージョン、ゾーン]。
3. 委託先を通じた影響:[数]社に確認、[数]社がIDCFクラウド上と回答、影響を受けたサービス:[一覧]。
4. 当社の基盤:ESXiとvCenterの確認[完了/期日]、管理範囲の外のバックアップ[あり/なし]、全体の復元テスト[日付、所要時間]。
5. 判断が必要な事項:[例:基盤の外へのバックアップの予算化、委託先にホスティング事業者の開示を求める、従業員へのフィッシング注意喚起]。次回報告:[時刻]。

まだ分かっていないこと

  • 攻撃者がどうやって、いつ侵入したか。 リモートアクセス機器、機器の脆弱性、盗まれた管理者の認証情報、委託先のどれかは公表されていません。
  • 攻撃者の数字が正しいか。 7分、239台のハイパーバイザー、3.6PB、破壊されたスナップショットとバックアップです。
  • メールシステムからデータがコピーされたか。 IDCフロンティアは4ゾーンの顧客のサーバー内のデータについて痕跡はないとしましたが、メール配信の委託先がこの基盤を使っていた企業は、漏えいの可能性を否定できないとしています。ほかのゾーンとリージョンの確認は続いています。
  • 取り出せるようになった194の顧客のスナップショットから、システムを復元できるか。 ほかの顧客が何を取り戻せるか、管理クラスターとコンソールがいつ戻るか。
  • ほかのゾーンやリージョンにも手が及んだか。 調査は東日本と西日本の両方にわたっています。
  • 攻撃者は誰か、 身代金の要求が公開されるか。
  • 495の顧客のうち、どれだけが個人データを持っていたか、 これからいくつ公表が続くか。

出典と更新履歴

この事案は、国内の侵害公表60日分のまとめにも掲載しています。

2026年10月15日13時15分頃: IDCフロンティアの第5報(10月14日。194の顧客でバックアップを取り出せる、顧客のサーバー内のデータが外部に出た痕跡はない、ポータルで48社の登録情報が照会された)と、JR東海、マウスコンピューター、イズミの公表を追加しました。曜日の誤りもあった図1を更新しました。防御側の視点、経営層向け報告のテンプレート、まだ分かっていないことも第5報に合わせて改めました。出典は10月15日(日本時間)に報道と検索結果を通じて確認しました。各社のページを直接開くことはできませんでした。

2026年10月12日: 初版を公開しました。IDCフロンティアの報告と各社の公表は、10月12日午前(日本時間)に確認しました。IDCフロンティアが次の報告を出したら、この分析を更新します。

記事一覧へ →Read in English ↗