AI が生成する Mythic エージェント：従来の静的シグネチャとインプラント検出からの脱却とは？

AI-Generated Mythic Agents Challenge Static Signatures and Traditional Implant Detection

2026/06/29 gbhackers — LLM を悪用する “使い捨てツール” の登場が、攻撃側の戦術／手法を再定義しつつあり、静的シグネチャや既知のインプラントの振る舞いに依存する検出モデルの見直しを、防御側に対して迫っている。最近の実験では、プロンプトからデプロイまでをカバーする、Mythic エージェントの自動生成が実証されている。そこで明らかにされたのは、LLM とオーケストレーション・ハーネスにより個別に生成される、短命かつ使い捨てのインプラントという新たな脅威クラスである。

Mythic Traffic flow diagram (Source : Specterops).

これらのエージェントは軽量であり、短期間の攻撃活動を目的として設計され、人間の介入を最小限に抑えながら大規模に生成される。つまり、現在の多くの検出パイプラインに組み込まれるエージェントの前提を覆すものである。

LLM が生成する Mythic エージェントは、技術的な観点における 3 つの点で検出を困難にする。

  • コードの多様性：このモデルは、複数の言語 (Python／Go／Zig／C#／Rust) および出力形式 (EXE／DLL／シェルコード) に対応する実装を生成できるため、バイト・パターン／ハードコードされた文字列／静的なコンパイル・アーティファクトを照合するシグネチャ・ベースのエンジンは機能しなくなる。
  • 急速な変化：ワンショット生成と頻繁な再ビルドにより、ほぼ同等の機能を維持しながら、構文上の特徴が異なる多数のユニークなバイナリが生成される。その結果として、レピュテーション・ベースやハッシュ・ブロックリストによるアプローチの有効性が低下する。
  • 運用上の分離：Mythic を中心としたアーキテクチャでは、RPC メッセージングとコンテナ化されたビルダ／ハンドラ・コンポーネントを介したインプラントの実行環境と C2 インフラが分離されている。したがって攻撃者は、ネットワーク監視ツールに露出する C2 の振る舞いを変更することなく、インプラントの置き換えやタスク・ハンドラの調整を行える。その結果として、管理プレーンの正当な通信の背後に悪意を隠蔽できる。

これらのリスクに関する実証実験では、Oracle／LabKit／Mythicd／mythic-cli により構成された多層的なテスト・ハーネスを使用し、ビルド／テスト／QA サイクルを自動化することで、モック・サーバと QA サブエージェントによる End-to-End の検証を可能にした。このエージェントは、チェックインを実施して鍵交換を完了した後に、コマンド (ls／cd／shell／upload／download／execute／stage) を実行した。

Specter Ops によると、初期の LLM の出力に関しては、依存関係の不足／存在しない RPC 呼び出し／不正確な鍵交換などに対する、手作業による多くの修正が必要であった。しかし、ドメイン固有のドキュメントとテスト・ハーネスを用いた反復作業により、開発時間は数週間から数時間へ短縮された。

AI が生成する Mythic エージェント

その結果、初期アクセスや後続段階でのインプラントの置き換えに利用できる、機能的かつ最小限のインプラントが実現した。この種のインプラントは、防御側による確実な検出が最も難しいものである。

このようなエージェントがもたらす問題は、防御側にとって差し迫ったものであり、実践的な課題となっている。静的な YARA ルール／ファイル・ハッシュ／限定的なテレメトリ・シグネチャなどに依存しても、大規模に生成される多数の変種を見逃す可能性が高い。したがって、有効な対策を実現するには、振る舞いとコンテキストに基づく検出への移行が必要となる。

Obligatory Disclaimer (Source : Specterops).
Obligatory Disclaimer (Source : Specterops).

具体的には、Mythic のような RPC メッセージングにおけるプロトコル異常や、不審なコンテナのビルド／デプロイ活動、Windows ホスト上の異常な一時プロセスのライフサイクルなどに加えて、プロセス系統／ネットワーク・コールバック／管理プレーン API の使用状況といった、複数のテレメトリにまたがる相関分析を行う必要がある。

また、CI/CD およびコンテナ・オーケストレーションのプラットフォームに対して監視機能を組み込み、予期しない Dockerfile のビルドや C2 サーバへのアーティファクトの自動プッシュを検出することで、自動化されたエージェント生成パイプラインの悪用を検知できる可能性がある。

同様に、メモリ内実行／CreateProcess の異常な使用／シェル呼び出し／短命なアーティファクトの急激な増加を監視するために強化されたエンドポイント制御は、静的シグネチャでは検出が困難な攻撃を検出する上で有効である。

研究者が設計したインプラントは、きわめて単純なものである。gRPC を介して通信する Go 製のクライアントとサーバで構成され、Windows 上で Mythic エージェントの実行に必要な複数のコマンドをサポートする。

Debugging Harness (Source : Specterops).
Debugging Harness (Source : Specterops).

それに対して、脅威インテリジェンスも進化させる必要がある。名前付きインプラントだけではなく、開発ハーネスに関する指標も追跡すべきである。具体的には、不審な Mythic GraphQL パターン／ビルダ・エンドポイントへの呼び出し／Oracle／LabKit／mythic-cli を参照する CI アーティファクトなどが該当する。

また、静的 IOC を配布するだけではなく、ビルダの呼び出しからデプロイのステージに至るまでの、使い捨てエージェントのライフサイクル全体を記述する、振る舞いベースのプレイブックを共有する必要がある。LLM を活用する攻撃用ツールの台頭により、検出が不可能になるわけではないが、防御側に求められるのは、振る舞いのコンテキスト／継続的な検証／インフラ・レベルの可観測性を重視する運用体制となる。

機能的なインプラントを生成するための障壁が、LLM により低下し続ける中、防御側にとって必要なことも変化していく。脅威アクターの俊敏性に対抗していく体制は、自動化された検出パイプラインや強化されたビルド環境に加えて、テレメトリ・エンジニアと脅威インテリジェンス・チームによる緊密な連携を通じて実現される。

訳者後書：LLM を悪用する攻撃用ツールの台頭が、防御側にとって深刻な課題となっています。問題の原因は、LLM と自動化システムを組み合わせることで、人間が手を下さなくても、短命で使い捨ての不正なプログラムを大量に自動生成できてしまう点にあります。この方法で作られたプログラムは、使用するプログラミング言語や出力形式が毎回異なるため、従来のパターンマッチングやハッシュ値による検出が通用しません。さらに、プログラムの実行環境と管理用の通信基盤が分離されていることも、検出を難しくしている原因です。開発のハードルが下がり、短時間で多様な亜種が作られるため、防御側にとって必要なことは、システム全体の不審な動きを監視する、新しい対策を導入していくことです。