はじめに――「Exploit」とは何ぞや？

サイバーセキュリティー
2026.09.15

今回取り上げるのは、「BlueMoon（ブルームーン）」と呼ばれるExploit Kit（エクスプロイト・キット）です。

いきなり聞き慣れない言葉が出てきました。

Exploitとは何ぞや？

ここから始めたいと思います。

サイバーセキュリティの記事を読んでいると、「脆弱性」「Exploit」「マルウェア」「Payload」といった言葉が当たり前のように登場します。

まず、Vulnerability（ヴァルナラビリティ）とは、ソフトウェアやシステムに存在する「脆弱性」のことです。

家に例えるなら、鍵が壊れている、窓の構造に欠陥がある、あるいは本来開かないはずの場所から中へ入れてしまう――そんな「弱点」に相当します。

では、Exploit（エクスプロイト）とは何でしょうか。

Exploitとは、その弱点を実際に利用して、本来は許されていない処理を実行させるためのコードや手法を指します。

つまり…

脆弱性は「弱点」。
Exploitは「その弱点を利用する方法」。

ここを区別しておく必要があります。

そして、一つのExploitだけですべての防御を突破できるとは限りません。

たとえば、最初のExploitでWebブラウザ内部の防御を突破する。

しかし、そこにはまだSandbox（サンドボックス）と呼ばれる隔離された領域がある場合がある。

そこで二つ目のExploitを使って、その境界を越える。

さらにWindows側に存在する別の脆弱性を三つ目のExploitで利用し、より高い権限を獲得する。

このように複数のExploitを連結して、一つの攻撃経路を作るものを、

Exploit Chain（エクスプロイト・チェーン）と呼びます。

そして今回の主役であるBlueMoonは、このExploit Chainを実際の攻撃で利用できるように組み上げたExploit Kitです。

ここで、もう一つ重要なことがあります。

BlueMoonそのものを「マルウェア」と考えてしまうと、この事件の本質を見誤ります。

BlueMoonは、侵入後に情報を盗み続けることを主目的とした単体のマルウェアではありません。

ブラウザとWindowsに存在する複数の脆弱性を連続して利用し、最終的に攻撃者が選んだプログラムを実行できるところまで道を開く――いわば侵入経路を作るための道具一式です。

その先で何を送り込むのかは、BlueMoonを利用する攻撃者によって異なります。

ここで登場するのが、“Payload（ペイロード）”です。

Payloadとは、Exploitによって侵入経路を確保したあと、実際に標的のコンピューター上で目的の処理を行わせるために送り込まれるプログラムを指します。

たとえば「情報を盗む」「ブラウザに保存された情報を取得する」「遠隔操作を可能にする」といった、攻撃者が最終的に行いたい処理を担当します。

今回確認された攻撃では、ある攻撃グループはBlueMoonを使って侵入経路を開いたあと、“GemStone（ジェムストーン）”と呼ばれる悪意あるブラウザ拡張機能を投入していました。

別の攻撃グループでは、同じBlueMoonを侵入手段として利用しながら、その先に“ShadowPad（シャドウパッド）”と呼ばれるマルウェアを投入していました。

つまり、簡単に整理すると…

BlueMoon ＝ コンピューターへ侵入するための「突破口を開く道具」

GemStone／ShadowPad ＝ 突破口を開いたあとに送り込まれ、実際の諜報活動などを行う「Payload」

という関係になります。

BlueMoonとは何者なのか？

BlueMoon（ブルームーン）の存在を明らかにしたのは、米国のセキュリティ企業Proofpointです。

Proofpointは2026年9月9日、「Once in a BlueMoon」と題する調査報告を公開しました。

そこで報告されたのは、単なる新しいマルウェアの出現ではありませんでした。

ChromeをはじめとするChromium系ブラウザとWindowsに存在する複数の脆弱性を連続して利用する、新しいExploit Kitが実際のサイバー諜報活動へ投入されていたのです。

Proofpointは、このExploit KitをBlueMoonと名付けました。

最初に確認されたのは、2026年8月28日です。

BlueMoonを使用していたのは、TA412と呼ばれる中国系の国家支援型攻撃グループでした。

TA412は、APT31、Violet Typhoon、JungleBamboo、TIDE CASTLEなど複数の名称でも追跡されている攻撃主体で、今回のBlueMoonを使った攻撃では、米国の非政府組織（NGO）、鉱業企業、現物商品取引に関係する企業などが標的となりました。

攻撃の入口は、非常にありふれたものでした。

電子メールです。

攻撃者は大学生を装ってインターンシップへの応募を持ちかけたり、アジア研究関連の国際会議を装ったりして、標的となる人物へリンクを送りました。

場合によっては、いきなり攻撃用リンクを送りつけるのではなく、標的となる人物とのメールのやり取りを重ね、ある程度の信頼関係を作ってからリンクを送る手法も確認されています。

そして標的となった人物が、そのリンクをクリックする。

ここからBlueMoonが動き始めます。

リンク先には攻撃者が用意したWebページがあり、画面には数秒間、読み込み中であるかのようなページが表示されます。

しかし、その数秒間に裏側ではブラウザに対するExploitが試みられていました。

攻撃が終了すると、利用者はGitHubや学会などの正規Webサイトへ転送されます。

利用者から見れば…

  • 「リンクをクリックした」
  • 「少し読み込みに時間がかかった」
  • 「普通のWebサイトが表示された」

…というだけに見える可能性があります。

ところが、条件が揃ったコンピューターでは、その数秒間にブラウザ内部でExploit Chainが実行されていたのです。

そしてBlueMoonによって侵入経路が開かれたあと、TA412はGemStone（ジェムストーン）と呼ばれる悪意あるブラウザ拡張機能を送り込んでいました。

GemStoneはGoogle GeminiのAIブラウジング支援機能を装いますが、実際にはCookie、キー入力、ブラウザ内の保存情報、閲覧状況、スクリーンショットなどを取得できる監視・情報窃取用のバックドアです。

ここで前項で説明した“Payload（ペイロード）”という言葉が出てきます。

BlueMoonが「侵入するための突破口を開く道具」であるなら、GemStoneはその突破口を通って送り込まれ、実際の情報窃取などを担当するPayload側のプログラムです。

ところが、BlueMoonを使用していたのはTA412だけではありませんでした。

わずか数日の間に別の攻撃主体へ

9月2日になると、ProofpointがUNK_LateNightという仮称で追跡している別の中国系サイバー諜報活動クラスターがBlueMoonを使用し始めました。

こちらの標的は、米国の航空宇宙企業でした。

攻撃者は企業間取引や見積依頼（RFQ）を装ったメールを送り、実在する米航空宇宙企業に似せた偽ドメインへ標的を誘導しました。

しかし、侵入後に送り込まれたものはGemStoneではありません。

この攻撃では、“ShadowPad（シャドウパッド）”と呼ばれるバックドア型マルウェアが使用されていました。

つまり…

●TA412
→ BlueMoonで侵入
→ GemStoneを投入

であるのに対し、

●UNK_LateNight
→ BlueMoonで侵入
→ ShadowPadを投入

…だったのです。

さらに同じ9月2日には、UNK_DoubleCheckと呼ばれる別の活動クラスターが、ベトナムの製造企業を標的とした攻撃でBlueMoonを使用しました。

翌9月3日には、UNK_QuietRacketと呼ばれる別のクラスターによる使用も確認されました。こちらではインドネシアやシンガポールの政府、コンサルティング、金融関連組織などが標的となっています。

Proofpointが確認しただけでも、

8月28日から9月3日までのわずか1週間ほどの間に、少なくとも4つの異なるサイバー諜報活動クラスターがBlueMoonを使用していたことになります。

しかも、それぞれ標的も、フィッシングメールの内容も、最終的に送り込むPayloadも異なっていました。

それにもかかわらず、ブラウザとWindowsの防御を突破する根幹部分には、同じExploit Chainと同一の制御・読み込み機構が使われていたのです。

Proofpointは、確認されたBlueMoonの各ビルドについて、ほぼ間違いなく同じソースから派生したものだと評価しています。

※注）ここでいう「ソース」とは情報源という意味ではなく、“プログラムを作る元となるソースコード（設計図のようなもの）”のことです。
たとえば、同じ設計図をもとに作られた自動車でも、利用者によって色を変えたり、装備を追加したりすることができます。
BlueMoonもこれと似ています。攻撃ごとに細かな違いはあるものの、根幹となるプログラムの構造や動作には強い共通性があり、それぞれがまったく別々に一から開発されたものではなく、共通する元のプログラムから作られた可能性が極めて高い、という意味です。

