Microsoft 365の不正アクセス対策｜
MFAをすり抜ける攻撃と、管理者が最初に確認すべき7項目

いま起きている不正アクセスは「パスワードを盗まない」

1か月で340組織：デバイスコードフローを悪用する手口

2026年2月に登場した「EvilTokens」と呼ばれるフィッシングキャンペーンでは、最初の検出から約1か月で、340を超えるMicrosoft 365組織が侵害されました。フィッシング・アズ・ア・サービス（PhaaS）としてTelegram上のBotで提供されており、専門知識のない攻撃者でも実行できる形で流通しています。

この手口が厄介なのは、偽サイトを使わない点です。攻撃者は標的に「microsoft.com/devicelogin」という本物のMicrosoftのURLと確認コードを送ります。標的が本物の画面で本物のコードを入力し、本物のMFAを完了させる——その瞬間に、攻撃者側でOAuthのリフレッシュトークンが発行されます。

つまり利用者から見ると、不審な点がほとんどありません。ドメインは本物、証明書も本物、MFAも自分の端末で承認している。にもかかわらず、メール・OneDrive・Teamsへの継続的なアクセス権が攻撃者に渡ります。

AiTM（中間者型）との違い

もう一つ広く使われているのがAiTM（Adversary-in-the-Middle）です。こちらは攻撃者が用意したプロキシを経由させ、利用者が入力したID・パスワード・MFAコードをリアルタイムで中継しながら、発行されたセッションCookieを奪います。

両者の共通点は「認証情報ではなく認証結果を奪う」ことです。だからパスワードを変更しても、MFAを有効にしても止まりません。奪われたトークンが有効な間、攻撃者は正規ユーザーとして振る舞えます。多要素認証そのものの考え方はMFA（多要素認証）とは？で解説しています。

ここから導かれる実務上の結論は明快です。「MFAを入れたか」ではなく「トークンを守れているか」を基準に設定を見直す必要があります。

標準ライセンスでどこまで防げるのか

「対策にはE5が必要」と説明されることがありますが、上に挙げた攻撃を止める設定の大半はBusiness PremiumおよびE3に含まれるMicrosoft Entra ID P1の範囲で実施できます。2026年8月時点の主要プランの違いを整理します。

なお本記事の内容は、Microsoft 365（旧Office 365）のいずれのプランでも共通して確認すべき項目です。

ライセンスの内容は改定されます。上表は2026年8月時点の情報です。Business PremiumとE3のDefender for Office 365 Plan 1同梱は2026年7月時点の構成であり、契約内容によって異なる場合があるためご自身のテナントでご確認ください。

防げることと防げないことを正直に切り分けると、次のようになります。Business Premium／E3の範囲では、攻撃の「入口」を閉じることはできます。デバイスコードフローを止める、レガシー認証を止める、不審なOAuthアプリの同意を止める、といった設定です。

一方で、侵害が起きた「後」の検知と自動対処は弱くなります。サインインのリスクスコアに応じて自動でブロックする、権限を必要な時だけ付与する、といった機能はE5（Entra ID P2）の領域です。ここを埋める方法は、E5へのアップグレードだけではありません。詳しくは第4章で触れます。

管理者が最初に確認すべき7項目

優先度の高い順に並べています。①と②は影響範囲を確認したうえで、まず「レポート専用」モードで挙動を見てから有効化してください。

① デバイスコードフローをブロックする（最優先）

デバイスコードフローは、キーボード入力が難しい機器（会議室のディスプレイなど）のために用意された認証方式です。ほとんどの企業では業務で使っていません。使っていないのに有効なままだと、前述のEvilTokens型の攻撃の入口として残り続けます。Microsoftも、可能な限り一律でブロックすることを推奨しています。

設定手順は次のとおりです。Microsoft Entra管理センターにサインインし、［Entra ID］→［条件付きアクセス］→［ポリシー］を開いて［新しいポリシー］を選びます。［割り当て］→［ユーザーまたはワークロード ID］で「すべてのユーザー」を含め、緊急アクセス用アカウントを除外します。［ターゲット リソース］→［リソース］で「すべてのリソース」を選択します。［条件］→［認証フロー］で［構成］を「はい」にし、「デバイス コード フロー」にチェックを入れて［完了］。［アクセス制御］→［許可］で「アクセスのブロック」を選択します。最初は［ポリシーの有効化］を「レポートのみ」にして作成し、想定外の業務影響がないことを確認してから「オン」に切り替えます。

注意：ブロック前に、既存のデバイスコードフロー利用状況を必ず監査してください。更新できないレガシーツールが使っている場合があります。緊急アクセスアカウントとサービスアカウント（Entra Connect同期アカウント含む）は除外リストに入れ、除外リストは定期的に棚卸ししてください。

② 認証転送をブロックする

認証転送（Authentication transfer）は、PCからスマートフォンなど別の端末へサインイン状態を引き継ぐ機能です。これも悪用経路になり得ます。設定箇所は①と同じ［条件］→［認証フロー］で、「認証転送」を選んでブロックします。こちらは業務影響が読みやすいため、確認後に「有効」で作成して差し支えありません。

③ レガシー認証をブロックする

IMAP、POP、SMTP AUTH、古いOfficeクライアントなどが使う認証方式は、MFAに対応していません。ここが開いている限り、MFAを設定してもすり抜けられます。条件付きアクセスで「レガシー認証クライアント」を対象にブロックします。複合機からのスキャン送信やバックアップツールが使っている場合があるため、サインインログで「クライアントアプリ＝レガシー認証クライアント」を絞り込み、実際の利用元を洗い出してから実施してください。

