Microsoft 365のカレンダーやメールをAIエージェントに接続している開発者に向けて、実際の攻撃手口から学べる設定確認のポイントを整理します。AIコーディングツールやMCP（Model Context Protocol、AIエージェントが外部サービスと連携するための標準規格）でMicrosoft Graph APIを触っている方は、他人事ではない内容です。
2026年7月20日、セキュリティ企業のGroup-IBが「HollowGraph」という新しいスパイウェアを公表しました。侵害済みのMicrosoft 365メールボックスを乗っ取り、カレンダーの予定を隠れたC2チャネル（Command and Control、攻撃者が遠隔操作の指示をやり取りする通信路）として使う仕組みです。少なくとも12台のシステムが感染し、うち3台が2026年6月3日から7月9日にかけて攻撃者と実際に通信していたと報告されています。
何が起きているのか
HollowGraphは軽量な.NET製DLLで、対応コマンドはGETとSENDの2つだけです。攻撃者は2050年5月13日という遠い未来の日付でカレンダー予定を作成し、そこに暗号化ファイルを添付します。
マルウェアはカレンダーを検索し、「Event ID: 〈7文字のタスクID〉」という件名の予定を見つけると添付ファイルをダウンロードします。復号にはRSAとAES-256-GCMを組み合わせたハイブリッド暗号方式を使い、受信用と送信用で鍵ペアを分けている点が特徴です。
窃取したデータは「Boss{..}ID{..}」という件名の新規カレンダー予定として、攻撃者の公開鍵で暗号化してアップロードされます。これが「デッドドロップ（dead drop、直接接触せずに情報を受け渡す諜報手法）」と呼ばれる仕組みで、遠い未来の日付にすることでメールボックスの所有者が偶然見つける可能性を最小化しています。
さらに厄介なのは、通信経路がすべてMicrosoft Graph API（Microsoft 365のデータをプログラムから操作するための公式API）を通る点です。攻撃者専用の外部サーバーへの通信ではないため、宛先ベースで攻撃を検知する従来型のネットワーク監視では引っかかりません。
加えてDNSトンネリング（本来は名前解決用のDNS通信にデータを埋め込んで隠す手法）を使い、cloudlanecdn[.]comというドメインへのIPv6 AAAAレコード（IPv6アドレスを返すDNSレコード）問い合わせから14バイトずつペイロードを組み立て、Microsoft Entra ID（旧Azure AD）の認証情報を更新するlogAzure.txtという一見ログファイルに書き込みます。Group-IBはCavernというバックドアフレームワークとの関連性を高い確度で指摘しています。
なぜこの手口が刺さるのか
原因を分解すると3つの層があります。
第一に、Microsoft Graph APIのトラフィックは正規の企業利用と見分けがつきません。カレンダー操作やメール添付ファイルのアップロードは、Teams連携やOutlook拡張機能でも日常的に発生する操作です。
第二に、OAuthアプリの権限管理が緩い環境では、不審なクライアントアプリがメールボックスやカレンダーへの読み書き権限を持っていても気づかれにくい構造があります。攻撃者はこの隙を突いて、正規のAPI経由でC2を成立させています。
第三に、AI開発の現場ではMCPサーバー経由でMicrosoft 365と連携するケースが増えています。Claude DesktopやCursorなどのAIツールからGraph APIにアクセスするMCPサーバーを導入すると、そのアプリ自身が広いスコープ（アクセス権限の範囲）を要求しがちで、審査が甘いまま本番運用に入ってしまう懸念があります。
自分の環境が該当するか確認する
まず、Microsoft 365テナントでOAuthアプリの登録状況を洗い出します。
# Microsoft Graph PowerShell SDKを使った例
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -All | Select-Object DisplayName, AppId, Homepage出力の中に、把握していない名前のアプリや、公開先が不明なものがないか確認してください。とくにMCPサーバーやAI連携ツールを社内で自作・導入している場合、そのアプリ登録が該当します。
次に、そのアプリが持つ権限スコープを確認します。Calendars.ReadWriteやMail.ReadWriteのような広い権限を要求していないか、Azureポータルの「エンタープライズアプリケーション」→「権限」画面で確認できます。
MCPサーバーの設定ファイル（claude_desktop_config.jsonや.mcp.jsonなど）を使っている場合は、そこに記載されたクライアントIDと、実際にAzure ADへ登録済みのアプリを突き合わせてください。設定ファイルに書かれた権限と、Azure側で実際に許可された権限が一致していないケースは意外とあります。
監査ログの確認も重要です。Microsoft Purview監査ログ（旧Office 365監査ログ）で、アプリケーション経由のカレンダー作成イベントを検索し、日付が極端に未来のものや、件名が不自然なパターンを含むものを探します。
# Microsoft 365 Defender advanced huntingの例（KQL）
CloudAppEvents
| where ActionType == "CalendarEventCreated" or ActionType == "CalendarEventUpdated"
| where Timestamp > ago(30d)
| where AppDisplayName != "Outlook" and AppDisplayName != "Teams"このクエリで、Outlookや Teams以外のアプリ名で作成されたカレンダーイベントが多数出てくる場合、そのアプリの正体を確認する必要があります。
対策の手順
条件付きアクセスポリシー（Conditional Access、特定の条件下でのみアクセスを許可する仕組み）を使い、承認済み発行元以外のOAuthアプリ登録を制限します。Azure AD管理センターの「条件付きアクセス」→「アプリの制御」から設定できます。
MCPサーバーやAI連携ツールを導入する際は、要求スコープを最小権限に絞ります。カレンダー閲覧だけで十分な用途にCalendars.ReadWriteを許可しない、といった具体的な見直しが有効です。
Graph APIのアプリ権限を定期的に棚卸しします。四半期ごとにGet-MgServicePrincipalとGet-MgOAuth2PermissionGrantを実行し、不要になったアプリの権限を取り消す運用を組み込むと良いです。
外部宛のDNSクエリ、とくにAAAAレコードの異常な問い合わせパターンを監視対象に加えます。SIEM（Security Information and Event Management、ログを集約して脅威を検知するシステム）側でIPv6 AAAAクエリのボリュームや宛先ドメインの新規性をルール化しておくと、DNSトンネリングの兆候を捉えやすくなります。
導入前に確認すること
Microsoft 365とAIエージェントを連携させる構成は、開発効率を大きく上げる一方で、OAuthアプリの権限が想定より広くなりがちです。
新しいMCPサーバーや連携ツールを導入する前に、要求スコープをAzureポータルで一度確認する習慣をつけてください。
既存の連携についても、Get-MgServicePrincipalでの棚卸しと監査ログのクエリを月次で回すだけで、不審なアプリの早期発見につながります。
信頼できるクラウドAPIだからこそ、攻撃者に悪用されたときの発見が遅れます。権限の最小化と定期的な確認を、開発フローの一部として組み込んでおくことが現実的な備えになります。