サインインログでアカウントの乗っ取りを確かめる｜見る列と、怪しいサインインの例（Entra ID）

たとえば、社員から「自分では何もしていないのに、多要素認証の確認がスマホに届いた」と言われたとします。多要素認証は、パスワードのあとにスマホのアプリなどでもう一段の確認を求める仕組みです。その確認が本人の知らないところで出たのなら、誰かがその人のパスワードでサインインしようとした疑いがあります。管理者は Entra 管理センターのサインイン ログを開きますが、列が多く、行も1回ごとに細かく並びます。どこを見れば「乗っ取られた（他人がその人としてサインインできた）」と言えるのかで、手が止まります。

この記事を読むと、サインイン ログのどの列を並べ、どこで絞り、1件のどのタブを見れば、「本人の操作」「パスワードは知られたが止まった」「本人でない『成功』」を分けられるかが分かります。当社は Microsoft 365 の導入を支援している会社で、この記事は検証用の環境でサインイン ログを開いて書きました。開いた画面では、一覧の［条件付きアクセス］の列が「適用されていません。」なのに、1件の詳細ではセキュリティの既定値群が「成功」と出ていて（1件で見ただけです）、その読み方も書きます。

サインイン ログの開き方と、遡れる日数

サインイン ログは、Entra ID（Microsoft 365 のアカウントを管理する仕組み）が、サインインの1回ごとに残す記録です。Learn（Microsoft の公式の技術文書のサイト Microsoft Learn）の手順では、Entra 管理センターの［Entra ID］>［監視 & 正常性］>［サインイン ログ］で開きます。見るのに要る最小の管理者ロールはレポート閲覧者です（Microsoft Learn「アクティビティ ログにアクセスする方法」）。ログの行はシステムが作るもので、変えることも消すこともできません。

撮った日（2026年11月6日）には、一覧の上に、このビューは間もなく新しいビューに置き換えられる、という帯が出ていました。列や絞り込みの並びは、新しいビューでは変わることがあります。

遡れる日数は、ライセンスで決まります（Microsoft Learn「Microsoft Entra のデータ保持」）。Business Premium には Entra ID P1 が入っているので、サインイン ログは30日分です（Microsoft Learn「Microsoft Entra licensing」）。P1 も P2 も無い会社（Entra ID Free）では、7日分しか残りません。後から P1 にしても、日数はさかのぼって延びません。Free で残っていた最大7日分より前は戻りません。

ですから、社員から話を聞いたら、その日のうちにログを開くことをお勧めします。Free の会社では、1週間たつと手がかりが消えます。［許可された時刻］の選択肢は「過去 1 か月」「過去 7 日間」「過去 24 時間」「カスタム期間」で、最初は「過去 24 時間」になっていました。もっと長く残したいときは、Azure Monitor でログを Azure のストレージなどに送る設定が要ります。この記事では扱いません。

なお、Entra 管理センターのサインイン ログと監査ログは、Microsoft Purview の監査ログ（ファイルを開いた・メールを送ったなどの記録）とは別のものです。サインイン ログで分かるのは「誰が、どこから、どのアプリに入ったか、入れなかったか」までです。入った後に何をしたかは、Microsoft 365 の監査ログの検索の記事の手順で調べます。

一覧には［ユーザーのサインイン (対話型)］と［ユーザーのサインイン (非対話型)］のタブがあります。非対話型は、アプリが本人の代わりに裏でトークン（サインイン済みであることを示す鍵のようなデータ）を更新したときなどの記録で、本人は何も入力していません。行がとても多いので、まず対話型から見ます。

この記事に関連するサービス

M365・Google Workspace の移行と設定の相談移行と設定を、1件から相談できます。詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →Google Workspace 導入・移行支援Gmail移行から権限設計・Gemini活用まで詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Notion 導入支援議事録・ナレッジ・タスクを一箇所にまとめる詳しく見る →

並べる列：既定の列に「クライアント アプリ」と「オペレーティング システム」を足す

開いたときの一覧の列は、［許可された時刻］［要求 ID］［ユーザー］［アプリケーション］［状態］［サインインのエラー コード］［IP アドレス］［場所］［条件付きアクセス］［エージェントのタイプ］［認証の要件］でした。選べる列は30以上あります（Microsoft Learn「ID アクティビティ ログをカスタマイズおよびフィルター処理する方法」）。乗っ取りを確かめるときは、既定の列に［クライアント アプリ］と［オペレーティング システム］を足すことをお勧めします。どちらも、本人の普段の使い方と違う行を見つけるのに使います。