では、誰がBlueMoonを開発したのでしょうか。

そして、なぜ複数の異なる攻撃主体が、ほぼ同じ時期にこの高度なExploit Kitを利用できたのでしょうか。

ここについては、現在も答えが出ていません。

Proofpointも、複数の異なる攻撃主体がどのようにBlueMoonへアクセスできるようになったのかは不明としています。

したがって現段階で、「中国政府がBlueMoonを各攻撃グループへ配布した」「特定の業者が販売した」といったところまで断定することはできません。

しかし、一つだけ確認できる事実があります。

本来、開発にも入手にも高い技術力を必要とするブラウザExploit Chainが、極めて短期間のうちに複数のサイバー諜報活動で使用されていた。

私は、ここに今回のBlueMoonを考えるうえでの重要な問題の一つがあると考えています。

では、そのBlueMoonは、いったい何を使ってChromeとWindowsの防御を突破したのでしょうか。

ここから、BlueMoonの中身を一つずつ見ていきたいと思います。

BlueMoonによる攻撃――利用者の目には何が見えるのか？

ここで一度、攻撃を受ける側の視点からBlueMoonを見てみましょう。

難しいプログラムの話は、まだ必要ありません。

たとえば、あなたのところへ一通のメールが届いたとします。

差出人は大学生を名乗っているかもしれません。

あるいは、取引先からの見積依頼や、国際会議への案内を装っているかもしれません。

メールの文章にも、特に不自然なところはない。

場合によっては、それ以前から何度かメールのやり取りをしている相手かもしれません。

そしてメールには、Webサイトへのリンクが記載されています。

あなたは、そのリンクをクリックします。

すると、いつも使っているWebブラウザが開きます。

Webブラウザとは、普段私たちがWebサイトを見るために使っているソフトウェアです。

Google Chrome、Microsoft Edge、Firefox、Safariなどがこれにあたります。

画面には、Webページを読み込んでいるような表示が現れます。

数秒待つ。

その後、GitHubや学会など、何の変哲もない正規のWebサイトが表示されます。

利用者から見えるのは、ほぼこれだけです。

ファイルをダウンロードした覚えもない。

怪しいプログラムを起動した覚えもない。

「このアプリケーションをインストールしますか？」と聞かれたわけでもない。

ただ…

メールに書かれたリンクをクリックして、Webページを開いた。

…それだけです。

ところが、BlueMoonの攻撃では、その「数秒間」に別のことが起きていました。

攻撃者が用意したWebページには、ブラウザ上で実行されるプログラムが仕込まれています。

通常であれば、そのプログラムが利用者のコンピューターを自由に操作することはできません。

Webブラウザには、Webサイト側から送られてくるプログラムがコンピューター内部へ勝手に入り込めないよう、何重もの防御が用意されているからです。

しかしBlueMoonは、その防御に存在していた複数の脆弱性を利用しました。

まずブラウザ内部の弱点を突く。

次に、ブラウザの中から外へ出られないようにする防御を突破する。

さらにWindows側の脆弱性を利用して、より強い権限を獲得する。

そして最後に、攻撃者が目的に応じて用意したPayloadを実行する。

一方、利用者の画面には正規のWebサイトが表示されます。

つまり、表側では、

メール
→ リンクをクリック
→ 数秒待つ
→ 正規サイトが表示される

だけです。

しかし、その裏側では、

攻撃用Webページ
→ ブラウザの脆弱性を利用
→ ブラウザの防御境界を突破
→ Windowsの脆弱性を利用
→ 権限を引き上げる
→ Payloadを実行

という、まったく別の処理が進んでいた可能性があります。

これがBlueMoonというExploit Kitの恐ろしさです。

ここで、ある疑問が出てきます。

なぜ、Webサイトを見ただけで、そこまでのことができるのか？

その答えを理解するためには、私たちが普段何気なく使っているWebブラウザの中身を、少しだけ覗いてみる必要があります。

そして今回のBlueMoonで標的になったブラウザの技術的な土台が、Chromium（クロミウム）です。

BlueMoonの攻撃が成立する条件

ここまで読んで、「では、リンクをクリックしただけで、どんなパソコンでもBlueMoonに侵入されてしまうのか？」と不安に思われた方もいるかもしれません。

でも、そうではありません。

BlueMoonによる攻撃が最後まで成立するためには、いくつもの条件が揃う必要があります。

今回Proofpointが実際の攻撃で確認したBlueMoonは、大きく分けて二つの場所に存在する脆弱性を連続して利用していました。

一つは、私たちがWebサイトを見るために使っているWebブラウザ側。

もう一つは、パソコンを動かしているWindows OS側です。

つまりBlueMoonは、

Webブラウザを攻撃する
↓
ブラウザ内部の防御を突破する
↓
Windows側を攻撃する
↓
より強い権限を獲得する
↓
攻撃者が用意したPayloadを実行する

という流れで攻撃を進めます。

ここで重要なのは、ブラウザへの攻撃とWindowsへの攻撃を分けて考えることです。

BlueMoonは、ブラウザだけを攻撃する仕組みでも、Windowsだけを攻撃する仕組みでもありません。

ブラウザから侵入を始め、複数の防御を突破しながらWindows側へ攻撃をつないでいく。

これが、冒頭で説明したExploit Chain（エクスプロイト・チェーン）です。

Windowsが狙われた――ではLinuxやmacOSなら関係ない？

ここでLinuxやmacOSを使っている方は、

「BlueMoonはWindowsを狙った攻撃なら、自分には関係ないのでは？」

と思われるかもしれませんが甘いです。

ここは少し注意が必要です。

今回確認されたBlueMoonは、攻撃を最後まで成立させるためにWindowsを必要とするように作られていました。

しかし、攻撃の最初からWindowsだけを狙っているわけではありません。

BlueMoonが最初に攻撃するのは、Webブラウザの内部です。

そこで狙われるのが、Google Chromeなどで使われている“V8（ブイ・エイト）”という仕組みです。

V8については、このあと詳しく説明します。

ここでは…

「Webサイトから送られてきたJavaScriptというプログラムを、ブラウザの中で動かすためのエンジン」

…くらいに考えておいてください。

このV8は、Windowsだけで使われているものではありません。

Windows版のGoogle Chromeだけでなく、Linux版やmacOS版のChromeなどでも利用されています。

したがって…

BlueMoonが利用したV8の脆弱性そのものは、Windowsだけの問題ではありません。

では、なぜ今回Windowsが重要になるのでしょうか。

BlueMoonは、V8を攻撃して終わるわけではないからです。

ブラウザ側の防御を突破すると、攻撃は次の段階へ進みます。

そこでBlueMoonが利用するのが、Windows固有の脆弱性です。

大まかに分けると…

前半＝ブラウザ側を攻撃

後半＝Windows側を攻撃

…という構造になっています。

LinuxやmacOSには、BlueMoonが後半で利用するWindows固有の仕組みがありません。

そのため、Proofpointが実際に確認したBlueMoonの攻撃チェーンを、そのままLinuxやmacOS上で最後まで成立させることはできません。

これは…

「LinuxやmacOSでは、まだ動作確認されていない」

…という意味とは少し違います。

現在確認されているBlueMoonそのものが、途中からWindows固有の攻撃へ進むように作られているだけなのです。

故に…

「LinuxやmacOSなら、この問題とはまったく無関係」と胸を撫で下ろして安心とまでは言えないのです。

先ほど説明したように、攻撃の前半で利用されるV8の脆弱性そのものはWindows固有ではないからです。

また理論上は、攻撃者がBlueMoonの後半部分を作り替え、Windowsの脆弱性の代わりにLinuxやmacOS側の別の脆弱性を組み込めば、異なるExploit Chainを作ることも考えられます。

ただし、そのようなLinux版やmacOS版のBlueMoonが実際の攻撃で確認された、という意味ではありません。

ここでは、「現在確認されている事実」と「技術的に考えられる可能性」を分けておく必要があります。

現時点で確認されているBlueMoonについては…

①V8の脆弱性そのものはWindowsだけの問題ではない。

しかし…

②実際に確認されたBlueMoonの完全な攻撃チェーンは、Windowsを標的として設計されている。

この二つを分けて理解しておけば十分です。

ChromiumとGoogle Chrome――名前は似ているけれど何が違う？

BlueMoonを調べていると、Google Chrome（グーグル・クローム）と、Chromium（クロミウム）という、よく似た二つの名前が登場します。

