2026年7月、日本交通株式会社へのサイバー攻撃が明らかになりました。
日本交通は7月13日、外部からの不正アクセスによるマルウェア感染を確認したことを公表しました。
同社によれば、7月11日未明にサーバーへの不正アクセスを確認し、被害拡大を防ぐためネットワークを隔離しました。その影響により、ハイヤーのWeb受注・予約管理、電話によるタクシー配車、一部の社内システムなどが利用できない状態となりました。
その後、システムは順次復旧しましたが、7月22日、日本交通は今回の攻撃によって“「弊社から流出した疑いのある情報をインターネット上で確認した」”と発表しました。
つまり、システムを停止させたマルウェア感染だけではなく、情報流出を伴った可能性のあるインシデントであることが明らかになったのです。
ネット探検ラボでも、この事件についてランサムウェアグループ「AiLock」側の動きを継続して観測してきました。
そして8月11日、AiLock側の日本交通に関する掲載内容を改めて確認したところ、これまでの「2.9TB」という主張に加えて、新たな記述が確認できました。
AiLockは現在、
2.9Tb contain about 8,000 driver’s licenses
と表示しています。
「2.9TBのデータには約8,000件の運転免許証が含まれている」という主張です。
さらに詳細ページには「List of Files」「Password」に加え、Part 01からPart 06までのデータ公開項目が設けられていました。
Part 01～05はそれぞれ約400GB、Part 06は約234GBと表示されており、単純合計すると約2.234TBになります。
これらはすべてZIP形式で掲載されています。そのため、AiLockが主張する2.9TBが圧縮前のデータ量で、約2.234TBがZIP圧縮後の容量である可能性も考えられます。
ただし、AiLock自身がこの容量差について説明しているわけではありません。
したがって本稿では、“「2.9TBは攻撃者側の主張」「約2.234TBは公開ページ上で確認できたZIPファイルの表示容量」”として区別して扱います。
ネット探検ラボがこの調査を行う目的
ここで、本稿の調査目的を明確にしておきます。
ネット探検ラボがランサムウェア攻撃や情報流出事件を追跡する目的は、窃取・流出したデータそのものを収集したり、その内容を閲覧したりすることではありません。
攻撃者が公開したファイルリストやディレクトリ構造、公開情報などを分析することで、攻撃者が組織内部のどこまで到達した可能性があるのか、どの程度の範囲へアクセスできたのか、侵入後にどのような行動を取った可能性があるのかを可能な範囲で推定します。
そこから攻撃者の能力や行動を理解し、防御側の知見を深めること。
そして、「同じ攻撃を自分たちが受けたとき、どこで止められるのか」を考え、実際の被害事例から得られた知見を、今後のサイバーセキュリティ対策に活かせる教訓へ変えること。
それがネット探検ラボの調査目的です。
今回もこの方針に基づき、AiLockがPart 01～06として公開している大容量データ本体について、ネット探検ラボではダウンロードを行っていません。
今回の主な分析対象は、AiLockが公開した“「List of Files」”です。
これは、攻撃者が取得したと主張するデータについて、そのファイル名やディレクトリ構造などを列挙したものです。
個人情報そのものを調べるのではなく、このファイルリストを「攻撃者がどこまで到達したのか」を読み解くための材料として分析します。
そして、そのList of Filesを詳しく調べていくと、「2.9TB」というデータ量だけでは見えてこなかった、今回の侵害の広がりが浮かび上がってきました。
57万件の「List of Files」から見えてきたもの
今回確認したList of Filesには、約57万件のファイル・ディレクトリエントリが記録されています。
しかし、重要なのは「57万」という数字そのものではありません。
注目したいのは、そのディレクトリ構造です。
リストの上位階層には、
driverlicenseSQL_backup全社共有部門
など、用途を推測できる名称が確認できます。
特に大きいのが「部門」と「全社共有」です。
「部門」配下だけで約45万6,000件、「全社共有」配下では約11万1,000件に達しています。
さらに「部門」の下を追っていくと、本社だけに限定された構造ではありません。
複数の営業所や事業部、採用、研修、工場など、異なる業務や拠点を示す多数のディレクトリが存在しています。
ここから最初の重要な特徴が見えてきます。
一つのPCから持ち出されたデータとは様相が違う
仮に一人の従業員が使用するPCだけが侵害され、その端末内に保存されていたファイルだけが持ち出されたのであれば、通常はその利用者の担当業務に関係するデータが中心になると考えられます。
ところが今回のList of Filesは、そのような構成には見えません。
異なる部門、異なる業務、異なる拠点を示すディレクトリが、一つの巨大なファイルリストに含まれています。
もちろん、ここから…
- 「Active Directoryを完全に掌握された」
- 「ドメイン管理者権限を奪われた」
- 「バックアップサーバーそのものを乗っ取られた」
…などと断定することはできません。
- 攻撃者がどこから侵入したのか。
- どの認証情報を取得したのか。
- どのように内部を移動したのか。
…これらについては、今回のList of Filesだけでは分かりません。
しかし、AiLockが公開したリストが実際に取得したデータを反映しているという前提に立てば、少なくとも一つのことは見えてきます。
攻撃者が到達した環境から、組織内のかなり広い範囲に存在する業務データを読み取ることができた可能性がある。
ここが今回の事件を防御側から考えるうえで、最初の重要なポイントだと考えています。
PDFだけで約18万件 異なる種類のデータが混在
次にファイルの種類を確認しました。
List of Filesを拡張子ごとに分類すると、PDFが約18万2,000件、Excelの.xlsxが約9万件、CSVが約4万2,000件、Word文書が約1万5,000件確認できます。
さらにJPEGなどの画像、動画、データベース関連とみられるファイルも大量に含まれています。
.dbだけでも約6,100件が確認できます。
つまり、AiLockが取得したと主張しているのは、単なるWordやExcelによる「社内文書の山」ではありません。
文書、表計算、画像、動画、CSV、データベース関連ファイルなど、性質の異なる業務データが広範囲に混在していることがList of Filesから分かります。
ここにも防御上の意味があります。
一つの重要文書だけが流出することと、異なる業務システムや部署から生成された大量のデータがまとめて取得されることでは、その後に第三者ができることが違います。
一見すると重要性の低そうなデータでも、複数の情報を組み合わせれば、人、組織、取引、業務などの関係性を推測できる場合があります。
攻撃者にとって価値があるのは、目立つ「極秘資料」だけではないのです。
「約8,000件の運転免許証」という主張は本当なのか
そして今回、特に確認したかったのがAiLockによって新たに追加された、
about 8,000 driver’s licenses
という記述です。
List of Filesには、最上位にdriverlicenseという明確な名称のディレクトリが存在します。
さらに、それ以外のディレクトリにも「免許」に関連するとみられる名称のファイルが多数存在しています。
そこでネット探検ラボでは、ファイルの中身を見るのではなく、ファイルパスと拡張子のみを対象として機械的に集計しました。
その結果、driverlicense配下や「免許」を含むパスには、JPEG、PNG、PDFなど画像・文書形式のファイルが大量に存在し、その数は約7,800件となりました。
これは興味深い結果です。
AiLockの主張は「約8,000件」。
List of Filesから機械的に抽出された免許関連とみられる画像・文書ファイルは約7,800件。
両者はかなり近い数字になります。
ただし、ここには重要な注意点があります。
約7,800ファイル＝約7,800人ではありません。
ファイル名には免許証の表面・裏面を示すとみられるものも存在します。同一人物について複数のファイルが存在する可能性や、更新前後、重複保存なども考えられます。
したがって、ファイル数を人数へ置き換えることはできません。
現段階で言えるのは…
AiLockが主張する「約8,000」という数字と、公開されたList of Filesの構造との間には一定の整合性が確認できる
…というところまでです。
そして、List of Filesをさらに追っていくと、もう一つ見過ごせないものがありました。
「SQL_backup」――バックアップとみられるファイルまで存在する
List of Filesの最上位階層には…
SQL_backup
…というディレクトリが存在します。
その配下には、Microsoft SQL Serverのバックアップで一般的に利用される.bak形式のファイルが複数確認できます。
しかも、小さなテストファイルという規模ではありません。
リスト上には、数十GBから250GBを超える規模の.bakファイルも存在しています。
さらに別の部門配下にも、定期的なバックアップを思わせる名称を持つ.bakファイルが複数確認できます。
これは重要です。
ただし、ここでも事実と推定を分けなければなりません。
このList of Filesだけから、
「AiLockがバックアップサーバーそのものを侵害した」
とは断定できません。
SQL Serverへ直接侵入したことを示す証拠でもありません。
本番データベースから生成されたバックアップファイルが別の共有ストレージなどへ保存されており、その領域を攻撃者が読み取れた可能性もあります。
しかし、防御側から見れば、それでも重大な意味があります。
本番データベースへ直接侵入しなくても、そのコピーであるバックアップファイルへ到達できれば、そこに保存された情報を取得できる可能性があるからです。
ここから、今回の事件が私たちに突き付ける重要な教訓の一つが見えてきます。
バックアップは「復旧できる」だけでは足りない
ランサムウェア対策では、バックアップの重要性が繰り返し指摘されています。
本番環境が暗号化されても、正常なバックアップが残っていれば復旧できる。
これは非常に重要です。
しかし、現在のランサムウェア攻撃では、もう一つの視点が必要です。
データ窃取です。
仮に攻撃者がバックアップを削除できなかったとしても、そのバックアップを「読む」ことができたらどうでしょうか。
バックアップは残っています。
システムも復旧できます。
しかし、そのコピーが攻撃者の手元へ渡ってしまえば、可用性を守ることには成功しても、機密性を守ったことにはなりません。
だからこそ、バックアップについても…
- 「消されないか」
- 「暗号化されないか」
…だけではなく、
- 「盗まれないか」
…という視点が必要になります。
- バックアップ保存領域を誰が読み取れるのか。
- 通常のユーザーや侵害された端末から到達できない構造になっているのか。
- 本番環境とバックアップ環境の認証情報は分離されているのか。
- バックアップ自体は暗号化され、その鍵は別のセキュリティ境界で管理されているのか。
- そして、数十GB、数百GBというバックアップファイルが通常とは異なる方法で読み出された場合、それを検知できるのか。
今回のList of Filesは、バックアップ戦略を「復旧」のためだけに考えてはいけないという、防御側にとって非常に重要な問題を投げかけています。
AiLockはどこまで入り込んだのか――攻撃者の力量を考える
ここまで見てきたList of Filesからは、AiLockが取得したと主張するデータの規模と広がりが見えてきました。
では、ここから攻撃者の力量について、どこまで推定できるのか。。。
最初に明確にしておかなければならないことがあります。
今回のList of Filesだけでは、AiLockが日本交通へ最初に侵入した方法は分かりません。
- VPNなどの外部公開機器の脆弱性を悪用したのか。
- フィッシングなどによって認証情報を取得したのか。
- 何らかのマルウェアを実行させたのか。
- あるいは、別の経路が存在したのか。
日本交通は「外部からの不正アクセス（マルウェア感染）」と公表していますが、現時点で公表されている情報だけから具体的な初期侵入経路を特定することはできません。
したがって、ここから先は“「どうやって入ったか」ではなく、「入った後に何ができたと考えられるか」”を中心に見ていきます。
57万件のリストは「侵入後」の行動を考える材料になる
攻撃者が企業ネットワークへ侵入したとしても、それだけで組織内のすべてのデータが見えるわけではありません。
侵入後には、自分がどこにいるのか、どのシステムへアクセスできるのか、どこに価値のあるデータが存在するのかを調べる必要があります。
MITRE ATT&CKでは、このような侵入後の情報収集活動を「Discovery（探索）」という戦術として整理しています。
今回のList of Filesから特に連想されるのが、“File and Directory Discovery（T1083）”です。
これは攻撃者が侵害したシステム上でファイルやディレクトリを列挙し、どのような情報が存在するのかを調査する行動です。
ただし、今回確認したList of FilesそのものがAiLockの探索ツールによって生成されたものなのか、それとも窃取後に別の方法で作成された一覧なのかは分かりません。
したがって、「AiLockがT1083を実行したことが証明された」とまでは言えません。
しかし、57万件規模のファイルとディレクトリ構造を把握し、それを公開できる状態になっているという結果は、少なくとも攻撃者が大量のデータを体系的に扱える状態まで到達した可能性を示しています。
注目すべきは「横への広がり」
今回、ネット探検ラボが特に注目したのは、侵害の深さだけではありません。
横方向への広がりです。
List of Filesには、本社だけではなく、複数の部門、営業所、事業部、採用、研修、工場など、組織内の異なる領域を示すディレクトリが含まれています。
さらに全社共有領域、運転免許証関連とみられる領域、SQLバックアップとみられる領域まで存在します。
ここから考えなければならないのは、
「一つの認証情報や一つの侵害端末から、どこまでアクセスできる設計だったのか」
という問題です。
もちろん、AiLockが複数のアカウントを取得した可能性もあります。
権限昇格を行った可能性もあります。
複数端末を侵害しながら横展開した可能性もあります。
逆に、非常に広いアクセス権を持った一つのアカウントを取得しただけだった可能性もあります。
List of Filesだけでは、これらを区別できません。
しかし防御側にとって重要なのは、攻撃者がどの方法を使ったとしても、最終的にこれほど広いデータへ到達できた可能性があるという結果です。
「共有フォルダ」が攻撃者にとって宝の山になる可能性
ここで注目したいのが、ネットワーク上の共有領域です。
企業では業務効率のため、ファイルサーバーやNASなどに共有フォルダを作り、複数の従業員が同じデータへアクセスできるようにすることがあります。
これは業務上必要な仕組みです。
しかし攻撃者から見ると、侵害したアカウントに広い読み取り権限が与えられていれば、共有領域は大量のデータへ一度にアクセスできる場所にもなります。
MITRE ATT&CKには、これに対応する“Data from Network Shared Drive（T1039）”という手法があります。
攻撃者が侵害したシステムからネットワーク共有ドライブを探索し、そこに存在する情報を収集する行動です。
今回のList of Filesには「全社共有」と明示された巨大なディレクトリ構造が存在します。
だからといってAiLockがT1039を使用したと断定することはできません。
しかし、今回の事例を防御側から考える際には、ネットワーク共有領域からの大量データ取得を想定する必要があります。
重要なのは「書き込み権限」だけではない
企業のアクセス権管理では・・・
- 「このユーザーはファイルを変更できるか」
- 「削除できるか」
・・・という書き込み権限に注意が向きがちです。
しかし、情報窃取型の攻撃を考える場合、もう一つ重要な権限があります。
読み取り権限です。
攻撃者は必ずしもファイルを書き換える必要はありません。
削除する必要もありません。
読めればよいのです。
仮に侵害されたアカウントが、
営業部門の共有フォルダを読める。
人事関連フォルダも読める。
全社共有も読める。
バックアップ保存領域も読める。
という状態であれば、攻撃者はシステムを破壊することなく大量の情報を収集できる可能性があります。
つまり、ランサムウェア対策で考えるべき「最小権限」は、
「何を書き換えられるか」だけではなく、「何を読めるか」まで含めて設計する必要があります。
今回のList of Filesは、その問題を非常に分かりやすく示しているように見えます。
AiLockの力量を「高度な攻撃者」の一言で片付けない
では、AiLockは高度な技術を持った攻撃者なのでしょうか。
現時点では、そう断定する材料はありません。
未知の脆弱性、いわゆるゼロデイを利用した証拠もありません。
独自の高度な攻撃ツールを使用したことも、今回のList of Filesからは分かりません。
その意味では、初期侵入能力についてAiLockを評価する材料は不足しています。
しかし、侵入後の結果については別です。
今回のList of Filesが実際に取得したデータを反映しているとすれば…
- 複数の組織領域にまたがる大量のデータを発見し
- それを収集し
- 大量のデータを外部へ持ち出し
- さらにZIP形式にまとめて分割し
- 公開可能な状態まで処理した
という一連の能力があった可能性があります。
ここで重要なのは、映画のような「天才ハッカー」であるかどうかではありません。
既存の技術やツールを利用していたとしても、侵入後の探索・収集・持ち出しを実際に完遂できる攻撃者は十分に危険です。
防御側が相手にするのは、攻撃手法の華麗さではありません。
最終的にデータを持っていかれるかどうかです。
2TBを超えるデータは一瞬では外へ出ていかない
そして、ここでもう一つ重要な問題が出てきます。
AiLockは窃取量を2.9TBと主張しています。
仮にその主張がおおむね事実だったとすれば、これは非常に大きなデータ量です。
数GB程度のファイルを持ち出すのとは事情が違います。
大量のファイルを探索し、読み出し、必要に応じてまとめ、そして組織外へ転送するには相応の処理と通信が必要になります。
ここに、防御側にとって非常に重要な検知機会が存在します。
たとえば…
- 通常とは異なる大量のファイル読み取り。
- 短時間での大量ディレクトリ列挙。
- 普段アクセスしない部署の共有領域へのアクセス。
- 数十GB、数百GB級のバックアップファイルへのアクセス。
- 大量データの圧縮処理。
- 通常とは異なる大容量の外向き通信。
こうした行動が組み合わされれば、初期侵入そのものを防げなかったとしても、データが組織外へ出ていくまでのどこかで異常を検知できる可能性があります。
ここが、今回の記事で最も重要な転換点です。
攻撃者が入ってしまった。
だから終わり。
ではありません。
侵入された後にも、防御側にはまだ止める機会があります。
むしろ今回の57万件というList of Filesと、AiLockが主張する2.9TBという規模から考えるべきなのは、
「入口を突破された後、2.9TBが外へ出るまでに、私たちは何回その攻撃を止める機会を持っていたのか」
ということではないでしょうか。
次は、この問いを起点にして、“「防御側はどこで止められたのか」”を具体的に分解してい来たいと思います。
入口対策だけではなく、最小権限、ネットワーク分離、共有フォルダのアクセス制御、バックアップ分離、大量読み取りの検知、そして外向き通信の監視まで。
今回の事件から得られる教訓を、具体的な防御策へ落としていきたいと思います。
AiLockはどのようにデータを探したのか
ここまで見てきた約57万件のList of Filesからは、攻撃者がかなり広い範囲のデータへ到達した可能性が見えてきました。
では、これほど大量のデータの中から、攻撃者はどのようにファイルを探し、収集したのでしょうか。
ここで参考になるのが、先ほど紹介したMITRE ATT&CKです。
MITRE ATT&CKでは、攻撃者が侵入後にファイルやディレクトリを列挙し、目的の情報が存在する場所を探す行動を“File and Directory Discovery（T1083）”として整理しています。
MITREの説明でも、攻撃者は侵害した端末やネットワーク共有上のファイルやディレクトリを列挙し、その情報をその後の攻撃行動に利用する場合があるとされています。
今回、AiLockがこの手法を使用したことを直接示すログはありません。
そのため、
「AiLockがT1083を実行した」
と断定することはできません。
しかし、約57万件に及ぶファイル名とディレクトリ構造がList of Filesとして存在するという結果から考えれば、攻撃者が何らかの方法で大量のファイルやディレクトリを把握できる状態にあった可能性は高いと考えられます。
そして、もう一つ今回のList of Filesと非常に関係が深いのが、“Data from Network Shared Drive（T1039）”です。
これは、侵害したシステムからアクセス可能なネットワーク共有ドライブやファイルサーバーなどを探し、そこから情報を収集する行動です。MITRE ATT&CKでも、侵害した端末からアクセス可能な共有ドライブを通じて、リモートシステム上の機微なデータが収集される場合があると説明されています。
今回のList of Filesには「全社共有」という大規模なディレクトリが存在し、その配下だけでも約11万1,000件に及ぶエントリが確認されています。
さらに「部門」配下には約45万6,000件が存在し、複数の部署や拠点を示すディレクトリへ広がっています。
ここでも、AiLockがT1039を使用したと断定することはできません。
しかし、ネットワーク上で共有されていた可能性のある大量の業務データへ、攻撃者がアクセスできる状態になっていたのではないかという視点は、防御側にとって重要です。
「共有できる」は「誰からでも読める」であってはならない
企業にとって共有フォルダは便利な仕組みです。
複数の従業員が同じ資料を利用し、部署をまたいで業務を進めるためには欠かせません。
しかし、攻撃者から見れば事情が変わります。
一つのアカウントを侵害しただけで、多数の部署や共有領域を読み取ることができれば、その利便性はそのまま攻撃者の利便性にもなってしまいます。
ここで重要になるのが、読み取り権限の最小化です。
セキュリティというと「ファイルを書き換えられるか」「削除されるか」に目が向きがちですが、情報窃取を目的とする攻撃者にとっては、ファイルを書き換える必要すらありません。
読めればいいのです。
今回のList of Filesが示唆しているのは、この問題です。
- 本社
- 営業所
- 事業部
- 採用や研修
- 全社共有
- 運転免許証関連とみられる領域
- そしてSQLバックアップとみられる領域
これほど性質の異なるデータが一つのList of Filesに並んでいるのであれば、防御側は、
「侵害された一つのアカウント、あるいは一つのシステムから、どこまで読むことができるのか」
を改めて確認する必要があると考えます。
そして興味深いことに、MITRE ATT&CKはT1083について、通常とは異なるユーザーやプロセスによる再帰的なディレクトリ探索や、広範囲・機微な領域へのアクセスを検知対象として挙げています。T1039についても、ネットワーク共有に対する通常とは異なる読み取りやコピー操作の監視が示されています。
つまり、ここに一つの防御機会があります。
侵入そのものを防げなかったとしても、攻撃者が組織内部を探し始めた段階で、その異常な動きを捉えられる可能性がある。
今回の約57万件というList of Filesは、単に「大量のデータがあった」という話ではありません。
防御側から見れば、
「これほど広い範囲を探索・収集されるまでに、どこかで異常を検知できなかったのか」
という、次の問いにつながっていくと考えます。
57万件の列挙は自動化されていたのか
ここでもう一つ、攻撃者の行動について考えてみたいと思います。
今回確認したList of Filesは約57万件に及びます。
これほど大量のファイルやディレクトリを、人間が一つずつ確認しながら探していったとは考えにくいでしょう。
そこで考えられるのが、アクセス可能な領域を再帰的に探索する何らかの自動化された処理です。
専用のマルウェアを投入してファイルシステムやネットワーク共有をクロールした可能性もあれば、スクリプト、OSの標準機能、既存の管理ツールなどを利用した可能性もあります。
今回のList of Filesだけから、その方法を特定することはできません。
しかし、driverlicense、SQL_backup、全社共有、部門など性質の異なる領域が巨大な一覧として列挙されていることを考えると、侵入後にアクセス可能な領域を機械的に探索し、その結果を基に価値のあるデータを選別・収集した可能性は、合理的な仮説の一つとして考えることができます。
自動化された探索は、防御側にとって検知の機会にもなる
もし、このような探索が自動化されていたとすれば、それは攻撃者にとって効率的である一方、防御側にとっては一つの検知機会にもなります。
人間が必要なファイルを一つずつ開く通常業務とは異なり、再帰的なクロールでは、短時間に大量のディレクトリやファイルへアクセスする可能性があります。
- 普段利用しない共有領域へ次々とアクセスする。
- 複数の部署をまたいで大量のファイルを列挙する。
- 数十GB、数百GBというバックアップファイルへアクセスする。
こうした動きは、一つひとつを見れば正規のファイルアクセスと区別しにくくても、量、速度、範囲、時間帯、アクセスしたユーザーや端末を組み合わせて見れば、通常とは異なる行動として検知できる可能性があります。
つまり防御側は、「不正ログインがあったか」だけを見ていればよいわけではありません。
ログインした後、そのユーザーや端末が何を始めたのか。
そこまで監視することが重要になります。
侵入を防げなかった。その後をどうするのか
今回のList of Filesから見えてきた最大の問題は、「2.9TB」という数字の大きさだけではありません。
- 約57万件に及ぶファイル・ディレクトリ構造。
- 複数の部門や拠点。
- 全社共有領域。
- 運転免許証関連とみられる大量のファイル。
- そしてSQLバックアップとみられるデータ。
これらが一つのList of Filesに含まれているという事実から考えたいのは、一度侵入を許した後、攻撃者をどこまで行かせてしまうのかという問題です。
サイバー攻撃への対策というと、どうしても「侵入させない」ことに意識が向きます。
もちろん、それは第一の防御として重要です。
しかし、脆弱性、認証情報の窃取、フィッシング、人為的なミスなど、攻撃者が利用できる入口を完全にゼロにすることは容易ではありません。
だからこそ、侵入されないための防御と、侵入されても被害を広げないための防御。
この二つを同時に考える必要があります。
- 一つのアカウントが侵害されても、必要のない部署のデータまでは読めない。
- 一つの端末を突破されても、重要なサーバーやバックアップ領域までは到達できない。
- 大量のファイル探索が始まれば、それを異常として検知する。
- 大量のデータが読み出されれば、それを検知する。
- そして大量のデータが組織外へ向かえば、そこで再び検知・遮断する。
一つの防御線を突破されても、次の防御線で止める。
今回の事件から得られる教訓は、ここにあるのではないでしょうか。
攻撃者の足跡を、防御側の知識へ変える
本稿では、AiLockが公開したデータそのものではなく、List of Filesを分析してきました。
そこから見えてきたのは、単なる「大量の情報流出」という言葉だけでは分からない、侵害範囲の広がりでした。
一方で、今回の分析だけでは分からないことも数多くあります。
- AiLockが最初にどのように侵入したのか。
- どのような権限を取得したのか。
- 内部でどのように移動したのか。
- ファイル探索にどのツールを使用したのか。
- そして、どの経路からデータを外部へ持ち出したのか。
これらについては、確認できる証拠がない以上、断定するべきではありません。
しかし、分からない部分があるからといって、そこから何も学べないわけではありません。
約57万件のList of Filesという攻撃後に残された情報から、攻撃者がどこまで到達できた可能性があるのかを考え、その途中にどのような防御を置くことができるのかを考えることはできます。
攻撃者の行動を分析する目的は、その能力を誇張したり、攻撃手法そのものを興味本位で追いかけたりすることではありません。
攻撃者が通った可能性のある道を逆方向からたどり、防御側が次に置くべき「関所」を見つけるためです。
被害事例を、単なる被害事例で終わらせない。
攻撃者が残した足跡から、その行動を読み解く。
そして、そこから得られた知見を次の防御へつなげる。
ネット探検ラボでは、今後もこの視点からサイバー攻撃を追跡・分析していきたいと思います。
関連資料：日本交通侵害事案 分析報告書
本記事の作成にあたり、AiLockが公開した「List of Files（ファイルツリー一覧）」を基に、攻撃者の到達範囲や力量、防御側が得るべき教訓について分析を行いました。
分析対象は、ファイル名・パス・拡張子・サイズ・ディレクトリ構造などの目録情報のみです。窃取されたとされる文書・画像・データベースなど、データ本体の内容は分析対象としていません。
より詳しい分析結果については、以下のPDFにまとめています。
『AiLockランサムウェアによる日本交通侵害事案
リーク目録（インデックス）分析報告書』
2026年8月11日／全6ページ
コメント