LLM発展後のEDRとの攻防 - 検知ロジックの解析がもたらす攻撃・防御の変化

はじめに

2026年6月、SpecterOpsからLLMを活用してEDRの検知ロジックを解析し、その結果を基にしたEDRの回避手法について紹介されたブログが公開されました。

参考情報

• Accelerating EDR Evasion with LLM-Driven Analysis

近年、LLMの発展により、高度な知識や多くの時間を要していた調査・分析を効率的に進められるようになりました。こうした技術の進歩は、防御側の業務を効率化する一方で、攻撃側にも活用されることが想定されます。

その一例として、上記ブログのような方法で、これまで高度な攻撃者しか実施できなかったような検知回避の試行錯誤が効率化され、EDR検知を回避した攻撃が今後さらに増加していく可能性があります。

当社では、LLMが登場する以前から、高度な攻撃者を想定したTLPT/レッドチーム演習において、EDR検知を回避するためのアプローチを取り入れてきました。一方で上記のとおり、今後はLLMの活用によってEDR検知ロジックの回避がコモディティ化し、「EDR検知を回避してくるような、高度な技術力を持った攻撃者はごく一部」という言説が通用しなくなる可能性は十分に考えられます。

本記事では、LLMによるEDRの検知ロジック解析が攻撃側・防御側に与える影響を整理するとともに、実際の攻撃者が今後どのようにこれらの技術を活用する可能性があるのかを考察します。あわせて、LLM時代において防御側が講じるべき対策についても解説します。

なお、本記事はEDRの静的解析に着目した検証であり、実際のEDR製品が備える振る舞い検知やクラウド分析などを回避できることを示すものではありません。

---

EDRの仕組みとは？

EDR（Endpoint Detection and Response）は、PCやサーバーなどのエンドポイント上で発生するイベントを継続的に監視し、不審な挙動やマルウェアの実行を検知・対応するためのセキュリティ製品です。

一般的なEDRは、エンドポイントにインストールされたEDRエージェントと、収集した情報を分析するクラウドのバックエンドで構成されています。

エンドポイント（管理端末）にはEDRエージェントがインストールされており、プロセス、ファイルシステム、ネットワーク通信などを監視する複数のセンサー（Sensor）が組み込まれています。各センサーは、それぞれの対象からセキュリティ上重要なイベント（テレメトリ）を収集し、一定間隔でクラウドのバックエンドへ送信します。

クラウドでは、各エンドポイントから送信されたテレメトリを集約し、データベース検索や検知ルール、AI・機械学習などを組み合わせて分析を行います。マルウェア感染や侵害の兆候が検出された場合にはアラートを生成し、必要に応じてエンドポイントへプロセスの終了や端末の隔離といったレスポンスを指示します。

なお、これらの分析は必ずしもリアルタイムで実施されるわけではありません。

EDRは、エンドポイント上のCPU使用率やメモリ消費、ネットワークの帯域、さらにクラウド側の処理能力とのバランスを考慮する必要があります。そのため、収集したテレメトリは一定量ごとにまとめて送信・分析されることが一般的であり、すべてのイベントをリアルタイムに解析しているわけではないのです。

また、エンドポイント上で発生するすべてのイベントを監視すると性能への影響が大きくなるため、EDRは製品ごとに監視対象となるイベントを選択し、それらを組み合わせることで高い検知精度を実現しています。

参考情報

• What is Endpoint Detection and Response (EDR)?

EDRの主な検知手法

各ベンダーによって実装は異なりますが、多くのEDRでは以下のような複数の検知手法を組み合わせて脅威かどうか判定しています。

静的解析

静的解析は、プログラムを実行せずにファイルそのものの特徴を解析する手法です。

一般的な静的解析では、まずファイルのハッシュ値を既知のマルウェアデータベースと照合します。次に、シグネチャやパターンマッチング（YARAなど）によって既知の悪性パターンと一致するかを検査します。

これらの手法で判定できないファイルに対しては、機械学習モデルによる評価が行われます。機械学習モデルは、以下のような情報を特徴量としてファイルを評価します。