「私はGoogle Chromeを使っているけれど、Chromiumなんて使っていない」

そう思われる方もいるでしょう。

実は、この二つには深い関係があります。

Chromiumとは、簡単に言えば、Google ChromeなどのWebブラウザを作るための大きな共通基盤です。

Googleは、このChromiumを基盤としてGoogle Chromeという製品を開発し、私たち利用者へ提供しています。

自動車に例えるなら…

Chromium＝基本となる車体や設計

Google Chrome＝その設計をもとにGoogleが完成させた車

…くらいに考えると分かりやすいでしょう。

しかも、この「車体」を使っているのはGoogleだけではありません。

Microsoft Edge、Brave、Opera、Vivaldiなど、現在利用されているさまざまなWebブラウザがChromiumを基盤としています。

そのため、「Chromiumに脆弱性が見つかった」というニュースを見て…

「自分はChromiumというブラウザを使っていないから関係ない」

…と考えてしまうのは早計です。

自分が使っているブラウザがChromiumを基盤としていれば、Chromiumのどの部分に脆弱性が見つかったのかによっては、自分が使っているブラウザにも影響する可能性があります。

そしてBlueMoonが狙ったのが、そのChromium系ブラウザの内部で重要な役割を担っている、

V8（ブイ・エイト）でした。

V8とは何なのか？

V8とは、Googleが開発している“JavaScript Engine（ジャバスクリプト・エンジン）”です。

難しそうな名前ですが、役割そのものはそれほど難しくありません。

私たちがWebサイトを開くと、ブラウザは文章や画像を表示するだけではなく、そのWebサイトから送られてきたさまざまなプログラムも実行しています。

  • ボタンを押すと画面が変化する。
  • メニューが開く。
  • 入力した内容を確認する。
  • 地図を動かす。
  • Webアプリを動かす。

こうしたWebページ上のさまざまな処理に広く使われているプログラミング言語が、JavaScript（ジャバスクリプト）です。

そして、そのJavaScriptを読み取り、実際にコンピューター上で動かす重要な役割を担っているのがV8です。

ここまでを簡単に整理すると、

Chromium
＝ブラウザを作るための大きな共通基盤

そのChromiumを使って作られた製品の一つが、

Google Chrome

そして、その内部でJavaScriptを実行している重要なエンジンの一つが、

V8

という関係になります。

BlueMoonは、まずこのV8に存在していた脆弱性へ攻撃を仕掛けました。

しかし、ここで一つ疑問が生まれます。

Webサイトを見るたびにJavaScriptが実行されているのであれば、

悪意あるWebサイトを開いただけで、パソコンを自由に操作されてしまうのでしょうか？

もちろん、通常はそんなことにはなりません。

Webブラウザには、Webサイトから送られてきたプログラムがパソコン内部を好き勝手に操作できないよう、いくつもの防御が用意されています。

そしてBlueMoonを理解するうえで、次に知っておきたい重要な防御の一つが、

Sandbox（サンドボックス）です。

BlueMoonは、この防御を一枚ずつ突破していきます。

ここから、いよいよ今回利用された3つの脆弱性…

CVE-2026-85046

CVE-2026-87491

CVE-2026-85880

が、それぞれ何を担当していたのかを見ていきましょう。

Sandboxとは何か？――ブラウザの中に作られた「隔離された部屋」

前項では、Webサイトから送られてきたJavaScriptを、V8が実行していることを説明しました。

ここで少し考えてみましょう。

インターネット上には、世界中の誰が作ったのか分からないWebサイトが無数に存在します。

そして私たちは毎日のように、それらのWebサイトを開いています。

もしWebサイトから送られてきたJavaScriptが、Windowsのファイルを自由に読み書きしたり、勝手にプログラムを起動したりできるとしたら、大変なことになります。

そこでWebブラウザには、Webサイトから実行されるプログラムの行動範囲を制限するため、さまざまな防御が設けられています。

その考え方の一つが、Sandbox（サンドボックス）です。

Sandboxを直訳すると「砂場」です。

子どもを砂場の中で遊ばせ、簡単には外へ出られないようにする。

ブラウザのSandboxも、イメージとしてはこれに似ています。

Webサイトから受け取ったプログラムを、パソコン全体を自由に操作できる環境で動かすのではなく、強く制限された領域の中で動かすのです。

仮に、その領域の中で何らかの脆弱性が悪用されたとしても、

「ここから先へは行かせない」という、もう一枚の壁を用意しているわけです。

そのため、V8に脆弱性が一つ見つかったからといって、通常はそれだけでWindows全体を自由に操作できるわけではありません。

ところがBlueMoonは、この防御を一つのExploitだけで突破しようとはしませんでした。

一枚の壁には、一つの突破手段。

それを連続させています。

ここで、今回使われた3つの脆弱性が登場します。

BlueMoonが狙った「3枚の壁」

BlueMoonの攻撃を細かなプログラムの動きではなく、まず「どの壁を破ったのか」で見ると理解しやすくなります。

大まかな流れは次のようになります。

第1段階
CVE-2026-85046
↓
V8内部に足掛かりを作る

↓

第2段階
CVE-2026-87491
↓
V8側の防御境界を突破し、次の攻撃へ進む

↓

第3段階
CVE-2026-85880
↓
Windows側の脆弱性を利用して権限を引き上げる

↓

攻撃者が用意したPayloadを実行

冒頭で説明したExploit Chainという言葉が、ここで具体的な形になってきます。

3つのCVE番号は、単に「3件の脆弱性があった」という意味ではありません。

それぞれに違う仕事が与えられ、その仕事を順番に成功させることで、一つの攻撃を完成させていたのです。

では、一枚ずつ見てみましょう。

第1段階――CVE-2026-85046：まずV8内部に足掛かりを作る

最初にBlueMoonが利用したのが、CVE-2026-85046です。

これはV8に存在していた“Type Confusion（タイプ・コンフュージョン／型混同）”と呼ばれる種類の脆弱性です。

「型混同」と言われても、プログラミングに馴染みがなければ、何のことか分からないと思います。

ここでは難しく考える必要はありません。

コンピューターのプログラムは、扱っているデータが…

  • 「これは数字」
  • 「これは文字」
  • 「これは別の種類のデータ」

…という具合に、何であるのかを区別しながら処理しています。

ところがType Confusionでは、その判断に食い違いが生じます。

本来はAとして扱わなければならないデータを、プログラムが誤ってBだと思い込んで処理してしまう。

人間に例えるなら…

「この荷物は危険物なので、この場所から出してはいけない」

と管理されていたものを…

「これは普通の荷物だ」

…と誤認して処理してしまうようなものです。

BlueMoonは、このV8の誤ったデータ処理を利用しました。

ただし、ここで重要なのは、CVE-2026-85046を利用しただけでWindowsを乗っ取ったわけではないということです。

これは、あくまで最初の足掛かりでしかないのです。

BlueMoonはこの脆弱性を利用してV8内部で、本来許されていないメモリー操作を行える状態へ攻撃を進めました。

しかし、まだ攻撃者は自由ではありません。

ブラウザ内部には、さらに越えなければならない防御境界が残っています。

そこで二つ目の脆弱性が登場します。

第2段階――CVE-2026-87491：ブラウザ内部の防御境界を越える

次にBlueMoonが利用したのが、CVE-2026-87491です。

これはV8に存在していた“Out-of-Bounds Write（アウト・オブ・バウンズ・ライト／範囲外書き込み）”の脆弱性です。

名前は難しそうですが、考え方は比較的単純です。

プログラムには通常、「この範囲のメモリーだけを使ってよい」という境界があります。

ところが範囲外書き込みの脆弱性が存在すると、その境界を越え、本来書き換えてはいけない場所へデータを書き込める場合があります。

BlueMoonはこの脆弱性を利用し、WebAssembly（ウェブアセンブリー）に関係する内部情報を操作して、V8の防御境界を突破する次の段階へ進みました。

WebAssemblyについても、ここでは名前だけ覚えておけば十分です。

Webブラウザ上で、JavaScriptとは異なる形の高速なプログラムを動かすための技術の一つです。

重要なのは…

第1段階でV8内部に足掛かりを作り、
第2段階でそこからさらに外側へ攻撃範囲を広げた

ということです。

ここまで来て、ようやくBlueMoonはブラウザの世界から、その外側にあるWindowsへ攻撃をつなげられる状態になります。

しかし、Windowsにも当然、防御があります。

そこで三つ目のExploitが登場します。

第3段階――CVE-2026-85880：Windows側で権限を引き上げる

