攻撃者が攻撃者を攻撃したとき

サイバーセキュリティー

サイバー犯罪者同士の衝突から、防御側には何が見えるのか？

サイバー犯罪者同士が、何やら揉めているぞ！笑

サイバー犯罪の世界で、ちょっと妙なことが起きています。

企業や組織を攻撃し、盗んだ情報をリークサイトに掲載して金銭を要求する攻撃者たち。

ところが今回は、その攻撃者自身が別の攻撃者から攻撃されました。

ShinyHunters（シャイニーハンターズ）が、ランサムウェアグループとして知られるCl0p（クロップ）のリークサイトへ侵入したのです。

「攻撃する側が攻撃されているじゃないか」と、少し笑ってしまいそうな話でもあります。

しかし、ネット探検ラボがこの出来事に注目した理由は、犯罪者同士の争いを面白がるためではありません。

むしろ注目したのは、その先です。

攻撃者が攻撃者を攻撃したとき、防御側には何が見えてくるのだろうか？というものです。

普段、サイバー犯罪グループの内部は外から簡単には見えません。

どんなサーバーを使い、どんなソフトウェアを動かし、どのようにリークサイトを管理しているのか。どんなログが残り、どんな鍵を管理し、どのような運用をしているのか。

ところが犯罪者同士が攻撃し合えば、その一部が思わぬ形で外へ露出することがあります。

今回もShinyHuntersは、Cl0pのソースコード、Grav CMSのプラグイン、サーバーログ、さらにTor（トーア）上のサービスで使用する秘密鍵などを取得したと主張しています。

もちろん、これはShinyHunters側の主張であり、そのすべてが独立して確認されたわけではありません。

それでも、こうした「犯罪者側からの情報流出」は、防御側にとって重要な観測機会になり得ます。

こちらから犯罪インフラへ侵入するのではありません。

外へ出てきた情報を観測し、検証し、そこから攻撃者のインフラや手法、運用上の特徴を読み取る。

犯罪者同士の争いを眺めて笑って終わるのではなく、そこから防御に使える情報を拾い上げる。

今回は、そんな視点からShinyHuntersによるCl0pリークサイト侵害を追ってみたいと思います。

まず、この2つのサイバー犯罪者は何者なのか？

今回の出来事を理解するために、まず登場する2つの名前について少し詳しく見てみましょう。

“ShinyHunters（シャイニーハンターズ）とCl0p（クロップ）”です。

どちらも金銭を目的とするサイバー犯罪の世界で知られた名前ですが、その歩みと攻撃スタイルは同じではありません。

活動履歴を追ってみると、サイバー犯罪そのものがどのように変化してきたのかも見えてきます。

ShinyHunters――盗んだデータを「商品」と「脅迫材料」にする

ShinyHuntersという名前が広く知られるようになったのは、2020年ごろです。

米司法省によれば、2020年4月から2021年7月にかけて、ShinyHuntersの名前で60社を超える企業から盗まれたデータが、RaidForumsなどの犯罪フォーラムで販売されました。

盗まれたものには、顧客情報、個人情報、金融関連情報なども含まれていました。

初期の活動を単純化すると…

侵入する
↓
データを盗む
↓
犯罪市場で販売する

…という「データ窃取型」のサイバー犯罪です。

侵入方法として、正規企業のログイン画面を模倣したフィッシングサイトを作り、従業員から認証情報を盗む手法なども米司法省の事件資料で明らかになっています。

つまり、最初から「高度なマルウェアだけで勝負する犯罪者」だったわけではありません。

人間をだまし、正規ユーザーの資格を奪う。

この考え方は、現在のクラウドサービスを狙った攻撃にも通じています。

クラウドに集まる「企業のデータ」を狙う

ShinyHunters周辺の活動を見ていくうえで、もう一つ重要なのがクラウドサービスを狙ったデータ窃取です。

現在、多くの企業は顧客情報や営業情報、大量の業務データなどを、自社のパソコンやサーバーだけで管理しているわけではありません。

さまざまなクラウドサービスを利用しています。

たとえば“Snowflake（スノーフレーク）”は、企業が大量のデータをクラウド上に保存し、検索・集計・分析するためのデータ基盤です。

“Salesforce（セールスフォース）”は、顧客情報や商談、営業活動などをクラウド上で管理するCRM（Customer Relationship Management：顧客関係管理）サービスです。

用途は異なりますが、攻撃者から見ると共通点があります。

『企業にとって価値のあるデータが集まっている」という点です。