［クライアント アプリ］を足すのは、古い方式のサインインを見つけるためです。IMAP4・POP3・認証済み SMTP のような古い方式（レガシ認証）は、多要素認証をサポートしていません（Microsoft Learn「レガシ認証をブロックする」）。Microsoft Learn「パスワード スプレーの調査」は「ほとんどの攻撃でレガシ認証が使用されます」と書いています。メールソフトの設定で古い方式を使っている社員がいないなら、この列に古い方式が出た行は、まず疑います。

読むときに間違えやすい点が2つあります。1つ目は場所です。場所は IP アドレスから推定したもので、IP アドレスとその機器が実際にある場所には明確な関係がありません。携帯の回線や VPN では、使っている所から遠く離れた場所が出ることがあります（Microsoft Learn「サインイン ログのアクティビティの詳細について」）。2つ目は日時です。表示される時刻は、サインインした人ではなく、ログを見ている管理者のタイム ゾーンに合わせたものです。海外からの行の時刻は、現地の時刻ではありません。

本人の行に絞り、普段と違う行を探す

次に、［フィルターの追加］で絞ります。［ユーザー］で本人だけにし、期間を「過去 1 か月」か、話を聞いた日の前後の［カスタム期間］にします。［状態］の選択肢は「成功」「失敗」「中断」の3つです。ここで「失敗」だけに絞らないことが大事です。他人が入れた行は「成功」に出るからです。

本人の行が並んだら、IP アドレス・場所・アプリケーション・クライアント アプリ・オペレーティング システムの列を上から見て、普段と違う行を探します。Microsoft Learn「パスワード スプレーの調査」は、ユーザーが以前にその OS・IP・回線の事業者・デバイス・ブラウザーを使っていたかを確かめ、使ったことがなく異常なら、その人のすべての操作を調べるよう書いています。本人に「この日のこの時刻に、どこから何で入りましたか」と聞き、本人の操作だと分かった行は、そこで外します。

怪しい行が見つかったら、その行の IP アドレスで絞り直します。同じ IP アドレスから、ほかの社員にもサインインが試されていないかを見るためです。パスワード スプレーの調査の手順も、攻撃の IP アドレスを特定し、その期間と IP アドレスで成功したサインインを絞り込む順で書かれています。

同じ IP アドレスで、［ユーザーのサインイン (非対話型)］のタブも見ておくことをお勧めします（当社の読み方です）。リスク検出の一覧では、P2 の検出の1つ「見慣れないサインイン プロパティ」が非対話型のサインインで出たときは、トークン リプレイ攻撃（盗んだトークンを使い回す攻撃）のおそれがあるので、より詳しく調べるとしています（Microsoft Learn「リスク検出の種類」）。ログを目で見るときも、本人が何も入力していない非対話型の行に、本人の普段と違う IP アドレスが出ていないかは見ておく値打ちがあります。

当社の検証用の環境で過去24時間の対話型を見たときは、読み込まれた50行がすべて「成功」でした（続きはまだ読み込める状態でした）。期間を「過去 1 か月」にして「失敗」に絞ると、1行だけ出ました。この1行は、次の節で開きます。

1件を開いて、5つのタブを見る

行を選ぶと「アクティビティの詳細: サインイン」が開きます。タブは［基本情報］［場所］［デバイス情報］［認証の詳細］［条件付きアクセス］［レポート専用］［認証イベント］［追加の詳細］の8つでした。乗っ取りを確かめるときに見るのは、このうち5つです。

［基本情報］：状態と、失敗の理由

［基本情報］には、状態・サインインのエラー コード・アプリケーション・クライアント アプリなど、1件のほとんどの情報が並びます。［認証の要件］も出ますが、これはアプリの側が求めた認証で、実際にどこまで認証したかとは限りません。この欄は、サインインの途中で達成された認証を表さないことがあります（Microsoft Learn「サインイン ログのアクティビティの詳細について」）。どこまで通ったかは［認証の詳細］で見ます。

