IDCF クラウドのランサムウェア被害｜利用者が確認すべき復旧の備え

はじめに

2026 年 10 月 7 日、IDC フロンティアは「IDCF クラウド」の一部システムが第三者から不正アクセスを受けたと公表し、同日の第 2 報で、東日本リージョン 1 の障害がランサムウェア攻撃によるものと明らかにしました。業務システムを同クラウドで運用している組織にとっては、自社のデータを戻せるのか、漏えいのおそれはないのかを早急に判断する必要があります。

一方で、具体的な侵入経路や、スナップショット・バックアップの残存状況はまだ公表されていません。本記事では、公式発表で確認できる事実と未確認の主張を分けたうえで、仮想化基盤の管理権限が奪われる一般的な経路、イミュータブルの保護範囲、漏えいと復旧の違いを整理し、利用者が確認すべき項目を表にまとめます。

結論として、IDC フロンティアはランサムウェア攻撃を公式に認めていますが、侵入経路、悪用された脆弱性、データの持ち出しの有無は 10 月 7 日時点で公表されていません。利用者は原因の推測より先に、自社の対象リソース、残存する復元ポイント、復元に必要な鍵と権限を確認し、事業者への質問を整理することが重要です。確認項目は、後半の「クラウド利用者が確認する項目と事業者への質問」で表にまとめています。

本記事は、2026 年 10 月 7 日 21 時 59 分（日本時間）時点で確認した公式発表（第 2 報まで）に基づきます。続報が公表された場合は、本記事に追記して更新します。

IDCF クラウドの被害で判明していること

公式発表は同日中に 2 回出ており、第 1 報の「不正アクセスによる一部障害」から、第 2 報で「ランサムウェア攻撃」へ更新されています。ここでは、確認済みの事実、予防的な措置、未公表の事項を分けて整理します。

第 1 報から第 2 報で更新された内容

第 1 報は、10 月 7 日午前 3 時 40 分頃から東日本第 1 リージョンで障害が発生しているとし、原因を第三者からの不正アクセスとしていました。第 2 報では、障害が同時刻頃から継続中であること、原因が第三者からのランサムウェア攻撃であることが明記され、影響範囲として IDCF クラウドを契約している 495 の企業や自治体が挙げられています。対象の顧客には個別に連絡しているとしています。

参考: IDC フロンティア「【第2報】当社サービスの一部システムに対する不正アクセスについて」
「第三者からのランサムウェア攻撃によるものであることが判明しました」
https://www.idcf.jp/news/topics/20261007002

確認済みの事実と未公表の事項を分ける

第 2 報の記載を、被害が確認された範囲、予防的な措置、調査中・未公表の事項に分けると次のとおりです。

区分	内容（第 2 報時点）	読み方の注意
被害が確認された範囲	東日本リージョン 1 の障害がランサムウェア攻撃によるもの。影響範囲は IDCF クラウドを契約する 495 の企業や自治体	自社が対象かは、個別連絡と問い合わせで確認する
完了した対応	二次被害やデータ漏えいを防ぐため、東日本リージョン 1 をネットワークから遮断し、システムを停止	遮断は防止のための措置であり、漏えいがなかった証拠ではない
予防的な停止	東日本リージョン 1 以外で、利用者が外部からアクセスできる管理コンソールを安全性確認のため停止	他リージョンで暗号化が確認されたという意味ではない
調査中	侵入経路の特定と遮断、その他リージョンの安全性確認	原因や範囲は続報で変わる可能性がある
未公表	初期侵入経路、悪用された脆弱性、取得された管理権限、データの持ち出し、スナップショットやバックアップの残存状況、復旧時期	推測で補わず、続報を確認する

SNS 上では、攻撃者を名乗る画像で、ESXi / vCenter やデータストア、バックアップへの被害が主張されています。ただし、画像の真正性や個々の記載は確認できていません。ランサムウェアが公式に確認されたことは、画像の数値や主張まで裏付けるものではないため、本記事では画像の内容を根拠として扱いません。

