2026年、企業システムにおける「ワーム(自己増殖マルウェア)」の定義が再び更新されつつある。かつてはOSやネットワークサービスの脆弱性を足がかりに横展開したが、現在の主戦場はSaaSとID基盤である。さらにLLMが攻撃の探索・文章生成・手順化を高速化し、ワームを「環境に適応する自動化パイプライン」へ押し上げる。
本稿は、1988年11月2日のMorrisワームから得られた古典的教訓を起点に、SaaS-to-SaaS(SaaS間)で自己増殖するOAuthワームの成立条件、そしてLLMパイプラインを悪用するプロンプトインジェクション型ワームのメカニズムを整理する。そのうえで、AIエージェントが業務ツールとして普及する環境で、従来のワーム防御が効きにくい理由と、防御設計をどこから作り替えるべきかを提案する。
ワームは「ホスト」から「アイデンティティ」へ移動した
ワームは自己複製によって感染範囲を指数関数的に広げる。Morrisワーム(1988年11月2日)は、当時のUNIX環境に存在した複数の欠陥を組み合わせて拡散し、インターネット全体に大きな影響を与えた。Spaffordの解析レポートやRFC 1135が示す通り、この事件は「単一の脆弱性」ではなく、複数の入口と複製ロジックの組み合わせが社会インフラ級の障害を引き起こし得ることを明確にした。
しかし2026年のエンタープライズでは、ワームが「同一LANにいる別ホスト」へ移動するだけでは、価値の中心(データ、権限、ワークフロー)に到達できない。価値はSaaSにあり、移動の鍵はIDである。ここでいうIDは、ユーザーの資格情報だけでなく、OAuthアプリ、サービスプリンシパル、APIトークン、ワークフロー自動化の接続(コネクタ)を含む。
この変化は、ワームの爆発半径を「ネットワーク境界」ではなく「権限境界」で決める。つまり、複製の単位はホストではなく、アクセス許可(スコープ)とトークンである。
AI駆動型ワームが加速する3つのループ
本稿でいう「AIワーム」とは、LLM等を組み込み、拡散・実行・隠蔽の意思決定や生成物(メール文面、説得文章、手順、コード断片)を自動化して、自己増殖を最適化する攻撃の総称である。AIがワームを強化するポイントは、ゼロデイの魔法ではない。既存の攻撃要素を、より速く、より多様に、より状況適応的に回す点にある。
- 探索ループ: 侵害済み環境のログ、権限一覧、SaaSのアプリ一覧、メール/チャット履歴を入力として、次の「有望な横展開」を選ぶ。
- 生成ループ: フィッシング文面、業務っぽい依頼文、承認依頼、社内規程の引用などを状況に合わせて生成し、承認・同意・クリックを引き出す。
- 手順化ループ: APIの利用手順、Graph/Drive/Slackなどの操作を「実行可能なタスク列」に変換し、エージェント的に遂行する。
これらは「攻撃の自動運転」を意味する。加えて、OWASPのLLM Top 10が指摘するように、LLMアプリはプロンプトインジェクションや不適切な出力取扱い、過剰な自律性(Excessive Agency)といった新しい失敗モードを持つ。防御側がAIエージェントを導入するほど、攻撃側も同じ構造を逆用しやすくなる。
SaaS-to-SaaS OAuthワーム: 「同意」を感染経路にする
OAuthを悪用した攻撃は、ユーザーのパスワードを盗まずにSaaSのAPI権限を獲得できる。Microsoftは「consent phishing(同意フィッシング)」として、ユーザーに悪性アプリへの権限付与を促し、クラウドデータへアクセスする手口を解説している。また、2023年7月から11月にかけて、攻撃者が大量のマルチテナントOAuthアプリを作成し、Graph API等を悪用して大規模にフィッシングメール送信を自動化した事例も報告されている。
これを「SaaS-to-SaaSワーム」に進化させる条件は、複製がID境界を越える仕組みを持つことである。典型的な成立パターンは次の通りである。
- 初期感染: メール/チャット/ドキュメント経由でOAuth同意画面へ誘導し、広いスコープ(例: メール読み書き、ファイル、連絡先、チャット)を付与させる。
- 永続化: 付与されたリフレッシュトークン等で継続アクセスし、監視回避のために受信トレイ規則や通知抑制を行う。
- 横展開(同一SaaS内): 取得したAPI権限で、組織内の他ユーザーへ「業務らしい共有」や「承認依頼」を大量送信し、同意獲得を反復する。
- 横展開(SaaS間): 侵害したSaaSから、別SaaS(例: ストレージ、チケット、CRM、チャット、ワークフロー自動化)へつながる連携設定やボット、コネクタ、Webhookを探索し、二次的なトークンやシークレットを奪取して拡散する。
重要なのは、ここでの「自己増殖」は、同一OSの脆弱性を突く必要がない点である。むしろ、同意と連携が多いほど感染速度が上がる。SaaS導入が進んだ企業ほど、攻撃者にとっての「複製媒体」が豊富になる。
また、SaaSの可観測性はベンダー依存であり、端末EDRの観測範囲外に攻撃の主戦場が移りやすい。従来のワーム対策(ネットワーク遮断、端末隔離)が効きにくい理由はここにある。
プロンプトインジェクション型ワーム: LLMパイプラインを複製媒体にする
AIエージェントが日常業務に入り込むと、ワームは「実行環境」をOSからLLMパイプラインへ移すことができる。イメージしやすいのは、以下のような間接型プロンプトインジェクション(データ混入)を起点にした連鎖である。
- 攻撃者が、共有ドキュメント、チケット本文、Wiki、メール署名、CSV等に「指示文」を埋め込む。
- 社内のLLM(RAGや要約、問い合わせ自動化、エージェント)がそのデータを取り込み、指示を「ユーザー要望」や「根拠」と誤認して処理する。
- LLMがツール呼び出し(メール送信、ファイル共有、チケット作成、外部API)を行い、攻撃者の指示を組織内外へ拡散する。
OWASPが列挙するリスク分類でいえば、これはLLM01(Prompt Injection)とLLM02(Insecure Output Handling)の組み合わせであり、ツール実行を許した場合はLLM08(Excessive Agency)の問題に接続する。ワームは「悪性コード」である必要がない。悪性の指示文がデータ平面に紛れ、LLMが制御平面へ橋渡ししてしまう時、組織の自動化パイプラインが複製装置になる。
防御設計: エージェント時代の“ワーム前提”セキュリティ
防御側の中心課題は「侵入をゼロにする」よりも、「侵入しても自己増殖できない構造」を作ることである。SaaS-to-SaaS OAuthワームとプロンプトインジェクション型ワームに共通する防御原則は、権限と自律性を最小化し、可観測性と遮断手段を事前に用意することにある。
- 同意とアプリ登録のガバナンス: ユーザー同意を無条件に許可しない。発行元検証、許可する権限(低リスクスコープ)を限定し、監査ログで同意イベントを常時監視する(Microsoft Learnの推奨に沿う)。
- トークン衛生: アクセストークンとリフレッシュトークンの監査、不要アプリの無効化、広すぎるスコープの棚卸し、期限とローテーションを制度化する。
- “自動化連携”の棚卸し: Zapier/Make/Power Automate等の連携、Webhook、ボット、サービスアカウントの権限を「横展開路」として扱い、最小権限・分離を徹底する。
- LLMの制御平面を分離: RAGの参照データは信頼境界で分離し、外部/社外由来データは「実行禁止」扱いにする。LLMの出力をツール実行へ直結させず、スキーマ検証とポリシー評価(許可リスト)を挟む。
- キルスイッチ: 兆候を検知したら、特定アプリを即時無効化し、関連トークン失効、連携停止を自動化する。端末隔離ではなく、IDとSaaSの遮断を主戦術にする。
結論として、「ワーム対策」はネットワークの話から、ID・SaaS・エージェントの話へ移った。2026年に求められるのは、境界防御の強化ではなく、権限設計と自動化設計そのものの再定義である。
FAQ
AIワームとは何か
自己増殖する攻撃にLLM等の生成AIを組み込み、探索・文章生成・手順化を自動化して拡散効率を上げる攻撃形態の総称である。新しいのは“脆弱性”よりも“意思決定の自動化”である。
SaaS-to-SaaS OAuthワームは従来のワームと何が違うか
複製単位がホストではなく、OAuth同意やAPIトークンといった権限に移る点が異なる。感染はネットワーク境界よりも、スコープと連携の広さで決まる。
MFAを導入していれば安全か
MFAは重要だが、同意フィッシングや悪性OAuthアプリによる権限付与は「パスワード窃取を経由しない」ため、MFAだけでは防ぎきれない。ユーザー同意・アプリ登録・スコープ管理が別系統の防御面となる。
プロンプトインジェクション型ワームを防ぐ要点は
外部由来データをLLMに与える際の信頼境界の設計、LLM出力の検証(スキーマ/ポリシー)、ツール実行権限の最小化が要点である。LLMの出力を「実行命令」として扱わないことが基本である。
監視すべきログや兆候は何か
OAuth同意イベント、異常なアプリ登録、権限の急拡大、Graph等のAPI呼び出しの急増、受信トレイ規則の不審な作成、ワークフロー連携の新規作成や設定変更などが主要な観測点である。
参考文献
- The Internet Worm Program: An Analysis — Purdue University, 1988-11-18
- RFC 1135: Helminthiasis of the Internet — RFC Editor, 1989-12-01
- Protect against consent phishing — Microsoft Learn, 2025-01-08
- Threat actors misuse OAuth applications to automate financially driven attacks — Microsoft Security Blog, 2023-12-12
- Threat actor consent phishing campaign abusing the verified publisher process — Microsoft Security Response Center (MSRC), 2023-01-31
- Announcing the LLM Top 10 version 1.1 Update — OWASP GenAI Security Project, 2023-10-18