三つ目は、CVE-2026-85880です。

ここで攻撃対象が変わります。

前の二つはV8、つまりブラウザ側に関係する脆弱性でした。

ところがCVE-2026-85880は、Windows側の脆弱性です。

種類としては、Privilege Escalation（プリビレッジ・エスカレーション／権限昇格）に利用される脆弱性です。

「権限昇格」とは、その名前のとおり、本来与えられているよりも強い権限を手に入れることです。

パソコンの中では、すべてのプログラムが同じ権限で動いているわけではありません。

自由にできることが制限されたプログラムもあれば、システムの重要な部分へアクセスできる強い権限を持つものもあります。

これは、会社の入館証を想像すると分かりやすいでしょう。

一般社員のカードでは通常の執務室まで。

管理担当者のカードなら、さらに重要な設備がある区画まで入れる。

BlueMoonはブラウザ側から侵入したあと、このWindowsの脆弱性を利用して、より強い権限を獲得するための処理を行っていました。

ここまで来ると、最初に利用者が行った、「メールに書かれたリンクをクリックする」という行為からは、ずいぶん遠いところまで攻撃が進んでいます。

利用者の目には数秒間のWebページ読み込みにしか見えなかった裏側で…

Webページ
↓
JavaScript
↓
V8
↓
第1のExploit
↓
第2のExploit
↓
ブラウザ側の防御境界を突破
↓
Windows
↓
第3のExploit
↓
権限昇格
↓
Payloadの実行

…という処理が連続していたのです。

これが、BlueMoonのExploit Chainの大枠です。

そして、ここでもう一つ重要なことが見えてきます。

BlueMoonは、闇雲に3つの脆弱性を並べただけのプログラムではありません。

ブラウザのどこを突破し、次にどこへ進み、どのWindows環境なら攻撃を続けられるのかを判断しながら動く、一つの攻撃システムとして組み上げられていました。

ではBlueMoonは、標的となったパソコンの環境をどのように調べ、どのWindowsなら攻撃を続行するのかを判断していたのでしょうか。

ここから、もう一段だけBlueMoonの内部へ入ってみたいと思います。
少し技術的な話になりますが、難しい部分は読み飛ばしても大丈夫です。プログラムに興味のある方は、「BlueMoonは実際に何で作られ、どのように動いていたのか」という視点で一緒に覗いてみてください。

BlueMoonは何で作られているのか？

まず最初に知っておきたいのは、BlueMoonが「一つのプログラムだけ」でできているわけではないということです。

Proofpointが解析したBlueMoonでは、Webブラウザ上で動くJavaScriptを中心として、役割の異なる複数の部品が組み合わされていました。

大まかな構造は…

JavaScript
↓
V8を狙うExploit
↓
WebAssemblyを利用した次の突破
↓
Windowsを調べるDLL
↓
Windowsを攻撃するDLL
↓
Shellcode
↓
最終的なPayload

…となっています。

少し聞き慣れない言葉が増えてきました。

一つずつ見ていきましょう。

司令塔となるJavaScript

BlueMoonの中心で攻撃全体を取り仕切っているのが、“JavaScript（ジャバスクリプト）です。

JavaScriptそのものは悪意あるプログラムではありません。

先ほど説明したように、現在のWebサイトではごく普通に使われているプログラミング言語です。

BlueMoonでは、このJavaScriptが攻撃全体の「司令塔」のような役割を果たしていました。

最初期にProofpointが確認したTA412のBlueMoonでは、driver-html.jsというスクリプトがWeb Worker（ウェブ・ワーカー）として動作し、Exploitを実行するタイミングや再試行、攻撃成功後に何を取得するのか、といった処理を管理していました。

Web Workerとは、簡単に言えば、Webブラウザの中でJavaScriptの処理を別の作業として動かすための仕組みです。

ここでも細かな仕様まで覚える必要はありません。

重要なのは、BlueMoonではJavaScriptが、次にどの処理を動かすのかを管理していたという点です。

JavaScriptの中に隠されていた「3つの部品」

さらに興味深いのは、Proofpointが解析したBlueMoonの中核JavaScriptには、3つの大きな部品がBase64（ベース・シックスティフォー）という形式で組み込まれていたことです。

Proofpointは、それぞれを変数名から…

p1

p2

pp

…として説明しています。

Base64とは、プログラムや画像などのデータを、文字列として扱いやすい形へ変換する方法の一つです。

ここで、「暗号化されていたのか？」と思われるかもしれませんが、Base64は暗号ではありません。

元へ戻す方法が決まっているデータの表現方法です。

つまりBlueMoonは、JavaScriptだけですべての攻撃を行っていたのではなく、その中に別の役割を持った部品を抱え込み、必要になったところで利用する構造になっていました。

では、その3つは何をしていたのでしょうか。

p1――まず相手のWindowsを調べる

最初のp1は、攻撃対象となったWindowsを調査するための部品です。

ここで登場するのが、DLL（ディー・エル・エル）です。

DLLは「Dynamic Link Library（ダイナミック・リンク・ライブラリー）」の略で、Windowsでさまざまなプログラムから利用されるプログラム部品の形式です。

BlueMoonのp1には、このDLLが含まれていました。

そして興味深いことに、BlueMoonはいきなりWindowsへの攻撃を仕掛けるのではありません。

まず…

  • どのWindowsなのか？
  • WindowsのBuild（ビルド）はいくつなのか？
  • 現在のプロセスは、どの程度の権限で動いているのか？

…といった情報を調べます。

つまりBlueMoonは、「Windowsを見つけた。攻撃開始！」と無条件に突っ込むプログラムではありません。

相手の環境を調べ、「このWindowsなら次の攻撃が使えるか？」を確認してから先へ進むように作られていました。

p2――条件が合ったWindowsだけを攻撃する

その判断によって次に呼び出されるのがp2です。

こちらにもDLLが含まれていました。

ただし役割は違います。

p1が、「相手を調べる部品」だとすれば、p2は、「条件が合った相手にWindows側のExploitを実行する部品」です。

ここで、先ほど紹介したWindowsの脆弱性、CVE-2026-85880が利用されます。

つまり…

p1で調べる
↓
攻撃可能か判断する
↓
条件が合えばp2を動かす

…という流れです。

この仕組みを見ると、BlueMoonが単に3つの脆弱性を順番に実行しているだけではないことが分かります。

相手の環境を確認しながら、攻撃を続行するか判断していたのです。

pp――最後の橋渡しをするShellcode

そして3つ目がppです。

Proofpointはこれを、“Process Injection（プロセス・インジェクション）を行うためのLauncher（ランチャー）として機能するShellcode（シェルコード）”と説明しています。

また難しい言葉が二つ出てきました。

まずShellcodeとは、ここでは、「コンピューターに直接実行させるために用意された、小さな命令のまとまり」くらいに考えてください。

Process Injectionとは、すでに動いている別のプロセスの中へ処理を送り込み、そこで実行させる手法です。

BlueMoonでは、このppが最終的な橋渡しを担当していました。

ブラウザ内部から始まった攻撃を、Windows上で別の処理を実行できる段階へつないでいくのです。

そして最終的に、攻撃者が指定したプログラムを取得して実行します。

ここでようやく、記事の前半で説明した、Payload（ペイロード）へ到達します。

つまりBlueMoon内部を大きく整理すると…

  1. JavaScript＝攻撃全体を取り仕切る
  2. p1＝相手のWindowsを調べる
  3. p2＝Windowsの脆弱性を攻撃する
  4. pp＝最終的なプログラム実行へ橋渡しする

…という役割分担が見えてきます。

こうして見ると、BlueMoonは「一つのマルウェア」というよりも、複数の技術とプログラム部品を順番に動かしながら、ブラウザからWindows、そして最終的なPayloadへ攻撃をつなぐExploit Kitであることが、よりはっきり見えてきます。

そして、ここにはもう一つ興味深い特徴があります。

BlueMoonは、どのWindowsでも無差別に最後まで攻撃していたわけではありません。

p1で相手を調べたうえで、特定のWindows Buildに該当した場合にだけ、次のWindows Exploitへ進むように作られていました。

では、BlueMoonは具体的にどのWindowsを「攻撃可能」と判断していたのでしょうか。

BlueMoonが狙ったWindows――p1は何を見ていたのか？

前項で紹介したp1には、重要な役割がありました。

攻撃対象となったパソコンのWindows環境を調べることです。

Proofpointの解析によると、p1はWindowsのバージョンやBuild番号、現在のプロセスが持つ権限などを調べていました。