では、攻撃者はどうやってそこへ侵入するのでしょうか。

必ずしもSnowflakeやSalesforceそのものの「システムの穴」を見つけて突破するわけではありません。

むしろ、そこで利用される正規のアカウントを奪う方法があります。

2024年に発生したSnowflake顧客環境からの大規模なデータ窃取事件は、その分かりやすい例です。

MandiantがUNC5537として追跡した攻撃者は、Snowflakeそのものの脆弱性を突いたのではなく、過去に情報窃取型マルウェアなどによって盗まれていた顧客側のIDやパスワードを利用してSnowflake環境へアクセスしました。

被害を受けた一部のアカウントでは、MFA（Multi-Factor Authentication：多要素認証）も設定されていませんでした。

たとえるなら…

金庫を壊したのではなく、盗んだ「本物の鍵」を使って金庫を開けた。

…という攻撃です。

そして近年のShinyHuntersブランドに関連する活動でも、これとよく似た「正規のアカウントを奪う」という考え方が見られます。

Salesforceなどを利用する企業の従業員へ電話をかけ、IT担当者などを装って相手を信用させる
“ビッシング（Voice Phishing：音声を使ったフィッシング）”です。

攻撃者は人をだますことで、ログインに必要な認証情報やMFAコードなどを取得し、正規ユーザーになりすましてクラウド環境へアクセスします。

つまり、システムを壊して侵入するのではなく、人から「鍵」を奪って正面から入る。

そしてアクセスできてしまえば、そこには企業の重要なデータが集まっています。

このように、近年のデータ窃取型攻撃では、必ずしも高度なマルウェアや未知の脆弱性だけが武器になるわけではありません。

「重要なデータはどこに集まっているのか」
「そこへ入るための正規のアカウントをどう奪うのか」

そこに目を付ける攻撃が、大きな脅威になっています。

「ShinyHunters」という名前には注意が必要

ここで一つ、ShinyHuntersについて注意しておきたいことがあります。

現在「ShinyHunters」と呼ばれている活動のすべてを、一つの固定された組織によるものと考えるのは正確ではありません。

Google Threat Intelligence Group（GTIG）は、ShinyHuntersの名前に関連する活動について、UNC6240、UNC6661、UNC6671など、複数の脅威クラスタに分けて追跡しています。

「では、RaaS（Ransomware as a Service：ランサムウェア・アズ・ア・サービス）のようなものなのか？」と思われるかもしれません。

しかし、それとも少し違います。

RaaSとは、ランサムウェアの開発・運営側が攻撃に必要な基盤を提供し、「アフィリエイト」と呼ばれる実行役がそれを利用して攻撃を行い、得られた身代金などを分配する犯罪モデルです。

ShinyHuntersについてGTIGが複数のクラスタに分けているのは、そのような明確なサービス提供型の仕組みが確認されているからではありません。

活動ごとに関係する攻撃者が異なる可能性や、協力関係の変化、さらには別の攻撃者がShinyHuntersの名前を利用している可能性などを考慮し、観測された活動を区別して追跡しているのです。

したがって、本稿でも、

「ShinyHuntersという名前」と「実際に観測された個々の攻撃活動」を完全に同一視しない。

この点には注意しながら見ていきたいと思います。

そして2026年――PeopleSoftを狙った攻撃

2026年には、Oracle PeopleSoftを標的とした攻撃でもShinyHuntersの名前が登場します。

PeopleSoftは、企業や大学などで、人事、給与、財務といった業務を管理するために利用される企業向けシステムです。

Google/Mandiantによれば、UNC6240は2026年5月末から6月にかけて、PeopleSoftの脆弱性CVE-2026-35273を、修正プログラムが公開される前の「ゼロデイ脆弱性」として悪用していました。

そして9月になると、さらに興味深い動きが観測されます。

防御側は、攻撃に利用されていた…

/PSEMHUB/

…というURLへのアクセスをWAF（Web Application Firewall：ウェブ・アプリケーション・ファイアウォール）で遮断しました。

WAFとは、Webサーバーへ送られてくる通信を検査し、攻撃と思われる通信を入口で止める「門番」のような仕組みです。

ところが攻撃者は…

/PSEMHUB/

という表記を…

/%50SEMHUB/

…へ変更しました。

「%50」は、URLエンコードという表記方法ではアルファベットの「P」を意味します。

人間が文字列として見れば…

PSEMHUB

と、

%50SEMHUB

…は違って見えます。

単純に「PSEMHUBという文字列を含む通信を遮断する」というルールであれば、WAF側でも別の文字列として扱われる可能性があります。

