【IDCFクラウド侵害・第3続報】中国系サイバースパイとランサムウェア――三菱電機、Rook、Night Skyから考える新たな仮説

サイバーセキュリティー

ネット探検ラボ|【矢又小次郎】2026年10月15日

1.IDCFクラウド侵害をめぐる新たな疑問

2026年10月7日、IDCフロンティアが運営する「IDCFクラウド」で、大規模なシステム障害が発生しました。

同社は第三者によるランサムウェア攻撃を確認し、495の企業・自治体が影響を受けたと公表しています。

10月14日の第5報を目にしてから、筆者は、当該事案は、中国系サイバー攻撃(スパイ)事案ではないのか?との疑いを抱くこととなりました。

そこで今回は、その疑いを抱くに至った経緯について簡潔に語って参りたいと思います。

第5報では、顧客の仮想サーバー内データについて、外部への持ち出しや不正照会を示す痕跡は確認されず、データ流出はなかったと判断されていますが、その一方で、48社のクラウドポータル登録情報に対する不正照会が確認されています。

ネット探検ラボは、IDCFへの攻撃について、今まで2回に渡り従来とは異なる視点から検証を進めてきておりますが、今回はその続報でもあります。

今回の着目点は…

  • ランサムウェアによるクラウド基盤の破壊は、攻撃者の最初からの目的だったのか?
  • それとも、それ以前に行われた別の活動を隠すための最終工程だったのか?

…です。

この疑問を考えるうえで、筆者には忘れられない過去のサイバー攻撃があります。

  1. 2019年の三菱電機への侵入事件
  2. 2021年のデンソー・メキシコ拠点へのRookによる攻撃
  3. 2022年に登場したNight Sky

…です。

これらの事件を振り返ると、ランサムウェアの使用目的について、もう一つの可能性が浮かび上がってきます。

2.三菱電機へのサイバースパイ攻撃――侵入活動を追跡された攻撃者

2020年1月20日、三菱電機は、同社のネットワークが第三者による不正アクセスを受け、個人情報や企業機密が外部へ流出した可能性を公表しました。

事件が発覚したのは、前年の2019年6月28日でした。

しかし、その後の調査で、攻撃者は同年3月18日の時点ですでに中国拠点のネットワークに侵入していたことが判明しており、約3ヶ月間に渡り侵入を許していたことになります。

攻撃者は、中国拠点のウイルス対策管理サーバーに存在した未公開の脆弱性を悪用し、正規の更新機能を利用して侵害範囲を広げました。

さらに4月3日には、日本国内のウイルス対策管理サーバーも攻撃され、国内の複数拠点へ侵入が拡大しています。

攻撃には、Windowsの正規機能であるPowerShellを悪用するファイルレスマルウェアが使用されていました。

ファイルレスマルウェアとは、通常の不正プログラムのように実行ファイルを保存することを避け、メモリ上などで活動することで検知を難しくする手法です。

三菱電機は、国内外の約24万5千台の端末とサーバーを対象に調査を実施しています。

その結果、侵入経路、横展開の過程、使用された技術、外部通信など、攻撃者の活動が具体的に明らかになっています。

また、一部ではログが削除されており、情報流出の全容を確定できない部分も残りました。

それでも、攻撃者は侵入活動を完全に隠し通すことができなかったのです。

日本側が注目したもの、攻撃者が失ったもの

当時、日本国内では、防衛関連情報や機密情報が流出した可能性に大きな関心が集まりました。

防衛省は後に、流出した可能性のある防衛関連ファイル約2万件のうち、59件について安全保障上の影響のおそれがあったと公表しています。

もちろん、機密情報の流出は重大な問題です。

しかし、攻撃者側の視点から考えると、別の重大な問題が生じていた可能性があります。

それは、侵入経路や横展開の方法、使用した技術、活動の痕跡まで調査されたことです。

攻撃者は、ある一定の情報の取得に成功したとしても、本来狙っていた情報のすべてを入手できたとは限りません。

発覚によって侵入活動が中断されたのであれば、さらに重要な情報へ到達する前に撤退を余儀なくされた可能性も考えられます。

また、侵入手法や使用した技術が明らかになれば、それらを将来の攻撃に再利用することも難しくなります。

日本側が「何を盗まれたのか」を調べていた一方で、攻撃者側は「なぜ発見されたのか」「どこまで活動を追跡されたのか」を検証していたかもしれません。

ここで、筆者は一つの仮説を考えています。

情報収集を終えた後、あるいは侵入の発覚を察知した際に、調査の手掛かりを破壊し、事件そのものを別の犯行目的に見せかけることはできないのか?ということです。

