Gemini APIを悪用し“毎時自己変形”するVBScript「PROMPTFLUX」—静的検知の前提が崩れつつある段階です

今日の深掘りポイント

• LLMをループに組み込んだ「自己変形マルウェア」は、署名・ハッシュ依存の検知面を継続的に無力化し、検知と運用の主戦場をネットワーク・挙動・アイデンティティ側へ押し出す圧力を強める兆候です。
• 現段階のサンプルは開発・テスト段階と報じられており、即時の大規模侵害リスクは限定的と見える一方、設計思想は犯罪・国家の双方で再利用可能であり、短いリードタイムで実運用へ転化し得る構造です。
• 防御の肝は「AI API濫用の可視化と制御」「スクリプト実行基盤（WSH/PowerShell）の縮退」「モデル利用の監査・鍵ガバナンス」の3点に集約されます。
• 企業ネットワークから外部AI APIへの直接到達を“許可制”に転換し、発呼主体（人・端末・サービスアカウント）を明確化することが、検知回避の優位性を相殺する最短手です。
• 一部指標が示す高い新規性と成立確度に対し、影響規模は現状限定的という非対称性があるため、「今すぐの封じ込め設計」と「中期的な運用標準化」を併走させる意思決定が求められます。

はじめに

Googleにより発見されたと報じられる「PROMPTFLUX」は、GeminiのAPIを呼び出して自身のVBScriptコードを毎時書き換える自己修正機能を持つマルウェアです。狙いは静的署名ベースの検出回避で、既存のシグネチャ運用を前提から崩す設計思想が読み取れます。公開情報では開発・テスト段階とされ、現時点で被害者ネットワークに侵入する完成した手段は備えていないとされています。また、AIを用いて行動を調整するツールを地下フォーラムで販売する動きが観測されていると報じられています。
この種の「AI-in-the-loop」な攻撃は過去数年の概念実証を踏まえ、実運用設計に踏み込んだ転換点として捉えるべきです。誇張に流されず、どこに運用上の摩擦が生じ、どこを代替・無力化してくるのかを冷静に設計に落とし込む段階です。

参考: The Hacker Newsの報道です。

深掘り詳細

事実関係の整理（公開情報ベース）

• PROMPTFLUXはVBScriptで記述され、GeminiのAPIを呼び出して自身のソースを毎時変異させる自己修正機構を持つと報じられています。静的署名に依存した検知を回避する狙いです。
• 公開情報では、現状は開発・テスト段階であり、侵入や被害拡大を伴う完成度には至っていないとされています。
• 脅威アクターはAIを用いたオペレーション調整ツールを構築し、地下フォーラムで販売する動向が観測されているとされています。

上記は報道に基づく要点であり、テクニカルアーティファクト（サンプルハッシュ、C2ドメイン、API呼び出しの具体）などの一次データは現時点で限定的にしか開示されていません。SOCは今後公開される追加指標やIoCよりも、行動・接続パターンの抽象検知を先に整えるほうが実運用上の効果が高い局面です。

Packet Pilotのインサイト（なぜ重要か、何が難しいか）

• 変異が“外部化”されたことの意味です。従来のポリモーフィック/メタモーフィックはローカルに変異エンジンを内包するのが通例でしたが、PROMPTFLUXタイプはクラウドのLLMを「変異サービス」として利用します。これにより、攻撃者は軽量なローダとAPI鍵だけで継続的変異を獲得でき、検体の同定や家族分類を困難にします。
• 静的の次は準静的、からの行動の差分検知へです。毎時書き換えは静的シグネチャを壊しますが、逆に同一ホストが定時に外部LLMへアクセスしてスクリプトを自己更新する“行為”は検知対象になり得ます。つまり指紋から行動時系列（Who/When/Where/How）へのピボットが鍵です。
• 企業の“正規AI利用”がカバースモークになり得ます。業務でGemini等を使う組織では、AI APIへのアウトバウンドが正規通信のノイズになります。したがって、AI APIの発呼主体を人・端末・アプリ単位で明確化し、プロキシやSSOと突き合わせられる「利用者—通信—キー—ジョブ」連鎖の監査可能性を作ることが急務です。
• 経済性のしきい値が低いです。毎時の変異はAPI消費を要しますが、攻撃側は低頻度・小サイズのプロンプトで十分に“署名揺らぎ”を得られます。コストは阻害要因になりにくく、レート制御や異常利用検知が防御側の打ち手になります。
• 今回はテスト段階とされますが、設計はドロッパやステージャに容易に移植できます。初期侵入チェーンが加われば、変異ステージャ＋外部AI更新＋ローカル実行という普遍的パターンに拡張され、検体単位対処はほぼ無意味化します。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説シナリオです。公開情報に限定があるため、各TTPは合理的推定として提示します。

• シナリオA: フィッシング経由のスクリプトローダ

  • Initial Access: T1566.001（添付ファイルのスクリプト実行）です。
  • Execution: T1059.005（VBScript/WSH）です。
  • Defense Evasion: T1027（難読化）、T1036（正規ファイル偽装）です。
  • Persistence: T1053.005（スケジュールタスクで毎時更新）またはT1547.001（Runキー）です。
  • Command and Control: T1071.001（HTTPSで外部LLM APIへ）、必要に応じT1102（Webサービス悪用）です。
  • Impact/Collection: 実害機能は未確認のため保留ですが、後段で情報窃取や追加ペイロード取得（T1105）へ発展し得る仮説です。