ところが、その通信を受け取ったPeopleSoft側ではURLが元の文字へ戻され、

%50SEMHUB

は、

PSEMHUB

として解釈されます。

たとえるなら、

門番に「PSEMHUBという名前の人物を通すな」と指示したところ、攻撃者が最初の「P」だけを別の表記に変えて門を通り、建物の中では元の名前として扱わせた。

そんなイメージです。

ここで注目したいのは、単なる文字遊びではありません。

防御側が対策した。
攻撃者がその対策を観察した。
そして攻撃方法を変更した。

攻撃者が防御側の動きを見ながら、自らの手法を変化させていることが、実際の通信から見えてきた事例なのです。

一方のCl0p――暗号化型ランサムウェアから大量データ窃取へ

では、今回「攻撃される側」になったCl0pは、どのようなサイバー犯罪グループなのでしょうか。

Cl0pが広く知られるようになったのは2019年ごろです。

初期には企業ネットワークへ侵入し、データを盗み、さらにファイルを暗号化して金銭を要求する「二重恐喝型ランサムウェア」の活動で知られるようになりました。

つまり…

データを盗む
＋
ファイルを暗号化する
＋
情報公開をちらつかせて金銭を要求する

…という攻撃です。

ところが、その後Cl0pの攻撃モデルは少しずつ変化していきます。

2020～2021年――Accellion FTA

その変化を象徴する一つが、Accellion FTA（File Transfer Appliance）を狙った一連の攻撃です。

Accellion FTAは、企業や組織が重要なファイルを外部とやり取りするために使用していたファイル転送システムです。

攻撃者は製品に存在した脆弱性を利用して複数の組織からデータを盗み出し、その情報公開を材料として恐喝しました。

ここで重要なのは、

一社ずつ異なる侵入口を探すのではなく、多くの企業が共通して利用している製品の弱点を狙う。

という発想です。

一つの製品に重大な脆弱性が存在すれば、その製品をインターネットへ公開している多数の組織を、同じ攻撃方法で狙える可能性があります。

この考え方は、その後のCl0pの活動を理解するうえで重要になります。

2023年――Fortra GoAnywhere MFT

次に大きく注目されたのが、Fortra GoAnywhere MFTです。

MFTとはManaged File Transfer（マネージド・ファイル・トランスファー）の略で、企業や組織が重要なファイルを安全に送受信・管理するためのシステムです。

一般向けに言えば、「企業向けの重要ファイル交換所」と考えると分かりやすいでしょう。

2023年、GoAnywhere MFTに存在した脆弱性CVE-2023-0669が実際の攻撃に悪用され、多数の組織を対象とするデータ窃取へとつながりました。

そして同じ2023年、さらに大規模な事件が発生します。

MOVEit Transfer大量侵害事件

MOVEit Transferも、GoAnywhereと同じように、企業や組織が重要なファイルを安全に受け渡すためのMFT製品です。

2023年、Cl0pはMOVEit Transferに存在したSQLインジェクション脆弱性CVE-2023-34362を悪用しました。

SQLインジェクションとは、Webシステムからデータベースへ送られる命令に、攻撃者が不正な命令を紛れ込ませる攻撃です。

MOVEitを、「企業の重要書類を預かる電子金庫」だと考えてみましょう。

Cl0pは、一社一社の社員へフィッシングメールを送り、IDやパスワードを盗んで金庫を開けて回ったわけではありません。

世界中の企業が利用している「電子金庫」という製品そのものに存在する共通の欠陥を突きました。

そして、インターネット上からアクセスできる脆弱なMOVEit Transferへ侵入し、「LEMURLOOT（レムールート）」と呼ばれるWebシェルを設置してデータを盗み出しました。

Webシェルとは、侵害したWebサーバーを外部から操作するために設置される、小さな不正プログラムのようなものです。

攻撃の構造を単純化すると…

インターネット上のMOVEitを探す
↓
共通する脆弱性を突く
↓
Webシェルを設置する
↓
内部のデータへアクセスする
↓
データを持ち出す
↓
公開を材料に恐喝する

…という流れになります。

一つの企業だけを狙うのではありません。

一つの製品に存在する共通の弱点を見つけ、その製品を利用している多数の組織をまとめて狙う。

これがMOVEit大量侵害事件の怖さでした。

そして、この頃になるとCl0pの活動を「ファイルを暗号化して身代金を要求するランサムウェア」だけで説明することは難しくなっています。

