クラウドの「中枢」を奪われたら何が起きる？ 495社の仮想サーバを止めたIDCFランサムウェア攻撃の全容：突かれたのはOSS脆弱性

クラウド事業者へのサイバー攻撃は、利用企業にどこまで被害を及ぼすのか。IDCフロンティアの「IDCFクラウド」で起きたランサムウェア被害の全容が明らかになった。認証システムのOSS脆弱性を突かれ、495の企業・自治体の仮想サーバが停止・暗号化されたこの事件。攻撃者は何を突き、再発防止策にはどんな課題があるのか。利用企業が考えるべき備えを含めて専門家に聞いた。

[有限会社オングス,田渕聖人，＠IT]

　IDCフロンティアは2026年10月27日、同年10月7日から発生しているクラウドサービス「IDCFクラウド」へのランサムウェア攻撃に関する調査結果と再発防止策を発表した。

　発表によると、認証システムで使用していたオープンソースソフトウェア（OSS）の脆弱（ぜいじゃく）性を悪用され、攻撃者が仮想化基盤の管理者権限を不正取得。ランサムウェアによって495の企業・自治体の仮想サーバが停止・暗号化されたという。仮想サーバ内のデータについて外部への流出を示す痕跡は確認されなかった一方、クラウドポータルの登録情報には最大71社分の不正照会が判明した。

　今回の被害はどのような穴を突かれたのか、また同社が掲げる再発防止策を実行するにはどのような課題があるのか、クラウド基盤事業者を利用するユーザー側としては何を気を付ければいいのかを専門家に聞いた。

OSSの脆弱性から管理者権限を奪取　攻撃者はどう侵入したのか？

　障害は2026年10月7日午前3時40分ごろ、東日本リージョン1の4ゾーン（tesla、henry、pascal、joule）で発生した。仮想サーバが停止し、再起動できなくなった。

　同社は2026年10月7日午前6時20分ごろからサイバー攻撃の可能性を含めて調査を開始。同日6時48分に同リージョンの「IDCFクラウドポータル」を停止し、同日午前7時には影響を受けた4ゾーンのストレージ機器を切り離した。午前11時42分にランサムウェア攻撃を障害原因と特定した。

　外部のセキュリティ専門企業と連携してログや不正プログラムを解析した結果、攻撃者はIDCFクラウドポータルの認証システムに侵入した後、管理コンソールを経由して仮想化基盤の管理者権限を不正取得したことが分かった。侵入の原因は、認証システムで使用していたOSSの脆弱性だったという。同社は被害拡大を防ぐため、他リージョンのポータルも停止し、全リージョンでポータルと外部をつなぐネットワークを遮断した。

ランサムウェア攻撃の概要（出典：IDCフロンティアのWebサイト）

　なお、脆弱性を悪用されたOSSについて、IDCフロンティア側から具体的な言及はないものの、SNSでは、IaaS（Infrastructure as a Service）環境の構築や管理に利用されるOSS「Apache CloudStack」だったのではないかという見方もあった。

　これについてホワイトハッカーとして活動するレオンテクノロジーの守井浩司氏（代表取締役社長）に聞いたところ、「ソフトウェア名や脆弱性は公表されていないので推測になるが、類似のものとしては、OSSの認証・認可・ID管理を実施する『Keycloak』というOSSが存在し、2026年8月にCVE-2026-18963と呼ばれる脆弱性が公開されていた。これは攻撃者がパスワード回復プロセスの電子メール検証ステップをバイパスして、あらゆるユーザーアカウントに完全にアクセスできるようになる脆弱性だ。IDCフロンティアへの攻撃では攻撃者がIDCFクラウドポータルの認証システムに侵入後、管理コンソールを経由して仮想化基盤の管理者権限を不正に取得したと記載されている。そのため、当該脆弱性のように管理者のアカウントを窃取するような脆弱性を悪用したケースが考えられる」とコメントがあった。

