「Microsoftの公式サイトだから安全だろう」——そんな思い込みを利用して、AIエージェントからOAuthアクセストークンを盗み取る手口が報告されています。
その名前はCoPhish(コフィッシュ)。
2025年10月、Datadog Security Labsは、Microsoft Copilot Studioの正規機能を悪用する攻撃手法を公開しました。偽のログイン画面を用意しなくても、利用者が正規の認証画面でアクセスを許可した後に、トークンが攻撃者へ渡る可能性があります。
図1:CoPhishの危険性(説明用イメージ。実際の製品画面とは異なります)*
この記事では、CoPhishの仕組みと、Microsoft Entra ID・Microsoft 365の管理者が実施できる対策を説明します。
1. Microsoftの正規ドメインでも危険なの?
ある日、Teamsに「新しいAIアシスタントを試してください」という案内が届いたとします。リンクのドメインは `copilotstudio.microsoft.com`。開くとCopilot Studioのエージェントが表示され、「サインインして続行してください」と案内されます。
利用者はMicrosoftの正規画面でログインし、アプリから要求された権限にも同意しました。画面はその後、何事もなかったようにチャットへ戻ります。
ところが、同意によって取得されたアクセストークンが、エージェントの不正な処理を通じて攻撃者へ転送される場合があります。
ここで問題なのはMicrosoftのドメインやログイン画面が偽物だったことではありません。正規のサービスで動作する、悪意を持って作られたエージェントやアプリです。
2. CoPhishとは? パスワードではなく「アクセス許可」を狙う攻撃
CoPhishは、Copilot Studioを悪用したOAuth同意フィッシングの手法です。
OAuthアクセストークンは、アプリが利用者に代わって特定のデータや機能にアクセスするための「デジタル通行証」のようなものです。例えば、メールを読み書きする権限に同意すると、アプリは許可された範囲でMicrosoft Graph APIからメールを操作できる場合があります。
| 権限の例 | 許可される操作の例 |
| Mail.ReadWrite | メールの読み取り・書き込み |
| Mail.Send | 利用者としてのメール送信 |
| Files.ReadWrite.All | 利用者がアクセス可能なファイルの読み取り・書き込み |
| Calendars.ReadWrite | 予定表の読み取り・書き込み |
実際に操作できる範囲は、トークンに付与されたスコープ、利用者の権限、各サービス側の認可条件に依存します。これらの権限すべてが、一般ユーザーに自由に同意できるわけではありません。
重要なのは、パスワードを盗まれなくても、トークンの有効期間中に許可済みの操作を悪用されるおそれがあることです。
3. 図解:CoPhishの攻撃フロー(4ステップ)
図2:CoPhishの攻撃フロー。図の権限名や製品画面は説明用の例です。
STEP 1 - 攻撃者がエージェントを作成する
攻撃者はCopilot Studioでエージェントを作ります。そしてサインイン処理の直後に、取得したアクセストークンを外部へ送る不正なHTTPアクションを組み込みます。
STEP 2 - OAuthアプリを設定する
攻撃者は、利用者にアクセス許可を要求するOAuthアプリを登録し、エージェントの認証に関連付けます。要求する権限は攻撃対象や同意ポリシーによって異なります。
STEP 3 - 正規のMicrosoftドメインのリンクを配布する
攻撃者はエージェントへのリンクをメールやTeamsなどで配ります。リンクは `copilotstudio.microsoft.com` を使うため、正規のMicrosoftサービスであることだけでは危険性を判断できません。
STEP 4 - サインイン後にトークンを窃取する
利用者が正規の認証画面でアクセス許可に同意し、認証を完了すると、エージェントにアクセストークンが渡ります。Datadogの検証では、サインイントピックへ追加されたHTTPアクションにより、トークンが外部へ転送されました。
つまり、利用者のブラウザーから攻撃者のサーバーへ直接通信しなくても、クラウド側の処理でトークンが流出し得るのです。
4. なぜURL確認やMFAだけでは防ぎきれないのか?
「MicrosoftのURLを確認した」「多要素認証(MFA)を有効にした」——どちらも大切な対策です。しかしCoPhishでは、それだけでは不十分な場合があります。
| 従来の対策 | CoPhishで残るリスク |
| URL・ドメイン確認 | Microsoftの正規ドメイン上でも悪意あるエージェントが動作し得る |
| HTTPS・証明書確認 | 通信相手の真正性と、アプリに与える権限の安全性は別問題 |
| MFA | 正規の認証完了後にトークンが悪用される可能性がある |
| 端末の通信監視 | クラウドサービス側から行われるトークン転送は端末に現れない場合がある |
これらの対策が無意味になったわけではありません。**URLやMFAに加えて、アプリへの同意と付与権限を管理する必要がある**ということです。
5. 特に注意したい管理者アカウント
Datadogは、一般ユーザーと、Application Administratorなどの管理者を狙うシナリオを説明しています。
| 対象 | 攻撃で問題になる条件 | 特に必要な対策 |
| 一般ユーザー | 組織の同意ポリシーで許される範囲の権限を、不正なアプリへ許可してしまう | ユーザー同意ポリシーとアプリ登録の制御 |
| アプリケーション管理者など | ロールで許可された広範なアプリ同意権限を悪用される | 管理者ロールの最小化、PIM、管理者への注意喚起 |
管理者であっても、無条件にすべてのデータへアクセスできるわけではありません。影響範囲は付与された委任権限などに左右されますが、高権限の利用者による不用意な同意は、被害を大きくする可能性があります。
6. まず取り組みたい3つの対策
対策① アプリへの同意を制限する
Microsoft Entra IDで、一般ユーザーがアプリに同意できる条件を確認してください。必要に応じて、組織の業務とリスクに合わせた同意ポリシーを設定し、管理者による同意申請・審査の仕組みを整えます。
Microsoftの管理対象ポリシーや既定値は更新される場合があります。実際にテナントへ適用されている設定を確認することが大切です。
対策② 管理者ロールを最小限にする
Application AdministratorやCloud Application Administratorなどのロールを棚卸しし、必要な人だけに割り当てます。Microsoft Entra Privileged Identity Management(PIM)で必要なときだけ権限を有効にする運用も検討しましょう。
対策③ アプリ同意とエージェント変更を監視する
不審なアプリへの同意やCopilot Studioエージェントの変更を監視し、必要な場合に調査できる状態にします。
| 監視対象 | 主なログ・イベント |
| アプリへの同意 | Entra ID監査ログ:`Consent to application` |
| エージェントの作成 | Microsoft Purview監査:`BotCreate` |
| エージェントの変更 | Microsoft Purview監査:`BotComponentUpdate` |
| サインイントピックの変更 | `BotComponentUpdate`の対象に`*.topic.Signin`が含まれるか確認 |
ログで利用できる操作名・項目・保存期間は、製品の更新、ライセンス、監査設定などに依存します。イベントが記録されたという事実だけで攻撃と断定せず、操作した利用者・アプリ・権限・変更内容を合わせて調査してください。
7. 管理者向け:Microsoft Entra IDでの確認ポイント
ユーザー同意設定
Microsoft Entra管理センターにサインインし、Entra ID → エンタープライズ アプリケーション → 同意とアクセス許可 → ユーザー同意設定を開きます。
確認するポイントは、ユーザー同意が許可されている条件、対象アプリの発行元、許可される権限の範囲です。画面名や項目は更新で変わる場合があります。
- 管理者の同意ワークフロー
同じ「同意とアクセス許可」から管理者の同意設定を確認します。一般ユーザーからの申請を誰が審査するか、どう判断するかも運用として決めましょう。
- 不審なアプリへの同意が見つかったら
- 対象アプリと許可された権限、同意を行ったユーザーを確認する。
- 不正な同意や権限付与を取り消し、必要に応じてアプリを無効化する。
- 関連セッションの取り消しなどを検討する。ただし、発行済みアクセストークンが即時にすべて無効になるとは限らない。
- Microsoft 365およびEntra IDのログで、メール・ファイル等への不審なアクセスがなかったか調査する。
パスワードの変更だけでは、悪意あるアプリへの同意が自動的に削除されるわけではありません。
8. まとめ:守るべきものは「AIに渡す権限」
CoPhishが示したのは、「Microsoftの正規サービス上にある」ことと「そのアプリが安全である」ことは別という点です。
Copilot Studioそのものに必ずしも脆弱性があるという話ではありません。柔軟なエージェント作成機能とOAuth認証の仕組みを攻撃者が悪用することが問題です。
企業では、まず次の3点を確認しましょう。
- ユーザー同意ポリシーは自社のリスクに合っているか。
- 高権限ロールを必要最小限にできているか。
- 不審なアプリ同意の監視・対応手順が整っているか。
AIエージェントの利用が広がる今こそ、「どのサービスか」に加えて、「誰が作ったエージェントへ、どんな権限を渡しているか」を確認することが重要です。
執筆者プロフィール
くもぐもねこ W・J | Azure エンジニア
- Azureを中心に、インフラ、AI、セキュリティ領域の技術支援に従事しています。
- Microsoft Azure、セキュリティなどの技術情報について、実際の検証結果や導入・運用で得た知見を交えながら、お客様の課題解決に役立つ情報を発信しています。