SaaS-to-SaaS OAuth Worms: 「同意」ウイルスの脅威

エグゼクティブサマリー

2026年、「アイデンティティは新しい境界線」から進化し、「相互接続性が新たな脆弱性」へと変わっています。最新のサイバーセキュリティ脅威は、ブルートフォースパスワード攻撃やゼロデイエクスプロイトではありません。それは、SaaS-to-SaaS OAuth Worm — 正当なAPI接続を悪用した自己伝播型の「同意ウイルス」です。

この記事では、これらの攻撃の構造を解剖し、2025年を通じて記録された実際のキャンペーンと関連付け、Microsoft 365やGoogle Workspaceの管理者向けに具体的な防御戦略を提供します。

---

新たな攻撃対象：”ヘルパーアプリ” & AI統合

2026年までに、平均的な企業ユーザーは50以上のサードパーティアプリを企業IDに接続しています。これらは単なるシャドウITではなく、AIスケジューラーや文法チェッカー、会議アシスタントなどの「生産性向上ツール」です。

セキュリティチームは、フロントドア（MFA、SSO、生体認証）を強化してきましたが、OAuth Wormはバックドアを通じて侵入します。侵入を試みるのではなく、「入れてください」と頼むのです。認証後は、パスワードを必要とせず、OAuthアクセス トークン — デジタルキーを持っているため、資格情報の変更後も有効です。

---

「AI-Meeting-Summarizer」シナリオ

この脅威パターンの最も顕著な例は、「AI-Meeting-Summarizer」ウイルスです。感染のライフサイクルは以下の通り:

1. 患者ゼロ — ユーザーが同僚（既に感染済み）からの役立つメールを受け取り、「この会議の要約に協力してください」と新しいAIツールを使った招待を受ける。

2. 誘引 — このメールは従来のフィッシングリンクではありません。正当な内部ドメイン（例：user@company.com）から送信されており、送信者のアカウントがAPI経由で招待を自動化しています。

3. フック — ユーザーがリンクをクリックすると、Microsoft 365やGoogle WorkspaceのOAuth同意画面が表示されます。見た目は100%本物です — なぜなら、それは本物だからです。

4. ペイロード（「同意」） — アプリは以下の権限を要求します:

   • Contacts.Read — 新しい被害者の特定
   • Mail.Send — ウイルスの拡散
   • Files.ReadWrite.All — データの抽出
   • Offline_Access — 無期限のアクセス維持

5. 拡散 — 「承認」をクリックした瞬間、ウイルスは付与されたAPIトークンを使い、ユーザーの頻繁な連絡先をスキャンし、被害者のメールアドレスから50件のパーソナライズされた招待を送信します。

部署全体への感染時間：< 15分。

---

実例（2025–2026）

これらは理論的なシナリオではありません。攻撃パターンは2025年に大規模に展開され、2026年には加速しています。

Salesloft-Driftサプライチェーン侵害（2025年3月）

2025年の最も重要なOAuthインシデントの一つは、SaaS-to-SaaSの爆発範囲を完璧に示しています。攻撃者はSalesloftのGitHubリポジトリにアクセスし、その後、Driftの統合OAuthトークンを悪用して、700以上の組織のSalesforceインスタンスに侵入しました。Obsidian Securityの研究者は、攻撃者が直接Salesforceを狙った場合の10倍の被害が出ていると指摘しています — 1つの侵害された統合が複数の環境に連鎖したためです。

教訓：SaaSサプライチェーン内の単一のOAuthリンクが、あなたのビジネスエコシステム全体への入り口になり得るということです。

Chrome拡張機能の同意ウェーブ（2024年後半–2025年）

Google Chrome拡張機能のベンダーを標的とした同意フィッシングキャンペーンは、Cyberhavenを含む少なくとも35の一般的な拡張機能で約260万人のエンドユーザーに影響を与えました。侵害された従業員アカウントにより、攻撃者はChrome Web Storeにアクセスし、OAuth資格情報を大量に収集する悪意のある拡張機能のバージョンを公開しました。

「ShadyPanda」ブラウザキャンペーン（2025年12月）

「ShadyPanda」キャンペーンは、ChromeとEdgeの拡張機能で約430万インストールを獲得し、クッキーやセッショントークンの窃盗を通じてデータを外部に送信 — エンドポイント検知ツールの監視外です。

Microsoft 365 OAuthアプリのなりすまし（2025年、継続中）