ここでいうBuild（ビルド）番号とは、簡単に言えばWindowsの「世代や更新状態を識別する番号」です。

同じWindows 10という名前でも、長年にわたって機能更新が繰り返されてきました。

そのため攻撃者にとって、「Windows 10である」という情報だけでは十分ではありません。

「どのWindows 10なのか」まで確認する必要があるわけです。

BlueMoonがWindows側の攻撃へ進む対象としていたBuildを整理すると、次のようになります。

Windows Build主なWindows環境
17763Windows 10 Version 1809 / Windows Server 2019
19041～19045Windows 10 Version 2004～22H2
20348Windows Server 2022
22000Windows 11 Version 21H2

ここで、少し気になることがあります。

かなり古いWindows環境が並んでいます。

Windows 11についても対象となっていたのは、初期世代にあたるVersion 21H2のBuild 22000でした。

つまりBlueMoonは、「Windowsなら何でも攻撃してみる」という作りではなかったのです。

p1で相手の環境を調査し、Windows側のExploitが利用できる条件に一致した場合に、次のp2へ進むようになっていました。

逆に条件が合わなければ、Windowsの権限昇格を無理に試す必要はありません。

なぜ、こんな選別をするのでしょうか。

理由は、ExploitがどんなWindowsでも同じように機能する万能鍵ではないからです。

Windowsは更新によって内部の構造が変化します。

あるBuildでは成立する攻撃方法が、別のBuildではそのまま使えるとは限りません。

そこでBlueMoonは、相手の環境を確認してから、「この相手なら、持っている鍵が使える」と判断した場合にだけ、Windows側の攻撃へ進む仕組みを持っていたと考えると分かりやすいでしょう。

これは攻撃者の立場から見れば、かなり合理的です。

使えないExploitを無闇に実行すれば、攻撃に失敗するだけでなく、不審な動作を発生させて攻撃そのものを発見される可能性もあります。

BlueMoonは、まず相手を調べる。

条件が合うか確認する。

そして条件が揃ったときだけ、次の攻撃へ進む。

ここまで見てくると、BlueMoonが単なる「脆弱性を突くコードの寄せ集め」ではなく、複数のExploitを実際の攻撃で使うために制御する仕組みまで含めたExploit Kitであることが、よりはっきりしてきます。

p2に残された「2025年」という痕跡

そして、ここから少し面白くなります。

Windows側の権限昇格を担当するp2をProofpointが解析したところ、ある痕跡が残されていました。

コンパイルされた時刻を示すタイムスタンプです。

Compile（コンパイル）とは、人間が書いたプログラムを、コンピューターが実行できる形へ変換する作業だと考えてください。

そのp2に記録されていたコンパイル時刻は、2025年を示していました。

ところが、ProofpointがBlueMoonを実際の攻撃として初めて確認したのは、2026年8月28日です。

単純に考えると、1年近い時間差があります。

もちろん、プログラムに記録されているタイムスタンプだけを見て、「このExploitは間違いなく2025年に開発された」と断定することはできません。

タイムスタンプは書き換えることもできるからです。

しかしProofpointは、このタイムスタンプについて、意図的に偽装されたようには見えないと評価しています。

さらに先ほど見たように、p2が対象としていたWindowsも比較的古いBuildに集中していました。

ここから、一つの可能性が浮かび上がります。

Windowsを攻撃するこの能力は、BlueMoonのために2026年になって新しく作られたものではなく、以前から存在していたExploitをBlueMoonへ組み込んだのではないか。

Proofpointも、この可能性を指摘しています。

もしそうであるなら、BlueMoonの見え方が少し変わってきます。

すべてをゼロから開発した一枚岩の攻撃ツールではなく、新しいブラウザExploitと、以前から保有していた可能性のあるWindows Exploitを組み合わせ、一つのExploit Chainとして再構成した可能性が出てくるからです。

これはまだ、BlueMoonを誰が開発したのかを示す証拠ではありません。

しかし、「BlueMoonを構成するすべての部品は、同じ時期に、同じ目的で、一から作られたのだろうか？」という新しい疑問を投げかけます。

そして、その疑問はさらに大きな謎へつながっていきます。

BlueMoonが最初に確認されてから、わずか数日の間に、複数の異なる攻撃主体が同じ系統のExploit Kitを使い始めたのは、なぜなのか？

ここからBlueMoonを、単なる「3つの脆弱性を利用した攻撃」という視点から離して見てみる必要性が出てきます。

誰がExploitを作り、誰がそれを組み合わせ、そして誰が実際の攻撃に利用したのか。

BlueMoonの背後にある「開発と利用の関係」を探っていきます。

わずか数日で複数の攻撃主体へ――BlueMoonに何が起きたのか？

BlueMoonについて、Proofpointが特に注目したのは技術的な高度さだけではありません。

もう一つ、非常に興味深い現象が確認されています。

同じ系統のBlueMoonが、短期間のうちに複数の異なる攻撃主体によって使われ始めたことです。

Proofpointが最初にBlueMoonを確認したのは、

2026年8月28日。

使用していたのは、TA412と呼ばれる中国との関連が指摘されている国家支援型の攻撃主体でした。

ところが、それからわずか数日後。

9月2日には、別の攻撃クラスターであるUNK_LateNightがBlueMoonを使用します。

さらに同じ9月2日には、UNK_DoubleCheck。

翌9月3日には、UNK_QuietRacket。

つまり、確認された動きを時系列にすると…

8月28日　TA412
↓
9月2日　UNK_LateNight
↓
9月2日　UNK_DoubleCheck
↓
9月3日　UNK_QuietRacket

…となります。

最初の確認から、わずか1週間ほどです。

しかも興味深いのは、4つの攻撃が同じ作戦だったわけではないことです。

BlueMoonは同じ、しかし攻撃作戦は違った

TA412では、米国のNGO、鉱業企業、現物商品取引企業などが標的となりました。

大学生のインターン応募や学会に関係する内容などを装って標的を誘導し、BlueMoonによる侵入後には、“GemStone（ジェムストーン）”と呼ばれる悪意あるブラウザ拡張機能が利用されました。

一方、UNK_LateNightが狙ったのは米国の航空宇宙関連企業です。

こちらでは企業間取引で使われるRFQ――“Request for Quotation（リクエスト・フォー・クォーテーション／見積依頼）を装った誘導が使われ、最終的にはShadowPad（シャドウパッド）”が送り込まれていました。

さらにUNK_DoubleCheckでは、ベトナムの製造業組織が標的となり、東南アジアの政府機関から侵害されたメールアカウントを利用したとみられる、ワクチン接種予約を装った誘導が確認されています。

UNK_QuietRacketでは、インドネシアやシンガポールの政府、コンサルティング、金融関係組織などが狙われ、カンファレンスをテーマにした誘導が使われていました。

つまり…

  • 狙っている組織が違う。
  • 誘導方法も違う。
  • 侵入後に使うPayloadも違う。

…にもかかわらず、

侵入口としてBlueMoonが使われていた。

ここが重要です。

以前説明した「BlueMoonそのものとPayloadを分けて考える」という意味が、ここでも見えてきます。

BlueMoonはGemStone専用の攻撃ツールではありません。

ShadowPad専用でもありません。

BlueMoonが担当するのは、ブラウザからWindowsへ防御を突破して、その先のPayloadを実行できるところまで道を開くことです。

だからこそ、攻撃主体によって、その先に送り込むものを変えることができます。

4者が偶然、同じものを作ったのか？

ここで当然、疑問が生まれます。

これらの攻撃主体が、それぞれ独自にBlueMoonとよく似たExploit Kitを開発したのでしょうか。

Proofpointの解析は、その可能性が低いことを示しています。

それぞれのBlueMoonにはパッケージ方法などに違いがありました。

しかし、中核となるExploit Chainや攻撃を制御する仕組みには強い共通性があり、Proofpointは、確認されたBuildがほぼ確実に同じソースから生じたと評価しています。

細かな部分は違っていても、根本となる設計が非常によく似ている。

つまり、4者がそれぞれゼロから同じものを偶然作ったというより、共通するBlueMoonの原型から派生した可能性が極めて高いということです。

では、その「元のBlueMoon」は誰が作ったのでしょうか。

そして、なぜ異なる攻撃主体が、ほぼ同じ時期に利用できたのでしょうか。

「共有された」と断定するには、まだ早い

ここは慎重に考える必要があります。

4つの攻撃主体がBlueMoonを使用していた。

BlueMoonには共通するソースコード由来と考えられる強い類似性がある。

ここまでは、解析から確認された事実です。

