Microsoft CopilotをはじめとするAIワークフローの急速な普及に伴い、セキュリティチームは新たな課題に直面しています。それが、自律型・支援型エージェントの行動追跡です。
Microsoft Entra IDでは、アシスタントエージェントはOn-Behalf-Of（OBO）フローを使用し、データ分析やメール生成など、サインイン中のユーザーに代わってタスクを実行します。
これらのエージェントは潜在的な被害を最小限に抑えるために委任された権限で動作しますが、それでも操作されるリスクがないわけではありません。
攻撃者がエージェントを侵害した場合、正規のユーザー活動に溶け込む形で悪意ある操作を実行される恐れがあります。
OAuthフローやエージェント権限を標的とする攻撃者が増加している昨今、Entra IDログでこうした挙動を追跡する方法を理解することは、現代の脅威検知において不可欠です。
アシスタントエージェントに代理実行の権限を付与するには、ユーザーがエージェントの基盤となるブループリント・プリンシパルの「access_agent」スコープへの同意を行う必要があります。
攻撃者はこのフェーズを狙うことが多く、ローカルホストへのリダイレクトを悪用して認可コードを横取りする「ConsentFix」などの手法が使われるケースもあります。
同意が与えられると、エージェントの認可範囲はエージェント自身の権限とユーザーに割り当てられたロールの積集合となります。
現実的な脅威シナリオとして、次のような状況が考えられます。アシスタントエージェントが社員になりすまし、「請求書をお送りします」という件名の不審なメールを外部アドレスに送信するケースです。
Microsoft Purview Exchangeのログを最初に確認すると、基本的な情報は把握できます。エージェントのIDや、なりすまし対象のユーザー、操作の種類、送信先といった情報がログに記録されています。
Red Canaryの調査によると、悪意ある活動の真の発信元を特定する鍵となるのは、イベントの慎重な相関分析です。
最初のPurviewログからUniqueTokenIdとClientRequestIdを抽出し、Microsoft Graph Activity Logsとクロスリファレンスすることで、より深い分析が可能になります。
この重要なステップにより、MicrosoftのプロキシIPを迂回して、POSTリクエストの開始に使われた攻撃者の実際のIPアドレス、ユーザーエージェント文字列、フィッシングメールの送信に使用されたGraph APIエンドポイント（microsoft.graph.sendMail）が明らかになります。
真のネットワーク指標が特定できたら、次にエージェントの正確なIDを検証する必要があります。トークンIDをEntra IDの非インタラクティブユーザーサインインログと照合することで、認証の正確な性質を確認できます。
Microsoftは認証フローを明示的に示す単一のフィールドを提供していないため、アナリストは特定のログ属性から推測する必要があります。
この特定の属性の組み合わせにより、エージェントIDが人間のユーザーに代わって動作するためのトークンを受け取り、Mail.SendやMail.ReadWriteなどの付与されたOAuthスコープを使用したことが証明されます。
AIエージェントが企業インフラに深く統合されていく中、防御側はこれらの新しいIDタイプを追跡するために、脅威ハンティングの戦略を適応させていく必要があります。
自律型エージェント、エージェント専用のユーザーアカウント、アシスタントのOBOフローのいずれを調査する場合でも、セキュリティチームは単一のデータポイントだけに頼ることはできません。
不審なアシスタントエージェントの挙動を確実に検出するには、ExchangeデータとGraph APIアクティビティ、非インタラクティブサインインを相関分析し、AIを利用した攻撃の全体像を把握することが不可欠です。
翻訳元: https://cyberpress.org/entra-logs-flag-agents/
