デバイスコードフィッシングが37倍急増 新型キット拡散で企業アカウント乗っ取りが一気に現実化
OAuthの正規認証フローを悪用する「デバイスコードフィッシング」が、2026年に入り急拡大している。しかも注目すべきは、攻撃の巧妙化だけではない。攻撃キットの流通によって、これまで高度な知識を必要としていた手口が、より広い層の攻撃者に使われ始めている点だ。見た目は正規ログイン、入力するのは本物のコード、しかも被害者自身が認証を完了してしまう。この厄介な仕組みを理解しないままでは、従来のフィッシング対策だけでは防ぎきれない。いま企業と個人が知っておくべき脅威の本質を、わかりやすく整理する。
デバイスコードフィッシングとは何か
近年の認証基盤は、IDとパスワードだけでなく、多要素認証やトークン発行を組み合わせた仕組みへと大きく進化している。その一方で、攻撃者もまた、こうした“正しい認証の流れ”そのものを悪用する方向へシフトしている。デバイスコードフィッシングは、その代表例といえる。
この手口で悪用されるのは、OAuth 2.0の「Device Authorization Grant」と呼ばれる仕組みだ。もともとは、キーボード入力がしづらい機器や、ブラウザ操作に制約がある端末向けに設計された便利な認証方式である。たとえば、スマートテレビ、ストリーミング端末、プリンター、IoT機器などで、ユーザーが別の端末からコードを入力して認証を完了する場面を想像するとわかりやすい。
本来は利便性を高めるための仕組みだが、攻撃者はこの流れを逆手に取る。自ら認証要求を発行し、そこで取得したデバイスコードを被害者に送りつけ、何らかの理由をつけて正規のログインページでそのコードを入力させる。そして被害者が認証してしまうと、攻撃者側の端末が正規に承認された状態となり、アクセストークンやリフレッシュトークンを使ってアカウントへ継続的にアクセスできるようになる。
ここが、この手口の非常に危険な点だ。偽のログインページにパスワードを入力させる古典的なフィッシングとは異なり、被害者は本物のページにアクセスしている可能性がある。そのため「URLを確認してください」「本物そっくりの偽サイトに注意してください」といった従来型の啓発だけでは、防御が不十分になりやすい。
なぜ今、急増しているのか
この攻撃手法自体は新しい概念ではない。以前から存在が知られていたが、2026年に入って急激に注目度が高まっている背景には、攻撃の“商品化”がある。つまり、デバイスコードフィッシングを実行するためのキットやサービスが整備され、専門性が高くない攻撃者でも扱いやすくなってきたのだ。
報告では、2026年の初めと比べて、この種のフィッシングページの検出数が37倍以上にまで増加したとされている。短期間でここまで増えるのは、単に手口が優れているからではない。再現性が高く、複数の攻撃グループが横展開しやすい状態になっていることを示している。
サイバー犯罪の世界では、優れた攻撃手法が出てくると、それをテンプレート化し、月額制や招待制のサービスとして売り出す流れが定着している。今回のデバイスコードフィッシングも、まさにその段階に入ったとみるべきだろう。攻撃の敷居が下がることで、対象企業や被害件数は一気に広がる。しかも正規認証を悪用する手口であるため、従来のメールフィルタやURLブロックだけでは見抜きにくい。
攻撃はどのように成立するのか
実際の流れを整理すると、この攻撃は驚くほどシンプルに見える。
まず攻撃者は、対象となるサービスに対してデバイス認証要求を行い、認証用コードを取得する。次に、そのコードを被害者へ送る。このとき、送信手段はメール、チャット、業務連絡、文書共有の通知など、状況に応じてさまざまだ。文面は「ファイル閲覧のために認証が必要」「TeamsやSharePointで共有された資料を開くには確認が必要」「Adobe文書を確認するにはログインが必要」といった、もっともらしい内容になる。
被害者は、その案内に従って正規の認証ページへ移動する。ここで重要なのは、ページそのものが正規である可能性が高い点だ。被害者は警戒を解きやすく、企業のセキュリティ教育でも「正規ドメインなら安心」と誤って受け取っているケースが少なくない。
そして被害者がコードを入力し、自身の認証を完了すると、攻撃者が開始したデバイス認証フローが成立する。結果として、攻撃者は被害者のアカウントに対し、有効なトークンを取得する。ここから先は、メール閲覧、クラウドストレージへのアクセス、社内チャットの監視、追加の詐欺メール送信、内部ネットワークへの足がかりの確保など、被害が広がっていく。
つまり、被害者は「情報を盗まれた」というより、「自分で攻撃者の端末を承認してしまった」状態に近い。この認識のズレこそ、デバイスコードフィッシングの厄介さの核心である。
パスワード窃取型フィッシングとの決定的な違い
一般的なフィッシングとの違いを明確にしておくことは重要だ。通常のフィッシングでは、攻撃者は偽サイトを用意し、ID・パスワード・ワンタイムコードなどを盗み取ろうとする。そのため防御側は、偽サイトのドメイン、SSL証明書、ページのデザインの不自然さなどを手がかりに対処できる。
しかしデバイスコードフィッシングでは、被害者が本物の認証ページで操作してしまうことがある。つまり、見た目やURLの正しさだけでは安全を判断できない。ユーザーは「怪しいURLではなかった」「会社で使っているサービスのログイン画面だった」と感じるため、攻撃を受けた自覚を持ちにくい。
さらに厄介なのは、多要素認証を導入していても被害を防げない場合があることだ。多要素認証は通常、なりすまし防止に有効だが、この手口では被害者本人が正規のフローで認証してしまうため、攻撃者が認証済みのトークンを得られる。つまり、多要素認証があるから安心という単純な話ではなく、認証フロー全体の運用管理が問われる時代に入っている。
攻撃キットの拡散が意味するもの
今回特に見逃せないのは、デバイスコードフィッシングを支援する複数の攻撃キットが確認されている点だ。あるキットが目立っていたとしても、それだけを止めれば解決するわけではない。同種の機能を持つ別のプラットフォームが次々に現れており、市場として成立し始めていることが問題なのである。
こうしたキットは、単にメール文面を量産するだけではない。偽の文書共有通知、チャット風の誘導ページ、クラウドサービス風のUI、ボット対策回避、APIエンドポイントのローテーションなど、運用面までかなり洗練されていることが多い。中には、クラウドの正規サービスや無料ホスティング環境を巧みに使い分け、ブロックされにくい構成を取るものもある。
この状況が意味するのは、攻撃者の参入障壁が下がっているという事実だ。従来なら高度なOAuth理解やインフラ構築能力が必要だったかもしれない。しかしキット化が進むと、攻撃者は「どのブランドを騙るか」「どんな文面で送るか」に集中できるようになる。つまり、技術力よりも営業力に近い形で被害が拡大しやすくなる。
サイバー攻撃が一般化する瞬間は、手法そのものの登場時ではなく、誰でも使えるサービスになった時だ。デバイスコードフィッシングがまさにその局面に入っているとすれば、今後は単発の話題ではなく、企業防御の前提条件として扱わなければならない。
狙われやすいサービスと現場で起きる被害
この手口は、とくにクラウド型の業務サービスとの相性が悪い。メール、ファイル共有、チームコラボレーション、文書承認、SaaS連携など、トークンベースで広く接続される環境ほど、被害が深刻化しやすい。
たとえばメールアカウントが乗っ取られると、攻撃者は社内外のやりとりを把握できるだけでなく、信頼された送信元として追加攻撃を仕掛けられる。経理担当者に請求書差し替えを送ったり、役員になりすまして緊急送金を依頼したり、既存の会話スレッドに返信する形でマルウェアや詐欺リンクを送り込むことも可能になる。
また、ファイル共有やコラボレーションツールへのアクセス権が奪われれば、機密資料、顧客情報、契約書、設計情報などが外部へ流出する危険が高まる。さらに、クラウドサービス間のシングルサインオンや連携設定を起点に、被害が他のシステムへ連鎖する可能性もある。
現場では「アカウントが乗っ取られた」というより、「正規ユーザーの操作に見える不審な活動」として現れることが多い。そのため初動が遅れやすい。特に、ログイン失敗や海外IPからの明白な侵入といった典型的アラートに頼っている企業は、このタイプの異常を見逃しやすい。
企業が今すぐ見直すべき対策
この脅威に対処するには、単に「怪しいメールを開かない」で終わらせない対策が必要だ。まず重要なのは、デバイスコード認証フロー自体を業務上本当に必要としているかを棚卸しすることだ。使っていない、あるいは限定的な用途しかないのであれば、無効化または厳格な制御を検討すべきである。
次に必要なのが、認証ログとトークン発行の監視強化だ。通常と異なる端末、見慣れないアプリケーション、短時間での不自然な認証承認など、パスワード漏えいとは異なる観点での検知ルールを整備する必要がある。特に、ユーザーが自発的に承認したように見える認証イベントを、単純に正常扱いしない視点が求められる。
条件付きアクセスや認証ポリシーの活用も有効だ。場所、デバイス状態、リスクレベル、対象アプリケーションなどに応じて、トークン発行や認証承認を制限できれば、たとえユーザーがコードを入力してしまっても被害の連鎖を食い止めやすい。加えて、リフレッシュトークンのライフサイクル管理や不要なアプリ同意の制御も欠かせない。
利用者教育もアップデートが必要である。これまでの「偽サイトに気をつける」だけでは不十分だ。正規サイトであっても、第三者から送られたコードを入力しない、業務上の文書閲覧のために突然コード入力を求められたら疑う、チャットやメールで届いた認証依頼は別経路で確認する、といった具体的な行動指針まで落とし込まなければならない。
個人ユーザーが気をつけるべき危険サイン
個人レベルでも、この手口は十分に現実的だ。特に、クラウドメール、仕事用アカウント、Microsoft系サービス、文書共有サービスを日常的に使う人は注意したい。
危険サインのひとつは、「コードを入力してください」と急がせる連絡である。ファイル共有、会議参加、セキュリティ確認、請求書確認、本人確認など、もっともらしい理由が添えられていても、第三者から送られてきたコードを正規サイトで入力する行為は非常に危険だ。
また、「URLが本物だから安全」と判断しないことも大切だ。デバイスコードフィッシングでは、ログイン先が正規サイトであること自体が罠になり得る。むしろ、どこから届いた依頼なのか、その認証操作が自分の意図したものなのかを先に確認する必要がある。
少しでも不自然だと感じたら、そのメッセージ内のリンクを使わず、自分で公式サービスを開き、通知や共有依頼の有無を確認したほうが安全だ。会社の案件なら、送信者に別の手段で確認するのがよい。面倒に見えても、そのひと手間がアカウント乗っ取りを防ぐ。
今後の焦点は「正規機能の悪用」への対応
サイバー攻撃は、偽装の精度を高める段階から、正規機能をそのまま利用して防御をすり抜ける段階へ移っている。デバイスコードフィッシングの急増は、その象徴的な出来事といえる。
企業にとっては、認証基盤が複雑化するほど利便性と引き換えに新たな攻撃面が生まれることを意味する。個人にとっては、本物の画面だから安全という常識が崩れつつある。つまり、防御の考え方自体を更新しなければならない。
これから重要になるのは、「何を入力したか」ではなく、「なぜその認証を求められたのか」を問う姿勢だ。正規の認証フローは便利だが、便利であるほど悪用されたときの被害は大きい。攻撃キットの流通によって、この手口は一部の高度な攻撃者だけのものではなくなった。だからこそ今、情シス担当者も現場社員も個人ユーザーも、デバイスコードフィッシングを新しい標準脅威として理解しておく必要がある。
まとめ 37倍急増は一過性ではなく構造変化のサイン
デバイスコードフィッシングが37倍規模で増えているという事実は、単なる流行ではない。正規のOAuth認証フローを悪用し、しかも攻撃キットの普及によって誰でも扱いやすくなったことで、脅威が構造的に拡大していることを示している。
従来のフィッシング対策だけでは、この問題に十分対応できない。正規サイト、正規認証、多要素認証の存在が、かえって安心材料として悪用されるからだ。必要なのは、認証方式の棚卸し、トークン監視、条件付きアクセス、利用者教育の再設計といった、より実務的で多層的な防御である。
今後この手口は、さらに文書共有、チャット通知、業務アプリ連携の文脈に溶け込みながら広がる可能性が高い。だからこそ、「正規に見えるから安全」という思い込みを捨てることが、最初の防御になる。今回の急増は警告ではなく、すでに始まっている現実だ。