失敗した1件を開くと、［サインインのエラー コード］と［エラーの理由］が出ます。エラーの理由は英文のままでした。前の節で失敗に絞って出た1行のエラー コードは 50079 でした。Learn のエラー コードの一覧では、管理者が行った構成の変更などのために、ユーザーが多要素認証を使う必要がある（セキュリティ情報の登録が要る）という意味です（Microsoft Learn「Microsoft Entra 認証と承認のエラー コード」）。この1件は［条件付きアクセス］のタブで多要素認証の要求が「失敗」だったので、この記事の分け方では「パスワードは合ったが止まった」の形に入ります（この1件の［認証の詳細］は開いていません）。ただ、多要素認証を登録する前の本人のサインインでも同じ形の行は出るので、何の操作だったかまでは、記録からは決められません。

［場所］と［デバイス情報］：本人の回線と端末か

［場所］には、IP アドレス・場所と、自律システム番号（その IP アドレスを持つ回線の事業者を表す番号）が出ます。同じ回線の事業者なら、IP アドレスが変わっても自律システム番号は同じことが多いので、本人の普段の行と見比べるのに使えます（当社の読み方です）。下には、条件付きアクセスに登録した場所（ネームド ロケーション）に当たったかも出ます。場所の登録のしかたは、条件付きアクセスで IP と国を指定する記事に書いています。

［デバイス情報］には、ブラウザー・オペレーティング システムと、［準拠している］［マネージド］（会社が管理している端末か）が出ます。会社の端末を Intune で管理している会社なら、疑いの行で［マネージド］が「いいえ」のとき、会社が管理していない端末から入った見込みが高くなります（当社の読み方です）。端末の準拠の判定はIntune のコンプライアンス ポリシーの記事に書いています。

［認証の詳細］と［条件付きアクセス］：どこまで通ったか

［認証の詳細］には、使った認証方法の順と、それぞれが成功したかが並びます。パスワードの段が成功し、多要素認証の段が成功していなければ、パスワードは合っていたことになります。上には、適用された認証のポリシー（条件付きアクセスや、セキュリティの既定値群など）も出ます。サインインの直後は、ログが集計されきるまで、このタブの内容が不完全なことがあります（Microsoft Learn「サインイン ログのアクティビティの詳細について」）。

［条件付きアクセス］には、当たったポリシーと、その結果（成功・失敗）が出ます。撮った成功の1件では、一覧の［条件付きアクセス］の列は「適用されていません。」でした。ところが詳細のタブには［セキュリティの既定値群］が「成功」で出ていました（1件で見ただけです）。ポリシーで止めたかどうかは、一覧の列ではなく、このタブで確かめることをお勧めします。失敗の1件では、同じ［セキュリティの既定値群］の「多要素認証を要求する」が「失敗」でした。

このタブの下には、リスクのポリシーでサインインが中断されることもあるが、このタブに出るのは条件付きアクセスのポリシーだけだ、という説明が出ていました。リスクのポリシーは、後の節で書く Entra ID P2 の機能です。ポリシーの読み方と、止められた社員から相談されたときの見方は、条件付きアクセスの設定方法の記事に書いています。

怪しいサインインの例：危ないのは「成功」と、パスワードの後で止まった行

ここからは、ログにどう出たら怪しいかを、Microsoft の説明にある例から並べます。撮った環境では、こうした行は見ていません。

Microsoft Learn「パスワード スプレーの調査」は、調べた結果を次の順で扱うよう書いています。既知の攻撃者の IP アドレスからの「成功」、同じく「中断」、同じく「失敗」、そしてほかの見知らぬ IP アドレスからの「成功」です。また、パスワードは通ったが多要素認証で失敗した応答も記録するよう書いています。攻撃者がパスワードを手に入れたが、多要素認証は通れていないことを示すからです。

一方、パスワードの段で失敗した行は、その試行では入られていません。50126 はユーザー名かパスワードが違うという意味です。同じ IP アドレスから何人ものアカウントに 50126 が並び、間隔が規則的なら、よくあるパスワードを多くのアカウントに試すパスワード スプレーが疑われます。50053 は、何度も間違えてロックされたか、悪意のある活動に使われた IP アドレスからのサインインとして止められた、という意味です。

53003 は、条件付きアクセスのポリシーが止めたという意味で、入られてはいません。ただ、条件付きアクセスは1つ目の認証（多くはパスワード）が済んだ後に評価されます（Microsoft Learn「条件付きアクセス: ネットワーク割り当て」）。そのため、53003 で止まった行は、パスワードは合っていたと読めます。止まったから安心ではなく、パスワードを変える理由になります（当社の読み方です）。

