Microsoft 365やGoogle Workspaceなどのクラウドサービスを安全に利用するために、多要素認証（MFA：Multi-Factor Authentication）を設定している企業も増えてきました。
パスワードだけでログインできないようにするMFAは、アカウントを守るうえで非常に重要なセキュリティ対策です。
しかし最近では、
「パスワードを盗む」
だけではなく、
利用者自身に正規の認証操作をさせ、その認証結果を攻撃者が悪用する
という攻撃にも注意が必要になっています。
その一つが「デバイスコードフィッシング（Device Code Phishing）」です。
偽のログイン画面へ誘導する従来型のフィッシングとは少し異なり、正規のMicrosoftのサインイン画面が利用される場合があるため、利用者が「これは本物の画面だから大丈夫」と判断してしまう可能性があります。
今回は、デバイスコードフィッシングとは何か、その仕組みやMFAとの関係、そして企業が取るべき対策について、中小企業の経営者やセキュリティ初心者にも分かりやすく解説します。
デバイスコードフィッシングとは？
デバイスコードフィッシングとは、クラウドサービスなどで利用される「デバイスコード認証」の仕組みを悪用したフィッシング攻撃です。
一般的なフィッシングでは、
「Microsoft 365のサインイン画面に似せた偽サイトを作り、ID・パスワードを入力させる」
といった手法がよく知られています。
一方、デバイスコードフィッシングでは、攻撃者が必ずしも偽のMicrosoftサインインページを用意する必要はありません。
攻撃者があらかじめ認証用のコードを取得し、
「このコードをMicrosoftのサイトで入力してください」
などと利用者を誘導します。
利用者が本物のMicrosoftサインインページを開き、自分のアカウントで認証すると、その結果として発行された認証トークンを攻撃者側が利用できる場合があります。
つまりポイントは、
「偽サイトにパスワードを入力してしまう攻撃」とは限らない
ということです。
そもそも「デバイスコード認証」とは何か
デバイスコード認証、正式には「デバイスコードフロー（Device Code Flow）」は、本来は正規の便利な認証方法です。
例えば、
- テレビ
- 会議室端末
- IoT機器
- プリンター
- コマンドラインツール
- キーボード入力やWebブラウザー操作が難しい端末
などでは、通常のパソコンのようにウェブブラウザ（画面）を持たない、あるいはIDやパスワードを直接入力することが難しい場合があります。
そのような場合に、
|
① 端末側に短い認証コードを表示する |
| ② 利用者が別のパソコンやスマートフォンで認証サイトを開く （例：microsoft.com/devicelogin） |
| ③ 表示されたコードを入力する |
| ④ 自分のアカウントでログインする |
| ⑤ 元の端末が利用可能になる |
という流れで認証を行います。
Microsoftのデバイスコードフローも、ブラウザー操作が難しい機器などからサインインするために用意されている正規のOAuth 2.0認証方式です。
仕組みそのものが危険なのではありません。
問題は、
「どの端末を認証しようとしているのか」を利用者が十分理解しないまま、第三者から渡されたコードを入力してしまうこと
です。
攻撃者はどのように利用者を騙すのか
攻撃者は、デバイスコードフィッシングの便利な仕組みを悪用します。具体的な攻撃の流れは以下の通りです。
| 1. 攻撃者が認証を要求する |
攻撃者は自分のパソコンから、ターゲット企業のシステム（Microsoft 365など）に対してデバイスコード認証をリクエストし、「認証コード」を取得します。
| 2. 偽のメールを送信する |
攻撃者はターゲット（従業員）に対し、「重要な書類が共有されました。以下のリンクからコード『AB12-CD34』を入力して確認してください」といった業務を装ったメールを送ります。
| 3. ユーザーがコードを入力する |
メールを信じた従業員は、記載された正規のログインURL（MicrosoftやGoogleの本当のサイト）にアクセスし、攻撃者から送られたコードを入力してしまいます。
| 4. MFAもユーザーが突破してしまう |
ログイン画面は「本物」であるため、従業員のスマホに多要素認証（MFA）の通知が届きます。従業員はそのまま承認（MFAをクリア）してしまいます。
| 5. 攻撃者がアクセス権を獲得 |
ユーザーが認証を完了した瞬間、待機していた攻撃者のパソコンがシステムへのアクセス権（トークン）を取得し、乗っ取りが完了します。
Microsoftが確認した事例では、攻撃者が取得した認証トークンを悪用してアカウントにアクセスし、メールの検索・情報の窃取を行ったほか、侵害したアカウントから組織内の別の利用者にフィッシングメールを送信する動きも確認されています。
実際の被害ケース
|
ある中小規模の製造業で、営業担当者のもとに「取引先からの見積書（要確認）」というメールが届きました。 営業担当者が指示通りに正規のMicrosoftページでコードを入力し、スマホでのMFAも承認した結果、メールアカウントが完全に乗っ取られました。 その後、そのアカウントを踏み台にして、本物の取引先に対して偽の請求書メール（振込先が攻撃者の口座に変更されているもの）が一斉送信され、多額の金銭的被害と信用の失墜を招く事態となりました。 |
このように、たった1人の従業員の些細な誤認が、会社全体を揺るがす甚大な被害につながるのがデバイスコードフィッシングの恐ろしさです。
なぜパスワードやMFAだけでは防ぎにくい場合があるのか
ここが、デバイスコードフィッシングを理解するうえで重要なポイントです。
この攻撃を単純に、
「MFAを突破する攻撃」
と表現するのは正確ではありません。
攻撃者がMFAそのものを技術的に破っているとは限らないからです。
むしろ、
正規のMFA認証を利用者自身に完了させ、その認証結果を悪用する
という点に特徴があります。
例えば、
| パスワード |
| MFA認証 |
| 認証成功 |
| 認証トークン発行 |
という通常の流れそのものは正常に行われています。
問題なのは、その認証操作が「自分が利用しようとしている正規の端末・アプリ」のためではなく、「攻撃者が開始した認証要求」のために行われていることです。
そのため、
「MFAを導入しているからフィッシング対策は完了」
とは考えないことが大切です。
ただし、これはMFAが意味を持たないという話ではありません。
MFAは依然としてアカウント保護の基本であり、多くの不正ログインを防ぐために非常に有効です。Microsoftも、デバイスコードフィッシングへの注意を呼びかける一方、MFAを重要なIDセキュリティ対策として引き続き推奨しています。
重要なのは、
MFAに加えて、認証方法の制御、ログ監視、社員教育を組み合わせること
です。
Microsoft 365利用企業が特に確認したいポイント
デバイスコードフィッシングはMicrosoftだけの問題ではありません。
デバイスコード認証はOAuth 2.0の標準的な仕組みであり、Microsoft以外のサービスでも利用されています。
実際にGitHubでも、この仕組みを悪用したアカウント侵害がセキュリティ検証で確認されています。
一方、Googleではデバイスコード認証で利用できる権限が制限されており、サービスによって攻撃の成立条件や影響は異なります。
現在、実際の攻撃事例が多く報告されているのはMicrosoft 365環境であるため、以下ではMicrosoft 365を中心に、企業が確認すべきポイントを解説します。
Microsoft Entra IDでは、デバイスコードフローを利用することができます。
Microsoftはデバイスコードフローを「高リスクな認証方法」と位置づけ、業務上必要な用途に限定し、可能な限り利用をブロックすることを推奨しています。
特に、
「自社でそもそもデバイスコードフローを使っているのか」
を確認することが重要です。
中小企業では、Microsoft 365を利用していても、デバイスコードフローという言葉自体を知らないことも珍しくありません。
しかし実際には、
- Microsoft Teams関連端末
- Azure CLIなどの管理ツール
- 一部の開発ツール
- 古いシステムや端末
などで利用される場合があります。
Microsoftは、デバイスコードフローが不要な組織については、条件付きアクセスを利用して可能な限りブロックすることを推奨しています。
ただし、業務上必要な機器まで一律に停止すると正常な業務に影響する可能性があります。
そのため、
「まず利用実態を確認し、不要なものを止め、必要なものだけ例外として許可する」
という進め方が現実的です。
不審な認証を防ぐために企業ができる対策
デバイスコードフィッシングへの対策は、一つの製品を導入すれば終わるものではありません。
複数の対策を組み合わせることが重要です。
| ① デバイスコードフローの利用状況を確認する |
|
まず、自社でデバイスコードフローが実際に利用されているか確認します。 Microsoft Entra IDのサインインログなどから利用状況を確認し、 🔷 誰が利用しているか を整理します。 |
| ② 不要であればデバイスコードフローを制限する |
|
利用していないのであれば、条件付きアクセスなどを利用してブロック（無効化）することを検討します。 利用する必要がある場合も、 |
| ③ MFAは引き続き必須とする |
|
デバイスコードフィッシングがあるからといって、MFAをやめてはいけません。 可能であれば、パスキーやFIDO2セキュリティキーなど、フィッシング耐性の高い認証方式も検討するとよいでしょう。
|
| ④ 「コードを入力してください」を安易に信用しない |
|
社員教育では、 特に、 ❓ Teams会議への参加 などを装った連絡には注意が必要です。 「Microsoftの本物のサイトだったから安全」という判断だけでは不十分です。 大切なのは、 |
| ⑤ 不審な認証をログから見つけられるようにする |
|
認証攻撃を完全に防ぐことは難しいため、 例えば、 ✔️ 普段とは異なる国・地域からのログイン などを確認します。 ここでは、以前のコラムで紹介した「ログ監視」や「UEBA」の考え方も有効です。 |
OAuth連携・同意フィッシングとの違いは？
前回OAuth連携のコラムで紹介した「同意フィッシング（Consent Phishing）」と、今回のデバイスコードフィッシングは、どちらもクラウドサービスの正規の仕組みが悪用されるという点で似ています。
ただし、仕組みは異なります。
| 同意フィッシング |
| 利用者に悪意あるアプリへのアクセス権限を許可させる攻撃 |
| デバイスコードフィッシング |
| 攻撃者が開始したデバイスコード認証を利用者に完了させ、認証トークンなどを悪用する攻撃 |
デバイスコードフィッシングをもう少し詳しく説明すると、
|
このように、OAuthという本来は利便性と安全性を高めるための優れた技術が、攻撃者のアプローチ次第で悪用されてしまうのが、サイバー攻撃の恐ろしいところです。
OAuthの仕組みを理解していることは、こうした最新の攻撃手法の構造を理解し、適切な対策を打つための強力な武器になります。
同意フィッシング、デバイスコードフィッシングのどちらにも共通するのは、
「パスワードを盗まれなければ安全」という考え方だけでは守りきれない
という点です。
クラウドサービスでは、パスワードだけでなく、
✅ 誰が認証しているのか
✅ どのアプリに権限を与えているのか
✅ どの端末からアクセスしているのか
✅ どのような認証方式が使われているのか
✅ 認証後にどのような操作が行われているのか
まで含めて管理する必要があります。
（参考）：OAuth連携とは？Google Workspace・Microsoft 365の外部アプリ連携に潜むセキュリティリスク
「本物の認証画面だから安全」とは限らない
これまでのフィッシング対策では、
「URLを確認する」
「偽サイトにパスワードを入力しない」
という注意喚起が中心でした。
もちろん、これらは今でも重要です。
しかし、デバイスコードフィッシングのように、正規の認証の仕組みを利用する攻撃では、それだけでは十分ではありません。
これからは、
「そのサイトは本物か」だけではなく、「その認証を自分が本当に開始したのか」
を確認することが重要になります。
Microsoft 365やGoogle Workspaceなどのクラウドサービスは、現在の企業活動に欠かせない存在です。
だからこそ、
✴️ MFAを設定する
✴️ アカウントと権限を適切に管理する
✴️ 不要な認証方式を制限する
✴️ 認証ログを確認する
✴️ 社員が不審な認証要求を見分けられるようにする
といった対策を組み合わせる必要があります。
（参考）：クラウドグループウェアのセキュリティ設定とは？中小企業が確認したい10のポイント
セキュリティ対策というと、新しい製品を導入することに目が向きがちです。
しかし今回のような認証攻撃では、
「自社ではどの認証方法が使われているのか」「社員はどのような認証操作をしているのか」
を把握することも重要なセキュリティ対策です。
まずは、自社のMicrosoft 365などの認証設定とサインインログを確認するところから始めてみてはいかがでしょうか。
「自社のセキュリティ設定がどうなっているか分からない」
「クラウドサービスを導入したが、安全に運用できているか不安だ」
という経営者・ご担当者様は、ぜひ一度、LYSTにご相談ください。
貴社の環境に合わせた最適なセキュリティ対策をご提案し、安全なビジネス環境の構築をサポートいたします。