しかし…

  • 「誰かが4つの攻撃主体へBlueMoonを配布した」
  • 「中国政府が各攻撃主体へ提供した」
  • 「特定の開発会社が販売した」

…といったところまでは確認されていません。

Proofpoint自身も、複数の異なる攻撃主体が、どのようにBlueMoonへアクセスできるようになったのかは不明としています。

したがって現時点では、BlueMoonが共有されたと断定するより、複数の異なる攻撃主体が、同一系統のBlueMoonを短期間のうちに利用していたと表現する方が正確です。

しかし、それでも一つの事実は残ります。

8月28日に初めて確認された新しいExploit Kitが、その数日後には異なる標的、異なる誘導方法、異なるPayloadを使う複数の攻撃作戦へ組み込まれていた。

この速さです。

ここから、BlueMoon事件のもう一つの核心が見えてきます。

  • 脆弱性を発見する者。
  • Exploitを開発する者。
  • 複数のExploitをつないでExploit Kitを作る者。
  • そして、それを実際の諜報活動に利用する者。

これらは、本当にすべて同じ人物、同じ組織である必要があるのかということです。

私は、ランサムウェアを分析するときも、実際に攻撃を行う「攻撃実行者」と、攻撃に必要なマルウェアや侵入手段などを提供する、いわば「道具屋」を分けて考えています。

BlueMoonについても同じ視点が必要なのかもしれません。BlueMoonを実際の攻撃で使った者と、BlueMoonを開発・提供した者は、本当に同じなのか？或いは、同じである必要があるのか？です。

現時点で「BlueMoonの道具屋」が存在すると確認されたわけではありません。しかし、短期間に複数の異なる攻撃主体が同一系統のBlueMoonを利用していたという事実は、その可能性を検討する十分な理由になります。

過去のサイバー犯罪の世界では、すでにこれとよく似た「分業」が存在していました。

Exploitを作る者と、それを実際の攻撃に使う者が分かれ、Exploit Kitそのものが一つの商品やサービスのように流通した時代があります。

Blackhole、Angler、RIG――。

BlueMoonを理解するために、ここで少しだけ時計の針を過去へ戻してみましょう。

現在の国家支援型サイバー攻撃の世界で起きていることは、かつてのExploit Kitの歴史と、どこか似てはいないでしょうか。

「攻撃実行者」と「道具屋」――Exploit Kitの歴史から現在を見る

ここまで、BlueMoonがどのような仕組みでブラウザからWindowsへ攻撃をつなぎ、さらに複数の異なる攻撃主体によって利用されていたのかを見てきました。

かなり技術的なところまで踏み込んできましたので、ここで少し視点を変えてみましょう。

BlueMoonのようなExploit Kitは、2026年になって突然生まれたものではありません。

過去にもさまざまなExploit Kitが登場し、そのたびに攻撃する側と防御する側はせめぎ合いを続けてきました。

そこでここからは、Exploit Kitがどのように生まれ、どのように使われ、そしてなぜ一時期ほど姿を見せなくなったのかを簡潔に振り返ります。

これは単なる昔話ではありません。

過去を振り返ることで、BlueMoonの何が新しく、何が昔から変わっていないのか。

そして、

なぜ2026年になって、再びこのようなExploit Kitが現実の脅威として浮上してきたのか。

その現在地が見えてくるからです。

そして最後には、もう一度私たち利用者の側へ戻ります。

BlueMoonのような攻撃に対して、私たちは何をすればよいのか。

  • ブラウザを更新していれば十分なのか。
  • Windows Updateはどこまで有効なのか。
  • 不審なリンクを開かなければ防げるのか。
  • 企業では、どのような監視や防御が必要になるのか。

今回のBlueMoonから得られる具体的な防御策まで整理して、この記事を結びたいと思います。

もう少しだけ、ネットの奥を探検してみましょう。

Exploit Kitは以前から存在していた

BlueMoonのようなExploit Kitには長い歴史があります。

2000年代から2010年代にかけて、サイバー犯罪の世界ではさまざまなExploit Kitが使われました。

代表的なものとして…

  • Blackhole（ブラックホール）
  • Angler（アングラー）
  • RIG（リグ）

…などがあります。

当時のExploit Kitも、基本となる発想にはBlueMoonと通じるところがあります。

攻撃を実行する者が、ブラウザなどに存在する脆弱性を一つひとつ自分で研究し、すべてのExploitを自分で開発する必要はありません。

すでに作られた「侵入するための道具」を、別の攻撃者が利用できる仕組みが存在していました。

攻撃者は、改ざんされたWebサイトや悪意ある広告などを使って利用者をExploit Kitへ誘導します。

Exploit Kitはアクセスしてきたパソコンを調べ…

  • どのブラウザを使っているのか。
  • どのバージョンなのか。
  • 利用できる脆弱性が残っているのか。

…などを判断します。

条件が合えば、その環境で利用できるExploitを選んで攻撃する。

侵入に成功すれば、その先で攻撃者が目的とするPayloadを送り込みます。

ここまでBlueMoonを追ってきた方なら、「どこかで見たような仕組みだ」と思われるのではないでしょうか。

実際、相手の環境を調べ、利用可能なExploitを選び、その先にPayloadを送り込むという考え方そのものは、BlueMoonによって初めて生まれたものではありません。

昔は「広く狙う」、BlueMoonは「狙って送り込む」

ただし、昔のExploit KitとBlueMoonには大きな違いもあります。

かつてサイバー犯罪で広く使われたExploit Kitでは、できるだけ多くの利用者を攻撃ページへ誘導し、その中から攻撃可能なパソコンを探して感染させるという使い方が目立ちました。

いわば、「大勢を集め、その中から侵入できる相手を探す」という発想です。

一方、現在確認されているBlueMoonは違います。

  • 大学生のインターン応募。
  • 学会への案内。
  • 企業間の見積依頼。
  • ワクチン接種予約。
  • カンファレンスへの誘導。

標的となる人物や組織に合わせた内容を用意し、狙った相手をBlueMoonが待つWebページへ誘導していました。

つまり…

昔のExploit Kit
＝多くの人を入口へ連れてきて、攻撃できる相手を探す

今日のBlueMoon
＝狙った相手を入口へ連れてきて、条件が合えばExploit Chainを実行する

…という違いが見えてきます。

大量感染を狙ったサイバー犯罪と、特定の組織や人物を狙った諜報活動。

目的は大きく違います。

しかし、高度な侵入技術を「使える道具」としてまとめ、それを実際の攻撃へ組み込むという発想には、興味深い共通点があります。

Exploit Kitが生み出した「分業」

そして、ここで先ほどの「攻撃実行者」と「道具屋」という視点へ戻ります。

Exploit Kitの重要なところは、攻撃を自動化できることだけではありません。

高度なExploitを自分で開発できなくても、その攻撃能力を利用できる可能性が生まれることです。

  • 脆弱性を研究する者。
  • Exploitを開発する者。
  • 複数のExploitを実戦で使える形へ組み上げる者。
  • 標的を探す者。
  • 攻撃を実行する者。
  • 侵入後のPayloadを運用する者。

すべてを一人、あるいは一つの組織が担当する必要はありません。

こうした分業が成立すれば、非常に高度なサイバー攻撃能力そのものが、別の攻撃者によって再利用される可能性が生まれます。

そしてBlueMoonへ戻ってみると、Proofpointが最初の攻撃を確認してから、わずか数日の間に複数の異なる攻撃主体が同一系統のBlueMoonを利用していました。

  • 標的は違う。
  • 誘導方法も違う。
  • Payloadも違う。

しかし、侵入口として使われたBlueMoonには強い共通性がある。

これは、「高度なExploit Chainを作る能力」と「そのExploit Chainを使って実際の攻撃を行う能力」は、必ずしも同じ場所に存在する必要がないという可能性を考えさせます。

ただし、現在確認されている証拠だけでは、BlueMoonが過去の犯罪用Exploit Kitのように販売されていたのか、特定の開発者から提供されたのか、組織内部で共有されたのか、それとも別の経路で複数の攻撃主体が入手したのかは分かっていません。

ここは推測と事実を分けなければなりません。

確認されているのは、同一系統のBlueMoonを複数の異なる攻撃主体が、極めて短期間のうちに利用していたというところまでです。

しかし、それだけでも十分に興味深い現象です。

そして、ここからもう一つの疑問が生まれます。

なぜ、高度なExploit Kitをこれほど短期間で実戦投入できたのか？

