Microsoft 365でMFA（多要素認証）を設定していても、Kali365のような攻撃では、パスワードではなく認証後に発行されるOAuthトークンが狙われます。これは、利用者が正規のMicrosoft認証ページで操作してしまうことで、攻撃者側のセッションが認証済みになってしまうタイプの攻撃です。この記事では、OAuth攻撃の仕組み、従来のフィッシングとの違い、Microsoft 365管理者が確認すべき対策を実務目線で整理します。
私もMicrosoft 365でMFAを設定した経験があります。MFA導入時は、利用者への初回登録案内、スマートフォン変更時の再登録、認証アプリに慣れていない職員への説明など、運用面の負担が大きくなりがちです。だからこそ、導入が終わると「これで一段落」と考えやすいのですが、Kali365のようなトークン窃取型の攻撃では、MFAの次に確認すべきポイントがあります。
この記事では、Microsoft 365を管理する情シス担当者向けに、OAuth攻撃の基本、Kali365の攻撃の流れ、条件付きアクセスやサインインログ確認など、最初に取り組むべき対策を解説します。
結論：OAuth攻撃対策はMFAの次に確認すべきMicrosoft 365運用です
Kali365で注目すべき本質は、パスワードではなくOAuthトークンを狙う攻撃である点です。
従来のフィッシングでは、偽のログイン画面にIDとパスワードを入力させる手口が中心でした。一方、Kali365のような攻撃では、利用者に正規のMicrosoft認証ページで操作させたうえで、OAuthアクセス／リフレッシュトークンを取得する流れが使われます。
つまり、パスワードが強固であっても、攻撃者が有効なトークンを取得すると、Microsoft 365環境へアクセスされる可能性があります。
ここで大切なのは、MFAが不要という話ではないことです。MFAは今でも重要な基本対策です。ただし、MFAを設定して終わりではなく、以下のような運用を組み合わせる必要があります。
- 条件付きアクセスによる制御
- デバイスコード認証フローの制限
- サインインログの定期的な監査
- アクティブセッションの取り消し手順
- リフレッシュトークン失効の運用
- 不審なアプリ同意の確認
Microsoft 365管理者は、MFA導入後の次の一手として、OAuthトークンを悪用されにくい設定と、侵害時にすぐ確認できる運用を整える必要があります。
Kali365とは？Microsoft 365のOAuthトークンを狙うPhaaSです
Kali365とは、Microsoft 365環境の侵害に使われるPhaaS（Phishing-as-a-Service：サービス型フィッシング）基盤です。
FBI IC3は、Kali365を2026年4月に初めて確認された新しいフィッシング基盤として警告しています。Kali365は主にTelegram上で配布され、Microsoft 365のアクセストークン取得や継続アクセスに悪用されると説明されています。
参考：FBI IC3 Public Service Announcement
https://www.ic3.gov/PSA/2026/PSA260521
Kali365は技術力の低い攻撃者でも悪用しやすい攻撃キットです
Kali365が危険視される理由は、攻撃に必要な機能がパッケージ化されている点です。
FBIの警告では、Kali365には以下のような機能があるとされています。
- AI生成によるフィッシング誘導文
- 自動化された攻撃キャンペーンテンプレート
- 標的ユーザーや組織を追跡するダッシュボード
- OAuthトークンを取得する機能
高度な知識を持たない攻撃者であっても、このようなサービスを使うことで、Microsoft 365環境を狙いやすくなります。
攻撃のテンプレート化と自動化が進むほど、中小企業や社会福祉法人のような比較的小規模な組織も標的になりやすくなります。
Kali365で狙われるのはパスワードではなく認証後の通行証です
Kali365で狙われるOAuthトークンは、ユーザーが正規のログインに成功した後に発行される、デジタルな「通行証」のようなものです。
この通行証が攻撃者に渡ると、攻撃者はパスワードを知らなくても、Outlook、Teams、OneDriveなどのMicrosoft 365サービスへアクセスできる可能性があります。
特にリフレッシュトークンが悪用されると、一定期間アクセスが継続するリスクがあります。
そのため、Kali365のような攻撃では、被害後にパスワードを変更するだけでは不十分なケースがあります。
Microsoft 365管理者が警戒すべき被害です
Microsoft 365は、メール、チャット、ファイル共有、予定表、社内文書などが集約される業務基盤です。
1つのアカウントが侵害されるだけでも、以下のような被害につながる可能性があります。
- Outlookのメール閲覧
- Teamsのチャット確認
- OneDriveやSharePoint上のファイル閲覧
- 取引先や職員へのなりすましメール送信
- 追加のフィッシングメール送信
- メール転送ルールによる情報流出
特に、個人情報、職員情報、請求関連資料、会議資料などをMicrosoft 365上で扱っている場合は注意が必要です。
Kali365は、Microsoft 365管理者にとって「MFAを入れた後に何を確認すべきか」を見直すきっかけになる脅威です。
OAuth攻撃とは？パスワードを盗まないMicrosoft 365侵害です
OAuth攻撃とは、OAuthの仕組みを悪用して、クラウドサービスへのアクセス権を奪う攻撃です。
OAuthは本来、安全性と利便性を高めるための仕組みです。しかし、悪意あるアプリへの同意や、デバイスコード認証の悪用によって、攻撃者にクラウドサービスへのアクセス権を渡してしまうことがあります。
OAuthはパスワードを渡さずに権限を委譲する仕組みです
OAuthは、簡単に言うとパスワードを相手に渡さず、必要な範囲だけアクセスを許可する仕組みです。
たとえば、外部アプリに「Microsoft 365の予定表を読み取る権限」だけを与えるようなケースで使われます。ユーザーがパスワードを外部アプリに教えなくて済むため、本来は安全性と利便性を両立する仕組みです。
一方で、ユーザーが悪意あるアプリに同意してしまったり、攻撃者のデバイス認証を手伝ってしまったりすると、その許可が攻撃に使われる可能性があります。
Microsoft Entra Blogでも、OAuth同意フィッシングは通常の認証情報フィッシングより利用者が気づきにくく、長期的で検知しにくいアクセスにつながる可能性があると説明されています。
参考：Microsoft Entra Blog「OAuth consent phishing explained and prevented」
https://techcommunity.microsoft.com/blog/microsoft-entra-blog/oauth-consent-phishing-explained-and-prevented/4423357
従来型フィッシングとOAuthトークン攻撃の違い
情シス担当者が社内や上層部に説明しやすいよう、従来型フィッシングとOAuthトークン攻撃の違いを表にまとめます。
| 項目 | 従来のフィッシング攻撃 | OAuthトークン攻撃（Kali365など） |
|---|---|---|
| 狙われる情報 | ID、パスワード | OAuthアクセス／リフレッシュトークン |
| ユーザーの画面 | 攻撃者が作った偽のログイン画面 | Microsoftの正規の認証・コード入力画面 |
| MFA（多要素認証） | MFA未設定なら侵害されやすい | ユーザーが正規にMFAを完了した後のトークンを悪用される可能性がある |
| 発覚後の有効策 | パスワード変更、MFA再設定 | セッション取り消し、リフレッシュトークン失効、不審なアプリ同意の削除 |
| 利用者が気づきにくい点 | URLや画面の違和感 | 正規のMicrosoft画面が使われるため違和感を持ちにくい |
この表で特に注目したいのは、ユーザーの画面が正規のMicrosoftページに見える点です。
従来型フィッシングでは、偽サイトのURLや画面の違和感で気づけることがありました。しかし、デバイスコード認証を悪用する攻撃では、Microsoftの正規ページでコード入力やMFA操作を行うため、利用者が「本物だから大丈夫」と判断してしまうリスクがあります。
そのため、職員向けには「Microsoftの画面かどうか」だけでなく、自分で開始していないコード入力や認証要求は止めるというルールを伝える必要があります。
デバイスコードフィッシングの流れとKali365の攻撃プロセス
Kali365を悪用した攻撃では、利用者が「正規のMicrosoftページ」で操作させられる点が厄介です。
代表的な流れを4ステップで整理します。
1. AI生成されたビジネスメールを受信する
攻撃の入り口は、メールやクラウド文書共有通知を装ったメッセージです。
最近のフィッシングメールは、AI生成により文章が自然になっている場合があります。以前のように、日本語が不自然だからすぐ分かる、という判断だけでは危険です。
Microsoftも、AIを使ったデバイスコードフィッシングキャンペーンでは、標的の役割に合わせたフィッシングメールや、ユーザーがリンクを操作した瞬間に有効なコードを生成する手法が使われたと説明しています。
参考：Microsoft Security Blog「Inside an AI-enabled device code phishing campaign」
https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/
2. 正規のMicrosoftページでコード入力を求められる
デバイスコードフィッシングでは、攻撃者が発行したデバイスコードを、被害者に入力させる流れが使われます。
たとえば、メールやTeamsで「このコードを入力して文書を確認してください」と誘導し、Microsoftの正規の認証ページへアクセスさせます。
URL自体がMicrosoftの正規ページである場合、利用者は安心してコードを入力し、MFAまで完了してしまうことがあります。
3. 攻撃者がOAuthトークンを取得する
ユーザーが正規の画面で認証を完了すると、攻撃者側がOAuthアクセストークンやリフレッシュトークンを取得する可能性があります。
アクセストークンは、サービスへアクセスするための許可証です。
リフレッシュトークンは、アクセストークンを更新するために使われます。
この2つが悪用されると、パスワードを知られていなくてもMicrosoft 365へのアクセスが成立する可能性があります。
4. Microsoft 365サービスへ不正アクセスされる
トークンを取得した攻撃者は、Outlook、Teams、OneDrive、SharePointなどへアクセスする可能性があります。
影響はメールだけに限りません。Teamsのチャット、OneDrive上のファイル、SharePointの共有資料、予定表など、業務情報全体が対象になります。
そのため、OAuth攻撃は「メールアカウントが乗っ取られるだけ」と軽く見ない方がよいです。
デバイスコード認証とMicrosoft Authenticator番号一致の違い
デバイスコード認証は、Microsoft Authenticatorで表示される番号一致やOTPとは別の仕組みです。
この違いは、職員向けに説明するうえでも重要です。
Microsoft Authenticator番号一致は自分のログインを承認するMFAです
Microsoft Authenticatorの番号一致は、自分が開始したサインインをスマートフォン側で承認するためのMFAです。
たとえば、PCでMicrosoft 365にサインインすると、画面に数字が表示されます。その数字をスマートフォン側のAuthenticatorアプリで入力または選択して、本人確認を完了します。
これは、自分が開始したログイン操作をスマートフォンで確認する仕組みです。
デバイスコード認証は別の端末やアプリを認証する仕組みです
一方、デバイスコード認証は、別の端末やアプリに表示されたコードをMicrosoftの認証ページへ入力し、その端末やアプリを認証する仕組みです。
本来は、スマートTV、プリンター、CLIツール、会議室端末など、通常のブラウザログインがしづらい端末で使われます。
攻撃では、攻撃者が発行したデバイスコードを利用者に入力させることで、攻撃者側のセッションを認証済みにしてしまう点が問題になります。
整理すると、次の違いがあります。
| 項目 | Microsoft Authenticator番号一致 | デバイスコード認証 |
|---|---|---|
| 目的 | 自分のログインを承認する | 別の端末やアプリを認証する |
| 操作する場所 | スマートフォンのAuthenticatorアプリ | Microsoftのデバイスログインページ |
| 攻撃で悪用されるポイント | 身に覚えのない承認を押してしまう | 攻撃者が発行したコードを入力してしまう |
| 職員への注意点 | 自分がログインしていない承認要求は拒否する | メールやチャットで指示されたコードを入力しない |
職員には、「Microsoftのコード入力を求められたら必ず怪しい」とまでは言い切れません。ただし、自分で開始していないコード入力は止めるというルールを徹底するのが現実的です。
Microsoft 365でMFA設定後に見落としやすい運用ポイント
Microsoft 365のMFA導入は、利用者への案内、初期登録の支援、スマートフォン変更時の対応など、管理者にとって負担の大きい作業です。
実際にMFA設定を進めると、技術的な設定そのものよりも、職員への説明や問い合わせ対応に時間を取られます。たとえば、認証アプリの初回登録、機種変更後の再設定、スマートフォンを持っていない利用者への対応などは、現場でつまずきやすいポイントです。
そのため、導入が完了すると「これでセキュリティ対応は一段落」と考えやすくなります。
ただし、Kali365のような攻撃では、MFA後のトークンが狙われます。これからのMicrosoft 365運用では、MFAを設定したかどうかだけでなく、認証フロー、サインインログ、セッション管理まで確認する必要があります。
職員に周知すべき具体的な行動ルール
職員に対して「不審なメールに注意してください」と伝えるだけでは、現場は判断しにくいです。
難しいOAuthの仕組みを説明するよりも、以下のような具体的な行動ルールに落とし込む方が効果的です。
- メールやチャットの指示に従って、Microsoftの画面に見覚えのないコードを入力しない
- 自分がログイン操作をしていないタイミングで、Microsoft Authenticatorの承認要求が届いても承認しない
- Teamsやメールで「至急確認」と急かされても、リンク先で追加認証やアプリ許可を求められたら一度止まる
- 違和感のある画面が表示されたら、操作を進めずスクリーンショットを撮って情シスへ連絡する
このルールは、メールやTeamsの社内周知にそのまま使えます。特に「自分で開始していない認証は止める」という表現にすると、技術に詳しくない職員にも伝わりやすくなります。
Microsoft 365管理者が優先して実施すべきOAuth攻撃対策
Kali365をはじめとするOAuth攻撃への対策として、Microsoft 365管理者が優先して確認したいのは、デバイスコードフローの制限、サインインログの監査、トークン保護や再認証の強制です。
FBIもKali365への対策として、デバイスコードフローの制限またはブロック、条件付きアクセスポリシーの作成、既存利用状況の監査、認証転送ポリシーのブロック、緊急アクセスアカウントのロックアウト対策を挙げています。
参考：FBI IC3 Public Service Announcement
https://www.ic3.gov/PSA/2026/PSA260521
条件付きアクセスでデバイスコードフローを制限する
最も優先して確認したい対策の一つが、条件付きアクセスポリシーによるデバイスコードフローの制限です。
デバイスコード認証は、キーボード入力が難しい端末や一部の業務機器では便利な仕組みです。一方で、一般的なPCやスマートフォンを使った日常業務では、利用していない組織も多いはずです。
まずは以下を確認します。
- 自社でデバイスコード認証を業務利用しているか
- Teams Roomsや共有端末など、正当な利用があるか
- どのユーザーやグループに必要か
- 全ユーザーでブロックしても業務影響がないか
- 例外にすべき業務プロセスがあるか
いきなり全社でブロックすると、正当な業務端末が認証できなくなる可能性があります。
そのため、条件付きアクセスポリシーを作成する前に、既存のデバイスコードフロー利用状況を監査することが重要です。
緊急アクセスアカウントのロックアウト対策を確認する
条件付きアクセスを強化する際に怖いのが、管理者自身のロックアウトです。
FBIは、デバイスコードフローを完全に制限できない場合、ロックアウト防止のため緊急アクセスアカウントを除外することにも触れています。
緊急アクセスアカウントは、いわゆるブレークグラスアカウントです。
ブレークグラスアカウントとは？
ブレークグラスアカウントとは、条件付きアクセスやMFA設定の誤りによって、管理者自身がMicrosoft 365へログインできなくなった場合に備えるための緊急用管理者アカウントです。
「ガラスを割って非常ボタンを押す（Break Glass）」という意味から名付けられています。
通常業務では利用せず、パスワードを厳重に保管し、障害発生時のみ利用します。
特にデバイスコードフローを制限する条件付きアクセスを導入する場合は、ブレークグラスアカウントをポリシー対象外にしておくことが推奨されています。
ただし、除外アカウントを作れば安心という話ではありません。以下の点を確認します。
- 緊急アクセス用アカウントを用意しているか
- そのアカウントを通常業務に使っていないか
- 条件付きアクセスの対象から適切に除外しているか
- 除外理由と管理方法を記録しているか
- 定期的にサインイン確認をしているか
- 強いパスワードと厳格な保管ルールを設けているか
緊急アクセスアカウントは、抜け穴として放置するものではありません。通常利用を禁止し、保管方法、利用記録、定期確認をセットで運用する必要があります。
Entra IDサインインログを定期的に監査する
不審なサインインの兆候は、ログを確認しなければ検知できません。
以下は、参考までに実際のサインインログから個人情報等を架空のID等に変更したものです。
小規模な組織で専用のSIEM（ログ監視システム）がない場合でも、月1回以上の定期チェックを運用ルールに組み込むことで、異常に気づける可能性があります。
確認したい観点は以下です。
- 普段の業務ではあり得ない国や地域からのサインイン
- 短時間で物理的に移動不可能な距離から行われたサインイン
- 不審なアプリケーション名
- デバイスコード認証に関連するサインイン履歴
- 管理者アカウントによる通常とは異なる時間帯やIPからのアクティビティ
ひとり情シスや小規模組織では、毎日ログを確認するのは難しいかもしれません。
まずは月1回、管理者アカウントと重要ユーザーから確認を始めるのが現実的です。
トークン保護と再認証強制を検討する
Microsoft Entra IDには、トークン悪用を抑えるための機能や、再認証を求める条件付きアクセス設定があります。
たとえばToken Protectionは、トークンリプレイ攻撃を減らすことを目的とした機能です。
考え方としては、発行されたトークンを特定のデバイスに結び付け、別端末からの再利用を難しくする対策です。
ただし、Token Protectionにはライセンス要件、対応アプリ、利用者への影響があります。いきなり全社適用するのではなく、まずは以下のように段階的に検証します。
- Microsoft 365の契約ライセンスを確認する
- 対応アプリケーションを確認する
- 管理者アカウントや一部ユーザーで検証する
- 業務アプリへの影響を確認する
- 問題がなければ対象範囲を広げる
Microsoft 365でトークン窃取が疑われる場合の初動対応
職員がフィッシングメールに応じてデバイスコードを入力してしまった場合や、不審なアプリを許可してしまった場合は、パスワード変更だけで終わらせない対応が必要です。
OAuthトークンが悪用されている可能性があるため、セッション、アプリ同意、メール転送ルール、MFA登録情報まで確認します。
パスワード変更とセッションの強制終了
まずパスワード変更は必要です。
ただし、攻撃者がすでに有効なトークンを保持している場合、パスワード変更だけでは不十分なケースがあります。
以下の対応をセットで実施します。
- 対象ユーザーのパスワードを変更する
- Microsoft Entra管理センターからセッションを取り消す
- リフレッシュトークンの失効を検討する
- 該当ユーザーに再サインインを求める
- サインインログで不審なアクセスを確認する
実施前には、対象ユーザーへの影響も確認してください。再ログインが必要になったり、業務アプリの接続が一時的に切れたりする可能性があります。
不正なアプリ同意の確認と削除
OAuth攻撃では、悪意あるアプリにアクセス権限が付与されている可能性があります。
Entra IDのエンタープライズアプリケーションやユーザーの同意状況を確認し、見覚えのないアプリがないか確認します。
確認したい観点は以下です。
- 最近追加された不審なアプリがないか
- 高い権限を持つアプリが追加されていないか
- メール、ファイル、ユーザー情報へのアクセス権が付与されていないか
- ユーザー同意で許可されていないか
- 管理者同意が不要な設定になっていないか
不審なアプリが見つかった場合は、アクセス権を取り消し、必要に応じてアプリ自体を削除します。
メール転送ルールとMFA登録情報を監査する
攻撃者は、アカウント内に潜伏するための設定を残すことがあります。
特に見落としやすいのが、メール転送ルールとMFA登録情報です。
以下を確認します。
- Exchange Onlineで外部アドレスへの転送ルールが作成されていないか
- Outlookの受信トレイルールに不審な条件がないか
- 攻撃者の電話番号や認証アプリがMFA方法として追加されていないか
- 追加されたデバイスや認証方法に見覚えがあるか
- Teamsで不審なメッセージ送信履歴がないか
攻撃者がメール転送ルールを設定していると、パスワード変更後も情報流出が続く可能性があります。
インシデント対応の記録を残す
あとから報告書を作るときに、記録が残っていないと調査が難しくなります。
小規模な組織でも、Excelやチケット管理表でよいので、初動対応の記録を残してください。
最低限、以下を記録します。
- 発生日時
- 発覚の経緯
- 対象ユーザー
- 使用端末
- 原因となったメールやTeamsメッセージ
- 不審なサインインIPアドレス
- 不審な国や地域
- 作成されたメールルール
- 実施した対応
- 関係者への報告日時
職員向け案内文テンプレート
以下は、Teamsやメールに貼り付けて使える職員向けの注意喚起文です。
自社の連絡先や運用に合わせて、情報システム担当の連絡先だけ差し替えて使ってください。
件名：【注意喚起】Microsoftのコード入力を求める不審な案内について
職員各位
お疲れ様です。情報システム担当です。
現在、Microsoft 365の正規の認証仕組みを悪用し、企業のデータを狙う巧妙なフィッシング攻撃が確認されています。
メールやチャット（Teamsなど）で「文書を確認するために、画面に表示されたコードを入力してください」といった案内が表示されても、ご自身が開始した操作ではない場合は、絶対にコードを入力しないでください。
URLが本物のMicrosoftページに見えても、攻撃者の罠である可能性があります。
■ 特に注意すべき具体的な状況
・メールや画面で突然、Microsoftのコード入力を求められた
・見覚えのない相手からの文書共有リンクを開いた際、不審なサインインを求められた
・自分がログインしていないのに、スマホの認証アプリに承認要求が届いた
・「至急確認」を理由に、普段とは違う手順でのログインやアプリの許可を求められた
少しでも「いつもと違う」「怪しい」と感じた場合は、そこで操作を中断し、画面のスクリーンショットを撮影したうえで、速やかに情報システム担当までご連絡ください。
組織のセキュリティ維持のため、ご協力をよろしくお願いいたします。このテンプレートでは、難しいOAuthの説明は省き、「自分で開始していないコード入力はしない」という行動ルールに絞っています。
職員向け周知では、専門用語を増やすよりも、操作を止める判断基準を明確にすることが重要です。
FAQ：OAuth攻撃とMicrosoft 365セキュリティ対策
Q. Kali365とは具体的にどのような脅威ですか？
A. Kali365は、Microsoft 365環境の侵害を目的に作られたサービス型フィッシング基盤（PhaaS）です。
AIを使った自然なメール文面や、デバイスコード認証の悪用により、パスワードではなく認証後のOAuthトークンを狙う点が特徴です。
Q. OAuth攻撃とは何ですか？
A. OAuth攻撃とは、OAuthの仕組みを悪用して、クラウドサービスへのアクセス権を奪う攻撃です。
パスワードを直接盗むのではなく、認証後に発行されるトークンや、悪意あるアプリへの同意を悪用するケースがあります。
Q. MFAを設定していても被害に遭う可能性はありますか？
A. あります。
Kali365などのトークン窃取攻撃では、利用者自身が正規のMicrosoftページでMFAを完了した後に発行される認証済みトークンが悪用される可能性があります。
MFAに加えて、条件付きアクセスやデバイスコードフローの制御が必要です。
Q. Microsoft Authenticatorの番号一致とデバイスコード認証は同じですか？
A. 別の仕組みです。
Authenticatorの番号一致は、自分が開始したサインインをスマートフォンで承認するMFAです。
一方、デバイスコード認証は、別の端末やアプリに表示されたコードをMicrosoftの認証ページへ入力し、その端末やアプリを認証する仕組みです。
Q. 怪しい操作をしてしまった場合、パスワード変更だけで安全ですか？
A. 不十分なケースがあります。
攻撃者がすでに有効なOAuthトークンを取得している場合、パスワード変更だけではアクセスが続く可能性があります。
パスワード変更に加えて、セッションの取り消し、リフレッシュトークンの失効、不審なアプリ同意の削除を確認してください。
Q. 中小企業や小規模テナントでも条件付きアクセスは必要ですか？
A. Microsoft 365に業務データや個人情報を保管している場合は、有効な防衛策になります。
ただし、設定を誤ると正規ユーザーや管理者がロックアウトされる可能性があります。
まずはライセンスと業務影響を確認し、一部ユーザーや管理者アカウントから段階的に検証することをおすすめします。
まとめ：OAuth攻撃対策はMFA導入後のMicrosoft 365運用で差が出ます
Kali365のような攻撃では、パスワードそのものではなく、認証後に発行されるOAuthトークンが狙われます。
Microsoft 365管理者は、MFAを導入して終わりにせず、デバイスコードフローの利用状況、条件付きアクセス、サインインログ、セッション失効の運用まで確認する必要があります。
まずは、自社環境でデバイスコードフローを業務利用しているかを確認し、月1回のサインインログ確認から着手するのが現実的です。
- Kali365はMicrosoft 365のOAuthトークンを狙うPhaaSです
- OAuth攻撃では、パスワードではなく認証後の通行証が狙われます
- デバイスコード認証はAuthenticatorの番号一致やOTPとは別の仕組みです
- パスワード変更だけでは不十分なケースがあります
- 条件付きアクセスで不要なデバイスコードフローを制限します
- Entra IDのサインインログを定期的に確認します
- 侵害時はセッション取り消しとリフレッシュトークン失効を確認します
