RansomHouse「FULL DATA DUMP」を追う――Tree構造から見えたニチレイ侵害の到達範囲

サイバーセキュリティー

2026年7月、ニチレイグループでサイバー攻撃によるシステム障害が発生しました。

ネット探検ラボでは、この事案について発生当初から動向を追い、これまで3回にわたって記事にしてきました。

最初はシステム障害と業務への影響、その後はランサムウェアグループ「RansomHouse」側の動き、さらにリークサイト上で公開された情報など、状況の変化に合わせて確認を続けてきました。

そして今回、RansomHouse側で新たに「FULL DATA DUMP」と表示された大規模なデータ群が公開されていることを確認しました。

ここまで来ると、一つの疑問が浮かびます。

攻撃者は、実際にどこまで到達していたのか。

そこで今回、ネット探検ラボではFull Dumpの全ファイルをダウンロードするのではなく、公開されているディレクトリのTree構造をたどり、その広がりを確認することにしました。

目的は、窃取された文書の中身を覗き見ることではありません。

個人情報や取引情報などを探し出したり、それを再び公開したりすることにも意味はないと考えています。

私たちが知りたいのは、どのようなデータ領域まで攻撃者が到達したのか。

そして、その構造から、攻撃者の力量をどこまで推定できるのか。防御側は何を学べるのか。

という点です。

なお、本稿ではRansomHouseが「FULL DATA DUMP」として公開したデータが、同グループが窃取したデータ全体を反映しているとの前提に立って分析します。

現時点でネット探検ラボは、このFull Dumpとは別に未公開の窃取データが存在することを示す具体的な証拠を確認していません。

一方、Full Dump全体の総容量や総ファイル数については計測しませんでした。

今回の目的はデータ量の競争ではなく、Tree構造から侵害の到達範囲を見ることだからです。

これまでの経緯の振り返り

7月13日、7月13日、ニチレイグループは不正アクセスによるシステム障害を確認。被害の拡大を防ぎ、顧客・取引先の個人情報や顧客データを保護するため、同社はグループで使用するシステムを遮断。
この措置によって、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務や、ニチレイフーズの冷凍食品出荷業務などを停止せざるを得ない状況となりました。
同日、緊急対策本部を設置し、外部のセキュリティ専門会社とともに原因調査と復旧作業を開始しました。

7月17日には、冷蔵倉庫全拠点の入出庫業務と冷凍食品出荷業務を順次再開。この段階では受発注に一部制限を残しながら、部分稼働という形で復旧を進めています。

その後、攻撃者側ではRansomHouseが犯行を主張し、ニチレイに関する情報をリークサイトへ掲載しました。ネット探検ラボでも、この事件についてこれまで3回にわたり、ニチレイ側の発表とRansomHouse側の動きを追ってきました。

7月24日、ニチレイは受発注制限を解除し、全拠点で平常時の通常稼働へ移行したと発表しました。障害発生から約11日で通常稼働まで戻したことになります。

そして今回、RansomHouse側で新たに“「FULL DATA DUMP」”が公開されました。

そこで今回は、これまでの「何が起きたのか」という追跡から一歩進め、公開されたデータの中身を覗くのではなく、Tree構造そのものから攻撃者の到達範囲を考えてみます。

「FULL DATA DUMP」のTreeをたどる

今回、RansomHouseが公開した「FULL DATA DUMP」について、ネット探検ラボでは個々のファイル内容ではなく、ディレクトリのTree構造を中心に確認しました。

なお、ここからの分析では、RansomHouseが「FULL DATA DUMP」として公開したものが、同グループが窃取したデータ全体を反映しているとの前提に立ちます。

Full Dumpの最上位を確認すると、大きく3つの領域に分かれていました。

/full/
├── FS/
├── FS01/
└── nlgfls03/

最初にこの構造を見たときは、それほど複雑には見えませんでした。

ところが、それぞれのディレクトリを一段ずつ開いていくと、その印象は大きく変わりました。

特徴的だったのは、単純に一つの巨大なTreeが深く続いているのではなく、複数の業務領域が横方向へ大きく広がっていることです。

そして、その中の一部では、実際の業務で使用されていたとみられるフォルダが何階層にもわたって続いていました。

「FS」――複数の業務領域へ広がるTree

