AIが多要素認証を突破？Microsoftが警告する「デバイスコード・フィッシング」の正体と対策
【導入】「多要素認証（MFA）なら安心」という常識が崩れる日
「パスワードだけでは不十分。だからスマホでの承認（MFA）を有効にしましょう」 セキュリティの現場で長らく語られてきたこの「鉄則」が、今、AIの悪用によって揺らいでいます。
2026年に入り、Microsoftが改めて強い警告を発しているのが**「デバイスコード・フィッシング（Device Code Phishing）」**という手法です。ニュースの見出しだけを見ると「AIがついにMFAのシステムをハッキングしたのか？」と驚かれるかもしれませんが、実態はもっと巧妙で、もっと「人間臭い」隙を突いたものです。
生成AIの進化は、私たちが業務を効率化するのと同様に、攻撃者側の「騙しのプロセス」も劇的に効率化させてしまいました。本記事では、セキュリティ経験とサーバー監視の現場視点から、この最新の脅威がなぜこれほどまでに厄介なのか、そのメカニズムと防御策を深掘りします。
【解説】なぜMFAが突破されるのか？そのメカニズムとAIの役割
この攻撃を理解するには、まず**「デバイス認可フロー（RFC 8628）」**という便利な仕組みを知る必要があります。
1. 「デバイス認可フロー」という盲点
スマートTVやプリンター、あるいはコマンドラインツール（CLI）など、キーボード入力が難しいデバイスからMicrosoft 365などのクラウドサービスにログインする際、画面に数桁の英数字（デバイスコード）が表示され、「手元のスマホやPCでこのコードを入力してください」と促された経験はないでしょうか。
これがデバイス認可フローです。ユーザーが使い慣れたデバイスで認証を肩代わりすることで、入力しにくいデバイスでも安全にログインできるように設計された便利な仕組みです。しかし、攻撃者はこの「便利さ」を逆手に取ります。
2. 攻撃の4ステップ：ユーザー自身が「鍵」を開けてしまう
デバイスコード・フィッシングの恐ろしい点は、「偽のサイト」に誘導するのではなく「本物のMicrosoftのサイト」に誘導する点にあります。
偵察（AIの活用）: 攻撃者はAIを用いて、ターゲット企業のメールアドレスや業務内容を調査します。
コード生成: 攻撃者は自分のPCから「被害者のアカウント」でログインを試行し、正規のデバイスコードを発行させます。
フィッシング攻撃: ターゲットに対し、「セキュリティの更新が必要です。このコードを microsoft.com/devicelogin に入力してください」といったメールを送ります。
MFAの「肩代わり」: 被害者が本物のサイトでコードを入力し、いつものようにスマホでMFAの承認をタップした瞬間、攻撃者のPCにログイン権限（アクセストークン）が付与されます。
システム側から見れば、これは「正規のユーザーが、正規のサイトで、正規のコードを入力し、MFAをパスした」正当なアクセスに見えます。そのため、従来のセキュリティフィルターを通り抜けてしまうのです。
3. 生成AIがもたらした「騙しのスケール」
ここでAIが果たしている役割は、主に「ソーシャルエンジニアリングの高度化」です。
かつてのフィッシングメールは、日本語が不自然だったり、文脈が唐突だったりと、注意深く見れば見破れるものが多くありました。しかし、現在の生成AIは、ターゲットの役職や過去のプレスリリース、SNSの投稿、さらには業界特有の専門用語を学習し、**「その人が今、最も信じそうな文面」**を完璧な日本語で、かつ大量に生成します。
例えば、サーバー監視担当者には「深夜の異常検知ログの確認」、人事担当者には「採用候補者の履歴書確認」といった具合に、業務フローに完璧に組み込まれた騙しを仕掛けてきます。これが、AI時代のフィッシングの真の恐ろしさです。
4. 具体的な防御策
この攻撃を防ぐためには、ユーザーの注意喚起だけでは限界があります。技術的な多層防御が必要です。
デバイスコードフローの無効化: 業務でスマートTV等との連携が不要な場合、Microsoft Entra ID（旧Azure AD）の設定で、デバイスコードフロー自体を無効化するのが最も確実です。
条件付きアクセスの厳格化: 「許可されたIPアドレス以外からのアクセスを拒否する」「管理されていないデバイスからのログインを制限する」といった条件を課すことで、たとえコードが入力されても攻撃者の端末からの接続を遮断します。
FIDO2（パスワードレス）の導入: 指紋認証や顔認証を用いた物理的なセキュリティキーを使用することで、リモートからのコード入力を無効化する方向へシフトすることが推奨されます。
【まとめ】AI時代のセキュリティは「性悪説」の再定義が必要
今回の「デバイスコード・フィッシング」の流行は、セキュリティにおける一つの転換点を示しています。
AIは暗号を力技で解くのではなく、「認証プロセスの正当な参加者（ユーザー）」を操作することで、システムの内側から鍵を開けさせる手法を選びました。どれだけ堅牢な金庫（MFA）を作っても、鍵を持っている人間が騙されて鍵を渡してしまえば意味がありません。
私たちは今、「正規のURLだから安全」「MFAを入れているから安心」というこれまでの常識を一度捨てなければなりません。利便性とセキュリティは常にトレードオフの関係にありますが、AIという強力な武器が攻撃者の手に渡った今、私たちはより戦略的な防御態勢を構築する必要があります。
【感想】
今回のニュースには強い危機感を覚えるとともに、ある種の中断のない「いたちごっこ」の進化を感じています。
かつてのサーバー監視は「システムが動いているか、止まっているか」というバイナリな世界が主戦場でした。しかし、今のセキュリティは「その操作をしているのは本当に本人か？」「その意図は正当か？」という、より心理的で曖昧な領域に踏み込まざるを得なくなっています。
特に今回のように、OAuth 2.0という「標準的な便利な仕様」が悪用されるケースは、現場のエンジニアにとって最も頭が痛い問題です。利便性を損なえば業務が滞り、放置すれば致命的な情報漏洩につながる。このバランスをどう取るかが、今後のAIガバナンスにおいても重要なテーマになるでしょう。
私自身、日々AIの開発や活用を推進する立場にありますが、AIの「光」の部分である業務効率化を享受する一方で、その裏にある「影」——つまり攻撃の自動化や高度化に対しても、常にアンテナを高く張り、アップデートし続けなければならないと痛感しています。
出典・参考文献
Microsoft Security Blog: "Identifying and mitigating device code flow phishing"
RFC 8628: OAuth 2.0 Device Authorization Grant
IPA（独立行政法人情報処理推進機構）: 「組織における内部不正防止ガイドライン」
