水曜日のパッチ：根本原因分析に LLM を活用

• この調査では、パッチ適用された脆弱性の根本原因を見つけるために大規模言語モデルを使用する方法を検証しました。 

• Akamai は、Patch Tuesday の脆弱性の根本原因を自律的に分析し、詳細なレポートを生成する、PatchDiff-AI というマルチエージェントシステムを開発しました。 

• このような分析は、セキュリティチームがほぼ瞬時に脆弱性を分析するための助けになり、防御目的と攻撃目的のいずれにも役立ちます。

• 複数の戦略を使用することで、システムを微調整し、完全に自動化されたレポート生成で 80% 以上の成功率を達成（攻撃ベクトル分析やフローのトリガーなど）することができました。

Microsoft の定期的な更新サイクルは、毎月第 2 火曜日である Patch Tuesday に集中しており、CVE とそれに対応する修正の包括的なリストがリリースされます。これらの修正プログラムは、Microsoft スタンドアロンアップデート（MSU）ファイルとして配布されます。MSU ファイルは、コア・システム・ファイルにパッチを適用または置換することでアップデートを適用するパッケージ形式です。

Patch Tuesday の後に起こるのが、「Exploit Wednesday」と呼ばれるものです。これは、Microsoft がパッチを作成した脆弱性を攻撃者が競って解析するために発生します。更新されたバイナリに対してバイナリ差分を実行することで、攻撃者は根本的なセキュリティの問題を迅速に特定し、組織がパッチを広く展開する前にそれらの悪用を試みることが可能になります。

同様に、防御側はしばしば、検知方法と緩和策を作成するため、配布されたパッチを急いで分析し、脆弱性の根本原因を把握します。

今日では、パッチ差分解析は骨の折れる作業です。脆弱なコードの一片を特定するために、研究者は次のことを行う必要があります。

1. 脆弱性が含まれている可能性があるファイルを特定する

2. バイナリ差分を実行して、変更箇所を特定する

3. セキュリティ関連の変更を他のルーチンコード更新から分離する

4. 疑わしいパーツを分析し、根本原因を把握する

5. コールフローを動的に調査し、潜在的なトリガー手段を見つける

6. パッチ修正の完了を評価する

これらの手順の実行には数週間かかることがあり、毎月同時にリリースされる脆弱性の数が膨大であることから、この問題はさらに深刻化しています。

Akamai では、研究者がパッチを適用した脆弱性を迅速に解析し、その根本原因を把握できるようにする、より良い方法を見つけることに着手しました。

大規模言語モデル（LLM）は、ユーザー入力とともにトレーニング済みデータに基づいて、合理的で正確な情報を統計的に生成できます。しかし、限られたコンテキストウィンドウ（処理できるデータ量と運用コストに影響を与える）や悪名高いモデルのハルシネーションなど、いくつかの制限があります。

セキュリティ領域の脆弱性評価の分野において、LLM の貢献に関する多くの論文が、長年にわたって発表されてきました。今日、LLM はクローズド・ソース・ソフトウェアの解析に苦戦しているように見えますが、オープンソースと Web の脆弱性に関しては、人間が判読できるコードが存在するという共通点があるため、より高いパフォーマンスを発揮するようです。

OpenAI の Aardvark と Claude Code のセキュリティレビュー機能は、引き続き読み取り可能なソースコードに制限されています。一方、ゼロデイ脆弱性の発見を目指す Google Project Zero の Big Sleep というプロジェクトもあります。どちらのアプローチも、バイナリをクローズドソースとして分析しません。

Akamai の調査は、セキュリティパッチの根本原因分析（RCA）に LLM を使用することで、異なるアプローチを採用しています。検証済みと思われる私たちの理論は、バイナリの「diff」によって提供される追加コンテキストが、複雑で低レベルのコードを理解するという LLM の能力を大幅に強化するというものでした。

このタスクでは、特定のプラットフォームの Microsoft Knowledge Base（KB）更新プログラムの分析を自動化するマルチエージェントシステムを開発しました（図 1）。私たちはこれを、「PatchDiff-AI」と呼ぶことにしました。

コンテキストウィンドウの制限とハルシネーションのため、LLM を可能な限り効果的に使用するための関連性の高い簡潔なコンテキストを提供し、運用コストを削減しながら脆弱なコードコンポーネントを分離するタスクで高い精度を維持することが重要です。

今回の実装における重要な詳細の 1 つは、分析を焦点を絞った小タスクに分割し、最終的にエージェントとして機能させることでした。

• CVE に関する情報を取得してプロファイルを作成する

• 関連する更新をダウンロードし、ベース・バージョン・ファイルに対してデルタを適用する

• Windows 内部 AI エージェントを作成し、脆弱性メタデータを使用して関連ファイルを分離する

