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や画面の真偽だけでなく、「その認証は誰のために行われているのか」という視点で認証プロセス全体を管理・教育することとなる。