④ OAuthアプリへの同意を管理者承認制にする

攻撃者は、正規のOAuthアプリに見せかけたアプリへの同意を利用者から取り、そのままトークンを取得します。既定では利用者が自分でアプリに同意できる設定になっている場合があります。［Entra ID］→［エンタープライズ アプリケーション］→［同意とアクセス許可］で、ユーザーの同意を「許可しない」または「検証済み発行元の限定的な権限のみ」に変更し、管理者承認のワークフローを有効にします。

あわせて、すでに同意済みのアプリの棚卸しを行ってください。新しく同意されたアプリを月次で確認する運用にすると、侵害の早期発見につながります。

⑤ トークン保護を適用する

トークン保護は、サインインセッションのトークンを端末に暗号的に紐付け、別の端末に持ち出されたトークンを使えなくする条件付きアクセスのセッション制御です。トークン窃取に対する直接的な対策になります。

ただし現時点では適用範囲に制限があります。Windowsは一般提供（GA）ですが、iOS／iPadOSとmacOSはプレビューです。また対応するのはネイティブアプリのみで、ブラウザ経由のアクセスは対象外です。対象リソースはExchange Online、SharePoint Online、Microsoft Teamsで、Windowsではこれに加えてAzure Virtual DesktopとWindows 365も対象になります。なおmacOSとiOS／iPadOSはMDM管理下の端末が前提です。

つまり「これを入れれば安心」という機能ではなく、①〜④で入口を閉じたうえで重ねる層と位置づけるのが実務的です。ゼロトラストの考え方でいう「認証は一度で終わりではない」という前提が、そのまま設計方針になります。

⑥ サインインログでトークンの異常利用を確認する

パスワード変更では止まらない攻撃なので、検知は「サインインの成否」ではなく「同一トークンが不自然な場所・端末から使われていないか」で見ます。［Entra ID］→［監視］→［サインイン ログ］で、同一ユーザーの短時間内における国・IP・デバイスの変化、および「認証要件＝単一要素認証」で成功しているセッションを確認します。監査ログの保持期間はライセンスにより異なるため、長期保存が必要な場合は外部への転送設定を検討してください。

この領域を体系的に扱う考え方はITDR（ID脅威検知・対応）で整理しています。

⑦ 緊急アクセスアカウントを整備する

①〜⑤の設定は、誤設定するとテナント全体から管理者がロックアウトされる可能性があります。条件付きアクセスの対象外とする緊急アクセス（ブレークグラス）アカウントを2つ用意し、パスワードを厳重に保管したうえで、除外設定に含めてください。これは対策そのものではありませんが、対策を安全に進めるための前提条件です。

設定できても「維持できない」という別の問題

ここまでの7項目を設定しきれば、既知の主要な侵入経路は塞がります。ただし実務では、設定した後のほうが難しいというのが率直な実感です。

理由は3つあります。1つ目は仕様変更です。Microsoftは2024年後半から管理ポータルへのMFAを段階的に必須化し、2025年10月1日からはAzure CLI／PowerShell／REST APIなどの作成・更新・削除操作にもMFAを要求するフェーズ2を開始しました（2026年7月1日を期限としていた延期申請の受付は終了し、現在は順次適用が進んでいます）。前提が変われば、既存の除外設定やサービスアカウントの扱いを見直す必要があります。

2つ目は設定のドリフトです。新しい業務ツールを導入するたびに一時的な例外を追加し、その例外が消されずに残ります。半年後には「なぜこの除外が入っているのか誰も分からない」状態になりがちです。

3つ目は監視の空白です。上記⑥のようなログ確認を、限られた人数で24時間365日続けるのは現実的ではありません。攻撃者が動くのは夜間と休日です。

この3つに対する解は、人を増やすか、設定の維持と一次対処を自動化するかのどちらかです。当社ではMicrosoft 365専用のセキュリティ運用自動化ツール「Overe」の国内代理店として、推奨設定の自動適用・設定ズレの自動修復・AIによる乗っ取り予兆の自動隔離を、既存プラン（Business Premium／E3）のまま追加できる形で提供しています。E5にアップグレードしなくても、E5にも無い「設定の自動維持」まで踏み込めるのが特徴です。

まとめ

Microsoft 365の不正アクセス対策で今日確認すべきことは、MFAの有無ではありません。デバイスコードフローと認証転送を止めているか、レガシー認証が残っていないか、OAuthアプリの同意が利用者任せになっていないか。この3点だけでも、いま流通している主要な手口の入口は大きく狭まります。

そして、設定は一度やれば終わりではなく、仕様変更と業務変化で必ずズレます。「設定する」だけでなく「維持する」ところまで設計してはじめて、対策になります。

自社のMicrosoft 365の設定が、推奨状態からどれだけ離れているかを無償で診断しています。現在のご契約プランのまま、アップグレードは不要です。診断では現在の設定と推奨設定の差分、CIS BenchmarkやNIST CSFに照らしたギャップ、優先的に対応すべきリスクをレポートでご報告します。

出典

• 「条件付きアクセス ポリシーを使用して認証フローをブロックする」Microsoft Learn
• 「Microsoft Entra 条件付きアクセス トークン保護」Microsoft Learn
• 「Plan for mandatory Microsoft Entra multifactor authentication」Microsoft Learn
• 「Microsoft Defender for Office 365 Plan 1 is now rolling out to Microsoft 365 E3 and Office 365 E3」Microsoft Community Hub
• 「Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure」Huntress（2026年3月20日）
• 「New widespread EvilTokens kit: device code phishing as-a-service - Part 1」Sekoia.io（2026年3月30日）