• 次の処理を実行可能なリバースエンジニアリング AI エージェントを作成する。

  • シンボルを分解して適用し、バイナリ差分解析用にエクスポートする

  • バイナリを関連付け、変更とコールフローを特定する

  • 脆弱なコードブロックを特定する

• 可能性のある脆弱性パスを反復処理して相互相関を図り、可能な限り最良の結果を見つける、脆弱性調査 AI エージェントを作成する

この分割の主な利点の 1 つは、タスクタイプごとに特定のモデルを使用できることです。OpenAI o4-mini はファイルメタデータの強化に優れており、OpenAI o3 は脆弱性の疑いのあるコードの究極の詳細分析に使用されました。

タスクに適したモデルを選択することには、2 つのメリットがありました。1 つ目は正確性、2 つ目はコストです。

LLM は、大量の情報を「記憶」するマシンです。プロンプトを使用して LLM を呼び出すと、プロンプトのコンテキスト内で最も関連性の高い情報が提供されるように LLM が調整されます。

パッチを適用した脆弱性に関する情報を LLM に提供することで、より正確な応答を生成し、脆弱なコードを見つける可能性を高めることができます。ただし、脆弱性に関するあいまいな情報が紛れていると、結果の質は低下します。

分析中に脆弱性メタデータでコンテキストを強化することが重要であることが証明されました。コンテキストの強化を実現するために、私たちは LLM に KB の説明、システムファイルの説明、バイナリ差分データを投入しました。このアプローチにより、分析が必要な変更箇所の数を絞り込むことができたため、LLM でのコンテキストの長さと反復の数も絞り込むことができました。

私たちのフレームワークを評価するために、モデルの機能を検査し、以下を正確に特定しました。

• CVE に対応する脆弱な実行可能ファイル

• 実行可能ファイル内の脆弱な関数

• 脆弱性の根本原因とその正確な説明

これらのパラメーターに基づいて、Windows 11 24H2 の直近 3 回の Patch Tuesday のリリースを分析しました。私たちが開発したツールを実行して自動レポートを生成した後、選択した結果を手動で検査し、最終的なモデル応答の精度を判定しました。

コンテキストを調整し、さまざまなタスクに合わせて幅広いモデルを調整した結果、最終的に次のような結果が得られました。

• 問題の CVE に対してパッチが適用された正しい実行可能ファイルを 88.6% の確率で特定 

• 確実に脆弱性のある機能を 83.9% の確率で発見 

• 脆弱性の正しい根本原因を 71.4% の確率で特定

静的分析ツールのクラッシュやデルタパッチの適用不能など、コンテキストが不十分なために発生したレポート生成の失敗を除外すると、正しいコードブロックが与えられた場合のモデルの成功率を推定できます。このような場合、コンテキストで正しいコードブロックが与えられている場合、LLM の成功率は約 96% になります（図 2）。

その結果、いくつかの興味深いユースケースに遭遇しました。そこで、それらを共有し、徹底的に調査したいと思います。すべてのユースケースには、以下のとおり同じレポート構造があります。

• レポートを構成する CVE の詳細

• RCA（レポートの核心）

• パッチの前後のコードスニペット

• 脆弱性がトリガーされると考えられる方法に関するトップダウン概要

• パッチに関する強調された説明

• 脆弱性を悪用する可能性のある攻撃ベクトル

• 脆弱性の明確で詳細な影響

さらに、各レポートの最後のセクションでは、パッチの有効性に疑問を呈し、パッチがバイパスされる可能性を確認します。

次の 4 つのケーススタディでは、私たちのフレームワークが秀でている点、苦戦している点、完全に失敗している点に焦点を当てた興味深い事例をいくつか紹介します。

IDA と BinDiff を使用してこれらの結果を調べると、実際に正しい場所が記載されていることがわかります。また、Microsoft は機能フラグを使用して脆弱性修正プログラムをオプトアウトしていることがわかっているため、予期しない動作が発生した場合に同じやり方で元に戻すことができます（図 5）。

残りのセクションでは、パッチ自体とそのセキュリティ上のシステムへの影響について、より一般的な説明を提供します。ただし、最後のセクションでは、LLM をパッチに挑戦させ、修正プログラム内の別の脆弱性を特定することで迅速に成果が得られるかどうかを確認するよう依頼しました。今回の場合、パッチが完了したことが次のとおり評価されました。「すべてのエラーパスが、範囲外アクセスの可能性が生じる前に上げられるようになりました」

自動生成された IDA データベースと BinDiff 出力に照らしてレポートを評価することは、検知や緩和に重点を置いているチームにとって有益であり、多くの場合十分な情報となります。しかし、私たちのアプローチはさらに先を行き、攻撃的な目的にも役立つことが証明されています。なぜなら、場合によっては、システムが分析の範囲を超え、実際に有効な悪用方法を編み出すことができるからです。

