カレンダー招待を悪用するフィッシングが急増——「予定表」という盲点が、MFAとSaaSの防波堤を越えてきます

今日の深掘りポイント

• 招待が自動で予定表に“載る”設計が、信頼の踏み台になります。受諾前でも視野に入るUIがクリック率を押し上げます。
• GoogleやMicrosoftなどの正規カレンダー／会議基盤を“配送路”に使うことで、従来のメール中心のフィルタやユーザー教育を迂回します。
• 認証情報窃取が起点でも、AiTM（Adversary-in-the-Middle）でセッションクッキーを盗られるとMFAを越えやすくなります。
• 即応すべきは設定と検知です。自動追加の抑制、外部招待のポリシー化、リンク保護の適用範囲見直し、UEBAでの“いつもと違う招待”の可視化が効きます。
• 新規性は高くない一方で、今は「当たる面」が広い局面です。SaaS依存とリモートワークの常態化が、攻撃者の費用対効果を押し上げています。

はじめに

メール本文のリンクや添付を疑う習慣は広がりましたが、カレンダーに出る会議や更新通知は「仕事の延長」として素通りされがちです。今回取り上げるのは、GoogleやMicrosoftのカレンダー招待を悪用して、偽ログインに誘導する“招待フィッシング”の急増です。手法自体は新しくありません。しかし、SaaS全面化と予定表ベースの働き方が進んだいま、攻撃の実効性が一段と高まっています。編集部としては、ここを「メール対策の延長」ではなく、予定表という別のUX面で考え直すべきだと見ています。

参考として、英紙の報道もこの急増を取り上げています。Google/Microsoft/PayPalなどのブランドを装った“会議/更新”招待が自動的にユーザーの予定表へ入り、偽のログインページへ誘導されるという構図です。詳細は末尾の参考情報をご覧ください。

深掘り詳細

いま何が起きているか（事実の整理）

• 攻撃者は、正規のカレンダー/会議プラットフォーム経由の招待を送付し、ユーザーの予定表に“自動表示”される仕様を突きます。ユーザーが受諾しなくても「仮」や「保留」で見える状態が発生し、通知も飛びます。
• 招待の本文や場所欄、説明欄に、サービス更新やアカウント保護を装ったURLを埋め込み、偽のログインページ（Credential Harvesting）へ誘導します。
• 招待の送信元や配信経路が正規サービスに見えること、メール本文よりも警戒心が下がりやすいUIコンテキストで提示されることが、クリック率を押し上げます。
• 報道でも、GoogleやMicrosoftのカレンダー招待などが悪用され、偽のログインページに誘導される事案の増加が指摘されています（出典は参考情報参照）です。

注記: 「前年比200%増」などの数値は、一次データを突き合わせない限り断定しない前提で扱うべきです。複数の報告が“急増”を示唆する段階で、SOCとしては事実ベースの自組織テレメトリ（招待の流量、外部ドメイン比率、クリック率、誤受諾率）をまず整備することをおすすめします。

なぜ効くのか（編集部の視点と示唆）

• 信頼の転移が起きます。予定表は「自分の内側の空間」と心理的に捉えられがちで、そこに表示されるカード（会議や更新）は“許可済み情報”だと錯覚しやすいです。攻撃は、このUIバイアスを突いています。
• メールセキュリティの死角です。多くの組織はメール本文のURL/添付対策を強化してきましたが、text/calendar（ICS）や会議基盤経由の通知面まで同等の検査・ラベル・バナー適用が徹底されていません。結果、網目をくぐられます。
• 攻撃の費用対効果が高まっています。SaaSログインが企業資産の“関所”になったことで、1アカウントの窃取価値が上がりました。さらにAiTMプロキシでセッションクッキーを奪えばMFAも相対化できます。攻撃者は“少ない工数で広い面”を狙える状態です。
• 運用レイヤの遅れです。予定表の自動追加や外部招待の既定動作は利便重視で設計されています。リモートワーク常態化後の脅威モデルに照らし、ここを“意図的に不便”へ寄せ直す再設計が、まだ十分に進んでいません。

脅威シナリオと影響

以下は、編集部が想定する代表的シナリオと、MITRE ATT&CKの対応仮説です。現場での観測に応じて適宜読み替えてください。

• シナリオ1: 招待リンク経由の認証情報窃取からのBEC

  • 流れ: 外部招待（会議/更新通知）→ カレンダー表示/通知 → 偽ログイン（ブランド偽装）→ 資格情報入力 → メール規則改ざん・社内なりすまし → 送金指示/請求書改ざん
  • ATT&CK仮説:
    • T1566.003 Spearphishing via Service（正規カレンダー/会議サービス経由）
    • T1566.002 Spearphishing Link（招待本文のURL）
    • T1204 User Execution（ユーザーのリンク実行）
    • T1078 Valid Accounts（窃取済みアカウントの悪用）

• シナリオ2: AiTMによるMFA迂回とSaaS横断侵害

  • 流れ: 招待リンク → AiTMプロキシ（Evilginx等を仮定） → 認証通過と同時にセッションクッキー窃取 → Exchange/Drive/SharePoint/Teams/Meetなどへ横展開 → データ窃取/権限拡大
  • ATT&CK仮説:
    • T1566.002/T1566.003（初動）
    • T1557 Adversary-in-the-Middle（Web経路での中間者）
    • T1539 Steal Web Session Cookie（セッションクッキー窃取）
    • T1078 Valid Accounts（セッション/資格の再利用）