495の顧客に被害、復旧も困難に　「データ流出の痕跡なし」の内実

　同社によると、攻撃を受けた仮想サーバ内のデータについて、外部への持ち出しを示す痕跡や、それを裏付ける事実は確認されなかったという。影響を受けていないゾーンや他リージョンでも、同様の事実は見つかっていない。本件に起因する情報の不正利用や二次被害も、2026年10月27日時点では確認されていない。

　一方、IDCFクラウドポータルの登録情報については、最大71社分に対する不正照会が判明した。対象には、個人名や個人名を含む可能性のあるメールアドレスなどが最大31社分含まれていた。これらの情報についても、外部への持ち出しを示す痕跡は確認されていない。また、最大4件のログインパスワードが不正に変更されていた。同社は該当するパスワードをリセットし、対象顧客に個別連絡した。

　仮想サーバ内のデータと、ポータルに登録された情報は、対象も調査結果も異なる。今回の発表は、仮想サーバ内のデータ流出を示す痕跡が確認されなかったことを示すものであり、ポータル側で不正な操作がなかったという意味ではない。

　被害に遭った495の顧客について、同社は「従来環境での復旧は困難」との見通しを示している。バックアップデータを取り出せることが確認された顧客は、2026年10月14日時点の194から同月20日には206へ増えた。同月17日にはバックアップデータの取り出しと引き渡しを開始し、同月18日には「IDCFクラウド バックアップ」の提供を再開した。

　同社は顧客に代替環境への移行手順を案内し、親会社のソフトバンクと連携してシステムの復旧を支援する。攻撃者との接触や身代金の支払い、交渉はしていないという。

　今回の事案では、クラウド事業者側の管理基盤への侵入が、複数の顧客のシステム停止に波及した。障害の復旧だけでなく、バックアップからのデータ取り出しや代替環境への移行も必要となり、顧客側にも大きな負担が生じている。

再発防止策の実効性は　脆弱性管理と認証基盤刷新の課題

　同社は再発防止策として、外部専門家と社内のセキュリティ人材で構成する独立組織を設置した。脆弱性診断の実施計画と頻度を規定で明確化し、ソフトバンクが提供するパッチ適用自動化サービス「Patching as a Service」（PaaS）などを活用して、OSSを含む診断・攻撃診断の対象範囲を広げる。

　ただこの実効性については難しいポイントもある。守井氏は「パッチの適用に当たり、影響範囲の確認や適用後の動作検証が必要となる。大規模な環境においては影響範囲が膨大になりこれらの計画や実施に時間を有するという難しさがある」と指摘する。

　この他、部署ごとに管理していたソフトウェア構成情報を全社で一元管理し、ソフトウェア部品表（SBOM）として整理することも発表した。脆弱性情報との照合を自動化する他、不正アクセスの早期検知体制も拡充する。

　停止中の「IDCFクラウドポータル」は、新たな環境で再構築する。構成サーバの認証情報を全て変更し、侵入の原因となった認証システムを外部のIDプロバイダー（IdP）のシステムに刷新する。さらに、接続元を顧客のIPアドレスに制限し、多要素認証を必須化するという。

　ポータルの再開は3段階で進める。現在は仮想サーバの起動・停止や設定変更などの主要操作を同社が代行している。次に全機能の操作代行に範囲を広げ、最後に顧客自身が全機能を操作できる形で提供を再開する。安全性を確認した上で再開する方針だ。

クラウド利用企業にできる備え　バックアップの分離と冗長化

　今回の事件を踏まえてクラウド基盤事業者を利用するユーザーとして何かできることはあるだろうか。守井氏は「『クラウド基盤だから侵害されない』という意識ではなく、基盤事業であっても侵害される意識を持った上でのリスク管理が重要だ。ミッションクリティカルなシステムであれば、単一のクラウド基盤ではなく、マルチクラウドを採用して冗長化したり、バックアップだけは異なるクラウド基盤に保管するといった対策が考えられる」と語った。