ProofpointがBlueMoonの内部を解析すると、そこには大量のデバッグ情報、詳細なコメント、開発途中を思わせる記録、そして開発者から別の担当者へ引き継ぐためのような文書まで残されていました。

そこから浮上したのが、「BlueMoonの開発にAIが関与していたのではないか？」という、もう一つの可能性です。

ただし――ここでも先に結論を言っておきましょう。

BlueMoonがAIによって開発されたと確認されたわけではありません。

では、なぜProofpointはAIの関与を疑ったのでしょうか。

次は、BlueMoonに残されていた“「開発者の痕跡」”を調べてみます。

BlueMoonをAIが作った？――コードに残された奇妙な痕跡

BlueMoonを解析したProofpointは、その開発過程についても興味深い痕跡を発見しています。

ここで最初に、重要なことを確認しておきましょう。

BlueMoonがAIによって開発されたと確認されたわけではありません。

Proofpointも、AIによる開発を決定的に証明する単一の証拠は存在しないとしています。

では、なぜAIの関与が疑われたのか？

理由は、BlueMoonの内部に残されていた開発時の痕跡にあります。

大量に残されていたログとコメント

通常、プログラムを開発するときには…

  • 「ここまで正常に動いたか？」
  • 「どこでエラーが発生したのか？」
  • 「この値は正しいのか？」

…などを確認するため、途中経過を表示する仕組みを入れることがあります。

これが“Debug（デバッグ）”です。

BlueMoonには、このデバッグに使われたとみられる大量のログや、詳細なコメントが残されていました。

完成した攻撃ツールとして考えると、少し不思議です。

攻撃者にとって余計なログや特徴的な文字列は、セキュリティ研究者や防御側に発見・分析される手掛かりにもなります。

実際Proofpointも、BlueMoonには検知に利用できる特徴が多く残っており、隠密性より開発・投入の速さを優先した可能性を指摘しています。

「ログを送り返してください」

さらに興味深い文字列も残されていました。

BlueMoonのコードには、問題が発生した際に完全なログを送り返すよう求める趣旨の指示が含まれていました。

これは、単なる攻撃命令というよりも…

プログラムを動かす
↓
結果を確認する
↓
ログを受け取る
↓
問題を修正する

という、開発やデバッグのやり取りを思わせます。

そして、さらに奇妙なものがありました。

「handover.md」――誰から誰への引き継ぎなのか

ProofpointはBlueMoonの中から、docs/v8-ctf-chrome-stage4-handover.mdという名称のMarkdown（マークダウン）文書に関係する痕跡を確認しています。

Markdownとは、文章の見出しや箇条書きなどを簡単な記号で記述できる文書形式です。

プログラム開発では、READMEや仕様書、作業メモなどにもよく使われます。

ここで目を引くのが…

handover（ハンドオーバー）という言葉です。

日本語なら、「引き継ぎ」と考えると分かりやすいでしょう。

つまり名称だけを見ると、V8に関する作業を、次の工程や担当へ引き継ぐための文書のようにも見えるわけです。

もちろん、ファイル名だけから「AIから人間への引き継ぎ文書だった」と断定することはできません。

しかし、大量のデバッグ情報、詳細なコメント、試行錯誤を示す痕跡、そして引き継ぎ文書のような構造。

これらを総合してProofpointは、AIを利用した開発と整合する特徴があると評価しています。

ただし、ここまでです。

AIが使われたことを証明したわけではありません。

「v8CTF」という、もう一つの気になる言葉

そして、ファイル名にはもう一つ気になる文字列があります。

v8CTFです。

CTFとは、Capture The Flag（キャプチャー・ザ・フラッグ）の略です。

サイバーセキュリティの世界では、用意された脆弱性を発見したり、プログラムを解析したりして課題を解く競技や学習環境を指します。

つまり、v8-ctf-chrome-stage4-handoverという名称だけを見ると、V8を題材としたセキュリティ演習・研究のようにも見えるわけです。

ここでProofpointは、さらに興味深い可能性を提示しています。

本当にV8 CTFとして開発していた可能性。

その一方で、AIへExploit開発を支援させる際に、「これは実際の攻撃ではなく、CTF・セキュリティ研究のための作業だ」という体裁を使った可能性です。

もし後者なら、AIに設けられた安全上の制限を回避するための口実としてCTFが利用された可能性も考えられます。

しかし、これについても証拠はありません。

ここは明確に分けておきましょう。

確認されていること：
BlueMoonには、大量のログ、詳細なコメント、デバッグの痕跡、Markdown形式の引き継ぎ文書を思わせる名称、v8CTFに関係する文字列などが残されていた。

推定されていること：
これらはAIを利用したプログラム開発の特徴と整合する。

分かっていないこと：
実際にAIが使われたのか。使われたのであれば、どのAIだったのか。どこまでAIがExploit開発に関与したのか。そしてv8CTFが本当の研究目的だったのか、別の目的で使われた表現だったのか。

ここを混同してはいけません。

問題は「AIがBlueMoonを書いたか」だけではない

私は、この問題でより重要なのは、「AIがBlueMoonを書いたのか？」という犯人探しだけではないと考えます。

仮に今回、AIの関与を証明できなかったとしても、生成AIやAI Agent（AIエージェント）が、コード解析、デバッグ、文書作成、試行錯誤などを高速化できる時代になったこと自体は無視できません。

これまで高度なExploit Chainを完成させるには、高い専門知識と相応の時間、人員が必要でした。

ところがAIがその一部を補助できるようになれば…

  • 脆弱性を解析する時間
  • Exploitを組み立てる時間
  • エラーを修正する時間
  • 複数の部品を統合する時間

…が短縮される可能性があります。

すると、先ほど見てきた「道具屋」の意味も変わってきます。

高度なExploitを開発する能力のハードルが下がり、完成した攻撃能力を複数の攻撃主体が利用できるようになれば、Exploitの開発速度 × 攻撃能力の再利用という組み合わせによって、脆弱性が実際の攻撃へ転換される速度そのものが上がる可能性があります。

そしてBlueMoonでは、もう一つ、この問題を考えるうえで非常に重要な出来事が起きていました。

攻撃に使われたブラウザの脆弱性は、開発者しか知らない完全な秘密の脆弱性だったわけではありません。

修正コードが公開されていたにもかかわらず、一般利用者が使う安定版ブラウザには、まだその修正が届いていない時間が存在したのです。

攻撃者は、その「時間差」を利用した可能性があります。

ここで登場するのが、Patch Gap（パッチ・ギャップ）です。

BlueMoon事件を理解するうえで、私はここが最も重要な問題の一つだと考えています。

「修正されていたのに、なぜ攻撃できたのか？」

次は、この一見矛盾しているように見える問題を追ってみました。

修正されていたのに攻撃できた？――Patch Gapという「時間差」

ここまでBlueMoonを追ってきて、もう一つ不思議なことがあります。

BlueMoonが利用したブラウザの脆弱性については、攻撃が確認される以前から、Chromiumの開発側で修正作業が進められていました。

それなのに、実際の攻撃では利用できた。

「修正されたのなら、なぜ攻撃できたのか？」

ここを理解するために登場するのが、Patch Gap（パッチ・ギャップ）という考え方です。

Patch（パッチ）とは、ソフトウェアの不具合や脆弱性を修正するための変更です。

そしてGap（ギャップ）は「隙間」「時間差」。

つまりPatch Gapとは、簡単に言えば、「開発側では脆弱性を修正するコードが作られた。しかし、その修正が一般利用者の製品へ届くまでには時間差がある」という問題です。

Chromiumで直った瞬間に、Chromeも直るわけではない

先ほど…

Chromium＝ブラウザを作るための共通基盤

Google Chrome＝Chromiumを基盤としてGoogleが提供している製品

…と説明しました。

この違いが、ここで重要になります。

Chromiumはオープンソースで開発されています。

脆弱性が発見されれば、開発者はプログラムのどこに問題があるのかを調べ、コードを修正します。

しかし、Chromiumのソースコードが修正された瞬間に、世界中のGoogle Chromeが同時に書き換わるわけではありません。

修正されたコードを製品へ取り込み、テストし、安定版として公開し、それが利用者のパソコンへ配信される。

そこには一定の時間が必要です。

つまり一時的に、開発側には修正コードが存在する一方、一般利用者のChromeには、まだ脆弱性が残っているという状態が生まれることがあります。

これがPatch Gapです。

CVE-2026-85046で実際に何が起きたのか

BlueMoonが最初に利用したV8の脆弱性、CVE-2026-85046の時系列を見ると、この問題が非常に分かりやすくなります。