Proofpointは、Adobe、DocuSign、RingCentral、SharePointなどの信頼されたブランドを偽装したMicrosoft 365 OAuthアプリを用いた長期キャンペーンを特定しました。これらのキャンペーンは、900以上のMicrosoft 365環境の約3,000ユーザーアカウントを標的とし、50%以上の成功率でアカウント侵害を達成しています。悪意のあるアプリは、セッションCookieやMFAトークンを同時に収集するための中間者型フィッシングキット（Tycoonなど）にリダイレクトします。

国家連携OAuth乱用（2025年9月）

Proofpointは、UNK_AcademicFlareと追跡されるロシア系と疑われる脅威アクターが、OAuthデバイスコード認証を悪用してターゲットアカウントを乗っ取る事例を観測しました。攻撃者は、政府や軍のメールアカウントを侵害し、信頼を築いた後、偽装されたOneDriveリンクを送信し、被害者をデバイスコードフィッシングに誘導します。主なターゲットは、米国とヨーロッパの政府、学術機関、シンクタンク、交通セクターです。

---

進化の過程：「ConsentFix」 — 次の変異（2025年12月）

第三者OAuth同意フローのロックダウンが始まった矢先、Push Securityの研究者は2025年12月に大きな変異を記録しました：ConsentFix。

ConsentFixは、Microsoftが2025年に展開したより厳格なOAuth同意設定をバイパスするブラウザネイティブの攻撃です。なぜこれがより危険なのか:

仕組み: ユーザーを騙して「許可」をクリックさせるのではなく、被害者に正規のOAuth認証コードURLをコピー＆ペーストさせ、それを攻撃者のフィッシングページに貼り付けさせるソーシャルエンジニアリングです。これにより、ブラウザ内で有効なセッションを攻撃者に渡すことになります — ソフトウェアのインストールやMFAチャレンジは不要です。

ファーストパーティの抜け穴: ConsentFixは特にAzure CLIをターゲットにしています。これはMicrosoftの信頼されたアプリであり、すべてのEntra IDテナントで暗黙的に信頼されています。Azure CLIはMicrosoftネイティブのアプリなので、管理者によるブロックや削除ができません。昇格された権限を要求し、サードパーティアプリ制限ポリシーも適用されません。

フィッシング耐性のあるバイパス: 既にMicrosoftアカウントのブラウザセッションがアクティブな場合、ログインは不要です。これにより、フィッシング耐性のある認証方法（パスキーなど）も回避されます。

これは根本的な変化を示しています：攻撃者はもはやサードパーティアプリの同意ギャップだけを狙っているのではなく、クラウドプラットフォームが自社ツールに対して持つ暗黙の信頼を悪用しているのです。

---

OAuthワームの構造：なぜレガシーセキュリティを回避できるのか

MFAを回避

MFAは認証の瞬間 — ログインを守ります。OAuthワームは、許可 — 権限付与を悪用します。ユーザーが既に有効なセッションでログインしているため、「承認」をクリックしても、多くの設定ではMFAチャレンジは発生しません。攻撃者はOAuth 2.0 APIアクセスを通じて非人間のアイデンティティを利用しているため、MFA保護はトークンの乱用に対して無力です。

クラウド上で生きる（LotC）

エンドポイントにマルウェアはインストールされません。.exeファイルはありません。悪意のあるロジックはすべて攻撃者のクラウドインフラ（AWS/Azure/GCP）に存在し、直接あなたのテナントのAPI（Microsoft Graph APIやGoogle Workspace API）と通信します。

信頼された招待

迷惑メールフィルターは評価信号に依存します。internal-employee@yourcompany.comからanother-employee@yourcompany.comへメールを送ると、そのメッセージは有効なDKIMとSPFレコードで署名されており、「安全な送信者」許可リストを通過します。これは、信頼された内部アカウントからの送信だからです。

リフレッシュトークンによる持続性

被害者がパスワードを変更しても、攻撃は継続します。OAuthアプリはリフレッシュトークンを使い、新しいアクセス トークンを生成します。アプリの権限を明示的に取り消さない限り、攻撃者は最大90日以上アクセスを維持し続けます — パスワードリセットやMFA再登録、アカウントロックアウトを超えて。

トークンは鍵

ベアラートークンは送信者の検証を行いません。盗まれたOAuthトークンは、場所やデバイス、ネットワークに関係なく再認証なしで動作します。攻撃者が有効なOAuthトークンを取得すれば — 同意フィッシング、トークン窃盗、サードパーティの侵害を通じて — 認証制御を完全に回避します。トークンを持つ者が鍵を握るのです。