脆弱性を利用して大量のデータを盗み、その公開を材料として恐喝する。

データ窃取そのものが、大きな武器になっていったのです。

2つの犯罪者を並べてみると・・・

ここまでの活動履歴を並べると、両者には違いがあります。

ShinyHuntersの名前は、

データ窃取・販売
→ 認証情報の窃取
→ クラウド／SaaSを狙ったデータ窃取・恐喝
→ 公開システムの脆弱性悪用

という流れの中で登場してきました。

一方のCl0pは、

ランサムウェアによる暗号化
→ 二重恐喝
→ ファイル転送製品などの脆弱性悪用
→ 大量データ窃取・恐喝

へと攻撃モデルを変化させてきました。

出発点は違います。

しかし、現在の活動を見ると共通する部分があります。

相手の管理が甘い場所を見つける。
認証や公開システムの弱点を突く。
そこから重要なデータへ到達する。
そして盗んだ情報を金銭へ変える。

そんな犯罪者たちです。

そして今回――。

その矛先が企業ではなく、もう一方の犯罪者へ向きました。

ShinyHuntersが狙ったのは、Cl0p自身が運営するリークサイトでした。

ここで、なんとも皮肉な構図が生まれます。

Cl0pは長年、「インターネットへ公開されているシステムに残された脆弱性」を探し、それを攻撃へ利用してきました。

ところが今度は、そのCl0p自身がインターネットへ公開していたリークサイトで、古いGrav CMSを使用していました。

そして、その弱点を別の攻撃者に突かれたのです。

攻撃する側だった者が、攻撃される側に回った。

ここだけ見れば、確かに少し笑ってしまう話かもしれません。

しかし、ネット探検ラボが見たいのはそこではありません。

ShinyHuntersは、Cl0pのどこを、どのように突いたのか？

そして、その侵入によって、普段は外から見ることのできないCl0pの何が露出したのか。

さらに重要なのは、そこから私たち防御側は、何を拾い上げることができるのか。

ここから、今回の本題に入履帯と思います。

本題――ShinyHuntersはCl0pをどう破ったのか？

ここから、今回の事件そのものを見ていきたいと思います。

始まりは2026年9月です。

ShinyHuntersは、Cl0pがTor（トーア）ネットワーク上で運営していたデータリークサイトへ侵入しました。

ShinyHuntersは、Cl0pが自分たちのリークサイトを構築・運営するために使っていた（WordPressと同じく、Webサイトのページやコンテンツを管理するためのソフトウェア）Grav CMSの脆弱性を悪用して、Cl0pのサーバーへ挑発的なメッセージと自らのリークサイトへのリンクを記した小さなテキストファイルをアップロードしました。

これは、「Cl0pのサーバーへ外部からファイルを書き込める」ことを示す侵入成功の証明」でした。

そして数時間後。

今度はCl0pのリークサイトそのものが書き換えられ、ShinyHuntersが使用するポケモン「ブラッキー（Umbreon）」の図柄と、ShinyHuntersのサイトへのリンクが表示されました。

図：ShinyHuntersによって改ざんされたCl0pのリークサイト（出典：BleepingComputer）

いわゆる“Defacement（デフェイスメント：Webサイトの改ざん）”です。

BleepingComputerは、最初に置かれたファイルが実際にCl0pのTorサーバーから取得できたことと、その後サイトが改ざんされたことを確認しています。

つまり、「Cl0pのサイトが実際に侵害された」という部分については、ShinyHunters側の自己申告だけではありません。

では、どうやって侵入したのか？具体的に見てみたいと思います。

入口は「Grav CMS」だった

Cl0pのリークサイトでは、“Grav CMS（グラブ・シーエムエス）”が使用されていました。

CMSとはContent Management System（コンテンツ・マネジメント・システム）の略です。

WordPressと同じように、Webサイトの記事やページなどを管理するためのソフトウェアだと考えれば分かりやすいでしょう。

ShinyHuntersによれば、Cl0pのサーバーで使用されていたのはGrav CMS 1.7.43でした。

そして、ここに今回の侵入口となった脆弱性が残っていました。

CVE-2026-42608

と呼ばれるPath Traversal（パス・トラバーサル）脆弱性です。

Path Traversalとは何なのか？

名前だけでは分かりにくいので、簡単な例で考えてみましょう。

Webサーバーの中に…

tmp/forms/

…という「ファイルを一時的に置く場所」があったとします。

本来、Webサイトからアップロードされたファイルは、この決められた場所の中だけに保存されるはずです。

