- AIの関与は、コード支援からmalware の実行中のモデル呼び出しまで多岐にわたりますが、これらのパターンにはそれぞれ異なる証拠が必要です。
- 2025～2026年の症例記録では、確認された手法の範囲が広がっているが、その有病率は測定されていない。
- AIの来歴が確認されていない場合でも、実行、IDの使用、利用可能な場合はモデル呼び出し、動作、および影響について調査を行うべきである。
2026年9月、Google Threat Intelligence Groupは、攻撃者がAIを活用したワークフローを用いて、クラウドへのアクセス権を取得してから6時間足らずで、大規模な認証情報収集を計画、構築、実行した事例を報告した。これは観測された1つのキャンペーンに過ぎず、典型的な攻撃の所要時間ではない。この事例は、AIを活用したmalware 攻撃の背後にある運用上の懸念を浮き彫りにしている。すなわち、根本的な侵害が依然として既知の脆弱性に依存している場合でも、AIによって攻撃サイクルの特定の部分が短縮され得るということである。
AImalware 攻撃とは、攻撃者がAIを利用して悪意のあるソフトウェアを設計、改変、配信、または操作する侵入攻撃のことです。この用語は、AIの関与の度合いが異なるさまざまなケースを網羅しています。開発者がモデルを使用してコードを記述する場合もあれば、より珍しいケースでは、インプラントが実行中にモデルに問い合わせを行い、次の動作を決定することもあります。これらはそれぞれ異なる脅威であり、証拠や防御策も異なります。本ガイドでは、これらを区別し、報告されている事例を検証するとともに、セキュリティチームがこれらを検知し、対応するための実践的な方法を提示します。
重要なのは、AIが攻撃チェーンのどの段階で関与するかという点です。『Malware 』は、モデルの助けを借りて書かれたからといって、新たな技術的種となるわけではありません。セキュリティへの影響は、コードが何を行うか、攻撃者が何を制御しているか、そしてデプロイ後もモデルが関与し続けるかどうかに依存します。
これらのカテゴリーは重複する場合があります。また、AIの防御的な活用である「AIによる脅威検知」や、prompt injection のようなAIアプリケーションに対する攻撃と混同してはなりません。一般的な定義や分類については、『malware 』ガイドを参照してください。
「AI生成」という言葉は、開発の来歴について何かを示唆しています。「自律型」という言葉は、運用上の制御について何かを示唆しています。どちらの用語も、それだけでは攻撃が成功したかどうかを判断する手がかりにはなりません。モデルによって記述された情報窃取型マルウェアは、完全に固定された命令に基づいて実行される場合があります。逆に、比較的小さなプログラムであっても、実行時にインターフェースのナビゲーションといった限定的なタスクをモデルに委任することが可能です。
MITRE ATT&CK 多形コードを、その目的を維持しつつ実行時のフットプリントを変化させるソフトウェアとして定義している。ミューテーションエンジンは、大規模言語モデルが登場する以前から存在していた。AIはコードのバリエーション生成を加速させたり、変種を選択したりすることはあるが、ハッシュ値が変化したからといって、そのサンプルがAIによって生成されたという証拠にはならない。
最も説得力のある脅威モデルは、「あらゆる攻撃が完全に自動化されている」という主張ではなく、具体的な手順から出発するものである。現在の研究では、開発、難読化、および運用上の意思決定におけるAIの活用が、成熟度や可視性の異なるレベルで報告されている。
攻撃者は、コーディングモデルを利用して、コンポーネントの草案作成、エラーの説明、言語間のコード移植、おとりロジックの記述、あるいはテストの自動化を行うことができます。Google Threat Intelligence Groupは、2026年5月の分析レポートにおいて、ウクライナの組織を標的とした活動で使用されたmalware ファミリーである「CANFAIL」と「LONGSTREAM」について解説しました。 研究者らは、悪意のある機能を隠蔽するために設計された、モデル生成による「埋め草」コードと評価されるコードを発見した。LONGSTREAMでは、夏時間のステータスを照会する32件の非アクティブなクエリが特定されたが、これは新たな攻撃目的というよりは、一見無害に見えるコードの量を示す一例である。この32件は、分析対象となった1つのコードファミリーに関するものであり、普及度の指標ではない。
防御側にとって、当面の課題は、悪意のあるバイナリやスクリプトが実行され、システム内に潜伏し続け、認証情報を盗み出し、外部と通信できるかどうかという点にある。AIによる作成であることは、攻撃元の特定を複雑にする可能性はあるが、そうした挙動そのものを消し去るわけではない。
AIは、コードの書き換え、不活性な分岐の追加、パッケージングの変更などを通じて、静的マッチングを妨害するのに役立ちます。Google Threat Intelligence Groupは、モデルに自己変更を指示するように設計された実験的なVBScriptドロッパー「PROMPTFLUX」について解説しました。Googleの分析では、確認されたバージョンは開発またはテスト段階にあり、デバイスやネットワークを侵害する能力は示されていなかったと明記されています。これは手法の試みを示す証拠であり、広く成功裏に利用されている証拠ではありません。
既知のサンプルについては、静的ファイルのハッシュ値や署名には依然として価値があります。これらをプロセス、メモリ、ID、ネットワークのテレメトリと組み合わせることで、ファイルの外観が変化しても見落とされることがないようにします。
あるmalware は、AIサービスをランタイムワークフローの一部として組み込んでいます。Googleの報告によると、ウクライナを標的とした「PROMPTSTEAL」は、APIを介してモデルにクエリを送信し、システム情報や文書を収集するためのコマンドを生成していました。malware はこれらのコマンドを実行し、収集したデータを攻撃者のインフラストラクチャに送信しました。Googleは、実稼働環境において「malware 」がモデルにクエリを送信するのを確認したのはこれが初めてであると述べています。これは実験的な「PROMPTFLUX」サンプルよりも有力な運用上の証拠ですが、それでもなお、このような「malware 」が一般的であるとは断定できません。
Googleは2026年5月の分析において、モデルを用いてインターフェースの状態を解釈し、デバイスのナビゲーション操作を返すAndroid向けバックドア「PROMPTSPY」について解説しました。これは特定のデバイスに固有の事例です。Androidのアクセシビリティ機能やアプリの永続化メカニズムを、企業のWindowsやLinux環境に一般化して適用すべきではありませんmalware 。
AIは、malware の枠外で機能することも可能です。人間のオペレーターは、エージェントを利用して、標的の優先順位付け、ツールのデバッグ、あるいはスキャンや認証情報の収集を管理することがあります。2026年9月のGoogleの事例では、エージェントを活用した攻撃キャンペーンが6時間足らずで完了しました。このスピードが重要なのは、オペレーターの手動による判断を待つ時間が短縮できるからです。ただし、この事例は、AIを活用したすべての侵入がより迅速であることや、malware 自体がすべての決定を下したことを証明するものではありません。
コード支援から実行時モデルの利用への移行は、報告されている事例では実際に確認されていますが、こうした事例を一般的な傾向と混同してはなりません。研究者がサンプルや開発成果物、あるいはインシデントのテレメトリを調査し、実際に何が観察されたかを明らかにできた場合に、その証拠は最も説得力を持つことになります。
実際の傾向としては、開発支援から実行時のモデル呼び出しに至るまで、AIの関与範囲が拡大しています。これにより、変更されたコードの検査やワークフローの高速化が促進されます。しかし、malware がすでに自律化している、シグネチャは無用である、あるいは感染の大部分がAIによって生成されているといった、普遍的な主張を裏付けるものではありません。Googleの「M-Trends 2026」の要約でも同様に、同社が確認した侵入の成功事例の大部分は、依然として従来からある人的ミスやシステム上の欠陥に起因しているとの注意が喚起されています。
たとえ新しいインプラントであっても、アクセス権を取得し、実行され、効果を発揮しなければなりません。防御側は、単一の「malware 」というファミリー名に依存することなく、これらの観察可能な段階を中心に調査を組織化することができます。
1. 侵入と実行。悪意のある添付ファイル、侵害されたパッケージ、公開されたサービス、または盗まれた認証情報により、攻撃者は侵入経路を得ることになります。何が、どのIDで、どの資産上で実行されたのかを特定してください。
2. 発見と適応。コードまたはオペレーターが、ソフトウェア、セキュリティ対策、ファイル、あるいはクラウドサービスを調査・把握します。AIがこれらの観測結果の解釈を支援することはありますが、異常な事象の発見は依然として目視による確認が必要です。
3. 持続性と特権。スケジュールされたタスク、サービスの変更、トークンの使用、または不正な権限付与によって、アクセス範囲が拡大されることがあります。変更を悪意のあるものとみなす前に、その変更が許可されたものかどうかを確認してください。
4. 動きとコマンド。新しいリモートセッション、不審なアクセス経路、外部へのモデル／API呼び出し、およびコマンド＆コントロールトラフィックに注意を払う。モデルAPIへのリクエストだけでは侵害の証拠とはならない。そのリクエストをプロセスやその後の行動と関連付けて分析する必要がある。
5. 収集と影響。ファイルへのアクセス、認証情報の収集、データの集積、外部への持ち出し、暗号化、またはサービスの妨害などが、その目的を示しています。一連の経緯を再現できるよう、タイムスタンプやエンティティ間の関係を保持してください。
この段階別の視点は、ペイロードの形状が変化する場合に特に有用です。また、AI起源説の真偽が不透明な場合でも、チームが影響に焦点を当て続けることができます。
検知においては、既知のmalware 対策と、エンドポイント、ID、ネットワーク、クラウドサービスにわたる動作を組み合わせて行うべきです。その目的は、攻撃の連鎖を確認することであり、見慣れないプロセスをすべて「AImalware 」とラベル付けすることではありません。
エンドポイント保護、パッチ適用、ソフトウェアの出所確認、および既知の指標との照合は維持してください。既知のサンプルや亜種は、依然としてブロック可能です。単純なファイル照合を回避する手法に対しては、プロセスの系譜、スクリプトおよびメモリのテレメトリ、ならびに実行ポリシーの制御を追加してください。MITREの「ポリモーフィックコード」に関する記述では、マルウェア対策制御と併せて、行動ベースの手法を明示的に推奨しています。
新たに開始されたプロセスによる認証情報ストアの読み取り、見慣れない外部サービスへの接続、リモートアクセスの開始、データの準備といった一連の組み合わせを調査します。ホストを、そのホストが使用したアカウントや、それに続くクラウド／SaaS上の操作と関連付けます。ネットワークおよびIDのコンテキストを分析することで、ファイルのハッシュ値が変更された場合や、エンドポイントエージェントによる可視性が確保されていない場合でも、攻撃の進行状況を把握できます。VectraAIのEDRギャップ検出のユースケースでは、こうした相互補完的な可視性について説明されています。各チームは、自社の環境における実際のカバレッジを検証する必要があります。
ポリシーで許可されている場合は、エンタープライズAIサービスに対する呼び出し元プロセス、宛先、アカウント、時刻、リクエスト数、および下流のコマンドを記録してください。正当な開発者ツールでも同様のトラフィックが発生する可能性があります。不審なプロセスがモデルを呼び出した後、生成されたコマンドを実行したり、永続化設定を変更したり、機密データにアクセスしたりした場合は、上層へ報告してください。承認されたプライバシーおよび保存期間ポリシーを超える範囲で、プロンプトやペイロードを収集することは避けてください。
モデル使用ログが利用できない場合は、AIの関与は確認されていない旨を明記してください。その場合でも、観測された悪意のある行動に基づいて対応を進めることは可能です。
最も有用な制御手段は、malware やAI搭載のオペレーターが侵入後に実行できる動作を制限するものです。予防策と並行して、IDによるアクセス制御、実行パス、流出経路、および応答速度を優先的に考慮してください。
1. リスクへの露出を低減する。脆弱性が悪用されたサービスへのパッチを適用し、信頼できないパッケージやスクリプトの使用を制限し、開発者ツールの権限を見直し、APIキーやエージェントの認証情報を保護する。クラウドおよびSaaSのIDに対しては、最小権限の原則を適用する。
2. 攻撃経路を可視化する。エンドポイント、ネットワーク、ID、クラウド、および関連するAIサービスのログを、時刻を同期させた状態で保持する。モデルの使用履歴を誰が確認できるか、およびその保持期間を定義する。
3. 動作ベースの検知機能をテストする。正当なリソースの検出、認証情報のアクセス、リモート実行、およびデータのステージングをシミュレートする。チームが、既知のハッシュ値に頼ることなく、イベントを1つのインシデントとして結びつけられるかどうかを評価する。
4. 検出された感染チェーンを封じ込める。必要に応じて感染したホストを隔離し、アクティブなセッションや漏洩したトークンを無効化し、悪意があると確認された宛先への通信を遮断し、大規模なクリーンアップを行う前にフォレンジック証拠を保全する。
5. 復旧と教訓の抽出。信頼できる情報源に基づいてシステムを復旧させ、残存リスクが完全に除去されたことを確認し、影響を受けた認証情報を更新し、タイムラインを検知および封じ込めのタイムスタンプと照合します。見落とされたID、ネットワーク、またはクラウドに関する手順があれば、プレイブックを更新します。
有用な評価では、次のような問いを投げかけます。「チームは、侵害されたID、影響を受けた資産、および攻撃者の次の行動を、介入できるほど迅速に特定できたか？」検出時間、調査時間、封じ込め時間をそれぞれ個別に記録します。制御された演習を行うことで、特定のベンダーの有効性を前提とすることなく、この問いを検証することができます。
Vectra AIの「AIネイティブ」なセキュリティおよび可観測性の位置づけは、攻撃がID、ネットワーク、クラウドサービス、エンドポイントの間を移動する場合に有効です。同社のEDRギャップ検出のユースケースでは、管理対象のエンドポイントを超えた行動の可視化について説明されています。 AIを活用したmalware 調査において評価すべき価値は、利用可能なシグナルが、アナリストが認証情報の悪用、横方向の移動、およびデータ流出を、進行中の侵入と結びつけるのに役立つかどうかという点です。製品の適合性や対応措置は、導入状況、統合状況、および権限設定によって異なるため、価値実証（PoV）においてこれらを確認してください。
コントロールのマッピングを行う場合は、まず「malware の基礎」と「AIによる脅威検知ガイド」から始めてください。エンドポイントのテレメトリ以外のギャップを評価しているチームは、「EDRギャップ検出のユースケース」をご確認ください。その評価後に、導入に関する具体的な検討を行う場合は、Vectra AIのデモをご依頼ください。
出典および調査方法に関する注記： 本調査ガイドは、2026年10月22日に、元の調査報告書およびMITRE ATT&CK に基づいて確認されました。掲載されている事例は、発生率調査や独立した製品テストではありません。
AIは大量のコードを生成し、テストの自動化を支援することはできますが、文書化された事例においても、依然として人間の目的、アクセス権限、ツール選定、およびデプロイに関する決定が関わっています。「malware 」が完全に自律的であるという主張には、実際の運用環境または明確にラベル付けされたテストにおいて、システムがそれらのアクションを選択し実行したという証拠が必要です。
AIがコードやパッケージングの変更を支援する場合、静的マッチングはより困難になる可能性があります。検知の可否は、具体的な手法や利用可能なテレメトリ情報によって異なります。既知のサンプルに基づく制御、エンドポイントの動作、ID関連イベント、ネットワークアクティビティ、およびクラウログは、これらを組み合わせて活用することで依然として有用です。
いいえ。多くの正当なアプリケーションがモデルを呼び出しています。調査担当者は、malware が当該サービスを利用したと結論付ける前に、その呼び出しと、関連するプロセス、アカウント、生成されたアクション、およびその結果生じた挙動との関連性を確認する必要があります。
多態型（malware ）とは、同じ目的を維持しつつ、コードや実行時のフットプリントを変更するものです。これにはAIは必要ありません。AI（malware ）は、開発や運用におけるAIの役割を指します。AIを活用したサンプルも多態型である場合がありますが、これらのカテゴリーは同義語ではありません。
検知された侵入のトリアージを行う：影響を受けた資産と対象を特定し、プロセスおよびネットワークの証拠を保全し、認証情報とデータへのアクセスを評価し、確認された活動を封じ込める。緊急対応が開始された後、AIが関与していたかどうかを判断する。その判断によって、封じ込め作業が遅れることがあってはならない。