Device Code Phishing——M365を狙う認証フロー悪用の新型攻撃

2026年2月19日、米国・カナダ・オーストラリアなど340以上の組織でMicrosoft 365を標的とした新型フィッシングキャンペーンが検出された。攻撃者が悪用したのは、スマートTVやIoTデバイス向けに設計された「デバイスコード認証フロー」だ。従来のフィッシングとは根本的に異なるこの手法は、多要素認証（MFA）をバイパスし、被害者のアクセストークンを直接窃取する。パスワードを盗むのではなく、正規の認証プロセスそのものを乗っ取る点が極めて厄介だ。

MicrosoftのThreat Intelligence Centerは、このキャンペーンをロシア系脅威アクター「Storm-2372」の活動として追跡しており、政府機関、防衛産業、NGO、高等教育機関、エネルギー企業など広範な業種が標的になっている。2026年3月時点で、攻撃は依然として活発であり、検出されたインシデント数は増加傾向にある。

デバイスコード認証フローとは何か

デバイスコード認証（Device Code Flow / Device Authorization Grant）は、OAuth 2.0の認証方式の一つで、RFC 8628で標準化されている。本来は、キーボード入力が困難なデバイス——スマートTV、ゲームコンソール、IoTセンサー——がMicrosoftアカウントやGoogle Workspaceなどのクラウドサービスにログインするために設計された仕組みだ。

通常のログインフローでは、ユーザーがブラウザでメールアドレスとパスワードを入力し、MFAの認証コードを入力する。しかし、Apple TVのリモコンやプリンターのタッチパネルでパスワードを入力するのは現実的ではない。

デバイスコード認証はこの問題を解決する。具体的なフローは以下のとおりだ。

デバイスがコードを要求: アプリケーションがMicrosoftのトークンエンドポイントに対し、デバイスコードの発行をリクエストする
ユーザーコード表示: Microsoftが8桁程度のユーザーコード（例: ABCD-EFGH）と認証URL（https://microsoft.com/devicelogin）を返す
別デバイスで認証: ユーザーがPC やスマートフォンのブラウザで認証URLにアクセスし、表示されたユーザーコードを入力する
ログインとMFA: ユーザーが通常どおりパスワードとMFAで認証する
トークン発行: 認証が完了すると、元のデバイスにアクセストークンとリフレッシュトークンが発行される

このフロー自体は正当な技術仕様であり、Microsoft Entra ID（旧Azure AD）、Google Cloud、GitHubなど主要なIDプロバイダがサポートしている。問題は、ステップ3の「ユーザーコード入力」を攻撃者が巧みに誘導できる点にある。

攻撃の仕組み——Storm-2372の手口

Storm-2372によるデバイスコードフィッシングは、ソーシャルエンジニアリングと正規の認証フローを組み合わせた巧妙な攻撃だ。以下に攻撃の全体フローを示す。

以下の図は、デバイスコードフィッシングの攻撃フロー全体を示しています。

デバイスコードフィッシングの攻撃フロー。攻撃者がデバイスコードを取得し、フィッシングメールで被害者を認証ページに誘導、正規トークンを窃取する流れ

この図のとおり、攻撃者は一度もパスワードに触れることなく、被害者の認証済みトークンを入手する。具体的な手順は以下のとおりだ。

ステップ1: デバイスコードの事前取得

攻撃者は自身のマシンからMicrosoft Entra IDのトークンエンドポイントに対し、デバイスコードの発行をリクエストする。このリクエスト自体は完全に正規のAPIコールであり、特別な権限は不要だ。Microsoftはユーザーコード（例: GXFP-LMRQ）を返し、このコードは通常15分間有効となる。

ステップ2: フィッシングメールの送信

攻撃者は標的組織の従業員に対し、Microsoft Teamsの会議招待、ITヘルプデスクからの通知、セキュリティアラートなどを装ったフィッシングメールを送信する。メール内にはhttps://microsoft.com/deviceloginという完全に正規のMicrosoft URLが含まれている。

ここが従来のフィッシングとの決定的な違いだ。偽サイトへの誘導ではなく、本物のMicrosoftログインページにアクセスさせる。URLフィルタリングやフィッシング検知ツールは、正規ドメインへのアクセスをブロックしない。

ステップ3: 被害者による認証

メールを受け取った被害者は、正規のMicrosoftログインページで攻撃者が生成したユーザーコードを入力する。続いて、いつもどおりパスワードとMFA（認証アプリやSMS）で認証を完了する。被害者から見ると、一般的なMicrosoftへのログインと何ら変わりない操作だ。