3.デンソー・メキシコ事案――Rookの流出データを調べて見えたもの

2021年12月、デンソーのメキシコ拠点がランサムウェア攻撃を受けました。

攻撃者は「Rook(ルーク)」を名乗り、約1.1TBのデータを窃取したと主張しました。

一方、デンソー側は、被害を受けた約20台のコンピューターが旧ネットワーク上で使用されていたもので、現在の事業活動に必要な重要データは含まれていないと説明していました。

当時、筆者はLockBitなどのランサムウェア集団を継続的に観測しており、Rookがリークサイトで公開したデータについても、実際に取得して内容を調べていました。

その作業には、日本人の協力者も加わっていました。

「東京三菱銀行」という名称に目が向いた

筆者は金融業界に13年間在籍した経験があり、銀行の合併に伴う名称変更や、その表記順にも旧行の組織文化や力関係が反映される事情を理解していました。

そのため、Rookが公開した大量のデータを検証する中で、「東京三菱銀行」という名称に目が向いたのです。

東京三菱銀行は、1996年4月1日に東京銀行と三菱銀行が合併して誕生しました。

その後、2006年1月にUFJ銀行と合併して「三菱東京UFJ銀行」となり、2018年4月には現在の「三菱UFJ銀行」へ名称を変更しています。

つまり、2021年12月の時点で、「東京三菱銀行」はすでに約16年前に使われなくなった名称でした。

実際に流出データを調べると、こうした古い情報が数多く含まれていました。

これは、侵害された約20台のコンピューターが旧ネットワーク上にあり、現在の事業活動に必要な重要データは含まれていないという、当時のデンソー側の説明とも整合していました。

LockBitと比較して感じた、Rookの未熟さ

当時、ロシア語圏を中心とするランサムウェア犯罪の世界では、LockBitなどが猛威を振るっていました。

LockBitは、RaaS(ランサムウェア・アズ・ア・サービス)と呼ばれる分業型の犯罪モデルを発展させ、侵入、情報窃取、暗号化、交渉、リークサイトによる圧力を組み合わせていました。

筆者は、そうしたLockBitの活動とRookの事件を比較して、違和感というか大きな違いを強く感じていたものでした。

それは、単に流出データが古かったということだけではありません。

LockBitの事案と比較すると、Rookの侵害は深さが足りず、横方向への広がりも限定的であるように見えたのです。

窃取された情報の内容から攻撃者の行動を逆算しても、ネットワーク内部での横展開や、重要な情報資産を探し出す探索活動には未熟さが感じられました。

約1.1TBという大量のデータを持ち出しながら、旧ネットワークに残された古い情報が目立つという結果は、当時の筆者には熟練したランサムウェア集団の仕事には見えませんでした。

「もしかすると、新人研修でもしているのだろうか?」

そんなことさえ考えました。

Rookという名前ですが、実態は Rookie(ルーキー、新人)なのではないか、と(笑)

もちろん、これは窃取された情報から攻撃者の探索活動を推し量った、当時の筆者自身の評価です。

しかし、この違和感は、その後に登場するNight Skyを観測する中で、別の疑問へと変わっていきました。

4.Night Skyの登場――金銭目的とは異なる活動なのか

2022年1月、新たなランサムウェア「Night Sky(ナイトスカイ)」が登場しました。

Night Skyも、情報を窃取したうえで、身代金が支払われなければリークサイトで公開するという二重恐喝型の手法を採用していました。

筆者はRookに続いてNight Skyの活動にも注目しました。

また、それ以前から「LockFile(ロックファイル)」についても個人的に調査していました。

LockFile、Rook、Night Sky。

当時はそれぞれ個別の活動として調べていましたが、Rookで感じた未熟さと、短期間に登場するランサムウェアの動きを見ながら、次第に一つの疑問を抱くようになりました。

これらは本当に金銭獲得を主目的とするランサムウェア集団なのか?
それとも、別の目的を持つ攻撃者がランサムウェアを利用しているのか?

当時の筆者は、LockBitなどの主要なロシア語圏のランサムウェア集団とは、活動の性格が異なるのではないかと考えていました。

そして、中国系の攻撃者が関与している可能性も仮説として考えるようになりました。

その段階では、攻撃者の帰属を裏付ける技術的な証拠を持っていたわけではありません。

しかし、その後、この疑問に関係する研究結果が公表されることになります。

5.BRONZE STARLIGHT――別々に観測していた活動がつながった

2022年、セキュリティ企業Secureworksは、中国系と評価した攻撃活動「BRONZE STARLIGHT(ブロンズ・スターライト)」について、詳細な分析を公表しました。