なお、IDC フロンティアの FAQ では、IDCF クラウドのハイパーバイザーに VMware ESXi を採用していると説明しています（2026 年 7 月の更新時点で、東日本リージョン 1 は ESXi 6.7 または 8.0.3）。これは基盤製品に関する一般的な情報であり、今回攻撃された対象のバージョンやパッチの適用状況を示すものではありません。

ハイパーバイザーの管理権限はどう奪われるか

このセクションで扱う経路は、過去の実例や一般的に知られる攻撃パターンであり、今回の IDCF クラウドの原因を示すものではありません。今回の侵入経路は、10 月 7 日時点で公表されていません。

「ハイパーバイザーの管理権限を奪う」と聞くと、ハイパーバイザーのプログラムの脆弱性を直接突く攻撃を想像しがちです。実際には、正規の管理者の認証情報やセッションを盗み、正規の操作として基盤を操作する経路もあります。まず、仮想化基盤の「管理権限」が 1 つではないことを押さえます。

仮想化基盤の管理権限は 1 つではない

クラウド利用者のコンソール

利用者が自社の VM、ボリューム、スナップショット、ネットワークを操作する権限です。操作できる範囲は、契約したアカウント内に限られるのが一般的です。

vCenter などの管理サーバー

複数の ESXi ホストと VM を集中管理する権限です。管理下のホスト群にまたがって、VM の停止や削除、設定変更ができます。

ESXi ホスト

個々のホストと、その上で動く VM、ホストから見えるデータストアを操作する権限です。

ストレージ

VM のディスクを格納するストレージ装置や、スナップショットの保存領域を管理する権限です。

バックアップ管理

バックアップジョブ、保存先、保持期間、削除を管理する権限です。保存先が別のサービスであれば、認証も別になる場合があります。

攻撃による影響範囲は、どの権限を奪われたかで大きく変わります。基盤運用者の視点では、これらの権限を別のアカウント・別の認証で管理し、1 つの侵害ですべてに到達できない構成にすることが基本になります。

一般的な 4 つの経路と基盤運用者の防御策

仮想化基盤の管理権限に到達する一般的な経路と、それぞれに対応する防御策を整理します。

経路	必要な前提	基盤運用者の防御策
1. 管理者の資格情報・セッション・管理端末の侵害	フィッシングなどで管理者の認証情報やセッションを取得し、管理画面や管理端末へ到達できること	専用の管理端末、権限の分離、管理用の入口での MFA、セッション管理、操作の監査
2. vCenter / ESXi などの管理製品の脆弱性	攻撃者が管理インターフェースへ到達でき、脆弱性ごとの悪用条件を満たすこと	管理ネットワークの分離、接続元の限定、サポート対象バージョンへの更新、不要なサービスの停止
3. AD などの認証基盤からの横展開	ESXi が AD と連携しており、攻撃者が必要な AD 権限を持つこと	管理グループの保護と変更の監査、認証基盤の分離、修正の適用
4. ゲスト VM からホスト側への脱出	対象の脆弱性が存在し、その悪用条件を満たすこと。下記の例ではゲスト管理者権限などが前提	修正の適用、テナント間の隔離境界の維持

いずれも、クラウド事業者などの基盤運用者が講じる対策です。クラウド利用者が直接設定できるものではないため、利用者にとっては事業者の対策状況を確認する対象になります。

過去の実例: CVE-2024-37085 と VMSA-2025-0004

認証基盤からの横展開の実例として、Microsoft は 2024 年 7 月、複数のランサムウェア攻撃者が CVE-2024-37085 を悪用していたと報告しています。AD ドメインに参加した ESXi が、ESX Admins という名前のドメイングループのメンバーを既定でフル管理者として扱う問題で、攻撃者はこのグループを作成して自分の管理下のアカウントを追加し、ESXi の管理権限を得ていました。

前提は、ESXi が AD に参加していること、そして攻撃者がドメイン内でグループを作成・変更できる権限を持っていることです。報告された事例でも、攻撃者はドメイン管理者の認証情報を窃取した後にこの手法を使っています。通常のゲスト VM を侵害しただけで成立する攻撃ではありません。