ステップ4: トークンの窃取

被害者がMFA込みで認証を完了した瞬間、Microsoftは攻撃者のデバイスに対してアクセストークンとリフレッシュトークンを発行する。攻撃者はこのトークンを使い、被害者のメール、OneDrive、SharePoint、Teamsなどに完全にアクセスできるようになる。リフレッシュトークンの有効期限は最大90日間であり、その間は被害者がパスワードを変更しても、MFAを再設定しても、トークンが失効するまでアクセスが継続する。

なぜMFAを回避できるのか

デバイスコードフィッシングがMFAをバイパスできる理由は、攻撃のメカニズムを理解すれば明快だ。

従来のフィッシング攻撃では、偽サイトでパスワードを入力させ、そのパスワードを使って攻撃者がログインする。MFAが有効であれば、攻撃者がパスワードを入手してもMFAの壁に阻まれる。

一方、デバイスコードフィッシングでは、被害者自身が正規のMicrosoftサイトでMFAを含む全認証プロセスを完了する。攻撃者はパスワードもMFAコードも必要としない。必要なのは、被害者がユーザーコードを入力して認証を完了してくれることだけだ。

つまり、MFAは「正しいユーザーが認証している」ことを検証するが、「その認証がどのデバイスに対して行われているか」は検証しない。この設計上のギャップがデバイスコードフィッシングの根本的な脅威だ。

従来型フィッシングとの比較

デバイスコードフィッシングが従来のフィッシング手法とどう異なるのかを整理する。

比較項目	従来型フィッシング	Adversary-in-the-Middle (AiTM)	デバイスコードフィッシング
攻撃手法	偽サイトで資格情報を窃取	プロキシで通信を中継・傍受	正規認証フローを悪用
MFAバイパス	不可（基本的に）	可能（セッションCookie窃取）	可能（トークン直接取得）
使用URL	偽ドメイン	偽ドメイン（中継）	正規Microsoft URL
URL検知	検知可能	一部検知可能	検知困難
パスワード窃取	あり	あり（中継時に取得）	なし
トークン有効期間	パスワード変更で無効化	セッション依存（数時間）	最大90日間
攻撃インフラ	フィッシングキット・偽サイト	リバースプロキシサーバー	APIコールのみ
検出難易度	低〜中	中	高
主な対策	URLフィルタリング	フィッシング耐性MFA	条件付きアクセスポリシー

この表から分かるとおり、デバイスコードフィッシングは攻撃インフラのコストが極めて低く（偽サイトもプロキシサーバーも不要）、検出が難しく、効果が長期間持続するという三重の脅威を持つ。

被害の規模と影響——340以上の組織

Storm-2372のキャンペーンで確認された被害の概要は以下のとおりだ。

被害組織数: 340以上（2026年3月時点）
地域: 米国、カナダ、オーストラリア、英国、EU諸国
業種: 政府機関、防衛産業、NGO、高等教育機関、エネルギー企業、ヘルスケア
初検出日: 2026年2月19日
攻撃者: Storm-2372（ロシア系脅威アクター、Microsoftの分類）
窃取されたデータ: メール、OneDriveファイル、SharePointドキュメント、Teams会話

特に深刻なのは、窃取したトークンを使って被害者のメールアカウントから**さらなるフィッシングメールを送信する「ラテラルフィッシング」**が確認されている点だ。組織内の信頼された同僚からのメールは、外部からのフィッシングメールよりもはるかに開封率が高く、被害が連鎖的に拡大する。

また、攻撃者はMicrosoft Graph APIを通じてメールの検索・ダウンロードを自動化しており、「password」「credentials」「secret」「admin」などのキーワードで機密情報を効率的に収集していることが判明している。

条件付きアクセスポリシーによる防御

Microsoft Entra IDの条件付きアクセス（Conditional Access）ポリシーは、デバイスコードフィッシングに対する最も効果的な防御手段だ。以下に推奨設定を示す。

1. デバイスコードフローの制限

最も直接的な対策は、デバイスコード認証フローそのものを制限することだ。

条件付きアクセスポリシー設定:
├── 名前: デバイスコードフロー制限
├── ユーザー: すべてのユーザー
├── クラウドアプリ: すべてのクラウドアプリ
├── 条件:
│   └── 認証フロー: デバイスコードフロー
├── アクセス制御:
│   └── アクセスをブロック
└── 例外:
    └── IoTデバイス管理者グループ（必要最小限）