ところが、今回問題になった処理では、ファイルを保存する場所を決めるために、外部から送られてきた値が十分に検査されないまま使われていました。

そこで攻撃者が、

../../../

のような特殊な指定を与えます。

コンピューター上で「../」は、基本的に一つ上のディレクトリへ戻るという意味を持ちます。

たとえば、

tmp/forms/A/B/

という場所にいるとします。

そこから、

../

と指定すれば一つ上へ、

さらに、

../../

なら二つ上へ、

という具合に、本来いるはずの場所から外へ移動できてしまいます。

これが“Path Traversal（パス・トラバーサル）”です。

たとえるなら、「この部屋の中だけに荷物を置いてください」というルールだったのに、荷物の送り状へ、「廊下へ出る → 階段を上がる → 別の部屋へ行く」という指示を書き込めてしまったようなものです。

Gravでは何が起きていたのか？

今回の問題は、Gravがフォームからアップロードされたファイルを一時保存する仕組みにありました。

通常は、おおむね…

tmp/forms/<セッションID>/<フォームID>/

…という決められた場所へファイルを置きます。

ところが、この「フォームID」に相当する値を十分に検査していませんでした。

ShinyHuntersがBleepingComputerへ説明した内容では、__unique_form_id__というパラメーターへディレクトリを遡る指定を入れることで、本来のtmp/forms配下から抜け出し、別の場所へファイルを書き込めたとされています。

重要なのは、ログインした管理者だけが利用できる機能ではなかったという点です。

今回の脆弱性は「Unauthenticated（アンオーセンティケーテッド）」、つまり事前の認証を必要としない状態で悪用できるPath Traversalとして説明されています。

攻撃者がCl0pの管理者IDとパスワードを最初から知っていた、或いは、それら認証情報を窃取した、という話ではありません。
外部からファイルを送る処理そのものに問題があったわけです。

そして、そこを見事に突かれたのです。

ShinyHuntersの説明は本当だったのか？

ここは今回の事件で重要なポイントです。

攻撃者が、「この脆弱性を使いました」と言っただけなら、その説明をそのまま事実として扱うことはできません。

ところが今回は、その技術情報をBleepingComputerがGravの開発者へ提示しました。

Grav側は調査したうえで、脆弱性そのものとShinyHuntersが説明した悪用方法が正確であることを確認しています。

この脆弱性が、CVE-2026-42608です。

ただし、ここには少し複雑な事情があったようです。

「修正済み」なのに、なぜCl0pは侵入されたのか？

CVE-2026-42608は、今回初めて発見された脆弱性ではありません。

Gravによれば、この問題は以前に非公開で報告され、現在のメジャーバージョンであるGrav 2.0ではすでに修正されていました。

2026年4月27日にはアドバイザリも公開されています。

修正では、フォームIDとして使用できる文字を、英数字や一部の安全な記号だけに限定しました。

これによって「../」のようなディレクトリ移動に利用できる文字列を受け付けないようにしたわけです。

ところが問題がありました。

その修正が、旧系列のGrav 1.7へ反映されていなかったのです。

Cl0pが使用していたとされるのは、Grav 1.7.43でした。

つまり、現在のGrav 2.xではすでに塞がれていた穴が、旧系列を使い続けていた環境には残っていました。

そしてCl0p自身もBleepingComputerに対し、Gravを完全には更新していなかったことを認めています。

そして皮肉にも、事件が旧版の修正につながった

ここからが、防御側にとって非常に興味深いところです。

BleepingComputerから今回の攻撃方法について連絡を受けたGrav開発側は、旧系列である1.7にも修正を反映しました。

そして、Grav 1.7.53.4を公開しました。

つまり…

ShinyHuntersがCl0pを攻撃する
↓
攻撃方法が外部へ伝わる
↓
セキュリティメディアが開発者へ確認する
↓
旧バージョンにも同じ問題が残っていることが確認される
↓
修正版が公開される

…という流れが生まれたのです。

犯罪者同士の争いによって表面化した情報が、結果として一般のGrav利用者を守る修正へつながりました。

まさに今回の記事で考えたいこと…

「攻撃者を攻撃者が攻撃したとき、防御側には何が見えてくるのか？」

…その最初の答えが、すでにここにあります。

では、ShinyHuntersはCl0pから何を奪ったのか？

ここから話はさらに面白くなります。

ShinyHuntersは、単にCl0pのWebページを書き換えただけではないと主張しています。