参考: Microsoft Threat Intelligence「Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption」
“a domain group whose members are granted full administrative access”
（メンバーにフル管理者権限が付与されるドメイングループ）
https://www.microsoft.com/en-us/security/blog/2024/07/29/ransomware-operators-exploit-esxi-hypervisor-vulnerability-for-mass-encryption/

ゲスト VM からホスト側への脱出については、Broadcom が 2025 年 3 月に公開した VMSA-2025-0004 が参考になります。CVE-2025-22224 は、VM 内でローカル管理者権限を持つ攻撃者が、ホスト上で動作する VMX プロセスとしてコードを実行できる脆弱性です。CVE-2025-22225 は、VMX プロセス内の権限を持つ攻撃者がカーネルへの任意の書き込みを行い、サンドボックスから脱出できる脆弱性です。Broadcom は、いずれも悪用を示唆する情報があるとしています。

参考: Broadcom「VMSA-2025-0004」
“A malicious actor with local administrative privileges on a virtual machine”
（仮想マシン上でローカル管理者権限を持つ攻撃者）
https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/25390

ゲストの root / Administrator 権限だけで、ホストの管理権限を得られるわけではありません。この例では、ゲストから VMX プロセス内への到達と、そこからのサンドボックス脱出という段階を区別して考えます。修正版の適用と、テナント間の隔離境界の維持が対策の中心です。

ゲスト内の EDR だけでは基盤への攻撃を防げない理由

ハイパーバイザー側から仮想ディスクやデータストアが暗号化される場合、処理はゲスト OS の外側で行われます。ゲスト内の AV / EDR のエージェントだけでは、ホスト側の操作を直接監視・防止できるとは限らないため、こうした攻撃をゲスト側の対策だけで防げるとはいえません。Microsoft も前述の報告で、多くのセキュリティ製品は ESXi に対する可視性と保護が限られていると指摘しています。

また、ESXi のファイルシステムが暗号化されると、そのホスト上の VM がまとめて影響を受けます。管理権限の侵害で複数の VM に被害が広がり得るのはこのためです。ただし、影響が及ぶ範囲は奪われた権限の範囲で決まります。ESXi 1 台の権限から他の全ホストを操作できるとは限らず、独立した認証で管理されるバックアップ先まで自動的に操作できるわけでもありません。

イミュータブルでもバックアップを失うのか

「イミュータブルなバックアップがあれば安全」と考えがちですが、結果は保存場所、操作権限、保持設定、復元に必要な要素の組み合わせで決まります。まず IDCF クラウドの実際の機能を確認し、そのうえで一般論を整理します。

IDCF クラウドのスナップショットとバックアップの仕様

IDCF クラウドには、VM のボリュームを対象とするスナップショット機能と、別サービスの「IDCF クラウド バックアップ」があります。公式仕様で確認できる主な違いは次のとおりです。

項目	スナップショット	IDCF クラウド バックアップ
方式	ある時点のボリュームの状態を保存（即時または定期）	OS 上のエージェント（利用ガイドは Veeam のエージェントを使う手順）
保存先	VM にアタッチするボリュームとは物理的に異なる筐体（アーカイブデータ領域）	対象と異なる拠点のクラウドストレージ（バックアップストレージは東日本エリアで提供）
位置付け	長期保存ではなく一時保存が目的。定期スナップショットはバックアップ用途	ファイル単位を含むリストアに対応。ランサムウェア対策としてイミュータブルを選択可能
イミュータブル	仕様ページに変更禁止機能の記載なし（本記事の確認範囲）	問い合わせにより利用可能。設定日数は最小 1 日、最大 30 日

参考: IDC フロンティア「スナップショット」
「仮想マシンにアタッチするボリュームとは物理的に異なる筐体に保存される」
https://www.idcf.jp/cloud/spec/snapshot/

このため、一般的な VMware のスナップショット（VM と同じデータストア上の差分ファイル）と同一視して、「同じデータストアにあるから一緒に暗号化された」とは判断できません。同時に、保存先が物理的に異なることだけで、今回スナップショットが無事だったとも判断できません。公式発表から、スナップショットやバックアップが残っている、あるいは破壊されたと結論付けられる情報は、現時点ではありません。