Microsoft Entra ID P1以上のライセンスで、2025年後半から「認証フロー」を条件として指定できるようになった。これにより、デバイスコードフロー自体をブロックまたは制限できる。

2. 準拠デバイスの要求

デバイスコードフローを完全にブロックできない場合は、トークンの発行先を準拠デバイスに限定する。

Intune準拠デバイス: 企業のセキュリティポリシーに準拠したデバイスからのアクセスのみを許可
ハイブリッドAzure AD参加: オンプレミスADとEntra IDの両方に参加しているデバイスのみを許可
デバイス証明書: 管理対象デバイスにインストールされた証明書による認証を要求

3. トークンの有効期間短縮

リフレッシュトークンの最大有効期間をデフォルトの90日間から短縮する。

推奨設定: 最大有効期間を24時間〜7日間に短縮
Continuous Access Evaluation（CAE）: リアルタイムでトークンの有効性を評価し、リスクが検出された場合に即座に失効させる

4. サインインリスクポリシー

Microsoft Entra ID Protection（P2ライセンス）のサインインリスクポリシーを活用する。

リスクレベル「中」以上: 追加認証（MFA再要求）を強制
リスクレベル「高」: アクセスをブロック
不可能な移動（Impossible Travel）: 短時間で地理的に離れた場所からのアクセスを検出

フィッシング攻撃タイプ別の検出率

以下の図は、主要なメールセキュリティソリューションにおける各フィッシング攻撃タイプの検出率を比較しています。

フィッシング攻撃タイプ別の検出率比較。従来型フィッシングは高い検出率だがデバイスコードフィッシングは大幅に低い

この図が示すとおり、従来型フィッシングの検出率が90%以上であるのに対し、デバイスコードフィッシングは正規URLを使用するため検出率が大幅に低下する。メールセキュリティだけに頼る防御戦略では不十分であることが明確だ。

パスワードマネージャーの重要性

デバイスコードフィッシングはパスワードを直接窃取しないが、攻撃者がGraph APIでメールを検索する際に「password」「credential」などのキーワードを使う点は見逃せない。メールやチャットにパスワードを平文で記載していれば、トークン窃取後に追加の被害が発生する。

1Passwordのようなパスワードマネージャーを導入し、パスワードの共有をセキュアなボールト経由に限定することで、トークン窃取後の二次被害を大幅に軽減できる。特に以下の点が重要だ。

パスワードの平文共有を排除: メール・チャットでのパスワード送信を廃止し、パスワードマネージャーの共有機能を利用
ワンタイムリンク: 一度閲覧したら消えるセキュアなリンクでの資格情報共有
監査ログ: 誰がいつどの資格情報にアクセスしたかを記録
Watchtower機能: 漏洩したパスワードの自動検出と警告

組織が今すぐ実施すべき技術的対策

条件付きアクセスポリシー以外にも、多層的な防御が必要だ。

ネットワーク層の対策

Named Locations: 企業ネットワーク（オフィスIP・VPN）以外からのデバイスコード認証を制限
ネットワークセグメンテーション: IoTデバイスを隔離されたネットワークセグメントに配置
DNS Security: デバイスコード認証のAPIエンドポイントへのアクセスをモニタリング

エンドポイント層の対策

Microsoft Defender for Endpoint: トークン盗用の兆候（異常なGraph APIアクセスパターン）を検出
FIDO2セキュリティキー: フィッシング耐性のある認証方式への移行（デバイスコードフロー自体をバイパス不可にする根本対策）
Windows Hello for Business: デバイスバウンドな認証方式の採用

監視・検知の対策

Microsoft Sentinel: デバイスコード認証のサインインログを専用ルールで監視
アラートルール: 短時間に複数のデバイスコード認証が試行された場合にアラート
Graph API監視: 大量のメール検索・ダウンロードを検出するカスタムルール

セキュリティ監視のKQL例

Microsoft Sentinelで使用できるKQLクエリの例を示す。

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0  // 成功した認証のみ
| summarize
    Count = count(),
    DistinctUsers = dcount(UserPrincipalName),
    DistinctIPs = dcount(IPAddress)
    by bin(TimeGenerated, 1h)
| where Count > 5  // 1時間に5件以上のデバイスコード認証
| order by TimeGenerated desc

日本企業のMicrosoft 365セキュリティ対策