• PEヘッダー
• インポートアドレステーブル（IAT）
• セクション構成
• デジタル署名
• エントロピー
• 文字列情報
• バイナリ全体の特徴量

このため、シグネチャが存在しない未知のバイナリであっても、マルウェアと類似した特徴を持つ場合は悪性と判定される可能性があります。

振る舞い検知

振る舞い検知は、ファイルではなく実行後の動作に着目する検知手法です。

例えば、以下のようなイベントを継続的に監視し、通常とは異なる挙動を異常として検知します。

• WordやExcelのプロセスからPowerShellが起動された
• 新たなサービスが作成された
• 正規プロセスへコードインジェクションが行われた
• 普段通信しないドメインへのHTTP通信
• 深夜帯に大量の認証試行が発生した

近年ではAIや機械学習を活用し、端末やユーザーごとの通常の振る舞いを学習したうえで、そこから逸脱する行動を検知する製品も増えています。

---

このように、現在のEDRはシグネチャだけでマルウェアを判定しているわけではなく、静的解析・振る舞い検知など複数の検知手法を組み合わせることで、未知の脅威にも対応しています。

本記事では、EDRの静的解析の検知ロジックにフォーカスし、攻撃者がマルウェアを開発する際にどのようにマルウェアの品質を評価・改善するのか紹介します。

LLM×EDR製品検知ロジック=超高速で高精度な検知回避の実現

一般的なEDRでは、静的解析によって取得したファイルの特徴量をもとに、機械学習などを用いて悪性である可能性をスコアとして評価します。スコアが製品ごとに定められた閾値を超えた場合、そのファイルは悪性と判定されます。

LLMの登場以前では、EDRの検知ロジックを分析し、検知を回避するマルウェアを開発するためには、高度な専門知識に加え、多くの時間を要する試行錯誤が必要でした。

例えば、マルウェアを作成して実際にEDRが導入された環境で実行し、その検知結果を確認しながら実装を修正するという作業を何度も繰り返すか、リバースエンジニアリングによるEDR解析に非常に多くの時間をかける必要がありました。そのため、検知回避は一部の高度な攻撃者が長い時間をかけて行うものであり、容易に実現できるものではありませんでした。

しかし、LLMの登場により、この状況は大きく変わりつつあります。LLMを活用することで、EDRが静的解析でどのような特徴を評価しているのか、その傾向を効率的に整理・分析できるようになり、これまで多くの時間を要していた試行錯誤を大幅に効率化されていることを確認しています。

その結果、ターゲット環境へマルウェアを投入する前に、ローカル環境でマルウェアの品質を評価・改善し、ある程度完成度を高めたうえで攻撃に利用できるようにするというルーチンが、不正アクセスを試みるような攻撃者の間でも一般的になると考えます。

本章では、そのようなアプローチが実際にどのように活用されるのか、3つのEDR製品（製品A・製品B・製品C）を対象に、静的解析のスコア評価の傾向を分析し、ローカル環境でスコアを評価しながらマルウェアを段階的に改善していく流れを紹介します。

評価対象

評価対象として、ファイルからシェルコードを読み込み、メモリ上で実行するシンプルなローダー（評価用マルウェア本体をメモリ上に読み込み、実行するプログラム）を使用しました。VirtualAllocでメモリを確保し、CreateThreadで実行するという典型的な構成です。

各製品のEDRの閾値は下記の通りです。
このスコアを上回った場合、純粋なコーディングでの結果か、バイナリパッチのようなテクニックを使用した結果かなどで検知影響は変動するものの、悪性と判定されEDRに検知されると考えて良い数値となります。

製品A	製品B	製品C
0.002762	0.58	0.5

実行方法自体は変更せず、本評価用に定義した構成を維持したまま、段階的にスコアの改善を試みました。

スコアの改善

各製品の特徴量の重みや構成を参考に、以下の4段階でバイナリを改善し、スコアの変化を測定しました。

Step 01：シンプルな疑似マルウェア

Step 01のローダーは、一般的なローダーでよく使用されるWin32 APIであるVirtualAlloc、CreateThread、WaitForSingleObjectなどをそのまま実行するローダーです。各製品のEDRのスコアを確認するといずれのEDR製品においても高いスコアが算出されており、検知される可能性が高いことが確認できます。