IDCF クラウド バックアップのイミュータブルは既定の動作ではなく、利用ガイドでは問い合わせによって利用できると案内されています。追加されたイミュータブル有効のリポジトリ（通常は名前に -immutability-on が付くもの）を指定して Subtenant ユーザーを作成し、そのユーザーの認証情報でバックアップジョブを構成する手順です。つまり、機能が提供されていること、利用者が対象のジョブで有効にしていたこと、今回の攻撃で実際に保護されたことは、それぞれ別に確認する必要があります。

削除できない期間も、申請した日数だけでは決まりません。利用ガイドでは、バックアップのリテンション日数をイミュータブルの日数以上に設定する必要があるとしたうえで、データを削除できない期間を次のように説明しています。Block Generation の期間は、今後変更される可能性があるとも記載されています。

参考: IDCF クラウド ご利用ガイド「バックアップ – はじめに」
「イミュータブルの日数＋バックアップのリテンション日数＋Block Generation（10日間）」
https://guide.idcf.jp/backup/introduction/

設定の有無は、FAQ によると、クラウドコンソールのビリング画面からダウンロードする「請求明細」または「利用状況」の CSV で確認できます。G 列 ResourceDisplayName が immutability-on の行に金額や使用量があれば有効、immutability-off の行にあれば無効という判定です。これは契約上の設定を確認する方法であり、今回の攻撃でデータが保護されたかどうかは、事業者の調査結果で確認する必要があります。

保管場所と権限の分離を別々に評価する

バックアップの安全性は、「どこに置いたか」と「誰が消せるか」を分けて評価します。IDCF クラウド バックアップは IDCF クラウドとは異なる拠点のクラウドストレージに保存される仕様ですが、拠点が異なることは主に物理的な障害への備えであり、操作権限の分離までを意味するわけではありません。

同様に、「同じ事業者なら無効」「別事業者なら安全」という二択で判断するのも適切ではありません。別アカウントや別事業者に保管していても、共通の管理者アカウント、SSO、アクセスキー、バックアップサーバーの認証情報を介して削除できるなら、1 つの侵害で両方に到達し得ます。確認したいのは次の点です。

• バックアップの削除や保持期間の変更ができるアカウントと、その認証方式
• 本番環境とバックアップの管理者が、同じ ID や同じ SSO に依存していないか
• バックアップ先のアクセスキーや API トークンが、本番環境内に保存されていないか
• 事業者側の運用者が、利用者の保持設定を解除できる手順を持っているか

保管と権限を分離する設計の考え方は、『ファイルサーバーのランサムウェア対策｜不変バックアップ設計の基礎』で詳しく解説しています。

変更禁止が効く層と効かない層

「変更禁止」と一口にいっても、どの層で保護を強制しているかで結果が変わります。VM 内の OS で設定したファイルの変更禁止属性やアクセス権は、その OS 上の操作を制限するものです。仮想ディスクより下の層、つまりハイパーバイザーやストレージ側から仮想ディスクそのものを暗号化・削除されると、OS 上の設定は効力を持ちません。

これに対し、独立したストレージサービスが保持期間を強制する方式では、保存先のサービス自体が削除や上書きを拒否します。説明例として Amazon S3 Object Lock を挙げると、保護はオブジェクトのバージョン単位で、Governance モードでは s3:BypassGovernanceRetention 権限を持つユーザーが保持設定を解除・短縮できます。Compliance モードでは、保持期間中はルートユーザーを含めて削除・上書きできません。

参考: AWS「Locking objects with Object Lock」
“can’t be overwritten or deleted by any user, including the root user”
（ルートユーザーを含むいかなるユーザーも上書き・削除できない）
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html

ただし、これは S3 の仕様を説明するための例であり、IDCF クラウド バックアップが同じ実装・同じモードであるとは限りません。どの方式でも、上位管理者の権限、保持期間の長さ、保護される世代、データを書き込んだ時点の保護設定によって結果は異なります。保持期間が切れた世代や、保護を有効にする前に書き込まれたデータは、保護の対象外になり得る点にも注意が必要です。