---

「エージェンシック」な脅威：AI駆動のコンテキスト

2024年、研究者はMorris II — 最初の生成AIワームを実証しました。2026年までに、この概念は実運用の攻撃へと成熟しています。

最新のOAuthワームはLLMsを使い、被害者の最近のメールやカレンダーデータを読み取り、文脈に応じた招待を生成します。これらはほぼ正当な同僚の通信と見分けがつきません:

古いフィッシング	2026年AI支援OAuthワーム
“添付の請求書をご確認ください”	“やあサラ、今週火曜日の予算会議をこのAIツールで要約したものだよ。Q3の見通しについても良く捉えている — チェックしてみて”

この高いコンテキストのソーシャルエンジニアリングは、一般社員にとって疑念を抱きにくくします。メッセージは個別化され、実際の会話を参照し、信頼された同僚の実メールアドレスから届きます。

特に、ClickFix — ConsentFixに密接に関連した手法 — は、2025年にMicrosoftが検出した最も多い初期アクセスベクターであり、攻撃の47%に関与しています。

---

プラットフォームの対応：2025年に何が変わったか

Microsoftの2025年7月のデフォルトポリシー変更

重要な防御策として、Microsoftは2025年7月から、ユーザーが第三者アプリのファイルやサイトへのアクセスに対してデフォルトで同意できなくなると発表しました。管理者は代わりに、Admin Consentワークフローを通じて承認を要求する必要があります。Entra IDのリスクベースのステップアップ同意は、検証済みの発行者のないマルチテナントアプリの同意リクエストを自動的にエスカレートし、エンドユーザーがフィッシングURL経由で遭遇する疑わしいアプリに直接同意するのを防ぎます。

これは大きな改善ですが、ConsentFixやファーストパーティアプリのバイパスには完全には対応していません。

Google Workspaceのコントロール

Google Workspaceの管理者はAPIコントロールを設定し、サードパーティアプリのアクセスを制限できます。推奨される設定は、ドメイン所有のアプリと特定の許可リストに登録されたサードパーティアプリのみを許可し、それ以外をデフォルトでブロックすることです。これにより、同意フィッシングの攻撃対象範囲が大きく縮小します。

---

防御戦略：組織の防御力を高める

Consentウイルスに対抗するには、「アイデンティティセキュリティ」から「アプリガバナンス」へのシフトが必要です。

1. 「キルスイッチ」：ユーザーの同意を制限

Microsoft 365: - Entra ID > エンタープライズアプリケーション > 同意と権限に移動 - 「検証済み発行者のみのアプリに対するユーザー同意を許可」（推奨）を選択、またはユーザーの同意を完全に無効化 - 管理者同意ワークフローを有効にし、ユーザーが自己承認せずにアプリをリクエストできるように - 2025年7月に導入された管理された同意ポリシーを確認

Google Workspace: - セキュリティ > APIコントロール > アプリアクセス制御に移動 - 内部ドメイン所有のアプリのみ信頼し、承認済みサードパーティアプリの明示的許可リストを維持 - それ以外のアプリのGoogle Workspace APIアクセスをデフォルトでブロック

2. 監査と一掃（「アプリ衛生」プロトコル）

長期間にわたり放置された過剰権限のアプリが存在する可能性が高いため、CASBやMicrosoft Defender for Cloud Appsを使って以下をフィルタリング:

• Mail.SendやContacts.Read権限を持つアプリ
• 「低信頼」や「未検証の発行者」ステータスのアプリ
• 10人以上のユーザーが24時間以内に同意したアプリ — 活動中のウイルス拡散の強い指標
• offline_accessとFiles.ReadWrite.AllまたはMail.ReadWriteを組み合わせたアプリ — 長期的なデータ抽出の高リスク範囲

3. API使用の異常検知

標準のEDRはクラウドネイティブのOAuth攻撃に無力です。ITDR（アイデンティティ脅威検知と対応）を導入し、以下のアラートルールを設定:

• “高リスク権限を持つ新しいOAuthアプリの付与” — 初回発生時にアラート
• “内部アカウントからの異常な送信メール量” — 特に同一件名のメールを内部配信リストに送信
• “offline_access + Files.ReadWrite.Allを持つ新しいマルチテナントアプリ” — 60分以内に調査
• “初めての外部テナントDM +メールルール作成 + 新しいOAuth付与” — 24〜48時間以内に高信頼度のウイルス兆候
• “既存アプリの発行者ドメイン変更” — サプライチェーン侵害の可能性