• シナリオB: LLMをC2替わりの「変異・行動方針サーバ」として利用

  • Resource Development: PRE-ATT&CK系のT1587（能力開発）、T1608（能力のステージング）です。
  • C2/Control: モデル出力を“最新挙動テンプレート”として取得し、ローカルで評価・実行する設計です。T1573（暗号化プロトコル）により検査回避を補強する可能性が高いです。
  • Defense Evasion: 変異によりシグネチャ・ヒューリスティックの連続回避を図るT1027強化版として機能します。

• シナリオC: 「Mutation-as-a-Service」の商品化

  • Resource Development/Acquisition: T1588（能力取得、API鍵の確保）です。
  • 影響: 地下市場のツールキットにより、中堅以下のアクターでも“AI駆動の回避層”を安価に得る可能性が高まります。結果として中量級の侵害が広帯域化し、SOCのL1〜L2クラスの負荷が増大するリスクがあります。

影響評価としては、短期的には“騒がしいゼロデイ”ではなく、検知コストと運用の摩擦を上げ続ける継続的ストレス要因になるタイプです。業務AIトラフィックと攻撃AIトラフィックの分離が不十分な環境では、検知のための許容誤検知率が上がり、アラート疲労を招く可能性が高いです。

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

優先度順に実装のしやすさと効果の両面から整理します。

• すぐに着手すべきこと（0–30日）です。

  • AI APIの出口制御ポリシーを導入し、業務利用は専用プロキシ／固定送信元（e.g., 容量管理されたサーバやVDI）経由に限定します。エンドポイントからの直接到達は原則拒否し、例外は個別審査とします。
  • 組織で使用可能なAI APIとドメインの正規リストを定義し、発呼主体（人・端末・サービスアカウント）とAPI鍵のひも付けを台帳化します。個人アカウント・個人取得のAPI鍵の使用を禁止し、違反時の自動検知と是正フローを用意します。
  • WSH/PowerShellの縮退運用を再点検します。不要部門ではwscript.exe/cscript.exeの実行を無効化し、必要部門は署名付きスクリプトに限定します。WindowsのASR相当ポリシーで難読化スクリプトの実行を抑止します。
  • 検知ルールを追加します。wscript.exe/cscript.exeによるネットワーク外向き通信の監視、毎時実行のタスクスケジューラ作成、VBScript/JSの新規作成と直後のプロセス生成の相関検知を導入します。Sysmonのプロセス生成（Event ID 1）、ネットワーク接続（ID 3）、ファイル作成（ID 11）等の基本テレメトリを有効化します。
  • 代理実行の踏み台を潰します。ブラウザやcurl等の子プロセスとして生成されたスクリプト実行を高リスクとして扱い、EDRの振る舞いブロックを強化します。

• 中期対応（1–3か月）です。

  • 「AI利用の監査線」を引きます。プロキシ/SSO/DNSログ/EDRを関連付け、「誰が・どの端末から・どのAPI鍵で・どのエンドポイントに・どの頻度で」アクセスしたかを横断で追えるデータモデルを整備します。
  • モデル濫用のアノマリ検知を設計します。業務時間外の定期的なAI APIアクセス、エンドユーザー端末からの大量小リクエスト、特定部署以外からの急増といった単純な振る舞い指標から開始します。
  • レッド／パープルチームで「AI-in-the-loop」想定の演習を行い、E2Eでの検知・封じ込め時間を測定します。エグレス遮断、端末隔離、鍵失効の各レバーの実効性を検証します。
  • 供給者連携を確立します。AI APIプロバイダへの不正利用報告フロー、鍵失効のSLA、レート制御・地理制限・組織バインディング等の機能可用性を確認します。

• 監視・ハンティングの着眼点（仮説）です。

  • 毎時または等間隔での外部AI APIへのHTTPSアクセスが同一端末から継続するパターンです。
  • VBScript/JSの新規作成→短時間で内容変更→WSH実行というシーケンスです。
  • wscript.exe/cscript.exeが直接ネットワーク外向き通信を行う、あるいはHTTPクライアントCOMオブジェクト（例: WinHTTP/WinINet系）の呼び出しが併走する事象です。
  • 組織の正規経路外（ローカルWi-Fi、モバイルテザリング、パーソナルVPN）からのAI API到達です。

• ポリシーと人の側面です。

  • 「AI APIの利用はプロキシ経由」「鍵は中央発行・中央保管」「個人鍵での業務利用禁止」を明文化し、違反時の自動是正（鍵失効・端末隔離）を紐付けます。
  • 開発部門には“モデル利用のセキュアパターン”を提示し、必要な到達先・方法・認証・ロギングをテンプレート化します。例外は期限付のチケット制にします。

総合すると、今回の報道は「AI駆動の検知回避層」が商用APIで容易に外部化できることを改めて可視化しました。メトリクスが示唆する高い新規性と成立確度を踏まえると、個別検体への追随ではなく、AI APIの利用路とスクリプト実行基盤を“管理可能な面”に還元する設計が最短距離の防御になります。静的検知の限界を前提として、行動・接続・アイデンティティの三本柱にシフトする意思決定が必要です。

参考情報:

• The Hacker News: Google uncovers PROMPTFLUX malware that uses Gemini API to rewrite code hourly（2025-11-06）https://thehackernews.com/2025/11/google-uncovers-promptflux-malware-that.html です。