Gemini悪用で“思考ロボット”型マルウェアが現実化——LLM実行時生成が検出モデルを揺さぶります

今日の深掘りポイント

• マルウェアの変異が「暗号化・難読化」から「実行時のLLM生成」へと質的転換しています。検知の主戦場はファイルから振る舞いと外向き通信にシフトします。
• LLMをC2ないし能力供給源として用いる設計は、プロキシやゼロトラストの「外部SaaS制御」を一段と重要にします。AI APIドメインは新たな高リスクの出口カテゴリになります。
• APT42のような国家系がデータ処理（SQL生成・個人情報分析）でLLMを活用する動きは、侵害後のトリアージと情報価値抽出の加速を示します。検出・阻止は侵入前よりも侵入後対策の重みが増します。
• メトリクス全体からは「新規性が高く、近中期に現実のオペレーションへ波及する確度が高い」脅威像が読み取れます。優先すべきはAIエージェントの外部接続最小化、実行ガードレール、そしてLLM利用のテレメトリ可視化です。

はじめに

Googleの脅威分析部門の報告を受け、攻撃者がGeminiを含むLLMを悪用し、自己コードを書き換える“思考ロボット”型マルウェアや、スパイ活動向けのデータ処理エージェントを試作していると報じられています。特にイラン関連とされるAPT42が、GeminiでSQLクエリを生成し個人情報（PII）の分析を行う手法を模索したこと、そしてPromptFluxと呼ばれる新種のマルウェアが、実行時にLLMで悪性スクリプトを生成するアーキテクチャを持つ点が注目点です。PromptFluxはVirusTotal上での検証も観測されたとされ、従来の静的検出を回避しうる設計が示唆されます。これらはいずれもLLM-in-the-loopな攻撃運用の具体像を示し、AIとサイバー戦の軍拡競争の加速を物語る事例と言えます。報道ベースの情報であり、一次資料の全文は本稿執筆時点で未確認のため、以下の分析には仮説が含まれることを明示します。

参考: The Registerの報道（Googleの脅威分析の指摘として紹介）

深掘り詳細

事実関係（報道から読み取れるポイント）

• 国家系・犯罪系アクターがGeminiなどのLLMを用い、フィッシング運用の最適化、個人情報の分類・抽出、コード生成に取り組んでいるとされます。
• APT42は、PII分析のためのSQLクエリ生成にGeminiを活用するワークフローを試作したと報じられています。これは「侵害後のデータ価値最大化」を短時間で行う狙いと整合的です。
• PromptFluxは、マルウェア本体が実行時にLLM APIへ問い合わせ、返ってきたスクリプトを実行する設計とされます。生成物が毎回変動し、静的なシグネチャやYARAへの対抗効果が期待できるため、従来の検出に対する回避性が上がる可能性があります。
• この種のマルウェアは、ファイルに残る不変の「悪性アーティファクト」を極小化し、ネットワーク通信・プロセス行動・メモリ上の一時生成物に監視軸をずらすことを意図しているように見えます。

情報出典はいずれも上記報道に基づきます。一次資料の公開有無や技術的詳細は現時点で未確認のため、個々のTTPは仮説として取り扱います。

インサイト（編集部の視点）

• 何が「新しい脅威」なのか
  歴史的に、ポリモーフィック/メタモーフィック型の自己変形マルウェアは存在しましたが、LLMを能力供給源に据えると、変形は単なる暗号化や難読化を超え、機能レベルの非決定的生成に移ります。生成の温度やプロンプト制御により、同一意図でも出力が統計的にばらけ、静的検出のコストを押し上げます。一方で、外部LLMという「中央の依存点」が生まれるため、組織側は出口制御・SaaS可視化・Egress監査という既存の制御をてこに抑えに行けます。