データが残っても業務を戻せるとは限らない

バックアップのデータが残っていることと、業務を復旧できることは別の問題です。復元には、データ本体のほかに次の要素がそろっている必要があります。

復号鍵

バックアップや保存データを暗号化している鍵やパスワードです。鍵の保管先が本番と同じ侵害範囲にあると、データが残っても読めない状態になり得ます。

設定情報とカタログ

バックアップジョブの設定や、どの復元ポイントがあるかを示す情報です。バックアップサーバーごと失われた場合に、再取得する手段があるかを確認します。

復元ツールと認証

エージェント、リカバリメディア、管理コンソールと、それらを操作するアカウントや多要素認証の手段です。管理コンソールが停止している間に使える手段があるかも確認します。

復元先

侵害の影響を受けていない計算資源、ネットワーク、IP アドレス設計と、OS やソフトウェアのライセンスを持ち込めるかどうかです。

特に鍵は見落とされやすい要素です。AWS は、Object Lock がオブジェクトの削除・上書きを防いでも、暗号鍵へのアクセスの喪失や鍵の削除は防がないと明記しています。

参考: AWS「Object Lock considerations」
“it does not protect against losing access to the encryption keys”
（暗号鍵へのアクセスの喪失は保護しない）
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html

ライセンスについては、IDCF クラウド バックアップの利用ガイドでも、事業者が提供する有償 OS をバックアップした場合は、同じ VM か、同じ有償 OS の VM へリストアするよう案内されています。復元先を別の環境に切り替える場合は、ライセンスの扱いも事前に確認しておく必要があります。

暗号化から復旧できても漏えい対策は別に必要

暗号化からの復旧と、情報漏えいへの対応は別の課題です。今回の事案では、データの持ち出しの有無は 10 月 7 日時点で公表されていません。ここでは、可能性として考慮すべき点を整理し、発生した事実とは区別して扱います。

イミュータブルは読み取りを防がない

イミュータブルは、保持期間中のデータの変更・削除を防ぐ仕組みであり、読み取りや持ち出しを防ぐ仕組みではありません。バックアップが無事であっても、漏えいがなかったことの証明にはならないため、復旧の可否と漏えいの調査は分けて進めます。

Microsoft も CVE-2024-37085 の報告で、ESXi の管理権限を得た攻撃者は、ホスト上の VM にアクセスしてデータを持ち出す可能性があると指摘しています。基盤側からの読み取りはゲスト OS のログに残らない場合があるため、ゲスト側のログだけでは、基盤側からの持ち出しを否定できません。

暗号化が守る範囲と守らない範囲

データの暗号化は、対象となるデータの状態によって守れる範囲が異なります。

保存時の暗号化

ディスクやストレージに書き込まれたデータを暗号化します。媒体の持ち出しや、鍵を持たない第三者による読み取りへの対策になります。

通信の暗号化

ネットワーク上を流れるデータを TLS などで暗号化します。経路上での盗聴への対策です。

処理中のデータ保護

メモリ上で処理しているデータを、CPU の機能などで保護します。Confidential VM がこれにあたります。

VM 内のディスク暗号化（BitLocker や dm-crypt など）は有効な対策ですが、通常の VM が起動して処理している間、データは OS 上で復号されています。ホスト側からメモリや起動中の状態を参照できる立場の攻撃者に対して、平文や鍵の保護を保証するものではありません。また、暗号化されたディスク自体の削除や、外側からの再暗号化による停止も防げません。

対策としては、鍵を本番と同じ侵害範囲に置かないことや、機密性の高いデータはアプリケーション側で暗号化して鍵を別に管理することなどを検討します。Microsoft Azure の Confidential VM は、ホストの管理者やハイパーバイザーが VM のメモリと CPU の状態を直接参照・変更できないようにする技術で、ホストを脅威とみなす場合の機密性対策の参考になります。ここでは Azure の機能を参考例として紹介しており、IDCF クラウドの提供機能を説明するものではありません。また、可用性や復旧を保証する技術でもありません。

クラウド利用者が確認する項目と事業者への質問