研究者は、次の五つのランサムウェア活動に共通する技術的特徴を確認しました。

  • LockFile
  • AtomSilo
  • Rook
  • Night Sky
  • Pandora

この中には、筆者が個人的に調べていたLockFile、流出データを検証したRook、そして注目していたNight Skyが含まれていました。

Secureworksが特に注目したのは、「HUI Loader(エイチユーアイ・ローダー)」と呼ばれるプログラムです。

HUI Loaderは、正規のプログラムの動作を利用して別の不正プログラムを読み込ませる仕組みで、攻撃者が遠隔操作などに使用するツールの展開に利用されていました。

この技術は、知的財産を狙う中国系のサイバースパイ活動とも関連づけられていました。

Secureworksは、ランサムウェアの種類が短期間で切り替わること、標的の選び方、使用技術の共通性などを分析しました。

そして、BRONZE STARLIGHTについて、主目的が金銭獲得ではなく、知的財産の窃取やサイバースパイ活動であり、ランサムウェアを本来の目的を隠すために利用していた可能性を指摘していました。

さらに、JPCERT/CCのJSAC2022でも、日本を標的としたA41APTの活動と、ランサムウェア攻撃で確認されたHUI Loaderとの関連が議論されています。

ここで、筆者が別々の事件として観測していた活動に、技術的な共通点が見えてきたのです。

Rookの侵害範囲の浅さや探索の未熟さだけで、中国系攻撃者と判断することはできません。

しかし、後年の研究によって、これらのランサムウェア活動を金銭目的の犯罪という枠組みだけで捉えることには、再検討の余地が生まれました。

6.サイバースパイは、なぜランサムウェアを利用するのか

ここで、再び三菱電機事件に立ち戻ります。

三菱電機への攻撃では、一部のログが削除されていたにもかかわらず、侵入経路や横展開の過程、攻撃者の活動履歴が調査によって明らかになりました。

攻撃者側から見れば、情報の取得とは別に、侵入手法や活動の痕跡を追跡されたことも問題だったと考えられます。

一方、BRONZE STARLIGHTでは、ランサムウェアを利用することで、金銭目的の犯罪を装い、サイバースパイ活動の実態を隠していた可能性が指摘されました。

この二つの事案を踏まえ、ネット探検ラボでは次の仮説を検討しています。

サイバースパイ活動にランサムウェアを組み合わせることで、攻撃者は先行する情報収集活動の痕跡を破壊し、同時に事件の目的を金銭獲得に見せかけることができるのではないか。

ランサムウェアによってシステムやバックアップが破壊されれば、調査に必要な記録が失われる可能性があります。

また、事件が金銭目的のランサムウェア攻撃として扱われれば、調査の関心が暗号化、復旧、身代金要求へ集中する可能性もあります。

つまり、攻撃者にとっては二つの効果が考えられます。

第一に、侵入活動を追跡するための証拠を破壊すること。

第二に、先行する情報収集活動の存在や目的から、調査担当者の注意をそらすことです。

もっとも、三菱電機事件が直接BRONZE STARLIGHTの戦術変更を引き起こしたという証拠はありません。

ここで検討しているのは、特定の攻撃者が連続して事件を起こしたという主張ではなく、サイバースパイ活動における隠蔽手法の変化という仮説です。

7.IDCFクラウド侵害との接点――異常な破壊が意味するもの

ネット探検ラボは、IDCFクラウド侵害の第1報で、今回の攻撃がワイパーによる破壊ではないかという疑問にも触れていました。

その理由は、金銭獲得を目的とするランサムウェア攻撃としては、クラウド基盤の壊れ方があまりにも異常だったからです。

攻撃者は、仮想サーバーだけでなく、その稼働や復旧を支える基盤にまで深刻な影響を及ぼしていました。通常の身代金要求であれば、被害者に復旧の必要性を強く認識させることが交渉上の圧力になります。しかし、復旧そのものが極めて困難になるほどの破壊には、別の意図が隠されている可能性があると考えています。

その後、ランサムウェアによる攻撃が確認されたことで、ネット探検ラボは新たな疑問を抱きました。

なぜ攻撃者は、ここまで徹底してクラウド基盤の破壊に繋がる手法を執ったのか?

ここで、三菱電機へのサイバースパイ攻撃と、BRONZE STARLIGHTの活動が一つの仮説につながります。

攻撃者がクラウド基盤へ侵入した目的は、当初から破壊することではなく、内部の情報を収集することだったのではないか?

仮に8月に侵入し、9月に管理権限の取得や内部探索、情報収集を進め、10月にランサムウェアを実行したとすれば、今回の大規模障害は一連の侵入活動の最終段階だったことになります。