• どこで勝てるのか
  勝負所は「実行時の前後関係」です。LLM APIへの外向き呼び出し直後に、ローカルのスクリプト実行やプロセス生成が連鎖する挙動は高い検知価値を持ちます。さらに、企業環境で未承認のLLM SDKやプロンプトフレームワーク（例: 汎用エージェント実装）の存在自体がリスク指標になります。検知をファイル中心から「LLM利用のテレメトリ × 実行ガードレール × ふるまい相関」に切り替えるべき局面です。
• ガバナンスの遅延が技術的脆弱性に直結
  生成AIの業務活用に寛容なほど、未承認エージェントやスクリプト実行権限が野放図になりがちです。最小権限の原則を「AIエージェントのネットワーク権限」にまで拡張し、モデルへの送信内容のDLP、出力の実行ガードレール（コードは即実行不可・人手レビュー必須など）を標準にする必要があります。
• 地政学的含意
  国家系が分析・情報収集フェーズでLLMを実用化することは、侵害後の「価値収穫速度」を上げ、脅威の回転率を加速します。短期の直接的被害は限定的でも、中期には侵害検知から事業影響発現までの時間が短縮し、意思決定の猶予を削ります。指揮・統制のスケールが上がる点を過小評価すべきではありません。

メトリクスの読み替え（総合所見）

新規性が高く、実運用移行の確度も低くない一方で、組織が直ちに取り得る対策は存在します。したがって、短期の「緊急パッチ」ではなく、Egress管理・実行ガードレール・LLMテレメトリの常設化を優先した中期投資が最適化されます。前提となるのは、プロキシ/ファイアウォールによるAI APIのカテゴリ化と許可リスト化、そしてEDRによる「LLM呼び出し直後のコード実行」の高感度検知です。実装コストはかかりますが、効果が検出全体に波及するため費用対効果は見合います。

脅威シナリオと影響

以下は報道を踏まえた仮説ベースのTTPシナリオです。各テクニックはMITRE ATT&CKに準拠し、現実の環境に即してカスタマイズすることを推奨します。

• シナリオ1: LLM実行時生成によるフィッシング→スクリプト実行
  想定フロー:

  1. スピアフィッシングでドキュメント/リンク配布（T1566.001/T1566.002）
  2. ユーザー実行（T1204）→ローダが外部LLM APIに接続（C2としてのWebサービス: T1102 またはアプリ層プロトコル: T1071.001）
  3. 取得したスクリプトをPowerShell/WSH/Nodeなどで実行（T1059）
  4. 永続化設定（例: ログオン自動起動 T1547）→データ窃取・圧縮（T1005/T1560）→外送（T1041）
     兆候: 未承認アプリがLLM APIへ通信後、短時間でスクリプト実行・新規ファイル生成・スケジューラ登録が連鎖するタイムライン。

• シナリオ2: APT42型——侵害後のLLM支援データトリアージ
  想定フロー:

  1. 初期侵入後、メールボックス/クラウドストレージからデータ収集（T1114/T1530/T1039）
  2. 外部LLMでクエリ自動生成・分類・優先度付け（T1587.001/リソース開発としての能力開発）
  3. 要注意人物・機密文書の抽出を高速化し、後続のフィッシング/恐喝/オペレーションに展開（T1056系やT1646などは目的に応じて）
     影響: 侵害発覚までの短期間に、より多くの価値を抽出される。ブルーチームの封じ込め速度が遅いほど損害が逓増します。

• シナリオ3: “思考ロボット”型バックドア
  想定フロー:

  1. 軽量ローダが常駐（T1053/T1547）
  2. LLM APIから「その時点の環境・権限・ミッション」に合わせたタスク/コードを取得（T1102/T1071.001）
  3. 実行時にコード生成→実行→削除でアーティファクト最小化（T1027/メモリ常駐の可能性）
  4. 目的達成に応じてプロンプトを更新し、機能を差し替え（T1218 LOLBIN利用を併用しうる）
     影響: 検出は「何を実行したか」から「何を問い合わせたか」に軸足が移り、プロンプト/レスポンスを観測できない環境では相関が困難になります。

