Microsoft Sentinel の SigninLogs で「Office 365 Management」が ConditionalAccessStatus=notApplied、AuthenticationRequirement=singleFactorAuthentication と出ると、MFA が効いていないように見えて焦ります。本記事では原因の切り分け、侵害時の影響、確認すべきログ項目と対策を解説します。
現象：SigninLogs に「Office 365 Management」が出てきて、MFA が効いていないように見える
調査でよく出てくるのが、次のようなサインイン記録です。見た目だけだと「単要素で成功している」「条件付きアクセスが適用されていない」と読めてしまい、強い違和感につながります。
| フィールド | 例 | ぱっと見の解釈 | 落とし穴 |
|---|---|---|---|
| AppDisplayName | Office 365 Management | 未知のアプリがログインしている？ | Microsoft の正規アプリ（ファーストパーティ）として記録される名前の一つ |
| AppId | 00b41c95-dab0-4487-9791-b9d2c32c80f2 | 攻撃者が作ったアプリ？ | テナント内にある「エンタープライズ アプリケーション」のサービスプリンシパルとして見える |
| AuthenticationRequirement | singleFactorAuthentication | MFA が要求されていない | 「その試行が MFA まで到達していない」だけでもこう見える |
| ConditionalAccessStatus | notApplied | 条件付きアクセスが無効／穴がある | 第一要素で失敗した場合など、評価されないケースで normal に出る |
| ResultType | 0（成功）または 50126（資格情報不正）など | 成功なら危険、失敗なら安心？ | 「成功でも notApplied」があり得るため、追加の項目での切り分けが必須 |
重要ポイント
ConditionalAccessStatus が notApplied だからといって、直ちに「MFA バイパス」や「条件付きアクセスの不具合」とは限りません。まずは ResultType（結果コード）と FailureReason（失敗理由）で、第一要素で落ちているだけかを確認します。
「Office 365 Management」アプリの正体
「Office 365 Management」は、Microsoft 365 の管理系ワークロードに紐づく Microsoft の正規アプリケーションとしてサインインログに現れます。特に現場でよく遭遇するのが、Microsoft 365 管理モバイルアプリ（Microsoft 365 Admin アプリ）のサインイン時に、裏側でこのアプリへのサインインが発生するパターンです。
ユーザーが iOS / Android の Microsoft 365 Admin アプリを開いてログインしようとすると、画面上は「Microsoft 365 Admin にログイン」ですが、ログとしては「Office 365 Management」へのサインインが記録されます。つまり、一覧で見えたからといって「誰かが勝手に追加した怪しいアプリ」という扱いにはなりません。
ただし、Microsoft の正規アプリであっても、それを使ってログインした主体（ユーザー）が誰で、どの権限を持つかによってリスクは大きく変わります。次章以降で、notApplied の理由と、成功した場合の影響を整理します。
なぜ ConditionalAccessStatus が notApplied になるのか
結論から言うと、今回のような調査で多いのは次のケースです。
- サインイン試行が ユーザー名＋パスワード（第一要素）の時点で失敗している
- 条件付きアクセス（Conditional Access）は、第一要素が成功した後に評価・適用される
- そのため、第一要素で失敗していると ConditionalAccessStatus が notApplied になる（＝評価されていない）
現場での切り分けに役立つよう、サインインの流れを「観測できるログのポイント」に寄せて整理します。
| フェーズ | 起きていること | ログで見える代表例 | この時点でのCA |
|---|---|---|---|
| 第一要素の入力 | ユーザー名＋パスワードを検証 | ResultType が 50126（資格情報不正）など | 評価されない（notApplied になりやすい） |
| 第一要素が成功 | サインイン要求が先へ進む | ResultType が 0（成功） | ここから評価（適用/ブロック/MFA要求など） |
| 条件付きアクセス評価 | ポリシー条件に合うか判定 | ConditionalAccessPolicies に適用ポリシーが列挙 | applied / failure / notApplied（条件未一致など） |
| MFA/ブロック/セッション制御 | MFA を要求、またはブロック、セッション制御 | AuthenticationRequirement が multiFactor になったり、失敗コードが出る | 要求・制御が実行される |
今回のログが示す意味（50126 の場合）
調査の途中経過として「Office 365 Management」へのサインインが不審 IP からのみ発生し、さらに結果コードが 50126（ユーザー名またはパスワードが不正）で揃っている場合、次の読み方になります。
- 攻撃者（または自動化ボット）が、ユーザー名とパスワードの組み合わせを試している
- しかし第一要素で失敗しているため、MFA 以前で止まっている
- その結果として ConditionalAccessStatus は notApplied と記録されることがある
このパターンは「MFA を回避された」というより、パスワードスプレー／ブルートフォースの試行として取り扱うのが実務的です。
ログの読み間違いを防ぐ：ResultType と notApplied の組み合わせで判断する
ConditionalAccessStatus だけを単独で見ると誤判定しやすいので、最低でも「ResultType」「FailureReason」「IsInteractive」をセットで見る運用をおすすめします。
| ResultType の例 | 状況の目安 | ConditionalAccessStatus が notApplied に見える理由 | まず取るべきアクション |
|---|---|---|---|
| 50126 | 資格情報不正（第一要素で失敗） | CA 評価まで到達していない | 同一IP/多ユーザー/短時間集中など「スプレー」兆候を集計する |
| 50053 | Smart Lockout 等で一時ロック | 第一要素で失敗している | ロックアウトの増加は攻撃兆候。該当ユーザーへの周知と監視強化 |
| 0 | 成功 | 「ポリシー対象外」または「非インタラクティブ」など複数要因 | ポリシー適用状況、サインイン種別、適用除外、直前の MFA 成功を確認 |
「正規サインインでも notApplied が多い」ように見えるときの典型パターン
「MFA を必須にしているのに、正規ユーザーのサインインでも notApplied が見える」という相談もよくあります。これは設定不備の場合もありますが、ログの見え方の仕様でそう見えることもあります。
| パターン | ログの特徴 | 不具合かどうかの見分け方 | 対処の方向性 |
|---|---|---|---|
| 第一要素で失敗しているだけ | ResultType が 50126 等で失敗、notApplied | FailureReason がパスワード不正なら想定通り | 攻撃対策（スプレー対策・監視）へ |
| 非インタラクティブなトークン更新 | IsInteractive=false、ResultType=0、notApplied に見えることがある | 同ユーザーの直近に MFA を伴うインタラクティブ成功がないか確認 | まずは関連ログを時系列で紐付ける（相関IDなど） |
| ポリシーの対象外（ユーザー/グループ/アプリ/条件） | ResultType=0 でも notApplied、ConditionalAccessPolicies が空 | 該当ユーザーが除外に入っていないか、アプリが含まれているか確認 | CA のスコープを再点検し、例外を最小化 |
| サービスプリンシパルや自動処理 | ユーザー主体ではなくアプリ主体のログ（別テーブルに出ることも） | ユーザーのMFAとは別の話。資格情報（証明書/シークレット）管理が論点 | アプリの資格情報ローテーション、権限棚卸し |
攻撃者が「Office 365 Management」でサインインできたら何ができる？
ここが一番気になるポイントですが、結論はシンプルです。
- 侵入に成功すると、サインインに使われたユーザーに割り当てられたロール／権限の範囲で、Microsoft 365 の管理機能にアクセスできます。
- 逆に、管理者ロールを持たない一般ユーザーであれば、管理操作（ユーザー作成・設定変更など）は原則できません。
- ただし「一般ユーザーだから無害」とは限らず、アカウント乗っ取り自体は別のアプリ（Outlook、Teams、OneDrive など）への横展開に直結します。今回のログが攻撃兆候なら、全体の防御を強化すべきです。
「どのロールならどこまで危険か」を整理すると、対応の優先度が付けやすくなります。
| アカウントの立ち位置 | 想定される到達範囲 | 悪用例 | 守り方の要点 |
|---|---|---|---|
| 一般ユーザー（管理ロールなし） | 管理アプリ内の機能は限定的（多くは閲覧不可） | 直接の「テナント設定変更」は難しいが、アカウント自体の悪用（別アプリでの情報窃取・内部偵察）は起こり得る | パスワードレス、フィッシング耐性MFA、サインインリスク検知、侵害指標の追跡 |
| ライセンス管理者等の限定管理者 | ライセンス付与/回収、割り当て状況の参照 | ライセンス付与で不正ユーザーを有効化、痕跡を紛れ込ませる | 管理ロールの最小化、PIM によるJIT付与、強いMFAと場所制限 |
| ユーザー管理者 | ユーザー/グループの一部管理、パスワードリセット等 | パスワードリセットでアカウント乗っ取り拡大、グループ操作で権限拡張の足場を作る | 管理者専用アカウント分離、管理操作の監査、特権操作のアラート |
| グローバル管理者（Global Administrator） | テナント全体の管理（最強権限） | 新規管理者作成、条件付きアクセス変更、監査無効化、各サービス設定変更など重大インシデント | フィッシング耐性MFA（FIDO2等）、固定端末/準拠デバイス、アクセス元制限、Break Glass 運用 |
Microsoft Sentinel での調査手順：最短で「問題の種類」を切り分ける
「不審 IP から Office 365 Management が出た」という事象は、①認証失敗の攻撃兆候なのか、②成功しているのにCAが効いていない設定不備なのかで対応が大きく変わります。ここでは、現場で迷わないための順番で整理します。
手順1：対象アプリのサインインを一覧化する
まずは「いつ・誰が・どこから・成功/失敗」を機械的に並べます。疑いがある期間（例：直近30日）を切って、アプリIDで固定して追うのがおすすめです。
SigninLogs
| where TimeGenerated > ago(30d)
| where AppId == "00b41c95-dab0-4487-9791-b9d2c32c80f2"
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, ResultDescription,
ConditionalAccessStatus, AuthenticationRequirement, IsInteractive, ClientAppUsed, UserAgent
| order by TimeGenerated descここで ResultType=50126 が並ぶなら「第一要素失敗が続いている」可能性が高く、MFA バイパスではありません。一方で ResultType=0（成功）が混ざる場合は、次の手順で「成功＋notApplied」の理由を潰します。
手順2：成功しているサインインだけ抽出して CA の挙動を確認する
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == 0
| where AppId == "00b41c95-dab0-4487-9791-b9d2c32c80f2"
| project TimeGenerated, UserPrincipalName, IPAddress, ConditionalAccessStatus,
AuthenticationRequirement, IsInteractive, ConditionalAccessPolicies, AuthenticationDetails
| order by TimeGenerated descこの結果を見て、次を確認します。
- IsInteractive：true ならユーザー操作のサインイン（MFA が絡みやすい）／false ならトークン更新等の可能性
- ConditionalAccessPolicies：適用されたポリシーが列挙されているか（空なら対象外の疑い）
- AuthenticationDetails：MFA が実施された記録があるか（動的配列で入っていることが多い）
手順3：パスワードスプレーの兆候を数で把握する
不審 IP が多い／同一 IP から多数のユーザーを叩いている、などの特徴を集計します。パスワードスプレーでは「短時間に複数ユーザーへ同一パスワードを試す」挙動になりがちです。
// IPごとの試行数とユニークユーザー数（スプレー兆候）
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 50126
| summarize Attempts=count(), Users=dcount(UserPrincipalName), Apps=make_set(AppDisplayName, 5) by IPAddress
| order by Attempts desc// ユーザーごとの「多IP」攻撃（分散試行）の兆候
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 50126
| summarize Attempts=count(), IPs=dcount(IPAddress), IPList=make_set(IPAddress, 10) by UserPrincipalName
| order by Attempts desc集計して「狙われているユーザー（特に管理者）」が見えたら、優先度を上げて防御します。
Entra ID（Azure AD）側での確認：条件付きアクセスが本当に効いているかを検証する
「CA を全ユーザーに適用しているつもり」でも、現場では例外やスコープ漏れが起こりがちです。特に、次の観点は必ず棚卸しします。
| 確認観点 | よくある落とし穴 | 確認のコツ |
|---|---|---|
| 対象ユーザー/グループ | 緊急用アカウントや一部グループが除外のまま | 「除外」一覧を最優先で確認。除外があるなら監視ルールで補う |
| 対象クラウドアプリ | 「全クラウドアプリ」ではなく特定アプリだけを対象にしていて漏れる | 管理系アプリを含めたいなら、まず「全クラウドアプリ」＋最小限の除外が安全 |
| ポリシーの状態 | Report-only のまま運用されていた | Report-only だとログ上は評価されても強制されない。状態を必ず確認 |
| クライアントアプリ条件 | ブラウザーのみ対象にしていて、モバイルアプリ/デスクトップが抜ける | 「クライアントアプリ」でモバイル/デスクトップ/ブラウザーを意図通り含める |
また、机上の確認だけでは不安が残るため、条件付きアクセスの「What If」（シミュレーション）や、テストユーザーでのサインイン検証を行い、「Office 365 Management」がどう評価されるかを再現しておくと安心です。
対策の優先順位：まずは「管理者アカウント」と「スプレー対策」から固める
今回のように不審 IP から 50126 が継続する状況は、攻撃が止まっていないサインです。実害がないうちに、次の順番で固めるのが現実的です。
管理者アカウントの分離と強化（最優先）
- 管理者アカウントは通常利用アカウントと分離し、メールやTeamsなど日常用途に使わない
- 管理者にはフィッシング耐性の強い認証（FIDO2 など）を優先
- アクセス元を厳しく（特定IP、準拠デバイス、管理端末）
- PIM（Privileged Identity Management）で「必要な時だけ」ロール付与する
パスワードスプレーを前提にした防御
- Smart Lockout の挙動を把握し、ロックアウトが増えたときの運用（通知・解除手順）を整備
- 弱いパスワードを排除し、できればパスワードレスへ
- 国・地域やIP帯での制限を検討（業務要件と衝突しない範囲で）
- Entra ID P2 があるなら、サインインリスク／ユーザーリスクのポリシー活用
Sentinel で「検知→一次切り分け→封じ込め」までの型を作る
「見つけたら都度調査」だと疲弊するので、型を作ると強いです。以下は一例です。
| 目的 | 監視/検知の例 | アクション例 |
|---|---|---|
| スプレー検知 | 50126 が短時間に多ユーザーへ発生、同一IPで増加 | 攻撃元IPのブロック検討、対象ユーザーへ通知、パスワード変更誘導 |
| 管理者への攻撃優先検知 | 管理者ロール保有ユーザーへの 50126 を高優先度アラート | 即時に追加防御（強いMFA適用、アクセス元制限、サインイン履歴確認） |
| 成功＋notApplied の異常検知 | ResultType=0 かつ notApplied を検知し、対象ユーザー/アプリを絞る | CA スコープ漏れの棚卸し、例外の削減、サポート問い合わせの判断材料化 |
よくある質問：この事象は「侵害済み」のサイン？
ログだけで「侵害済み」と断定するのは危険ですが、次のように整理すると判断しやすくなります。
| 状況 | 可能性 | 優先度 |
|---|---|---|
| ResultType=50126 が不審IPから大量発生、成功はゼロ | スプレー/ブルートフォース試行。現時点で侵害の証拠は薄い | 中〜高（放置すると突破されるリスク） |
| ResultType=0 が不審IPから発生し、同時に notApplied が継続 | CA のスコープ漏れ、または既存セッション/非インタラクティブ等の可能性。要精査 | 高（追加調査が必要） |
| 管理者アカウントで成功が発生 | 重大インシデントの可能性。即時対応が必要 | 最優先 |
もし「成功＋notApplied」が説明できず、CA ポリシーやログの見え方の範囲で切り分けが困難な場合は、相関IDや該当ログのエクスポートを添えて Microsoft サポートへ調査依頼するのが現実的です。自力で追える範囲には限界があり、ログ内部の評価経路はサポート側のほうが早いことがあります。
まとめ：Office 365 Management の notApplied を恐れる前に、まずは「どこで止まっているか」を見極める
- 「Office 365 Management」は Microsoft 365 Admin（管理モバイルアプリ）などに紐づく 正規の管理系アプリとしてログに出ます。
- 条件付きアクセスは 第一要素認証が成功した後に評価されるため、パスワード不正（50126）で止まっている試行は notApplied になり得ます。これは MFA 回避ではなく正常な見え方です。
- 侵入が成功した場合の影響は、そのユーザーの管理ロール次第です。特に管理者アカウントは最優先で強化します。
- 正規サインインで notApplied が見える場合は、非インタラクティブ、スコープ漏れ、例外設定などを疑い、ログをセットで確認します。
コメント