- 今回のフィッシングキャンペーンでは、偽のTeams通知を使って被害者を本物のMicrosoftサインインページへと誘導していました
- 攻撃者はパスワードを盗む代わりに、攻撃者が管理するアプリへの権限承認を被害者に求め、MFAを突破することなくメール、ファイル、Teams、SharePoint、OneDrive、カレンダーへのアクセス権を手に入れていました
- Check Pointによれば、この手口は2026年に商用化され、レンタル可能なサービスとして提供されるようになっています。現実的な防御策は、ユーザーに偽物を見抜かせることではなく、アプリの同意権限を制限することです
2026年6月下旬から7月にかけて展開されたあるフィッシングキャンペーンは、各組織がこの10年間かけて社員に教え込んできたアドバイスの大半を無効にするようなものでした。被害者を本物のMicrosoftログインページへと誘導していたのです。
Check Pointのメール調査チームは、このキャンペーンを公表し、世界中の約120組織のユーザーを標的とした200件以上のフィッシングメールを確認したと発表しました。
誘い文句は偽のMicrosoft Teams通知でしたが、誘導先は本物でした。実際にアカウントを侵害していたのは盗まれたパスワードではなく、被害者自身が自らクリックして承認してしまった権限付与のプロンプトだったのです。
ユーザーを騙して権限を付与させる巧妙な攻撃
Check Pointは今回の報告書の中で、実際にアカウントを侵害していたのは盗まれたパスワードではなく、被害者が自ら進んでクリックしてしまった権限付与のプロンプトだったと指摘しています。これは攻撃者の手口における明確な変化を物語っています。攻撃者はもはやMicrosoftの正面玄関を偽造するのではなく、そこを堂々と通り抜けるようになったのです。
このメールは、Microsoft Plannerのタスク割り当て通知を装ったものでした。送信者名は「There’s New Activity On Team」と表示され、件名にはHRがTeamsチャットで3件のメッセージを送信したと書かれており、本文には給与・福利厚生の更新に関する記載と、4件の未処理タスクを示すカウンターが含まれていました。
セキュリティの専門家から見れば、このメッセージには典型的なフィッシングの兆候がいくつも見られました。メール内のすべてのリンク（2つの行動喚起ボタンを含む)が同一のリダイレクト先を経由していたこと。そして、表示されている送信者アドレスが受信者自身の組織のものであり、あたかも本人が自分自身に送ったメールのように見えたことです。
リンクをクリックすると、偽装ドメインではなく、login.microsoftonline.com上の本物のOAuth認可URLが開きました。サインインすると、権限を承認するか、組織を代表して権限を受け入れるかを求めるプロンプトが表示されます。
ユーザーがこれを承認すると、Microsoftはブラウザを、元のリクエストで指定されたリダイレクト先アドレスへと転送します。今回のキャンペーンでは、これは攻撃者が管理するAWS API Gatewayのエンドポイントでした。認可コードはそこへ送られ、攻撃者はそれをアクセス権と交換していました。この過程でパスワードが盗まれることは一切なく、見破るべき偽ページも存在しませんでした。
これはフィッシングサービス「Kali365」プラットフォームがMicrosoftアカウントを侵害する手口とも似ていますが、セッションクッキーやOAuthトークンを盗む代わりに、より恒久的な不正な同意を得る方法を選んでいる点が特徴です。
これは、これまでのセキュリティ教育の常識、つまり「例外に目を光らせるのではなく、通常のルールを守ること」を重視するチェックリストとは正反対の状況を生み出します。ユーザーはURLを確認し、鍵マークを探し、綴りの誤ったドメインに注意するよう教えられてきました。しかし、そもそも偽造されたものが何一つ存在しないため、こうした対策はどれも役に立ちません。ドメインも証明書も紛れもなくMicrosoftのものであり、サインインページも毎朝目にしているのと同じものです。そのため、この特定の攻撃手法を警戒していないユーザーには、誤った安心感を与えてしまいます。
多要素認証(MFA)もここでは役に立ちません。MFAが保護するのはログインの過程だけであり、ログイン後のユーザーデータへのアクセスは保護対象外だからです。攻撃者はパスワードも第二要素も必要とせず、ユーザー自身の正当なセッションから付与されたトークンを持ち去るだけで済みます。この手口は「同意フィッシング(consent phishing)」と呼ばれています。
これを防ぐ方法は数多くありますが、最もシンプルな2つの対策は、ユーザーがクリックするすべての権限・同意画面を必ず確認するよう徹底すること(このフィッシング手口も、結局のところユーザー自身の承認が必要です)、そしてシステム管理者レベルでMicrosoft Entra経由でアプリケーションが要求できるユーザーアカウントの権限を制限することです。
Check Pointは、今回のキャンペーンの基盤となった技術自体は今後もなくならないとしつつ、このキャンペーン自体はすでに活動を停止していると指摘していますが、それでも少なくとも後者の対策は講じておくのが賢明でしょう。