まず FS の直下には、11のディレクトリが存在していました。

FS/
├── A131/
├── A20/
├── A25/
├── A37/
├── A386/
├── TIZAI/
├── W55/
├── W60/
├── W66/
├── hcky/
└── news21/

これらをさらに確認すると、人事・労務、採用、福利厚生、経営管理、予算、債権管理、契約、請求、広報など、さまざまな業務を示す名称が現れました。

さらにIT関連では、VPN、BCP、CSIRT、JSOC、RPA、ID関連、Snowflake、S/4HANAなどの名称を含むフォルダも確認しています。

ここで注意したいのは、フォルダ名が存在することと、そのシステム自体が侵害されたことは同じではないという点です。

たとえば「VPN」という名称のフォルダが存在していても、それだけでVPN装置やVPN基盤そのものが侵害されたとは判断できません。関連する資料がファイルサーバー上に保存されていた可能性もあります。

したがって、ここから評価できるのは、

攻撃者側が、複数の部門や業務にまたがる広範なデータ領域へ到達していた可能性がある

というところまでです。

しかし、それだけでも侵害範囲を考えるうえでは重要な情報です。

「FS01」――さらに横へ広がる巨大な領域

次に確認した FS01 では、構造が少し変わります。

FS01/
├── nf_kansai_fax2890_data/
├── nf_south_fax2187_data/
├── nf_south_fax2189_data/
└── vol1/

FAX関連と思われる領域を確認すると、多数のPDFファイルが格納されていました。

しかし、さらに注目したのが vol1 です。

この直下には、A、B、E、F、G、H、L、P、Qなどから始まるコード化された多数のディレクトリが並んでいました。

一つひとつをこの記事で列挙することはしませんが、Tree全体を見る限り、ここでも特定の一部署や一台の端末に限定されたデータというより、多数の領域へ横方向に広がった構造になっています。

この段階で、今回のFull Dumpは単に「大量のファイルが公開された」というだけではなく、かなり広い範囲のファイル構造そのものが保持された状態で公開されていることが見えてきました。

「nlgfls03」――今回もっとも特徴的だった構造

そして、今回特に詳しく確認したのが nlgfls03 です。

最上位には…

nlgfls03/
├── log_hkd/
├── log_hn/
├── log_kns/
├── log_knt/
├── log_ksy/
├── log_thk/
├── log_tki/
└── lognet/

…という8つの領域が存在していました。

その先には、V系、A系、I系、D系、M系、C系、N系など、多数のコード化されたディレクトリが横方向に並んでいます。

いくつかをサンプルとして実際にたどってみると、多くの領域では、

コード
└── data
└── 業務データ

という似た構造が確認できました。

つまり、nlgfls03 全体として最初に受けた印象は、“「深い」というより「広い」”というものでした。

ところが、その中をさらに確認すると例外も見つかりました。

その一つが log_knt/D01/ です。

D01/
└── data/
├── RPA/
├── scanpdf/
├── 営業/
├── 管理/
└── 通関チーム/

ここから「営業」をたどると、月次資料、品種別入庫実績、年度、月と階層が続き、最終的には実際のExcelファイルが置かれている末端までTreeが続いていました。

「管理」についても、管理専用、業績関係、年度、業績サマリといった複数階層の構造を確認しています。

つまり、今回確認したFull Dumpは、

全体として非常に横に広く、その一部では実際の業務フォルダの末端まで深く到達している

と見ることができます。

ここが、今回のTree調査で最も重要なポイントの一つです。

さらに興味深いことも分かりました。

一部のTreeでは、2011年当時の業務データを示す名称のファイルまで残っていました。

もちろん、これは攻撃者が2011年から侵入していたという意味ではありません。

むしろ、2026年の侵害時点でアクセス可能だったデータ領域に、10年以上前の業務資料まで保存され続けていた可能性を示しています。

ここから、今回の記事のもう一つの重要なテーマが見えてきます。

「攻撃者はどれほど高度だったのか」という問題だけではありません。

企業側が長年蓄積してきたデータが、どのような権限で、どこから、どこまでアクセスできる状態になっていたのかという視点です。

次は、今回確認したTreeからRansomHouseの力量と実際の到達範囲をどこまで推定できるのかを考えてみます。