彼らによれば、サーバーへ「完全なアクセス」を獲得し…

  • ソースコード
  • Grav CMSのプラグイン
  • サーバーログ
  • その他のファイル

…これらを取得したとしています。

さらに、Linuxなどで各種ログが保存される、

/var/log

以下のファイルも取得したと主張しています。

もしこれが事実なら、そこにはシステムの動作記録や認証記録、場合によってはサーバーへ接続したIPアドレスなどが残っている可能性があります。

そして、もう一つ。

ShinyHuntersは、Cl0pのTor Onionサービスで使用されていた秘密鍵まで取得したと主張しています。

これは単なる「Webサイトのデータを盗んだ」という話とは意味が違ってきます。

しかし――ここは慎重になる必要があると考えています。

BleepingComputerが独立して確認できたのは、Cl0pのサーバーへファイルが置かれたことと、サイトが実際に改ざんされたこと。

一方で…

  • サーバーログを本当に取得したのか。
  • ソースコードをどこまで取得したのか。
  • Torの秘密鍵を本当に取得したのか。

これらについては、現時点ではShinyHunters側の主張であり、BleepingComputerも独立して確認できていません。

さらにCl0p側は…

侵害されたサーバーにはサイトのコンテンツしかなく、重要な運用情報や金融情報などは存在していなかった。

…と反論しています。

つまりここから先は…

ShinyHuntersの主張
対
Cl0pの主張

…です。

どちらもサイバー犯罪者側から出てきた情報でしかありません。

したがってネット探検ラボとしては、どちらかをそのまま信用するのではなく、

「確認された事実」と「当事者の主張」を分けて観測する。

その姿勢で、もう少し深く見ていきたいと思います。

攻撃者が攻撃者を攻撃した、その先に見えるもの

今回の出来事は、一見すると「サイバー犯罪者同士の争い」という、少し珍しい事件にしか見え無いかも知れません。

しかし、その過程を一つずつ追っていくと、別のものが見えて来たように思います。

Cl0pがリークサイトの運営にどのようなソフトウェアを使用していたのか。どこに弱点が残されていたのか。ShinyHuntersはその弱点をどのように見つけ、侵入へ結び付けたのか。そして侵入された側は、その後どのような対応を取ったのか。

普段は外から見えにくい“「攻撃する側のインフラ」”の一部が、攻撃者同士の衝突によって表へ出てきたと言えるでしょう。

そして興味深いのは、企業や組織のシステムを狙ってきたサイバー犯罪者も、自分たちのシステムを運営する立場になれば、私たちと同じ問題に直面するということです。

ソフトウェアを更新する。
脆弱性を把握する。
外部へ公開しているシステムを管理する。
認証情報や重要な鍵を守る。

これを怠れば、今度は自分たちが攻撃される側になります。

今回の事件ではさらに、Cl0pへの攻撃に利用されたGrav CMSの問題が改めて検証され、旧バージョン系列にも修正が提供されることになりました。

犯罪者同士の攻撃によって露出した一つの弱点が、結果として一般の利用者を守るための情報へ変わったことになります。

もちろん、私たち防御側が犯罪者のシステムへ侵入してよいという話ではありません。

こちらから侵入する必要もありません。

公開された情報、脆弱性情報、報道、リークサイトの変化、インフラの移動――。

外側から観測できるものだけでも、そこには多くの情報が残されています。

そして、それらを「ShinyHuntersの手口」「Cl0pの手口」と名前だけで整理するのではなく、

侵入経路、脆弱性、認証、ファイル書き込み、CMS、ログ、インフラ、鍵管理――

それら様々な手口を、一つ一つの「部品」として記録していく…。

ネット探検ラボでは、脆弱性情報とは別に、「様々な犯行手口」を「様々な攻撃手法」として整理し、「攻撃手法の目録」を構築しています。

将来、攻撃パターンやその経路、使用するツールやExploitチェーンなど、それぞれの特徴を「攻撃部品」として整理したデータベースを構築し、各種ソフトウェアの開発から防御側のオペレーションにまで役立てることができればと考えています。

別の事件で同じ「それら部品」が現れたとき、それまで別々に見えていた出来事の間に、思いがけない共通点が見つかるかもしれません。

攻撃者が攻撃者を攻撃したとき。

普段は閉ざされている攻撃者側の世界に、ほんの少しだけ隙間が開くことがあります。

その隙間から何が見えるのか。

そして、

そこから私たちは何を学び、防御へ生かすことができるのか。

ネット探検ラボでは、これからもそんな視点でインターネットの向こう側を観測していきたいと思います。

コメント

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