Step 02：IATの工夫をした疑似マルウェア

IAT（Import Address Table：インポートアドレステーブル） は、Windowsの実行ファイル（PEファイル：EXEやDLL）に含まれるテーブルで、プログラムが利用するWindows APIと、それらを提供するDLLの情報を保持しています。

マルウェアやシェルコードローダーでは、VirtualAlloc、VirtualProtect、CreateThread、WaitForSingleObject などの典型的なAPIのみを使用することが多く、その結果、IATには kernel32.dll のみがインポートされるケースがあります。

一方、一般的なWindowsアプリケーションでは、user32.dll や advapi32.dll をはじめ、複数のDLLからさまざまなAPIを利用することが一般的です。そのため、kernel32.dll のみをインポートし、かつマルウェアで頻繁に利用されるAPIが集中しているIATは、通常のアプリケーションとは大きく異なる特徴となり、EDRやアンチウイルス製品による検知の対象となる可能性があります。

そのため、Step 01のローダーが高スコアとなる主な要因として、IATにシェルコード実行に典型的なAPIが含まれていること、インポートするDLLがkernel32.dllに限られており正規アプリケーションと大きく異なることが挙げられます。
Step 02としてインポートするDLLの種類、APIがどの程度スコア評価に影響するか調査しました。

Step 01のローダーのスコアを0とした場合のスコア変化を下図に示します。

調査の結果、下記のことがわかります。

• version.dllが製品Aにとって非常に効果的である（-0.49）
• ws2_32.dllは製品Ａのスコアを逆に上昇させた（+0.11）
• 製品CはインポートするDLLの種類の増加は疑わしいと判定する傾向がある

さらにDLLの関数の数によってスコアにどう影響するか調査しましたが、本記事のローダーでは、いずれの製品においてもそこまでスコアには影響しないことが確認されました。

最終的にStep 02の実装の結果、下記に示す通りスコアが改善されることが確認できました。
※使用する関数によってスコアが変動するため、今回の検証では製品Cのスコアが少し低下する結果となりました。

Step	手法	製品A	製品B	製品C
01	シンプルなローダー	0.758986	0.931121	0.692020
02	IATの多様化	0.464185	0.707132	0.685216

Step 03：Windows APIをハッシュ化した疑似マルウェア

Step 02でIATを正規アプリケーションに近づけましたが、VirtualAllocやCreateThreadなどの不審なAPIは依然としてIATに残っています。不審なAPIをIATから除去し、実行時にハッシュ値で動的に解決するAPIハッシュ化を実装します。これによりIATからVirtualAllocやCreateThreadなどの不審なAPIが削除され、バイナリに含まれる文字列としてもAPI名が削除されます。

一般的なローダーでよく使用されるWin32 APIであるVirtualAlloc、CreateThread、WaitForSingleObjectを対象としました。

Step 01のローダーのスコアを0とした場合のスコア変化を下図に示します。

調査の結果、下記のことがわかります。

• VirtualAllocが製品A、製品Bにおいて非常に効果的である（製品A：-0.28、製品B：-0.16）
• WaitForSingleObjectはAPIハッシュ化しても効果が薄い、または逆効果
• 全ハッシュ化が最適とは限らない（製品Bでは、VirtualAlloc + CreateThreadの組み合わせが最も効果的）
• 製品Cでは、単純にAPIをハッシュ化するだけではスコアは大きく下がらない

その他のAPIについても同様に調査し、最終的にStep 03の実装の結果、下記に示す通りスコアが改善されることが確認できました。

Step	手法	製品A	製品B	製品C
01	シンプルなローダー	0.758986	0.931121	0.692020
02	IATの多様化	0.464185	0.707132	0.685216
03	APIハッシュ化	0.321753	0.238664	0.346828

Step 04：GMOイエラエ独自開発の疑似マルウェア