なお、ニチレイが7月13日にシステムを遮断したこと、17日から部分稼働を開始し、24日に全拠点で通常稼働へ移行した経過は同社の公式発表でも確認できます。後ほど、この復旧速度と今回のTreeを照らし合わせて、防御側で何が守られた可能性があるのかについても考えます

Treeから見えるRansomHouseの力量と到達範囲

ここまでFull DumpのTreeをたどってきました。

では、この構造からRansomHouseの力量をどこまで評価できるのでしょうか。

まず確認できるのは、今回の侵害が一つの端末や一つの業務フォルダだけに限定されたものではなかった可能性が高いということです。

FSFS01nlgfls03という大きく異なる領域が存在し、その下には人事、労務、経理、契約、営業、物流、IT関連など、多数の業務を示すTreeが広がっていました。

さらに、一部では単に上位フォルダへ到達しただけではありません。

D01で確認したように…

data
└── 営業
└── 月次資料
└── 品種別入庫実績
└── 年度
└── 月
└── ファイル

…という、実際の業務で使われていたとみられる末端の階層までTreeが続いていました。

つまり、公開されたFull Dumpをそのまま見る限り、RansomHouseはかなり広範なデータ領域へ到達し、そのディレクトリ構造を保った状態でデータを取得した可能性があると考えられます。

これは攻撃者側の一定の力量を示す材料にはなるでしょう。

しかし、ここで一つ立ち止まる必要があります。

「大量に盗まれた」=「高度な横展開」とは限りません

今回のTreeだけでは、RansomHouseが多数のサーバーや端末を次々と攻略し、内部ネットワークを高度な技術で横展開したのかまでは分かりません。

むしろ、もう一つの可能性も考える必要があります。

広範な共有データへアクセスできる権限そのものを奪われたのではないか。

仮に、ある認証情報やファイルサーバーへのアクセス権限を取得することで、複数部門の共有領域を横断して読み取れる環境だったとすれば、攻撃者は一台一台の端末を攻略しなくても、大量のデータへ到達できます。

これはRansomHouseの能力を低く評価するという意味ではありません。

逆です。

攻撃者の力量を評価すると同時に、“「一つ突破されたとき、そこからどこまで見えてしまう設計だったのか」”を防御側も検証しなければならないということです。

今回確認したTreeは、その問題を強く感じさせる構造でした。

10年以上前のデータまで守る必要があったのか

もう一つ気になったのが、データの保存期間です。

今回Treeを確認する中では、2011年当時の業務資料を示すファイル名まで確認できました。

もちろん、古いデータを保存すること自体が問題なのではありません。

法令、監査、契約、業務上の必要性などから、長期保存が必要な資料もあります。

しかし、保存する以上は、そのデータも現在の攻撃対象になります。

2011年に作成されたファイルであっても、2026年に同じ共有領域からアクセスできるのであれば、攻撃者にとっては「2026年に取得可能なデータ」です。

ここで企業側が考えるべきなのは、

「保存できるから保存する」のではなく、「今もオンラインでアクセス可能な状態にしておく必要があるのか」

ということではないでしょうか。

  • 利用頻度の低い古いデータを別領域へ移す
  • アクセスできる利用者を限定する
  • 保存期限を定める
  • 重要度に応じてオンライン領域とアーカイブ領域を分離する

こうしたデータライフサイクル管理も、ランサムウェア対策の一部として考える必要があります。

攻撃者が盗めるデータ量を減らす最も単純な方法の一つは、そもそも攻撃者が到達できる場所に不要なデータを置き続けないことだからです。

防御側が把握すべきは「侵入後の半径」

今回のTreeを見ていて、ネット探検ラボが最も重要だと感じたのはここです。

サイバーセキュリティでは、どうしても「侵入を防ぐ」ことに意識が向きます。

もちろん、それは重要です。

しかし、現実には脆弱性、認証情報の窃取、フィッシング、設定ミスなど、侵入経路を完全にゼロにすることは困難です。

だからこそ、もう一つの視点が必要になります。

侵入された後、攻撃者はどこまで行けるのか・・・です。

