「正規の認証画面」を踏み台にする攻撃が急増中

フィッシング対策の常識として「変なリンクは踏まない」「URLをよく確認する」と言われ続けてきた。しかしいま急増しているデバイスコードフィッシング（Device Code Phishing）は、その常識が通用しない。被害者が踏む先は本物のMicrosoftサインインページだからだ。

セキュリティリサーチ企業のPush Securityが発表したレポートによれば、このタイプの攻撃は今年に入ってから37.5倍に急増している。3月初頭の時点で15倍に達していたところ、わずか1ヶ月足らずでさらに跳ね上がった計算だ。

攻撃の仕組み——OAuth 2.0のデバイス認可フローとは

まず攻撃の流れを整理しておこう。

OAuth 2.0には「デバイス認可グラント（Device Authorization Grant）」と呼ばれるフローがある。これはスマートテレビやプリンター、IoT機器のようにキーボード入力がしにくいデバイスが認証を行うために設計されたものだ。

  • デバイスが認証サーバーにリクエストを送り、「ユーザーコード」を受け取る
  • ユーザーが別のデバイス（スマホやPCなど）でそのコードを入力する
  • 認証が完了すると、元のデバイスにアクセストークンが発行される

攻撃者はこのフローを悪用する。

  • 攻撃者がMicrosoftに対してデバイス認可リクエストを送り、ユーザーコードを取得する
  • そのコードをメールやチャットで被害者に送りつけ、「認証のため入力してください」と指示する
  • 被害者は本物の microsoft.com/devicelogin でコードを入力してサインインする
  • 攻撃者の「デバイス」に有効なアクセストークンと更新トークンが渡される

URLは正規のもの、認証もMFAを経由する場合がある——それでも乗っ取られる。これが従来型のフィッシング対策では防ぎきれない理由だ。

PhaaS化が加速——11種類ものフィッシングキットが確認

今回のレポートで特に深刻なのが、このテクニックの「商品化」だ。かつては国家系ハッカーや高度な攻撃者しか使いこなせなかったデバイスコードフィッシングが、今や初心者でも使えるPhaaS（Phishing as a Service）キットとして流通している。

最も主要なキットはEvilTokens。DocuSign・Office 365・SharePointなどのSaaS偽装ページを備え、アンチボット保護や回転するAPIエンドポイントまで実装している完成度だ。

Push Securityが追跡したキットはEvilTokensを含めて11種類に上る。特徴的なものをいくつか挙げると：

  • VENOM — EvilTokensのクローンと見られる閉鎖型PhaaSキット
  • SHAREFILE — Citrix ShareFile偽装で企業ユーザーを狙う
  • DOCUPOLL — GitHub Pages上でDocuSign偽装フローを実行
  • PAPRIKA — AWS S3ホスト。Microsoft 365ブランドにOktaフッターを偽装
  • LINKID — Microsoft TeamsおよびAdobeを偽装したルアーを使用

すべてがSaaS系のブランドを使ったリアルな偽装、クラウドプラットフォームへのホスティング、アンチボット保護を備えている。もはや個人のハッカーがゼロから構築するものではなく、使いやすいSaaSとして提供されている実態がある。

実務への影響——日本のIT管理者が今すぐ確認すべきこと

この攻撃が「うちには関係ない」とは言い切れない。Microsoft 365を使っている組織なら潜在的なターゲットだ。

条件付きアクセスで「デバイスコードフロー」を制限する

Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーで、デバイスコード認証フローをブロックまたは制限できる。IoTデバイスや業務上の必要性がない組織では、このフローを無効化することが最も直接的な対策だ。

FIDO2セキュリティキー・パスキーへの移行を加速する

デバイスコードフィッシングはMFAをバイパスできる場合があるが、FIDO2ベースの認証はフィッシング耐性（Phishing-resistant）があり、このタイプの攻撃に対して有効だ。Entra IDの「認証強度」ポリシーでフィッシング耐性MFAを必須にすることを検討したい。

ユーザー教育のアップデート

「変なリンクを踏まない」だけでは不十分な時代になった。「誰かから渡されたコードを公式サイトに入力する」という行為自体にリスクがあることを、エンドユーザーに伝えておく必要がある。

継続的なトークン監視

攻撃が成功してしまった場合の早期検知のために、Entra IDのサインインログやMicrosoft Sentinelでの異常なトークン発行・利用の監視を設定しておくことも重要だ。

筆者の見解

この攻撃を見て改めて感じるのは、「ゼロトラストは思想だけでなく、実装の細部にまで落とし込まないと意味がない」ということだ。

多くの組織がMFAを導入し、条件付きアクセスを設定し、「ゼロトラスト対応済み」と思っている。しかしデバイスコードフィッシングは、その前提を崩しにかかる。正規の認証フローを悪用するのだから、「信頼できるデバイスかどうか」「このアクセスは本当に意図されたものか」という問いを常に持ち続ける設計が求められる。

日本の大企業では、従来型のネットワーク境界セキュリティとゼロトラスト施策が混在し、複雑怪奇な構成になっているケースをよく目にする。こういった攻撃手法の前では、その「継ぎはぎ」が致命傷になりかねない。

MicrosoftがEntra IDに対してフィッシング耐性MFAや継続的アクセス評価（CAE）といった仕組みを整備してきているのは、正しい方向性だと思っている。あとは各組織がそれを正しく設定・運用できるかどうかの話だ。ツールは揃っている。使いこなせているかが問われている。

PhaaS化によってデバイスコードフィッシングが「大衆化」した今、この攻撃は一部の組織だけが気にすればいい高度な脅威ではなくなった。Microsoft 365を使っているすべての組織の管理者にとって、今週中に確認すべき設定項目として捉えてほしい。

出典: この記事は Device code phishing attacks surge 37x as new kits spread online の内容をもとに、筆者の見解を加えて独自に執筆したものです。