当社が提供するペネトレーションテスト（侵入テスト）は、EDRが有効化された環境を前提としています。そのため、本記事で紹介したような高度なアプローチを従来から採用しており、さらに単一の疑似マルウェアに対して複数のEDR製品のスコアを算出し、当社独自のアプローチによって検知スコアを低減させる内製システムを備えています。これにより、EDR導入端末においても高確率で実行可能な「疑似マルウェア」の状態を常に維持しています。

Step 04では、本記事で解説したアプローチをベースに、当社独自の検知回避手法を実装した疑似マルウェアのスコア評価結果を紹介します。

Step	手法	製品A	製品B	製品C
01	シンプルなローダー	0.758986	0.931121	0.692020
02	IATの多様化	0.464185	0.707132	0.685216
03	APIハッシュ化	0.321753	0.238664	0.346828
04	GMOイエラエ独自開発ローダー	0.000502	0.000777	0.161889

各段階でのスコア推移を以下に示します。

このように、EDR製品の検知ロジックを解析し、ローカル環境で動作するスコアリングツールを構築することで、マルウェアの改善サイクルを効率的に回すことは十分に現実的です。また、このようなアプローチ自体がパブリックな情報として公開され始めていることも、防御側として認識しておく必要があります。

本記事では、その一例として簡易的な検証結果を紹介しましたが、LLMの発展に伴い、こうしたアプローチは今後さらに攻撃者にとって有用なものになっていくと考えられます。そのため、防御側においても、攻撃者がLLMをどのように活用し、検知回避を試みるのかといった最新のアプローチを継続的に把握し、それを前提とした防御・検知戦略を検討していくことが重要です。

---

レッドチーム演習への影響と防御の考え方

上述の通り、LLMの発展により、攻撃者がEDRの検知ロジックを把握し、マルウェアを効率的に作成できる可能性が高まっています。

従来、このような検知回避を実現するためには、多くの試行錯誤や非常に高度な知識が必要でした。しかし、LLMを活用することで、静的解析において評価される特徴やスコアへ影響する要素を効率的に整理・分析できるようになり、検知回避に要する時間やコストは大幅に低下すると考えられます。

これはレッドチーム演習に限った話ではなく、実際の攻撃者にとっても同様です。今後は、これまで以上にEDRによる検知を回避したマルウェアが利用されるケースが増加することが予想されます。

そのため、防御側は「EDRで検知できること」を前提とした設計・運用ではなく、「EDRによる検知を回避される可能性」を前提とした多層防御を検討する必要があります。

以下では、その代表的な対策を紹介します。

実行制御

まず重要となるのが、不要なプログラムを実行させないことです。

実行制御には、AppLockerやWindows Defender Application Control（WDAC）など、組織で実行可能なアプリケーションを制御する仕組みがあります。

また、Windows 11ではSmart App Control（SAC）が提供されており、Microsoftのクラウド評価やデジタル署名をもとに、信頼できるアプリケーションのみ実行を許可することができます。

例えば、下記の実行制御を適切に構成することで、仮にEDRによる検知を回避されたとしても、マルウェア自体の実行を防げる可能性があります。

• デジタル署名のない実行ファイルを制限する
• 利用を許可したアプリケーションのみ実行を許可する
• ダウンロードフォルダなど特定ディレクトリからの実行を禁止する

一方で、msbuild.exeなどの正規バイナリを悪用するLiving off the Land（OSや正規ソフトウェアに含まれる標準機能・正規実行ファイルを悪用し、攻撃を行う手法）のように、実行制限を回避する手法も存在します。このような手法では、利用されるバイナリ自体は正規のものであるため、業務上の正当な利用と不正利用の判別が難しく、防御側には実行元、引数、親プロセス、実行後の振る舞いなどを踏まえた複合的な判断が求められます。そのため、実行制御は単独で完結する対策ではなく、端末の用途や業務内容に応じて利用可能な標準機能を整理し、不要な実行経路を制限したうえで、権限管理、通信制御などと組み合わせた多層防御として運用することが重要です。

通信制御

EDRによる検知を回避された場合でも、攻撃者は外部のC2（Command and Control）サーバーとの通信や、情報の持ち出しを行う必要があります。そのため、外部通信を適切に制御することは、被害の拡大を防ぐうえで重要な対策となります。

