Microsoft 365では、さまざまな認証方式が導入されていますが、その中でもデバイスコード認証は、端末やアプリの制約がある環境でも柔軟に利用できる仕組みとして注目されています。ユーザー自身が専用コードを入力することで、他の認証方式と同様のセキュリティを確保できる一方で、その手順を逆手に取った攻撃も報告されています。
この方式が悪用されると、ユーザーの意図しない認可が行われ、攻撃者にアクセストークンが発行されてしまう恐れがあります。しかも、見た目は正規のMicrosoftログイン画面を利用するため、多くの従業員が不正を見抜けないまま認証してしまう危険性もあります。
そこで本記事では、Microsoft 365におけるデバイスコード認証の仕組みと正規の利用方法、悪用されるケースや典型的な攻撃シナリオ、そして不正の痕跡を調査するための手順や対策について、わかりやすく解説します。
| 本ページには広告が含まれています。本コンテンツ経由で商品・サービスの申込みがあった場合、企業から送客手数料を受け取ることがあります。 |
Microsoft 365におけるデバイスコード認証とは
デバイスコード認証（device code flow）は、ブラウザを搭載していない端末や、入力操作に制約のあるアプリケーションでも安全に Microsoft 365 へサインインできるよう設計された認証方式です。
OAuth 2.0（認可のための業界標準プロトコル）の一部として実装されており、ユーザーが別端末からコードを手動入力することで認証を完了させるという特徴があります。
この方式では、アプリケーションやデバイス側に表示された デバイスコード を、ユーザー自身が指定されたURL（例：Microsoft公式のデバイスログインページ）に入力します。
その後、通常のMicrosoft 365アカウントでサインインし、必要に応じてMFA（多要素認証：パスワード＋別要素で本人確認する仕組み）を完了すると、アプリケーションに対して アクセストークン（APIアクセス用の認証情報）が発行されます。
この仕組みのメリットは以下のとおりです。
- キーボードやブラウザ操作が困難な端末でも利用できる
- 通常のOAuthアプリ連携と同様に、トークンベースでアクセス制御・管理が可能
一方で、この「ユーザーがコードを入力し、認可操作を自分で行う」という特性が、攻撃者に悪用されるケースも確認されています。
特に、ユーザーが意図せず攻撃者の用意したアプリケーションを認可してしまうことで、不正なアクセストークンが発行される点が問題となります。
次章では、こうしたデバイスコード認証が どのような仕組みで悪用されるのか を具体的に解説します。
なぜMicrosoftのデバイスコード認証が悪用されるのか
デバイスコード認証は、あくまで 正規のOAuth認証フロー であり、設計自体に脆弱性があるわけではありません。
しかし攻撃者は、この方式が持つ 「認証操作をユーザー自身に委ねている」 という特徴を巧妙に突いてきます。
重要なのは、MFA（多要素認証）を技術的に回避しているわけではなく、ユーザー本人が正規のMicrosoftログイン画面上でMFAを完了してしまうことで、「MFAを通過した正規セッションとして扱われるアクセストークン」 が発行されます。
つまり攻撃者は、「ユーザーにMFAを通過させ、その結果を横取りする」という手法を取っています。
さらに厄介なのが、ユーザーが操作するログイン画面は すべてMicrosoft公式の正規ページ である点です。
URLや画面デザインに不審な点がないため、ユーザーは「なぜこのページで認証を求められているのか」という 「導線そのもの」 を疑わない限り、攻撃に気づくことができません。
このように、「正規の認証フロー、ログイン画面、ユーザー操作」が組み合わされることで、従来のフィッシング対策やURLチェックでは検出が難しい攻撃となっています。
Microsoft 365 デバイスコード悪用攻撃の典型シナリオ
ここでは、攻撃者が実際にどのようにしてデバイスコード認証を悪用し、ユーザーからアクセストークンを取得しているのか、典型的な攻撃シナリオを時系列で紹介します。
①フィッシングメールやチャットで偽の依頼を送る
攻撃者は、Teamsの通知、業務アプリの連携依頼、管理者や取引先を装った連絡などに偽装し、
ユーザーに対して「認証が必要」「この手順を完了してください」といった内容のメールやチャットを送信します。
文面やレイアウトはMicrosoft公式の案内に酷似しており、ユーザーが違和感を覚えにくい構成になっているのが特徴です。
②ユーザーにコード入力を促す
案内に従ってユーザーがURL（例：Microsoft公式のデバイスログインページ）へアクセスすると、
正規のMicrosoftログイン画面が表示されます。
ここでユーザーは、攻撃者が事前に取得していた デバイスコード を入力します。
このコードが入力された時点で、攻撃者側で待機している認証フローと紐付けが完了します。
③ユーザーが正規ログインし、認可を完了
ユーザーは通常どおりMicrosoftアカウントでログインし、表示されたアプリケーションの認可リクエストに同意します。
この過程でMFAが求められた場合も、ユーザー自身が正規にMFAを完了します。
その結果、OAuthの仕様どおり 「MFAを通過した正規セッションとして扱われるアクセストークン」 が発行されます。
この時点で、ユーザーの操作と攻撃者のアクセスは完全に切り離された状態になります。
④攻撃者がアクセストークンを取得
認可が完了すると、アクセストークンは攻撃者が制御するアプリケーション側で取得されます。
このトークンを用いることで、攻撃者はユーザーになりすました形で各種APIにアクセス可能になります。
外形上は「正規ユーザーによる正常な認証」として扱われるため、ユーザー自身が不正に気付くことはほぼありません。
Microsoft 365サービスに横断的に侵入
バイスコード認証を悪用された場合、攻撃者はアクセストークンを用いてMicrosoft 365の複数サービスに不正アクセスすることが可能になります。この横断的な侵入により、業務データの大量取得やなりすまし行為といった深刻な二次被害が発生するおそれがあります。
具体的には、以下のような不正利用が確認されています。
- Exchange Online：なりすましメールの送信、取引先へのフィッシング拡散
- OneDrive・SharePoint：社内外のファイル流出、マルウェアの配布
- Teams：チャットでのフィッシング展開、招待リンクの偽装
さらに、攻撃者が内部展開型のフィッシングキャンペーンを実行することで、同一組織内の複数アカウントが連鎖的に侵害される事態も起こり得ます。このようなケースでは、「いつ誰がどのデータにアクセスしたのか」という痕跡を時系列で確認する必要があります。
不正トークンの有効期間中は、ユーザーがパスワードを変更してもアクセスが止まらないため、トークン自体を失効させる手続きが重要です。そのためには、適切なログの取得と分析、スコープやクライアントIDの確認が欠かせません。
Microsoft 365デバイスコードが悪用された際のインシデント対応
デバイスコード認証を悪用した不正アクセスが疑われる場合、最優先すべきは事実関係の特定と証拠の保全です。
この種の攻撃は、外形上「ユーザーが正規に認可した操作」として記録されるため、初動対応を誤るとログ消失や証拠改変により、原因の特定が困難になります。
そのため、Microsoft 365 環境におけるインシデント対応では、フォレンジック調査を前提とした対応が不可欠となります。
サインインログ・監査ログの分析
デバイスコード認証の悪用が疑われる場合、初動対応としてまず実施すべきは、サインインログおよび監査ログの保全と分析です。
具体的には、Microsoft Entra ID（旧 Azure AD）のサインインログと、Microsoft 365 監査ログを対象とし、後の調査に耐えうる形でエクスポート・保存したうえで分析を行います。
本調査の実施内容は以下の通りです。
- サインインログおよび監査ログのエクスポート・証拠保全
- Authentication Details および Client App 情報の確認
- 監査ログと突合し、実行された操作を時系列で整理
なお、調査開始前にログの保全を行わない場合、保存期間の経過や上書きにより証拠が失われ、事実関係の立証が困難となります。既に何かしらの被害が疑われる、分析できる人物がいない場合は、専門のフォレンジック調査会社にご相談ください。
不正に発行されたトークンおよびOAuthアプリの特定と失効
トークン発行元のアプリ（client_id）を特定したうえで、Microsoft Entra管理センターやGraph APIを通じて該当トークンの失効処理を行います。
必要に応じて、Azure AD上のアプリ登録や権限の見直し、条件付きアクセスの制限設定も検討します。
手順
- 不審なトークン発行元アプリのスコープと権限を確認
- アプリの削除・ブロックまたは該当トークンの明示的な失効
- 条件付きアクセスで再発を予防
なお、アクセストークンが有効な状態では、ユーザーのパスワード変更のみでは不正アクセスを遮断できない場合がある。そのため、トークンおよび認可設定の明示的な無効化が不可欠とです。
フォレンジック調査の実施
不正なアクセストークンが確認された場合、次に行うべきことは「どこまで影響が及んでいるのか」を正確に把握することです。
デバイスコード認証を悪用した攻撃では、Exchange、SharePoint、OneDrive、Teams など複数の Microsoft 365 サービスが同一トークンを通じて横断的に利用される可能性があります。
そのため、個別のログを部分的に確認するだけではなく、
- どのサービスにアクセスされたのか
- どの操作が実行されたのか
- その操作はいつ行われたのか
を時系列で整理する必要があります。
また、侵害がクラウド環境内に限定されているのか、それとも端末の不正利用やマルウェア感染を伴うものなのかについても、早い段階で切り分けを行うことが重要です。
これらを社内対応だけで正確に判断することは難しいため、影響範囲の調査段階では、Microsoft 365 環境に精通した専門家によるフォレンジック調査へ移行することが現実的な対応となります。
フォレンジック調査では、「アクセストークンの利用状況」「各サービスにおける操作履歴」「侵害の起点と影響範囲」を整理し、「何が起きたのか」「どこまで影響したのか」を明確にします。
影響範囲を曖昧なまま対応を終えてしまうと、被害の見落としや再発につながるおそれがあるため、
この段階での判断と対応が、その後の復旧と再発防止を大きく左右します。
編集部おすすめ調査会社：デジタルデータフォレンジック(おすすめ度)
デバイスコード認証の悪用など、Microsoft 365 上で発生する気付きにくい不正アクセスについて、
「何が起きたのか」「どこまで影響したのか」を明らかにするフォレンジック調査を行っている専門会社をご紹介します。
こちらの業者は、相談件数が39,000件を超え、民間の調査会社でありながら官公庁や大手企業との取引実績も多く信頼できるため、幅広い調査に対応していておすすめです。もちろん法人だけでなく、個人のハッキングやサポート詐欺調査などの相談も受け付けています。
まずは無料で相談・見積りまで行ってくれるようなので、不安な方は一度相談してみるとよいでしょう。
| 費用 | ★見積り無料 まずはご相談ください |
|---|---|
| 調査対象 | PC、スマートフォン、サーバ、外付けHDD、USBメモリ、SDカード、タブレット など |
| サービス | マルウェア・ランサムウェア感染調査、情報漏洩調査、ハッキング・不正アクセス調査、サイバー攻撃被害調査、退職者調査、労働問題調査、社内不正調査、情報持出し調査、横領着服調査、パスワード解除、データ改ざん調査、データ復元、デジタル遺品、離婚問題・浮気調査 など |
| 特長 | ✓累積ご相談件数39,451件以上 ✓国際基準をクリアした厳重なセキュリティ体制（ISO認証、プライバシーマーク取得済） ✓警視庁からの捜査協力依頼・感謝状受領の実績多数 |
デジタルデータフォレンジックは、国内トップクラスの調査力を有しており、累計3万9千件以上の豊富な実績があります。
規模が大きな調査会社でありながら、個人端末のハッキング調査、不正アクセス調査などの実績もあるようですし、24時間365日の相談体制、ニーズに合わせたプランのカスタマイズなど、サービスの利用しやすさも嬉しいポイントです。
ハッキング調査以外にも幅広い調査に対応しているだけでなく、ケースごとに専門チームが調査対応を行っているとのことで、高品質な調査が期待できます。さらに、警察への捜査協力も行っているなど、信頼がおける専門業者です
相談・見積りを“無料“で行っているので、まずは電話かメールで問合せをしてみることをおすすめします。
Microsoft 365デバイスコート悪用の防止策
デバイスコード認証の悪用を防ぐためには、単に一度の不正アクセスを封じるだけでは不十分です。認可の仕組みを理解し、防止策をとることが不可欠です。以下に主な改善ポイントを整理します。
再発防止策と教育のチェックポイント
条件付きアクセスによるリスク制御
Microsoft Entra（旧Azure AD）の条件付きアクセスポリシーを活用することで、「デバイスコードフロー」や「特定のクライアントID」を使ったログインを制限できます。
とくに「ユーザーアクション」「アプリケーション」単位での制御を明確に設計することで、未知のアプリや認可済みアプリの乱用を防止できます。
実施手順
- デバイスコードフローを制限対象とする条件付きアクセスを作成
- 業務で必要なアプリの明示的許可リストを作成
- ログから適用状況とブロック実績を継続監視
なお業務上デバイスコードフローが必要なケースがあるため、全面遮断ではなく用途を限定した制御設計が重要です。
OAuthアプリの制御と監査
組織内で利用されているOAuthアプリの権限と数を継続的に監視・制限することも重要です。必要に応じてユーザーによるアプリ承認を制限し、既存アプリの権限レビューを定期的に行います。
実施手順
- OAuthアプリの一覧と承認権限をエクスポート
- 利用実態と不要アプリの確認（Graph APIでも可）
- リスクの高いアプリのブロック・制限を実施
ユーザー向け認証確認プロセスの整備
攻撃の起点が「ユーザーによる誤認可」である以上、教育とプロセスの明文化も不可欠です。ユーザーがアプリ連携やコード入力を求められた際に立ち止まるための「確認フロー」を設けましょう。
例としては、「不明なコード入力は情シスに連絡」「正規アプリ以外の認可は不可」など、行動基準を明示するガイドラインが有効です。
実施手順
- 「デバイスコード認証とは何か」などの教育資料を配布
- アプリ認可時に確認すべき3項目（開発元／必要性／用途）を明文化
- 社内ガイドラインや通知フローに落とし込む