AI駆動型マルウェアは、感染先で動いている最中にLLMへ問い合わせ、実行する処理をその場で作らせるマルウェアです。攻撃者が生成AIにコードを書かせただけの検体とは、検知のしかたも防御の打ち手も違います。本記事ではGoogle脅威インテリジェンスグループ（GTIG）とESETの解析報告、NYUの研究論文、SentinelLABSのハント手法、IPAの公表資料をもとに、実戦で確認された系統と学術研究に由来する検体を分け、どの検知が外れ、どこに痕跡が残るのかを整理します。
まとめ｜AI駆動型マルウェアの現在地（2026年11月時点）
- GTIGが実戦投入を初めて観測した系統はPROMPTSTEAL（CERT-UAの呼称はLAMEHUG）。2026年にはGemini APIでコードを受け取るHONESTCUE、画面を読んで操作を決めるAndroidのPROMPTSPYが加わりました。
- 「初のAI駆動型ランサムウェア」と報じられたPromptLockは、NYU Tandon工科大学の学術PoCです。ESET自身が2025年9月3日の追記で研究由来だと公表しています。
- 限界があるのは静的検知だけではありません。NYUの論文では、高価値ファイルを狙う実験で従来型ランサムウェアに典型的な大量処理の痕跡が観測されず、量に依存する検知の限界が示唆されました。
- 代わりに、LLMへの依存そのものが痕跡になります。SentinelLABSは、一部の検体に埋め込まれたAPIキーやプロンプトを手がかりに、未知の検体を見つけています。
- 防御は「AI対策製品の買い足し」より先に、機微ファイルへのアクセス監視、LLM宛て通信の許可制、開発端末のAI CLIの権限見直しから着手するのが筋です。
AI駆動型マルウェアの定義と3つの型
実行時にLLMを呼ぶ型と、開発だけAIに任せた型
開発だけAIに任せた型は、出来上がった検体が普通のマルウェアです。バイナリは固定なのでハッシュもシグネチャも作れ、被害端末の上でAIは動きません。犯罪向けに売られている「悪のChatGPT」系サービスもこの側の道具で、その多くは商用APIの包み直しでした（Evil GPTとは？正体は10ドルで売られたOpenAI APIラッパー｜実態と企業が取るべき対策）。
実行時にLLMを呼ぶ型は、バイナリに自然言語のプロンプトを埋め込み、感染先でLLMに問い合わせて実行するスクリプトを作らせます。GTIGは2025年11月5日付のレポートで「実行中にLLMを使用するPROMPTFLUXやPROMPTSTEALのようなマルウェアファミリを初めて特定した」と書きました。MITRE ATLAS（2026.10版）のAML.T0102「Generate Malicious Commands」は、LLMで自然言語から悪性コマンドを動的に生成する手口を扱い、事例にAPT28のLAMEHUGを挙げています。本記事が「AI駆動型マルウェア」と呼ぶのはこの型です。
端末のAIエージェントを乗っ取る型｜s1ngularityとAmazon Q拡張
2025年夏から、自前でLLMを呼ぶのではなく、開発者の端末に入っているAIコーディングツールに攻撃を代行させる検体が出ています。Nxの公式ポストモーテムによれば、2025年8月26日にnpmへ公開された不正なNxパッケージは、post-installスクリプトで機微情報を探索し、ClaudeやGeminiなどのローカルAIツールの利用を試み、結果を被害者のGitHubアカウントに作った公開リポジトリへ上げました。GitHub Advisoryは、そのリポジトリ名に「s1ngularity-repository」が含まれると説明しています。npmのワーム型攻撃がその後どう広がったかはShai-Hulud（シャイ・フルード）とは？npmワーム2.0・Mini・CHAINDROPの影響確認と対策【2026年10月】で扱っています。
その前月の2025年7月にはAmazon Q Developer for VS Code拡張の1.84.0に悪性コードが混入しました。AWSのセキュリティ速報は、権限範囲が広すぎるGitHubトークンが原因で、コードは構文エラーのため実行されなかったと説明しています。Wizの整理によれば、混入したのはAIエージェントにシステムとクラウド資源の削除を指示する内容でした。この型では、悪意ある処理を考えるのは正規のAIツールで、通信先も正規のAPIです。
ポリモーフィック型ウイルスとの違い
ポリモーフィック型は暗号化ルーチンと鍵を変えて外見を変えますが、復号後の本体は同一なので、メモリ上で展開された時点のパターンで捕まえられました。LLMが生成するスクリプトはロジックそのものが毎回変わり、同じ「文書を集めて外部へ送る」目的でも、使うコマンドと順序が実行ごとに異なります。マルウェアの分類軸そのものはトロイの木馬とは？正体とウイルス・ワームの違い・感染の仕組みと企業の対策を実装目線で解説で整理しています。
AI駆動型マルウェアの実例｜実運用と実験段階の区別
報道では横並びに紹介されがちですが、実戦投入の有無で危険度はまったく違います。
| 検体名 | 報告元・公表 | 照会先LLM | LLMの役割 | 実戦投入 |
|---|---|---|---|---|
| MalTerminal | SentinelLABS 2025-09 | GPT-4 | ランサム・リバースシェル生成 | 未確認 |
| PROMPTSTEAL（LAMEHUG） | GTIG・CERT-UA 2025 | Qwen2.5-Coder-32B-Instruct | 偵察コマンド生成 | 確認済 |
| PROMPTFLUX | GTIG 2025-11 | Gemini | 自己書き換え（未完成） | 未確認 |
| PromptLock | ESET・NYU 2025-08 | gpt-oss:20b | Luaスクリプト生成 | なし（学術PoC） |
| HONESTCUE | GTIG 2026-02 | Gemini | 第2段階のC#生成 | 未確認（PoC段階と推定） |
| PROMPTSPY | ESET 2026-02 | gemini-2.5-flash-lite | 画面解析と操作指示 | 未確認（配布サイトあり） |
PROMPTSTEAL（LAMEHUG）｜GTIGが実戦投入を初観測した系統
GTIGは2025年6月、ロシア政府が支援するAPT28（別名FROZENLAKE）がウクライナに対して使った新種をPROMPTSTEALとして追跡しました。CERT-UAの呼称はLAMEHUGで、同一の検体です。Hugging FaceのAPI経由でQwen2.5-Coder-32B-InstructにWindowsのワンライナーを生成させ、システム情報と特定フォルダの文書を集めます。GTIGはこれを「実運用に展開されたマルウェアがLLMへ問い合わせた最初の観測例」と明記しました。
MalTerminal｜GPT-4を呼ぶ最初期の検体
SentinelLABSの2025年9月19日の報告は、GPT-4にランサムウェアのコードかリバースシェルを生成させるPython製の検体群を「MalTerminal」と名付けました。2023年11月初めに廃止されたOpenAIのチャット補完エンドポイントを使っていたことから、それ以前に書かれた検体と推定され、同社は既知で最も早いLLM対応マルウェアの可能性があるとしています。実戦で使われた記録はありません。
PROMPTFLUXとHONESTCUE｜Gemini APIでコードを差し替える検体
PROMPTFLUXはVBScriptのドロッパーで、「Thinking Robot」というモジュールが検知回避用の新しいコードをGemini APIへ定期的に要求します。ただし自己書き換えを担うAttemptToUpdateSelf関数はコメントアウトされており、GTIGは「被害者のネットワークや端末を侵害する能力を示していない」と評価しました。この検体では自己更新関数が無効化されていましたが、GTIGはソース全体の再生成を要求する別の亜種も報告しています。
HONESTCUEは一歩進んでいます。GTIGの2026年2月12日付レポートによれば、2025年9月に観測されたこのダウンローダーは、Gemini APIから受け取ったC#のソースコードを.NETの正規機能CSharpCodeProviderでメモリ上でコンパイルして実行し、別のマルウェアを取得します。ディスクにペイロードが残りません。GTIGは既知の攻撃グループには結び付けておらず、検体の開発状況からPoC段階の可能性が高いと評価しています。
PROMPTSPY｜画面を読んで操作を決めるAndroidバックドア
ESETは2026年2月19日、実行フローで生成AIを使う最初の既知のAndroidマルウェアとしてPromptSpyを公表しました。現在の画面のXMLダンプと自然言語の指示をGeminiに送り、返ってきたJSONの操作種別と座標に従ってタップを再現し、最近使ったアプリの一覧に自分を固定します。GTIGの追加分析では呼び出し先はgemini-2.5-flash-liteでした。生成AIを使うのは常駐の維持だけで、主目的は内蔵のVNCモジュールによる遠隔操作です。ESETは自社の観測網ではまだ検体を見ておらず概念実証の可能性もあるとしつつ、アルゼンチンの利用者を狙う配布ドメインを確認しています。ここでLLMはコード生成器ではなく、端末ごとに異なる画面を読み解く操縦者として使われています。
2026年後半の変化｜エージェント型の攻撃基盤
GTIGは2026年9月8日付のレポートで、2026年第2四半期に攻撃者がクラウド資源を侵害してから、エージェントを使った大規模な認証情報収集キャンペーンを計画・構築・実行するまでを6時間未満で終えた事例を報告しました。さらに2026年11月2日付のLLMJacking報告では、侵害したクラウド環境にManusエージェント基盤を使ったコンテナ型のバックドアを置き、上流のLLMに指示を推論させて得たコマンドをローカルで実行させた事例が載っています。
この事例で短縮されたのは、人間の判断や作業を待つ時間です。検知から遮断まで数日を見込む運用は、この速度に追随できません。AIが脆弱性を見つける側で使われる動向はAI製ゼロデイ攻撃とは｜従来型攻撃との違い・手口・実例と防御策【2026年】で別に扱っています。
PromptLockの正体｜NYU Tandonの学術PoC「Ransomware 3.0」
ESETの公表と2025年9月3日の追記
2025年8月、ESET Researchは「初の既知のAI駆動型ランサムウェア」としてPromptLockを公表しました。数日後、ESETは同じ記事に「2025年9月3日更新：ESET Researchは学術研究『Ransomware 3.0: Self-Composing and LLM-Orchestrated』の著者から連絡を受けた。その研究プロトタイプはVirusTotal上で見つかったPromptLockの検体と酷似している」と追記しています。検体を投稿したのはNYU Tandon工科大学の研究チームで、論文はarXivに2025年8月28日付で公開されています（arXiv:2508.20444）。「攻撃者がAIランサムウェアを実戦投入した」という文脈でPromptLockを引用するのは誤りです。
検体の技術構成｜gpt-oss:20b・Ollama・Lua・Golang
本体はGolangで、WindowsとLinuxの亜種がありました。実行時にOllama API経由でgpt-oss:20bを呼び、ファイルの列挙、検査、持ち出し、暗号化を担うLuaスクリプトをその都度生成します。ESETはデータ破壊の機能を未実装とし、実際の攻撃では観測していません。
論文が示したコストと精度｜「63〜96%」は列の取り違え
論文は「1回のエンドツーエンド実行あたり23,000トークンを消費し、GPT-5のAPI料金で約0.70ドル」と書いています。実験はオープンウェイトのモデルで行っており、これはGPT-5の料金に当てはめた換算値で、侵入や設備の費用を含む実測ではありません。検証はWindows 10のVM、Ubuntu 20.04 LTSのVM、Raspberry Pi 4Bの3環境で各10回、計30回です。
論文のTable 3では、機微なファイルを正しく特定できた割合は全環境平均でgpt-oss:20bが63%、120bが69%で、組込みコントローラ環境では38%と48%まで落ちます。同じ表にある96%は特定精度ではなく、特定済みファイルにペイロードを実行できた割合（全環境平均・120b）です。別の列なので、「63〜96%を正しく判別」のように1つの範囲としてまとめることはできません。企業サーバ環境では120bが10個中9個の機微ファイルを特定して暗号化まで終えた一方、内容を読み出す抽出だけはモデルが拒否し、脅迫文の個別化は成立しませんでした。安全訓練が止めたのは1フェーズだけで、暗号化はそのまま進みました。
検知面の移動｜静的シグネチャと負荷監視の限界
静的解析で照合できる部分と外れる部分
失われるのは、配布物から実行内容を事前に確定する能力です。固定のプロンプトとLLMとの通信を担う本体コードは配布時点から存在し、ESETがPromptLockの検出名とハッシュを公開したように照合できます。外れるのは生成されるスクリプトの側です。PROMPTFLUXがソース全体の定期的な書き換えをGeminiへ要求し、HONESTCUEがペイロードをメモリ上でだけコンパイルするのも、この部分の照合を無効にする狙いです。
少数ファイルを狙う攻撃と振る舞い検知の限界
NYUの論文はHPC（ハードウェア性能カウンタ）、ディスクI/O、システムコール、ネットワーク通信を計測し、プロトタイプが「従来型ランサムウェアの典型的なシグネチャを示さずに攻撃ライフサイクル全体を完了した」と報告しています。乱数生成の急増も、大きなデータブロックへの大量の読み書きも、システムコールやHPCの異常なスパイクも出ませんでした。理由は、LLMが高価値ファイルだけに狙いを絞るため痕跡が通常の動作に紛れるからだと論文は説明し、「LLM駆動型ランサムウェアは検知面を移動させる」と結論づけています。大量の暗号化書き込みだけを検知条件にすると、この種の攻撃を見逃す可能性があります。既存EDRの検知可否は、製品と設定ごとに検証する必要があります。EDRの検知の仕組み自体はEDRとは？EPP・XDRとの違いと検知の仕組み・導入判断を実装者向けに解説【2026年時点】で解説しています。
LLM依存が残す痕跡｜埋め込みAPIキーとプロンプトで探す
生成されるコードが毎回違っても、外部のLLMを使う検体には、APIキーやプロンプトを内部に埋め込んで配布されるものがあります。SentinelLABSはこの依存を逆手に取り、未知の検体を探し出しました。この手法は、生成コードだけでなく、配布物に残るプロンプトも調査対象にする点が特徴です。
SentinelLABSの手法｜APIキー形式とプロンプト構造
手がかりの1つ目はAPIキーの形式です。SentinelLABSによれば、現行のAnthropicのキーはすべてsk-ant-api03で始まり、OpenAIのキーには「OpenAI」をBase64で表したT3BlbkFJという部分文字列が含まれます。VirusTotalを1年分さかのぼって検索すると、6,000超の固有キーを含む7,000超の検体が見つかり、その大半は開発者のミスなどによる悪意のないファイルでした。PROMPTSTEALは検体全体で284個の固有なHugging Faceキーを抱えており、2023年に流出した認証情報の束から取ったものでした。キーが無効化されると動かなくなるため、複数のキーを持たせて寿命を延ばしているわけです。
2つ目はプロンプトです。LLMを使うソフトは必ずプロンプトを発行するので、バイナリやスクリプトからプロンプトの構造を探し、軽量なLLMで悪意の有無を採点してから人が読む、という手順でMalTerminalのような未報告の検体を見つけています。PROMPTSTEALのプロンプトには「Windowsシステム管理者」という役割の指定と、末尾に「Return only commands, without markdown」という指示がありました。
YARAルールの例と誤検知の扱い
次のルールは、APIキー形式とチャット形式のプロンプト構造という2つの文字列パターンを探す最小構成です。ルールの下に、検出テストの入力と実行結果を載せています。
rule LLM_Provider_Key_Embedded
{
meta:
description = "LLMプロバイダのAPIキー形式を含むファイル"
strings:
$anthropic = "sk-ant-api03" ascii wide
$openai = "T3BlbkFJ" ascii wide
condition:
any of them
}
rule LLM_Prompt_Structure_Embedded
{
meta:
description = "チャット形式のプロンプト構造を含むファイル"
strings:
$role = /"role"\s*:\s*"(system|user)"/ ascii wide
$content = "\"content\"" ascii wide
condition:
$role and $content
}上のルールをllm_hunt.yarとして保存し、ダミーのキー形式2種、チャット形式のJSON、無関係なコードの4ファイルに当てた結果です。-rはディレクトリの再帰走査、-sは一致した文字列と位置の表示です。
mkdir samples
printf 'key = "sk-ant-api03-XXXXXXXX"\n' > samples/a.py
printf 'k="sk-proj-abcT3BlbkFJxyz"\n' > samples/b.py
printf 'msgs=[{"role": "system", "content": "You are a Windows System Administrator"}]\n' > samples/c.py
printf 'print("hello")\n' > samples/d.py
yara -r -s llm_hunt.yar samples
# 出力（yara 4.6.0）。ファイルの表示順は環境で変わる。d.py は一致なし
LLM_Provider_Key_Embedded samples/a.py
0x7:$anthropic: sk-ant-api03
LLM_Prompt_Structure_Embedded samples/c.py
0x7:$role: "role": "system"
0x19:$content: "content"
LLM_Provider_Key_Embedded samples/b.py
0xe:$openai: T3BlbkFJこのルールの一致は、指定した文字列や構造があることだけを示し、感染や実際のLLM利用を証明しません。SentinelLABSの調査でも一致した大半は悪意のないファイルでした。逆に、GTIGはHONESTCUEに埋め込まれたプロンプトについて、それ単体では悪意があると判断されにくいと指摘しており、プロンプトの文面だけで白黒は付きません。正規の業務アプリや開発中のコードにも当たるため、一致したファイルを資産台帳と照合し、台帳に無いものと、キーを複数抱えているものから順に調べてください。見つかったキーが自社のものなら、マルウェアかどうかに関係なく、その時点で失効させる理由になります。
論文と実例から導く防御｜ファイル単位の監視とLLM接続の統制
NYUの論文は§7.2で、機微ファイルへのアクセスの能動的な監視、偵察を炙り出すおとりファイル、外部LLM接続の厳格な統制（信頼できる提供元のホワイトリスト化とAPI通信の検査）、LLM側の学習段階での悪用検知の強化を挙げています。前の3点は利用者側で今日から着手できます。s1ngularity型への備えはここに含まれないので、別に足します。
機微ファイルへのアクセス監視とおとりファイル
論文の観測で残った痕跡は、少数の重要ファイルへの読み取りでした。監査ログで機微なファイル群への読み取りを記録し、普段アクセスしない主体からの参照を異常として扱います。おとりファイルは、業務上は誰も開かないファイルを機微そうな名前で置き、読み取りが起きたら偵察段階と判定する方法です。論文はおとりファイルを防御候補に挙げていますが、おとりを選ぶ確率や検知率は測定していません。
外部LLM APIへの通信とAPIキーの失効
PROMPTSTEALはHugging Faceを、PROMPTFLUXとHONESTCUEとPROMPTSPYはGeminiを呼びます。業務でこれらのAPIを使っていない端末からの発信は、それだけで異常として扱えます。生成AI APIの宛先を利用実態に合わせて許可制にし、許可外の端末からの発信をプロキシやEDRのネットワークイベントで拾います。GTIGが関連アセットを無効化できたのも、攻撃者がプラットフォーム事業者の管理下にあるキーを使っていたからで、SentinelLABSが指摘するとおり、キーが失効すれば検体は動かなくなる可能性があるため、見つけたキーは提供元へ通報します。
開発端末のAI CLIとエージェントの権限
s1ngularity型では、通信先が正規のAI APIで、操作しているのも正規のツールです。宛先の許可制では止まりません。見直すべきは、開発端末のAIコーディングツールに確認なしでファイル読み取りやコマンド実行を許す設定と、npmのインストールスクリプトの扱いです。AIツールの自動承認を常用しないこと、依存パッケージのインストールスクリプトを既定で止めること、端末に平文のトークンを置かないことの3点が、この型の被害範囲を直接狭めます。
ローカル推論の配置先と容量監視の適用範囲
NYUの実験ではOllamaを被害端末ではなく別マシン（64コアCPU・RAM 500GB・NVIDIA L40を2基）に置いてLANで接続しています。モデルの容量で見つけられるのは、被害端末そのもので推論する構成に限られます。その構成なら、gpt-oss:20bはOllamaの配布で14GBあり、Ollamaの公式FAQによれば既定で127.0.0.1のポート11434で待ち受けるため、手がかりになります。
# macOSでOllamaの既定設定の痕跡を調べる例（lsofが必要）
# 保存先や待受は変更できるため、無出力でも未感染とは言えません
lsof -nP -iTCP:11434 -sTCP:LISTEN
du -sh ~/.ollama/models 2>/dev/null正規のローカルLLM利用でも同じ結果が出るので、資産台帳と突き合わせて例外を決めてから使ってください。
AI駆動型脅威検知の製品に求める確認項目
「AI駆動型脅威検知」をうたう製品を足す前に、この脅威に対して何を見られるかを3点確かめてください。第一に、実行ファイルやスクリプトに埋め込まれたAPIキーやプロンプトを静的に拾えるか。第二に、どの端末のどのプロセスがLLMのAPIへ通信したかを記録できるか。第三に、少数の機微ファイルへの読み取りを、量の閾値ではなく対象で警告できるか。まず既存のEDR、プロキシ、監査ログで各項目を満たせるか検証します。APIキーの静的検査やファイル読み取りの監査には、別のツールや設定が必要な場合があります。満たせないと分かった項目だけを、設定変更、外部の監視サービス、追加製品のどれで埋めるか比べます。生成AIを業務に組み込む側の統制も含めて相談したい場合は、AIセキュリティ対策の支援を用意しています。
日本企業の優先順位｜IPA10大脅威2026での位置づけ
IPAが2026年1月29日に公表した「情報セキュリティ10大脅威 2026」では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が初めて入りました。1位は「ランサム攻撃による被害」です。AI駆動型マルウェアは独立した新しい脅威というより、1位の攻撃の実行コストと所要時間を下げる要因として現れます。加えるべきはLLM接続とAIツールの権限の管理で、既存の対策を置き換えるものではありません。具体的には、バックアップからの復旧時間、EDRアラートの一次対応までの時間、外部への通信を止める権限が誰にあるかの3点を実測してください。
よくある質問
AI駆動型マルウェアとは何ですか？
実行中にLLMへ問い合わせ、実行する処理をその場で生成させるマルウェアです。GTIGが2025年11月に報告したPROMPTSTEALとPROMPTFLUXが代表例で、コマンドを生成させる手口はMITRE ATLASのAML.T0102が扱っています。生成AIに書かせただけで検体自体は固定のマルウェアは、この定義に含みません。
PromptLockは実際の攻撃に使われたのですか？
実際の攻撃での使用は確認されていません。NYU Tandon工科大学の研究チームが作った学術プロトタイプで、ESETは2025年9月3日の追記で研究由来であることを公表し、実際の攻撃では観測していません。
AI駆動型脅威検知の製品を導入すれば防げますか？
製品の追加だけでは足りません。NYUの実験では従来型ランサムウェアに典型的な大量処理の痕跡が観測されず、量だけに依存する検知では見逃す可能性が示唆されました。確かめるべきは、埋め込まれたAPIキーやプロンプトを拾えるか、LLM宛ての通信をプロセス単位で記録できるか、少数の機微ファイルへのアクセスを警告できるかの3点です。
AIマルウェアはどうやって見つけますか？
外部のLLMを使う検体の中には、APIキーやプロンプトを埋め込んで配布されるものがあります。SentinelLABSはAnthropicのキーの接頭辞sk-ant-api03やOpenAIのキーに含まれるT3BlbkFJをYARAで探し、未報告の検体を見つけました。端末側では、業務で使っていないLLMのAPIへの通信が手がかりになります。
ローカルモデルを使うマルウェアはどう見つけますか？
まず推論の場所を切り分けます。被害端末で推論する構成なら、14GBあるgpt-oss:20bのようなモデルファイルと、Ollamaの既定の待受ポート11434が手がかりです。NYUの実験のように別のサーバで推論する構成では、端末にモデルや推論サービスの痕跡はなくても、通信やファイル操作の痕跡は監視できます。