Googleによると、この脆弱性が報告されたのは…

2026年8月4日。

Proofpointの調査では、その脆弱性を修正する変更がChromium側へCommit（コミット）されたのが…

8月7日。

Commitとは、簡単に言えば、「このようにプログラムを書き換えました」という変更を、開発プロジェクトへ正式に記録することです。

そしてBlueMoonによる実際の攻撃が最初に確認されたのは…

8月28日。

Google ChromeのStable Channel（ステーブル・チャンネル／一般利用者向け安定版）にCVE-2026-85046の修正が配信されたのは…

9月3日

…でした。

時系列にすると…

8月4日
脆弱性が報告される

↓

8月7日
Chromiumで修正を含む変更がCommitされる

↓

8月28日
BlueMoonによる攻撃をProofpointが確認

↓

9月3日
Google Chrome安定版で修正版が公開される

となります。

Googleも9月3日のChrome更新情報で、CVE-2026-85046について、実際の攻撃で利用されるExploitが存在していることを把握していると公表しています。

ここで注目したいのは、8月7日から9月3日までです。

開発側には脆弱性を修正するためのコードが存在する。

しかし一般利用者が使う安定版Chromeには、まだ修正が届いていない。

この間にBlueMoonによる攻撃が確認されています。

修正コードが「脆弱性の場所」を教えてしまう

さらに難しい問題があります。

オープンソースでは、プログラムの変更内容を公開することがあります。

これは本来、大きな長所です。

世界中の開発者がコードを確認でき、問題を発見し、改善し、セキュリティを高めることができます。

ところが攻撃者も、その公開情報を見ることができます。

例えば、修正前のコードと、修正後のコードを比較する。

すると、「なぜ、ここを書き換えたのだろう？」という疑問が生まれます。

さらに解析すれば…

「この処理に問題があったのではないか」

「この条件を作れば異常な動作を引き起こせるのではないか」

…と、修正内容から元の脆弱性を逆算できる場合があります。

このように、公開された修正内容の差分――Diff（ディフ／差分）――を分析して脆弱性を調べることは、一般に“Patch Diffing（パッチ・ディフィング）”と呼ばれます。

Proofpointは、BlueMoonの開発者が公開されたChromiumの修正内容を利用して、Exploit Chainを武器化した可能性が高いと評価しています。

つまりBlueMoonでは…

修正コードが公開される

↓

攻撃者が変更点を研究する

↓

脆弱性の仕組みを推測する

↓

Exploitを開発する

↓

しかし一般利用者の安定版ブラウザには、まだ修正が届いていない

という競争が発生していた可能性があります。

ここにPatch Gapの怖さがあります。

オープンソースだから危険なのか？

ここで誤解してはいけないことがあります。

「Chromiumがオープンソースだから危険だ」という話ではありません。

ソースコードを公開することで、多くの研究者が問題を発見でき、修正内容を検証でき、セキュリティを改善できるという大きな利点があります。

問題は、修正情報が利用可能になる時点と、実際に利用者が安全なバージョンへ移行できる時点の間に生じる時間差です。

防御側が修正コードを公開すれば、攻撃側も研究できる。

一方、製品として利用者へ安全に配布するためには、テストやリリースの工程も必要になります。

ここには、「情報を公開して安全性を高めること」と、「公開された情報を攻撃者が利用すること」という難しい問題が存在します。

そしてBlueMoonは、その時間差が机上の問題ではなく、実際の攻撃へ結びつく可能性を示した事例になりました。

「アップデートしていなかった人が悪い」では説明できない

この点は、利用者側から見ると非常に重要です。

サイバー攻撃の被害が発生すると、「アップデートしていなかったからだ」と言われることがあります。

もちろん、公開されたセキュリティ更新を速やかに適用することは極めて重要です。

しかしPatch Gapの最中には、利用者が適用できる修正版そのものが、まだ安定版として提供されていない場合があります。

その時間帯については、「利用者が更新を怠った」だけでは説明できません。

BlueMoonが私たちに突きつけている問題は、まさにここです。

脆弱性の発見から修正、製品への反映、利用者への配布までの速度と、攻撃者がExploitを完成させる速度。

サイバーセキュリティは、この二つの速度を競う世界になっています。

そして、もし先ほど見たAIによる開発支援がExploit開発の時間をさらに短縮するようになれば、この競争は一段と厳しくなるでしょう。

では私たちは、どうすればよいのか。

「最新版へ更新してください」だけで、BlueMoonへの対策は十分なのか。

ここからは攻撃者側ではなく、私たち防御側へ視点を移します。

BlueMoonのExploit Chainを、今度は逆方向から見てみましょう。

どこで、この攻撃を止めることができるのか。

それを考えて結びとしたいと思います。

BlueMoonをどこで止めるのか――防御側から考える

ここまでBlueMoonを攻撃する側から追ってきました。

最後は視点を反対側へ移してみましょう。

私たちは、この攻撃にどう備えればよいのでしょうか。

まず基本となるのは、やはりブラウザとOSを最新の状態に保つことです。

Google Chromeだけでなく、Microsoft EdgeなどChromiumを基盤とするブラウザについても、それぞれの更新状況を確認する必要があります。

Windowsについても同様です。

そして更新後には、必要に応じてブラウザやOSを再起動し、修正版が実際に動作している状態にすることも重要です。

しかし、今回見てきたPatch Gapを考えれば、「最新版にしておけば、それだけで絶対に安全」とも言い切れません。

利用者が適用できる修正版がまだ存在しない時間帯に、攻撃が始まる可能性があるからです。

だからこそ、もう一つ重要になるのが多層防御です。

  • メールやメッセージの段階で不審な誘導を検知する。
  • 攻撃用ドメインへの接続を遮断する。
  • ブラウザから通常とは異なるプロセス操作が発生していないか監視する。
  • EDRなどを利用して、不審なプログラムの実行や侵入後の活動を検知する。

企業や組織であれば、こうした複数の防御を組み合わせることで、たとえ最初の一枚を突破されても、次の段階で攻撃を止められる可能性があります。

BlueMoonが複数の脆弱性をつないで攻撃を成立させるのであれば、防御側もまた、複数の防御を重ねて対抗する必要があります。

利用者にできること

一般の利用者に、高度なExploitを見抜くことはできません。

それを求めるべきでもないでしょう。

私たちにできるのは、もっと基本的なことです。

ブラウザやOSの更新を後回しにしない。

メールやSNSなどから誘導されたリンクについては、送信者だけで信用せず、内容やリンク先を確認する。

突然表示された画面の指示に従って、ファイルのダウンロードやセキュリティ設定の変更を行わない。

そして、普段と違う挙動に気付いたら、そのまま使い続けない。

地味に見える対策ですが、攻撃者から見れば、侵入までに越えなければならない壁を一枚増やすことになります。

最後に――BlueMoonが示したもの

今回BlueMoonを追ってみて、私が特に気になったのは、3つの脆弱性そのものだけではありません。

脆弱性が発見され、修正され、Exploitへ変わり、実際の攻撃で利用されるまでの速度です。

さらに、同一系統のExploit Kitが短期間のうちに複数の異なる攻撃主体によって利用されていました。

その背後に「道具屋」のような存在がいるのか。

AIが開発を支援していたのか。

どのような経路で複数の攻撃主体がBlueMoonへアクセスできたのか。

まだ答えの出ていない問題は残っています。

だからこそ、今後も追跡する価値があります。

BlueMoonは、利用者の目から見れば、

「リンクをクリックしてWebページを開いただけ」というところから始まる攻撃でした。

しかし、その数秒間の裏側には、今回見てきたような複雑な技術と攻撃者側の準備が存在していました。

私たちが普段何気なく使っているWebブラウザは、インターネットを見るための「窓」であると同時に、外の世界からプログラムを受け取り実行する巨大なソフトウェアでもあります。

そのことを知るだけでも、インターネットの見え方は少し変わってくるのではないでしょうか。

そして、「なぜ、Webサイトを開いただけで攻撃が成立するのか？」

その疑問から始まった今回のネット探検は、ここでいったん終わりにしたいと思います。

BlueMoonについて新しい動きが確認されれば、ネット探検ラボでも引き続き追跡していきたいと思います。

巻末掲載案

主要参考資料
Proofpoint Threat Research Team
Once in a BlueMoon: Multiple State-Aligned Threat Actors Rapidly Adopt Novel Exploit Chain Using Chrome and Windows Zero-Days
2026年9月9日
Proofpoint公式調査記事（日本語）

コメント

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