例えば、ある従業員の認証情報が奪われたとします。

  • そのアカウントから、自分の部署だけが見えるのでしょうか
  • 隣の部署まで見えるのでしょうか
  • 全社共有領域まで見えるのでしょうか
  • さらに10年以上前の資料まで、そのまま参照できるのでしょうか
  • 管理者権限を奪われた場合はどうでしょう
  • 一つのファイルサーバーが侵害された場合、その先に何がつながっているのでしょうか

防御側は、攻撃者が侵入してから到達できる「半径」そのものを平時から把握しておく必要があります。

最小権限、ネットワーク分離、アクセス制御、データ分類、古いデータのアーカイブ。

これらは別々の対策に見えますが、目的は共通しています。

一つ突破されても、全部を持っていかれない構造にすることです。

それでも、すべてを奪われたようには見えません

そして今回、もう一つ注目した点があります。

バックアップです。

本稿では、RansomHouseが「FULL DATA DUMP」として公開したものが、同グループが窃取したデータ全体を反映しているとの前提で分析しています。

その前提に立った場合、今回ネット探検ラボが確認したTreeからは、バックアップ基盤そのものへ到達したことを明確に示す構造は見つけられませんでした。

もちろん、Treeだけから「バックアップは完全に無傷だった」と断定することはできません。

しかし、ここでニチレイ側の復旧経過を重ねてみます。

  • ニチレイは7月13日の発生当日からシステムを遮断し、緊急対策本部を設置しました。
  • そして外部のセキュリティ専門会社と安全対策を進めたうえで、7月17日には冷蔵倉庫と食品工場を部分稼働させています。
  • さらに7月24日には受発注制限を解除し、全拠点で通常稼働へ移行しました。
  • また、7月22日の公式発表では、被害を受けたサーバーの一部に個人情報が保管されていたことを認める一方、外部専門会社と安全対策を講じながら復旧を進めていることも明らかにしています。

…障害発生から通常稼働まで11日です。

今回確認したFull Dumpの広がりを考えると、この復旧経過は無視できません。

侵害されたことと、すべてを失ったことは同じではありません

ここは、ニチレイ側について評価すべき部分だと考えます。

今回、広範な業務データが攻撃者側へ渡った可能性については厳しく見なければなりません。

一方で、情報を窃取されたことと、復旧能力まで奪われたことは別の問題です。

少なくとも今回確認したFull Dumpが窃取データ全体を反映しているという前提では、バックアップ基盤まで攻撃者が掌握したことを示す明確な材料は確認できませんでした。

そして実際にニチレイは、外部専門会社と安全確認を行いながら段階的に業務を戻し、11日後には全拠点を通常稼働へ戻しています。ニチレイ自身も、復旧は安全対策を講じたうえで進めたと説明しています。

この二つの事実を合わせると、復旧に必要なバックアップや復旧基盤まで完全に破壊・無力化される最悪の事態は回避できていた可能性があります。

これは推定です。

しかし、防御側を評価するときには、失敗した部分だけでなく、最後まで守れた可能性のある部分も見る必要があると考えます。

ランサムウェア対策は「侵入させない」で終わらない

今回のニチレイ事案をFull DumpのTreeから見ていくと、一見すると相反する二つの姿が見えてきます。

一方では、複数の業務領域にまたがる非常に広いデータTreeが公開されました。

他方では、ニチレイは発生当日にシステムを遮断し、4日後には部分稼働、11日後には全拠点を通常稼働へ戻しました。

ここから得られる教訓は明確です。

侵入を100%防ぐことだけが、ランサムウェア対策ではありません。

  • 侵入されたら、どこまで行けるのか。
  • 一つの認証情報から、どこまでデータを読めるのか。
  • 重要なデータと古いデータは適切に分離されているのか。
  • そして最後に、バックアップと復旧基盤を攻撃者から切り離して守れるのか。

今回のFull Dumpから見えてきたのは、攻撃者の力量だけではありません。

むしろ防御側にとって重要なのは、

「侵入を許したか」だけではなく、「侵入された後、どこで止められる構造になっているか」

ということではないでしょうか。

  • 侵入されても、全部は渡さない。
  • 暗号化されても、復旧できる。
  • 一つを突破されても、次の壁で止める。

今回のニチレイ事案は、ランサムウェア対策をそのような多層的な防御と復旧能力の問題として考える必要性を、改めて示しているように思います。

コメント

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