Microsoft 365が乗っ取られる パスワードを盗まない「EvilTokens」の手口：「本物のMicrosoft画面」がワナに
セキュリティベンダーのESETは、Microsoft 365を標的とするPhaaS「EvilTokens」に関する情報を公式ブログ「WeLiveSecurity」で公開した。本稿は、Microsoftの正規認証機能を悪用する仕組みや対策を紹介する。
フィッシング攻撃と聞くと、多くの人は「偽のログイン画面でIDやパスワードを入力させる手口」を思い浮かべる。しかし、そうした常識が通用しない新たな攻撃が確認されている。
セキュリティベンダーのESETは2026年6月15日、同社の公式ブログ「WeLiveSecurity」で、Microsoft 365を標的としたPhaaS（Phishing as a Service：サービスとして提供されるフィッシングツール）「EvilTokens」に関する情報を公開した。
EvilTokensは、Microsoftの正規認証機能を悪用してアカウントを乗っ取る。その最大の特徴は、パスワードを盗まないことだ。
ユーザーは本物のMicrosoft認証ページでログインし、多要素認証（MFA）まで完了する。しかし、その認証は自分の端末ではなく、攻撃者のセッションを承認するために使われている。このため、従来の「偽サイトを見分ける」「URLを確認する」といった対策だけでは防ぎにくい。本稿は、Microsoftの正規認証機能を悪用する仕組みを紹介する。
Microsoftの正規認証機能を悪用する仕組み
EvilTokensが悪用するのは、認証プロトコル「OAuth 2.0」の「Device Authorization Grant」（デバイスコード認証フロー）だ。
本来、この仕組みはスマートテレビやプリンタなど、キーボード入力が難しい機器向けに設計されたものだ。利用者は別の端末からMicrosoftの認証ページへアクセスし、表示された短いコードを入力して認証を完了させる。するとMicrosoftは、その機器へアクセストークンを発行する。
EvilTokensは、この仕組みを逆手に取るものだ。
攻撃者はまず、自身のセッション用のデバイスコードをMicrosoftから取得する。その後、請求書や共有ドキュメント、カレンダー招待、SharePointアクセス要求などを装ったメールを送り、「内容を確認するには認証してください」とユーザーを誘導する。
ユーザーがリンクをクリックすると、画面にはMicrosoftへのログインを促す案内とデバイスコードが表示される。ここで重要なのは、そのコードは攻撃者側のセッションに対応しているという点である。
ユーザーは本物のMicrosoftサイトでログインし、MFAも完了する。しかし、その結果としてMicrosoftが発行するアクセストークンは攻撃者側へ渡るため、攻撃者は正規ユーザーとしてMicrosoft 365環境へアクセスできる。
なぜMFAを導入していても防げないのか
近年、多くの企業はパスワード漏えい対策としてMFAを導入している。しかし、EvilTokensではMFAそのものを突破している訳ではない。
攻撃者は技術的にMFAを無効化するのではなく、利用者自身に攻撃者のセッションを承認させているのである。
そのため、以下の状態になる。
- パスワードは盗まれていない
- 偽のMicrosoftログイン画面も使われない
- Microsoftから見れば正常な認証に見える
従来のフィッシング対策教育では、「URLを確認する」「スペルミスを探す」「偽サイトに注意する」といった内容が中心だった。しかしEvilTokensでは、ログイン画面そのものが本物であるため、これらの確認だけでは十分ではない。
攻撃成功後に狙われるもの
攻撃者がアクセストークンを取得すると、企業のMicrosoft 365環境へアクセスできる可能性がある。
さらに、取得した情報を利用して取引先とのメールを悪用するBEC（ビジネスメール詐欺）や、機密情報の窃取、社内でのさらなる侵害活動につながる恐れがある。
特に経理、人事、物流、営業部門のアカウントは、送金指示や契約情報などを扱うことから、攻撃対象になりやすいと考えられる。
情シスが取るべき対策は5つ
EvilTokensへの対策では、「リンクを確認する」だけでは不十分だ。認証そのものの文脈を確認する運用が重要になる。
対策1．突然のデバイスコード要求を疑う
請求書や文書閲覧のためにデバイスコード入力を求められるという挙動は通常みられないものだ。予期しない要求は不審なものとして扱う。
対策2．認証ページではなく「何を承認しているか」を確認する
本物のMicrosoftページだから安全とは限らない。どのアプリケーションに対する認証なのか、自分自身が開始した操作なのかを確認する必要がある。
対策3．不要なデバイスコード認証を制限する
企業側では、利用実態がない場合はデバイスコード認証フロー自体を制限・無効化し、必要な利用者や端末のみに限定することが望ましい。
対策4．異常な認証ログを監視する
見慣れない端末からのアクセス、不審なデバイスコード認証、新しい受信トレイルールの作成、不自然なトークン利用などは侵害の兆候となる可能性がある。
対策5．フィッシング教育をアップデートする
「偽サイトにパスワードを入力してはいけない」という従来型の教育だけでは十分ではない。現代のフィッシングでは、本物のサイトで本物の認証を実施させ、その結果を攻撃者が悪用するケースが存在することを従業員に周知する必要がある。
「本物だから安全」という常識が通用しない
EvilTokensは、認証情報を盗むのではなく、利用者自身に攻撃者の認証を成立させてもらう攻撃だ。「Microsoftの正規ページだから安心」「MFAを導入しているから安全」という従来の前提が崩れつつあるということが分かる。
情シスに求められるのは、URLや画面の真偽だけでなく、「その認証は誰のために行われているのか」という視点で認証プロセス全体を管理・教育することとなる。
Copyright © ITmedia, Inc. All Rights Reserved.