ここまでの整理を、利用者が実際に確認・問い合わせできる項目に落とし込みます。自社で確認できることと、事業者に聞かなければわからないことを分けておくと、問い合わせが具体的になり、回答を待つ間にも準備を進められます。

確認表: 自社と事業者で確認すること

確認項目	自社で確認すること	事業者へ確認すること
対象の特定	利用サービス、リージョン / ゾーン、VM / ボリュームを台帳で整理する	個別通知の対象範囲と、対象となる自社リソース
停止の種類	業務の停止と管理コンソールの停止を区別し、外部の SaaS や委託先を経由した依存も洗い出す	自社リソースの状態（遮断・停止・暗号化の有無）と、コンソール再開の見込み
復元ポイント	スナップショット、IDCF クラウド バックアップ、他社保管コピーごとの最終成功時刻	各コピーの残存状況と整合性の調査結果
イミュータブル	申請記録、ビリング CSV の immutability-on 行、対象ジョブ / リポジトリ、保持期限、解除・削除できる権限	自社の対象ジョブが有効なリポジトリに書き込まれていたか、今回の保護状況
復元の前提	復号鍵、復元ツール、設定情報、正常な復元先、ライセンスの持ち込み可否	バックアップコンソールの利用可否、復元先リソースの提供、有償 OS の扱い
RPO / RTO	許容するデータ損失（RPO）と目標復旧時間（RTO）、データ量に対する転送・復元時間、DB と関連ボリュームの整合性、復元試験の実績	復元時に利用できる帯域と計算資源の見込み
漏えいの調査	ゲスト OS やアプリケーションのログの保全と確認	基盤側の読み取り・持ち出しの調査状況、対象ログの種類と期間
認証情報	管理者アカウント、API キー、アプリケーションの秘密情報を棚卸しし、侵害が疑われるものから優先する	事業者側で保管する認証情報や連携設定の影響評価

事業者へ問い合わせる際は、表の右列をそのまま質問リストとして使えます。回答が「調査中」の項目は、回答日時とともに記録しておくと、続報との突き合わせが容易になります。

被害時の初動の順序

個別通知を受けた場合や影響が疑われる場合は、次の順序を基本に進めます。

事業者側と利用者側の対策を分けて考える

管理ネットワークの分離、ESXi や vCenter への修正の適用、基盤の管理者アカウントの保護は、事業者側の責任範囲です。一方、ゲスト OS とアプリケーションの更新、利用者アカウントと API キーの管理、バックアップの設計と復元試験は、利用者側で取り組める範囲です。責任共有モデルは対策の分担を整理する考え方であり、事業者の基盤で起きた今回の被害を、利用者の責任と判断する根拠にはなりません。

利用者側では、平時から「事業者の基盤ごと使えなくなる」場合を想定し、別の権限で管理するコピーと、そこから戻すための鍵・手順を用意しておくことをおすすめします。3-2-1-1-0 の考え方は『ランサムウェア対策の基本と全体像｜3-2-1-1-0 で守るバックアップ設計』、他社保管を含む構成の選び方は『ランサムウェア対策バックアップ構成の比較｜3 構成例の選び方』を参照してください。

まとめ

IDCF クラウドの障害は公式発表でランサムウェア攻撃と確認されましたが、侵入経路やバックアップの状況は 10 月 7 日時点で公表されていません。利用者にとって重要なのは、原因の推測よりも、自社の対象範囲と復元手段を確認し、事業者への質問を具体化することです。侵入原因などの続報が公表された場合は、本記事に追記して更新します。

• 第 2 報で、東日本リージョン 1 の障害はランサムウェア攻撃と公表されました。
• 侵入経路、持ち出しの有無、バックアップの状況はまだ公表されていません。
• 管理権限は種類ごとに、奪われる経路と影響範囲が異なります。
• イミュータブルは機能、設定、今回の保護結果を分けて確認します。
• データが残っても、鍵や復元先がなければ業務は戻せません。
• 変更禁止の仕組みは、データの読み取りや持ち出しを防ぎません。
• 自社で確認する項目と、事業者へ聞く項目を分けて整理します。

以上、最後までお読みいただきありがとうございました。