冒頭の「本人が操作していないのに多要素認証の確認が届いた」も、怪しい例の1つです。リスク検出の説明は、ユーザーが始めていない多要素認証の要求は、資格情報が侵害されていることを意味する可能性がある、と書いています（Microsoft Learn「リスク検出の種類」）。ログでは、本人に聞いた時刻の前後に、本人の普段と違う IP アドレスからの行が無いかを探します。

3つに分けたら、止めてから調べる

本人の操作だったと分かったら、何もしません。本人に確かめた日と、見た行を残しておくと、次に同じ人から相談されたときに比べられます。

本人に聞いても分からない行もあります。多要素認証の登録の前だったなど、本人の側の理由でも、パスワードの後で止まった行は出るからです。前の節の 50079 の1行も、何の操作だったかは分かっていません。決めきれない止まった行は、止まった行と同じに扱い、パスワードをリセットすることをお勧めします。本人は新しいパスワードで入り直す手間がかかりますが、他人にパスワードを知られたままにするより小さい手間です（当社の考え方です）。登録の段で止まった行なら、本人の認証方法に知らない方法が足されていないかも、あわせて見ます（後の段落）。本人が覚えていない「成功」の行は、本人でない「成功」として扱います。

パスワードは合ったが止まった行があれば、パスワードをリセットします。同じ IP アドレスからほかの社員にも試されていないかを、IP アドレスで絞って見ます。まだ多要素認証を全員に求めていない会社は、多要素認証を全員に有効にする記事を先に読んでください。パスワードだけのアカウントは、パスワードが合った時点で入られます。

本人でない「成功」の行があれば、多要素認証を通った行でも、求められずに通った行でも、まず止めます。侵害されたアカウントは、すべてのアクセスを取り消す必要がある場面の1つに挙がっています（Microsoft Learn「Microsoft Entra ID でユーザー アクセスを取り消す」）。パスワードのリセット、すべてのセッションからのサインアウト（Entra 管理センターでは［セッションの取り消し］）、サインインのブロックの3つは、効き始めるまでの時間が違います。手順と時間は退職者のアカウントの処理の記事の「サインインを止める3つ」に書いています。

止めた後に、2つを調べます。1つは、本人の認証方法に、本人の知らない電話番号やアプリが足されていないかです。入った人が自分のスマホを登録していれば、パスワードを変えても多要素認証を通れてしまいます。認証方法の見方と消し方は多要素認証のリセットと再登録の記事に書いています。もう1つは、入った後にファイルを開いた・ダウンロードしたなど、何をしたかで、監査ログの検索の記事の手順で調べます。

Business Premium で、Microsoft の自動の検出はどこまで見えるか

Entra ID には、危険なサインインを Microsoft が自動で見つける ID Protection という機能があります。ただ、この機能を全部使うには Entra ID P2 が要ります（Microsoft Learn「Microsoft Entra ID Protection とは」）。Business Premium に入っているのは P1 です。P1 では、危険なサインインのレポートは見られても、リスクの詳細やレベルは出ません。

リスク検出の一覧では、Free と P1 でも名前つきで出る検出は一部です。匿名 IP アドレス（Tor ブラウザーや匿名化の VPN からのサインイン）、漏洩した資格情報（有効なパスワードが既知の流出に出た）、Microsoft Entra の脅威インテリジェンスなどです。新しい国・非定型旅行（Atypical travel）・パスワード スプレーなどの多くの検出は P2 が要り、P2 が無い会社では「検出された追加のリスク」という名前だけで出ます。

Business Premium の会社が P2 を使うには、Entra ID P2 を足すか、Microsoft Defender Suite for Microsoft 365 Business Premium のような追加の製品が要ります。英語版の Learn のライセンスのページに書かれています。2026年11月6日に見た日本語版の同じ箇所は訳が崩れていて、Business Premium に P2 が入っているように読めるので注意してください。P2 を足すかどうかとは別に、P1 の会社でもサインイン ログは自分で読めます。ここまでの見方は、P1 のままで使えます。

相談が来る前に、列を足しておく

相談が無くても、一度、自分のアカウントでサインイン ログを開き、［クライアント アプリ］と［オペレーティング システム］の列を足して保存しておいてください。いざというときに、列を探すところから始めずに済みます。管理者のアカウントと緊急用のアカウントのサインインを定期的に見る方法は、管理者ロールと緊急用アカウントの記事に書いています。当社では、サインインの守り方の設計を含めた Microsoft 365 の導入支援も行っています。