日本企業にとって、デバイスコードフィッシングは「対岸の火事」ではない。以下の理由から、日本市場でも同様のリスクが存在する。

日本企業特有のリスク要因

Microsoft 365の高い普及率: 日本の大企業・中堅企業におけるMicrosoft 365の導入率は70%を超えており、攻撃対象としての母数が大きい。特にTeamsの利用が急速に拡大しており、Teams会議招待を装ったフィッシングは日本でも有効な攻撃ベクターとなる。

MFA導入の遅れ: Microsoft Entra IDのMFA有効化率は、グローバル平均が約60%であるのに対し、日本企業は40%程度にとどまるとの調査がある。MFAすら導入していない組織では、デバイスコードフィッシング以前に従来型フィッシングのリスクが高い。

条件付きアクセスの活用不足: Entra ID P1/P2ライセンスを保有していても、条件付きアクセスポリシーを適切に設定している日本企業は少ない。ライセンスの機能を十分に活用していない「宝の持ち腐れ」状態が散見される。

日本語のフィッシングメール品質の向上: 生成AIの進歩により、自然な日本語のフィッシングメールの作成が容易になっている。以前は不自然な日本語が識別の手がかりとなっていたが、この防壁は急速に薄れている。

日本の規制環境

2024年4月に施行された改正個人情報保護法では、サイバー攻撃による個人データ漏洩が発生した場合、個人情報保護委員会への報告が義務化されている。デバイスコードフィッシングによるメール・ファイルの窃取が個人データを含む場合、報告義務が発生する。

また、金融庁のサイバーセキュリティガイドラインでは、多要素認証の導入とアクセス制御の強化が求められており、デバイスコードフローのリスクを考慮した対策が必要だ。

日本企業向けの優先対策

現状把握: Entra IDのサインインログでデバイスコード認証の利用状況を確認する。使用していないなら、条件付きアクセスでブロックする
ライセンスの活用: 既に保有しているEntra ID P1/P2ライセンスの条件付きアクセス機能を最大限に活用する
従業員教育: 「正規のMicrosoftサイトでも、誰かに頼まれたコード入力は危険」という啓発活動を実施する
FIDO2移行計画: パスワードレス認証（FIDO2セキュリティキー、Windows Hello for Business）への移行ロードマップを策定する

今後の展望——デバイスコードフィッシングの進化

セキュリティ研究者の間では、デバイスコードフィッシングが今後さらに進化する可能性が指摘されている。

QRコード型の派生攻撃: デバイスコードの代わりにQRコードをフィッシングメールに埋め込む手法が既に確認されている。スマートフォンでQRコードを読み取ると認証ページに直接遷移するため、ユーザーコードの手動入力という「違和感」すら排除される。

自動化ツールの普及: GitHub等でデバイスコードフィッシングのツールキットがオープンソースで公開されており、技術的な参入障壁が低下している。Storm-2372のような国家支援型の脅威アクターだけでなく、一般のサイバー犯罪者にも手法が拡散する可能性が高い。

他のIDプロバイダへの波及: 現時点ではMicrosoft Entra IDが主な標的だが、Google Workspace、Okta、Auth0など、デバイスコードフローをサポートする他のIDプロバイダも同様のリスクを抱えている。

まとめ——アクションステップ

デバイスコードフィッシングは、正規の認証フローを悪用する高度な攻撃であり、従来のセキュリティ対策では防御が困難だ。以下の3ステップを今すぐ実施することを推奨する。

条件付きアクセスポリシーの即時設定: Microsoft Entra IDの管理画面で、デバイスコードフローを条件とするポリシーを作成し、不要な場合はブロック、必要な場合は準拠デバイスに限定する。設定は30分程度で完了する
サインインログの監査: 過去30日間のサインインログでAuthenticationProtocol == "deviceCode"の認証を検索し、不審なアクティビティがないか確認する。Microsoft Sentinel導入済みの場合は、前述のKQLクエリでアラートルールを作成する
パスワードレス認証への移行開始: FIDO2セキュリティキーまたはWindows Hello for Businessの導入計画を策定し、まずはIT管理者・経営層から段階的に展開する。並行して1Password等のパスワードマネージャーを全社展開し、メール・チャットでのパスワード平文共有を禁止する

デバイスコードフィッシングの脅威は、「MFAを導入しているから安全」という誤った安心感を打ち砕くものだ。認証フロー全体を見据えたゼロトラストアーキテクチャの構築が、今まさに求められている。