そして、クラウド基盤の破壊によって、攻撃者がそれ以前に行っていた活動の痕跡まで失われた可能性があります。

金銭獲得を目的とする攻撃者なら、復旧を妨害することで身代金の支払いを迫るでしょう。

しかし、サイバースパイ活動を隠すことが目的だったなら、復旧に必要な情報だけでなく、侵入経路や内部での活動を追跡するための記録も破壊の対象になり得ます。

さらに、攻撃者が何らかの異変を察知し、情報収集を途中で切り上げて破壊活動に移ったという展開も考えられます。

攻撃者は目的を達成したから破壊したのか。それとも、目的を達成できなくなったから破壊したのか。

この疑問を解く鍵は、10月7日以前の活動履歴にあると考えています。

ネット探検ラボは、初期侵入の時期、管理権限の取得、内部探索、情報へのアクセス、外部通信、そしてランサムウェア実行までの流れに注目しています。

今回のIDCFクラウド侵害で追跡すべきなのは、破壊の規模だけではありません。破壊される前に、攻撃者が何をしていたのかです。

そして、もう一つ気になるのが、攻撃者がIDCF側に読むよう指定したファイルの存在です。

8.攻撃者が残したファイル――そこには何が書かれていたのか

今回のIDCFクラウド侵害には、もう一つ気になる出来事があります。

10月7日、IDCFクラウドの管理コンソールに、攻撃者を名乗る人物の声明が表示されました。

その画面では、攻撃者はクラウド基盤を掌握したと主張し、ハイパーバイザーやデータストア、仮想ディスク、スナップショットへの攻撃規模を具体的な数字で誇示していました。

さらに、IDCフロンティアの運用担当者に対して、VMware ESXiのホスト上に残したファイルを読むよう要求していました。

攻撃者が指定したファイル名は、次のものです。

RECOVER-INFO.txt

指定された場所は、ESXiのデータストアを示す /vmfs/volumes/ 以下でした。

公開された声明には、ファイルを探して内容を表示するためのコマンドも記されていました。

攻撃者は、このファイルに連絡・交渉方法を記載していると主張しています。

しかし、現時点で公開資料から確認できるのは、攻撃者がファイルの存在と場所を指定していたことまでです。

RECOVER-INFO.txtの本文に何が書かれていたのかは、明らかになっていません。

そこには身代金の要求額が記載されていたのでしょうか。

暗号化されたデータの復旧条件や、交渉方法が書かれていたのでしょうか。

あるいは、一般的なランサムウェア攻撃とは異なる要求が含まれていたのでしょうか。

攻撃者は公開声明の中で金銭要求の詳細を明かさず、運用担当者に対して、クラウド基盤内に残したファイルを読むよう求めていました。

この行動も、攻撃者の目的を考えるうえで重要な観測対象です。

9.結論を急がず、次の調査へ

2019年の三菱電機事件では、攻撃者の侵入活動が発覚し、侵入経路や横展開の過程、使用された技術が調査によって明らかになりました。

2021年のデンソー・メキシコ事案では、筆者自身がRookの流出データを検証し、LockBitなどと比較して侵害範囲の浅さや探索活動の未熟さを感じました。

その後、Night Skyの登場によって、金銭獲得とは異なる目的を持つ攻撃者がランサムウェアを利用しているのではないかという疑問が生まれました。

2022年には、SecureworksがBRONZE STARLIGHTの活動を分析し、ランサムウェアがサイバースパイ活動の偽装に利用されていた可能性を指摘しました。

そして2026年、IDCFクラウドで大規模なランサムウェア攻撃が発生しました。

これらを同一の攻撃者による連続した作戦として結び付ける証拠はありません。

また、今回のIDCFクラウド侵害について、攻撃者を中国系と結論づける段階にもありません。

しかし、過去の事件を観測する中で生まれた疑問は、今回の攻撃を検証するための一つの視点になっています。

私たちは、何を盗まれたのかに目を向けてきました。

一方で、攻撃者は何を知られることを避けようとしていたのか?

そして、IDCFクラウドの運用担当者に読むよう指定した「RECOVER-INFO.txt」には、いったい何が書かれていたのか?

ランサムウェアによる破壊が攻撃の目的だったのか。それとも、別の目的を隠すための手段だったのか。

ネット探検ラボは、結論を急ぎません。

次の調査では、攻撃者が残したメッセージの内容、ランサムウェア実行前の活動、そしてクラウド管理基盤への侵入経路を引き続き追跡していきたいと思います。

コメント

タイトルとURLをコピーしました