• シナリオ3: OAuth同意の悪用（仮説）

  • 流れ: 招待説明欄のリンク → 偽アプリの同意フローへ誘導 → メール/ファイルへの継続アクセス権を取得 → アカウントパスワード変更なしで持続化
  • ATT&CK仮説:
    • T1566.002/T1566.003（初動）
    • T1528 Steal Application Access Token（またはIllicit Consent Grant相当のクラウドTTP群）
    • T1098 Account Discovery（取得権限の範囲探索）
  • 注記: 実際の技術IDはクラウドプロバイダとフローにより揺れます。自組織のクラウドATT&CKマッピングに合わせて精緻化してください。

影響面の要点

• エグゼクティブや財務/購買周辺は予定表依存度が高く、秘書や委任設定も絡むため、なりすましと業務フローの乗っ取りが起きやすいです。
• セッションクッキー窃取が成立すると、メールのフォワードルール監視やパスワード変更だけでは封じ込めが不十分になります。トークン失効や全セッションの取り消し、条件付きアクセスでのリカバリが必要になります。
• リモートワークで私物端末からの予定表閲覧や通知タップが混在する環境では、MDM/ブラウザ制御の外側で初動が成立する確率が上がります。

セキュリティ担当者のアクション

“メール対策の延長”ではなく、“予定表/会議の面”として設計し直すことを基本方針に置きます。

• 48時間以内（即応）

  • 重要ロール（経営層・財務・人事・IT管理者・購買）のカレンダー設定を一括見直しします。
    • Googleカレンダー: 「招待状の自動追加」を“返信した招待のみ表示”へ。Gmailからのイベント自動作成もオフへする運用を検討します。
    • Microsoft 365: Outlook/OWAの自動処理設定を確認し、外部からの会議出席依頼が自動で予定表に仮登録されないように既定を見直します。
    • 注記: 実装はテナント/ポリシー単位で差異があります。変更は影響範囲と業務合意を取りつつ段階適用が望ましいです。
  • リンク保護の適用範囲を再点検します。メール本文だけでなく、text/calendar（ICS）や会議招待本文・説明欄のURLにもSafe Links等のリアルタイム判定を適用できているかを確認します。
  • セキュリティ意識付けの“追加版”を短報で即日配信します。予定表通知に含まれる“アカウント更新・決済確認・MFA再登録”は直リンクせず、ブックマークや公式アプリから入り直す行動を徹底します。

• 7日以内（短期）

  • 外部招待のポリシー化:
    • “組織外からの初回招待はデフォルト非表示＋メールで要承認”などの内規を作り、対象ロールから段階的に広げます。
    • メールゲートウェイ/SEGで、外部からのtext/calendarに含まれるURLへリライト・サンドボックス評価を適用します。
  • 検知の整備:
    • UEBAで「外部送信者からの招待を短時間に複数受信」「同一外部ドメインから高密度に招待到来」「招待のURLクリック後、短時間で認証が複数失敗→成功」という時系列シグナルをルール化します。
    • IdPのシグナル（不審なサインイン・新しい国/ASN・短時間の移動・異常なトークン寿命）と突合します。成功時も“いつもと違う”を拾うのが肝です。
  • インシデント対応プレイブックの追加:
    • 入口が“カレンダー招待”であるケースを明示し、セッショントークン失効、OAuth同意の取り消し、メール転送/受信トレイル確認、外部連絡先の改ざん確認までを標準化します。

• 30日以内（中期）

  • バナー/ラベルの統一設計: 予定表/会議招待にもメールと同一デザインの「外部」「新規ドメイン」「未承認アプリ」バナーを付け、UI上の“異質”を可視化します。
  • ドメイン年齢やレピュテーションを用いた“新生ドメイン遮断”を、メールと同様に招待経路にも適用します（会議URL、説明欄URL）。
  • 条件付きアクセスの強化: 高リスクサインイン時のFIDO2限定やデバイス準拠必須、MFAナンバーマッチングの徹底、サインイン後の継続的評価（CAE）を有効化します。

• 運用KPI（測り続ける指標）

  • 外部からのカレンダー招待総数、うち新規ドメイン比率
  • 招待由来URLのクリック率、サンドボックス判定の陽性率
  • 不審サインイン検知からセッション失効までの平均時間
  • 重要ロールの設定準拠率（自動追加オフ・リンク保護適用）

• トレーニングの一点突破メッセージ

  • 「予定表の“会議/更新リンク”からログインしない。公式ブックマークから入り直す」——これを一枚絵で全社に浸透させます。

• 注意すべき落とし穴

  • 自動追加を全面停止すると業務摩擦が大きいです。高リスク部門→全社の順で段階適用し、代替の“承認付きワンクリック登録”を併設します。
  • ICSを全面ブロックする運用も現実的ではありません。URLのみを動的評価し、既知安全ドメインは許容する「段階的検査」を設計します。

参考情報

• The Guardian: Calendar phishing scams surge, luring users to fake login pages via auto-added invites（2026-10-11報道）: https://www.theguardian.com/money/2026/oct/11/calendar-phishing-scam-meeting-renewal-google-microsoft-paypal

注記: 一次情報やベンダーの設定ドキュメントは各環境で最新を確認のうえ適用してください。本文のMITRE ATT&CKのID対応は編集部の仮説であり、自組織のテレメトリと照らして精緻化することを推奨します。今の局面は新奇性より“即応性”が価値を持つ段階です。予定表という盲点を、今日から“守る面”に変えていくことが肝要です。