たとえば、2025 年 6 月の更新プログラム（KB5060842）でパッチが適用された脆弱性 CVE-2025-32713 の説明は、次のとおりでした。「Windows Common Log File System Driver のヒープベースのバッファオーバーフローにより、認証を受けた攻撃者がローカルで権限を昇格させることができます。」私たちのツールは、約 2 分で、この問題を CClfsLogFcbPhysical::ReadLogBlock() にトレースバックするレポートを生成しました。

この時点で、悪用の課題に対処する方法は 2 つあります。 

1. 関数とその呼び出し元を手動でユーザーモード呼び出しに戻す 

2. LLM に任せて、自律的に PoC を作成してもらう 

しかし、多くの場合、3 つ目の選択肢があります。それが、ハイブリッドのアプローチです。間接的なコードフローを決定し、バイナリの論理部分間の複雑な接続を解決しながら、リバースエンジニアリングの負荷の高い作業を LLM に依頼します。これにより、LLM はより良い結果を出すことができます。

この手法を使用することで、わずか数時間でブルースクリーン（BSOD）攻撃を実現できました（図 9）。

この応答には非常に惑わされ、最終的に脆弱なコードをトリガーする方法を把握することから遠ざかってしまいました。実際、私たちはまったく無関係な研究パスにたどり着きました（私たちが操作しようとしたのは、すでに緩和策が導入されている .blf ファイル構造だったのです）。その後、セクターごとに異なる物理バイトと論理バイトを持つ仮想ディスクを作成し、デバッグを通じてそのふるまいを分析しました。

LLM が作業の大部分を処理したと言っても過言ではありませんが、経験豊富な研究者による綿密な監督が必要でした。LLM は、支援が正しく提供されている限り、人間を支援するツールになります。

モデルは時々非生産的な方向に向かって進むことがあるため、あるべき方向に進み続けるためには人間のガイダンスが不可欠でした。とはいえ、結果がそれを物語っています。LLM は脆弱なコードを正しく特定し、コールフローを正確に追跡し、v27 の誤った割り当てが CcCopyRead() でどのようにオーバーフローを引き起こしたかを説明しました。

LLM 出力を慎重に取得しなければならない場合があります。LLM のリスクはハルシネーションだけではありません。このことは、さまざまな LLM インターフェースで繰り返し言及されています（例：「ChatGPT は誤った回答をする可能性があります。重要な情報は確認してください。」）

ここでも同じことに注意する必要がありますが、システムは入出力を検証し、複数のパスを調べて根本原因を特定しようとします。条件が広すぎてあいまいなため、ほとんど不可能な場合があります。

5 月の KB5058411 アップデートから CVE-2025-29974 を取り上げます。脆弱性に関する MSRC 情報ページには、「Windows カーネルの整数アンダーフロー（ラップまたはラップアラウンド）により、攻撃者が認証なしで隣接するネットワークを介して情報を開示することができてしまいます」と記載されていますが、これはややあいまいかもしれません。

次に、MSRC ページで、攻撃者が近くにいる必要があることが示されています。つまり、攻撃者は無線送信を受信できる範囲内に潜んでいる必要があるということです。これは明らかに、情報のエアギャップ流出について説明しています。しかし、どのようにして流出するのか、またどのようなハードウェアを使用するかが明確ではありません。このようにコンテキストが欠落していると、有効なレポートを取得できる可能性が低くなります。

CVE-2025-29974 に関して、ツールを実行し、SUB_1408E6D3C と SUB_1408FAD58 という 2 つの名前のない関数に関するレポートを作成しました。便宜上、以降はこれらを「primary()」と「secondary()」と呼ぶことにします。図 13 は、これらの関数の BinDiff ビューです。これらの関数がかなり異なることがよくわかります。私に言わせれば、あまりにも違いすぎるといったところでしょうか。

コンポーネントに複数の脆弱性があり、アップデートによって解決される場合があります。単一のロジックの欠陥には異なるクラスの脆弱性の連鎖が含まれている可能性があるため、これは珍しいことではありません。 

KB5055523（2025 年 4 月）のアップデートを見ると、CVE-2025-24058、CVE-2025-24060、CVE-2025-24062、CVE-2025-24073、CVE-2025-24074 と呼ばれる一連のバグが確認できます（図 14）。これらはすべてデスクトップ・ウィンドウ・マネージャー（DWM）に関連しており、すべて「CWE-20：Improper Input Validation（不適切な入力検証）」というメッセージが表示されます。これにより、モデルが不明瞭かつあいまいになります。