組織影響としては、侵入初動の検知難度が大幅に上がるというより、検出から封じ込めまでの中間区間での分析負荷が増し、フォレンジックの可観測性が低下することが本質的なリスクになります。監査・規制面では、業務端末からの未承認AIサービス利用がコンプライアンス違反・データ移転規制違反に接続しやすくなります。

セキュリティ担当者のアクション

短期（0–90日）と中期（90–180日）で優先順位を付けて実行することを推奨します。

• ネットワーク／SaaS管理

  • 企業ネットワークからの生成AI/LLM APIへの外向き通信をカテゴリとして明確化し、デフォルト拒否＋業務上必要なエンドポイントのみ許可にします（プロキシ/ファイアウォールのアプリ制御を活用します）。
  • 未承認のAPIキーやクライアントSDKの利用をプロキシで検知・遮断し、開発部門は社内ゲートウェイ経由の利用に統一します。
  • LLMエンドポイント通信とスクリプト実行（PowerShell/WSH/Node/Pythonなど）が短時間で連鎖する相関ルールをSIEM/EDRに実装します。

• エンドポイント防御・実行ガードレール

  • AppLocker/WDAC/組織内の類似機能で、汎用スクリプトインタプリタの実行を署名/パス/発行元ベースで制限します。業務自動化は署名付きの社内パッケージへ移行します。
  • 「コード生成＝即実行」を禁止するガードレールを導入し、LLM出力のコードはデフォルトで無害化・隔離し、人手レビューまたは専用サンドボックスでの検証を必須化します。
  • EDRでのヒューリスティック強化（メモリ上のスクリプト実行、LOLBin連鎖、短時間のプロセスツリー爆発、ベース64/圧縮デコードの連発など）を優先的に有効化します。

• データ保護・DLP

  • LLM/AIサービスへの送信内容に対するDLPポリシー（個人情報・機微データの送信禁止）を適用し、違反時のワークフロー（遮断/隔離/教育）を整備します。
  • クラウドメール・ストレージでの「大量アクセス→外部送信」アラートの閾値を見直し、侵害後トリアージの高速化を想定した行動に追随できるようにします。

• 検知コンテンツ・ハンティング

  • IOCではなくTTPベースで、「LLM APIへの通信イベント」×「直後のスクリプト/LOLBIN実行」×「永続化試行」を結ぶ相関検知を用意します。
  • 端末上のLLMクライアント/エージェントフレームワーク（一般名で構いません）のスキャンと、未承認の自動化スクリプトの棚卸しを定期化します。
  • サンドボックスでの動的解析時はインターネット遮断版・許可版の両方で挙動差を観測し、外部LLMに依存するマルウェアの機能停止を確認します。

• ガバナンス・開発プロセス

  • 「AIエージェント最小権限」のポリシーを策定し、ネットワーク・ファイル・プロセス起動などの許可を機能単位で明示します。
  • セキュア開発のゲートに「AI出力のソース／検証ログ保存」「プロンプトチェーンの監査可能化」を追加し、追跡可能性を担保します。
  • レッドチーム演習に「LLM-in-the-loopマルウェア」を模擬するシナリオを組み込み、ATT&CK/ATLASマッピングで穴を炙り出します。

• ベンダー連携・リスク移転

  • EDR/プロキシ/メールセキュリティ各ベンダーに対し、「LLM実行時生成型」検出のロードマップと、AIドメイン可視化・制御の機能強化計画を確認します。
  • サイバー保険の条件に、生成AI関連のインシデント（非承認SaaS利用や外部AI送信）を含むのか再点検します。

最後に、これらの対策は「新しい専用プロダクト」ではなく、既存のゼロトラストとEgress管理、EDRの相関検知をAI時代の前提で調整することから始めるのが費用対効果に優れます。LLMをC2/能力供給源とみなしてネットワークを管理する——それが今回の報道が示す最も現実的な示唆です。

参考情報

• The Register: Attackers experiment with Google Gemini to build malware, spy agents, says Google（報道ベース。一次資料の確認は今後の課題です）