4. ファーストパーティアプリの新たな監視

ConsentFixは、Azure CLIのようなMicrosoftネイティブアプリも完全にバイパスできることを示しています。条件付きアクセスポリシーを見直し、デバイスコード認証フローをカバーし、予期しない場所やデバイスからの認証を検知する条件を追加しましょう。

5. 「Consent Phishing」シミュレーション

従来のフィッシングテストと並行してOAuth同意シミュレーションを実施:

• 「カレンダーアプリを更新してください」の偽メールを送信
• ユーザーを模擬同意画面に誘導
• 発生率を追跡し、「検証済み発行者」の青いチェックマークを確認させる

ユーザーに対し、承認前に「検証済み発行者」のマークを確認し、予期しないOAuthプロンプトはITセキュリティに報告させる訓練を行います。

---

復旧：感染した場合の対応

テナント内でOAuthワームの拡散を検知した場合、以下の手順を順に実行:

ステップ1：アプリのグローバルリボーク

Microsoft 365: Entra IDでエンタープライズアプリを見つけ、「プロパティ」に移動、「サインイン可能？」をNoに設定。アプリの割り当てとサービスプリンシパルを削除。

Google Workspace: APIコントロールで悪意のあるアプリのクライアントIDをブロック。

ステップ2：リフレッシュトークンの取り消し

パスワード変更だけでは不十分です。OAuthトークンを明示的に取り消す必要があります。

PowerShell（M365）:

Revoke-MgUserSignInSession -UserId <UserObjectID>

このコマンドは影響を受けたすべてのユーザーに対して実行します。

Google Workspace: サインインCookieをリセットし、各ユーザーのセキュリティ設定から連携アプリを取り消し。

ステップ3：内部メールの一掃

Microsoft Content SearchやeDiscoveryを使い、すべてのメールボックスからウイルスの招待メールを完全削除。削除されていない招待は新たな被害者を生み続けます。

ステップ4：情報漏洩範囲の監査

Files.ReadWrite.AllやMail.Read権限を持ち、Offline_Accessトークンが有効な場合、データ漏洩とみなします。トークンの滞留期間中にアクセスされたSharePointサイトやOneDriveフォルダ、メールボックスを特定し、侵害評価を行います。

---

脅威モデルの変化：2026年に求められること

2026年のフィッシング脅威モデルは、攻撃者がアカウント乗っ取りを認証フロー、OAuth同意、デバイスコード認証、ブラウザネイティブのトークン窃盗を通じて行うことを認める必要があります。もはやメールだけを守るのは不十分です。

運用上の違いも重要です。セキュリティゲートウェイ（SEG）は悪意のあるリンクをブロックできますが、正当な内部メールから届く同意プロンプトをブロックできません。ブラウザ内のコピー＆ペーストも見えません。

クラウドネイティブの世界では、悪意のあるアプリは悪意のあるファイルよりも遥かに危険です。厳格な同意ポリシーの実施、ITDRツールの導入、すべてのOAuth連携リクエストを実行可能ファイルと同じ基準で審査することで、感染の連鎖を未然に防ぐことができます。

---

重要ポイント

• OAuth同意攻撃は、*認証*ではなく*権限付与*を悪用し、MFAを完全に回避します
• Salesloft-Drift侵害（2025年3月）は、1つの侵害が700以上の組織に連鎖し、10倍の爆発範囲をもたらしました
• 「ConsentFix」（2025年12月）は、Azure CLIなどのファーストパーティアプリをターゲットにしたブラウザネイティブの変異です
• Microsoftは2025年7月から制限付き同意をデフォルトに設定 — テナントの準拠性を確認し、テストしましょう
• パスワードだけでなくトークンも取り消す — 侵害されたOAuthリフレッシュトークンは完全リセット後も生き続ける
• ITDRは必須：標準のエンドポイント検知はクラウドネイティブOAuthの悪用に無力
• ClickFix / ConsentFixのバリアントは、2025年にMicrosoftが検出した初期アクセスのほぼ半数を占めました

---

OAuthの脅威環境は、監査サイクルよりも早く進化しています。アプリの同意ポリシーを見直し、アプリ衛生監査を行い、ITDRのアラートが非対話型APIトークンの乱用をカバーしているか確認してください — そして次の全社員招集のカレンダー招待がPatient Zeroになる前に。