多くの組織では、以下のような仕組みを利用して外部通信を制御しています。

• Proxy
• PACファイル
• Firewall

しかし、外部通信を制限しているつもりであっても、実際には広範囲の通信が許可されているケースは少なくありません。

例えば、高度な攻撃者は、CDNやクラウドストレージ、スプレッドシートなどの正規サービスを通信先として利用することで、通常の業務通信に紛れ込ませながら外部と通信することがあります。これらのサービスは業務上利用されることが多く、組織によっては広範囲に通信が許可されているため、攻撃者に悪用される可能性があります。

そのため、通信制御を行う際は、「通信を制限している」という前提ではなく、「実際にどのような通信が許可されているのか」を定期的に確認することが重要です。また、ProxyやPACファイル、Firewallの設定を見直し、業務上必要な通信のみを許可する最小権限の考え方で設計・運用することが求められます。

業務上、外部通信を厳しく制限することが難しいケースも多くありますが、可能な限り通信先を限定し、業務上必要なサービスのみに外部通信を許可する運用を検討することが重要です。

アカウント権限やネットワーク公開ポートの見直し

仮に社員がフィッシングメールなどによってマルウェアを実行してしまったとしても、そのユーザーに付与されている権限が必要最小限であれば、攻撃者が実行できる操作を大きく制限できます。

例えば、一般ユーザーにローカル管理者権限を付与している場合、マルウェアはシステム全体への変更や永続化、セキュリティ機能の無効化などを容易に実行できる可能性があります。また、ローカル管理者アカウントのパスワードが複数端末で共通化されている環境では、SMB（445/TCP）やRDP（3389/TCP）など横展開に利用可能なサービスが有効になっているクライアントPCを経由して、攻撃者が容易に他の端末へ侵害を拡大できる可能性があります。

実際に当社が実施したペネトレーションテストでは、一般社員アカウントにドメイン管理者権限が誤って付与されているなど、権限管理に問題のある環境を確認したケースもあります。このような環境では、単一端末の侵害が組織全体への侵害に直結するリスクがあり、極めて深刻な問題となります。

一方、最小権限の原則に基づいて適切に権限を管理していれば、攻撃者が取得できる権限も限定されるため、被害を最小限に抑えられる可能性が高まります。また、管理者権限を持つアカウントと日常業務で利用するアカウントを分離することや、必要なタイミングのみ一時的に権限を付与するJIT（Just-In-Time）アクセスを採用することも有効です。

さらに、クライアントPC間で不要なSMBやRDPなどの通信を許可しない、不要なサービスや公開ポートを無効化するといったネットワーク面での対策も重要です。これらの対策を組み合わせることで、仮にEDRによる検知を回避されることを前提とした場合でも、攻撃者の行動範囲を制限し、侵害の拡大や重要資産へのアクセスを防ぐことができます。

---

終わりに

LLMの発展は、防御側の業務を効率化するだけでなく、攻撃側の活動にも大きな変化をもたらしています。

本記事では、LLMを活用したEDRのスコア評価を一例として、ターゲット環境へマルウェアを投入する前にローカル環境で評価・改善しながらマルウェア開発を進められる可能性について紹介しました。また、SpecterOpsの記事でも示されているように、LLMを活用してEDRの検知ロジック自体を解析することで、攻撃者の試行錯誤にかかる時間やコストは今後さらに低下していくことが考えられます。

もちろん、現在のEDRは静的解析だけでなく、振る舞い検知、クラウド分析など複数の技術を組み合わせており、LLMだけで検知を完全に回避できるわけではありません。しかし、攻撃者がこれまで以上に効率的に検知回避を試みられるようになることは、防御側として認識しておくべき重要な変化と言えます。

そのため、今後はEDRによる検知だけに依存するのではなく、実行制御や権限管理、通信制御などを組み合わせた多層防御を前提とした設計・運用がこれまで以上に重要になります。

LLMが発展した現在においてより求められるのは、「EDRで検知できること」を前提とするのではなく、「EDRによる検知を回避される可能性」を前提とした多層防御を実現することです。本記事が、そのような防御のあり方を見直すきっかけとなれば幸いです。