はじめに
こんにちは！横浜情報機器株式会社のインターン生ロホマン シャヒンです。
2026年10月4日、日本経済新聞社が「社員の Microsoft 365 アカウントが不正にログインされ、なりすましメール約9000件が送信された」と公表しました。公式発表には侵入経路が書かれていないので、原因は推測しません。ただ、ウイルスで画面が止まるわけでもなく、正規のアカウントとして静かにメールを送られるタイプの被害は、どの会社でも起きうると感じました。
じゃあ、自社のテナントは今「侵入されていない」と言い切れるのか。その確認方法を整理してみました。
1. なぜログ確認が重要なのか
最近の攻撃は静か
ランサムウェアのように業務を止める攻撃は、嫌でも気付きます。一方でアカウント乗っ取りは、正規ユーザーとしてログインして、メールを送る・情報を読むだけで終わることがあります。画面にも通知にも何も出ません。
日経新聞社の事例も、公式発表を読む限り「社員のアカウントに不正ログインされ、なりすましメールが送られた」という流れです。サーバーの異常ではなく、アカウントの動きから見えてくる種類の被害でした。
サーバーより先にアカウントが狙われる
Microsoft 365 を使っている会社では、メールもファイルも Teams も Entra ID のサインインが入口です。フィッシングやトークン窃取で認証済みセッションを奪われると、攻撃者は「本人」として動けます。
こうなると「侵入を防ぐ」だけでは足りず、侵入されたことに気付く仕組みが必要です。その材料になるのが、Entra ID のログです。
攻撃者は乗っ取ったあと、すぐに終わらせず「次も入れる状態」を作りにかかります。MFA の追加、デバイス登録、管理者権限の付与、OAuth アプリの同意。この痕跡が、これから見ていく5つのログです。
先に知っておきたい前提
ログは永遠には残りません。サインインログと監査ログの保持期間は、Entra ID Free で7日、P1/P2 で30日です。ライセンスを上げても過去分は遡って見られないので、気になる人は診断設定で Log Analytics などに送っておくのが安全です。
閲覧に必要な最小ロールは Reports Reader です。管理者ロールを持たない担当者に見てもらう場合も、これで足ります。
2. まず確認したい「サインインログ」
確認場所: Entra 管理センター → Entra ID → 監視とヘルス → サインインログ
最初に開くのはここです。私なら、怪しいユーザーを一人決めて絞り込み、時系列で眺めます。全体を一気に見ようとすると、正規のログに埋もれます。
| 見るポイント | 見る場所 | 怪しいサイン |
|---|---|---|
| 海外・初めての場所 | 場所、IP アドレス | 取引のない国、普段使わない国からの成功 |
| 深夜・休日 | 日時 | 勤務実態と合わない時間帯のサインイン |
| 失敗の連続のあとの成功 | ステータス | 失敗を重ねたあとに成功している |
| レガシー認証 | クライアントアプリ | IMAP、POP、SMTP など古いプロトコル |
| 非対話型のサインイン | 非対話型ユーザーサインインのタブ | 本人が操作していない時間に大量のトークン取得 |
レガシー認証は MFA を求められない構成だと迂回路になるので、見つけたら優先して潰したいところです。
Impossible Travel は条件付きで使える
「東京でサインインした10分後にブラジルから」といった動きは、ID Protection の Impossible travel という検出で拾えます。ただし、使えるのは Entra ID P2 と Defender for Cloud Apps の単体ライセンス、または Microsoft 365 E5 と EMS E5 の構成です。P2 だけでは出てきません。
P2 だけで使える似た検出に Atypical travel があります。見る場所は ID Protection → ダッシュボード → リスクのあるサインインです。ライセンスがない環境では、場所と日時の列を目で追うことになります。
3. MFA が勝手に変更されていないか
確認場所: Entra 管理センター → Entra ID → 監視とヘルス → 監査ログ
乗っ取った攻撃者が最初にやりたいのは、「パスワードを変えられても入り直せる状態」にすることです。そのために自分用の認証方法を足します。
監査ログのカテゴリを UserManagement
に絞り、次のアクティビティを探します。
| アクティビティ | 意味 |
|---|---|
User registered security info |
ユーザーが認証方法を登録した |
User deleted security info |
ユーザーが認証方法を削除した |
User updated security info |
認証方法を更新した |
Admin registered security info |
管理者が認証方法を登録した |
見るのは MFA の追加・削除、認証アプリの追加、電話番号の変更です。
危険なサインは、利用者本人が「そんな MFA は登録していない」と言うケースです。実行者（Initiated by）が本人なのか管理者なのか、そのときのサインイン元が普段の場所なのかを、サインインログと突き合わせます。
4. 見覚えのないデバイスが登録されていないか
確認場所: Entra 管理センター → Entra ID →
監視とヘルス → 監査ログ（カテゴリ: Device）、およびデバイス
→ すべてのデバイス
見たいアクティビティは Register device と
Add device です。
危険なサインは次の2つです。
- 同じ日に複数台のデバイスが登録されている
- 会社が配布していない個人所有の端末が登録されている
デバイスの状態を条件にしている条件付きアクセスがあると、登録された端末がすり抜け経路になることがあります。見覚えのないデバイスは、デバイス一覧で登録日時と所有者を確認し、疑わしければ無効化します。無効化すると PRT とリフレッシュトークンも失効します。
5. 管理者権限が追加されていないか
確認場所: 監査ログ（カテゴリ:
RoleManagement）、および Entra ID → ロールと管理者
特に見たいロールは3つです。
- Global Administrator
- Privileged Role Administrator
- Application Administrator
Global Administrator はテナント全体を操作できます。Privileged Role Administrator は他のユーザーにロールを付与できる立場です。Application Administrator はアプリに資格情報を追加できるので、そのアプリが持つ権限を借りる足がかりになります。
監査ログでは Add member to role や
Add eligible member to role を探します。PIM
を使っている環境なら、Add member to role outside of PIM (permanent)
が出ていないかも確認してください。PIM
の外で恒久的に付与された管理者権限は、まず疑う価値があります。
管理者の人数は少ないほど見やすいので、このタイミングで棚卸しもしておくと楽になります。
6. 見覚えのないアプリが追加されていないか
確認場所: Entra 管理センター → Entra ID →
エンタープライズアプリ、および監査ログ（カテゴリ:
ApplicationManagement）
最近増えているのが、OAuth 同意を使った手口です。偽のアプリにユーザーが「許可」を押すと、パスワードを盗まなくてもメールやファイルを読める状態になります。
監査ログでは
Consent to application、Add delegated permission grant、Add service principal
を探します。アプリ一覧では、新しく追加されたものと、付与されている権限を見ます。
| 権限 | できること |
|---|---|
Mail.Read |
ユーザーのメールを読める |
Mail.ReadWrite |
メールの作成・更新・削除ができる |
Files.Read.All |
ユーザーがアクセスできるファイルを読める |
offline_access |
ユーザーがいない間もアクセスを維持できる |
この攻撃のやっかいな点は、パスワードのリセットや MFA では止まらないことです。同意はアプリ側に残るので、アプリを無効化して同意を取り消す必要があります。Microsoft の対応手順では、悪性のアプリは削除せず無効化する流れになっています。
予防としては、次の2つが効きます。
- ユーザー同意設定で、検証済み発行元のアプリと低影響の権限だけに絞る
- 管理者同意ワークフローを有効にして、判断を管理者に集める
7. 条件付きアクセスが変更されていないか
確認場所: 監査ログ（カテゴリ:
Policy）、および Entra ID → 条件付きアクセス
5つのログに加えて、もう1か所だけ見ておきたいのがここです。攻撃者にとって、条件付きアクセスは「自分だけ通れるようにする」ための場所になります。
監査ログでは Update Conditional Access policy と
Add named location を探します。見る点は次のとおりです。
- MFA を要求するポリシーが無効になっていないか
- 除外ユーザーに見覚えのないアカウントが入っていないか
- 除外する国や場所が追加されていないか
ポリシーを大きく壊すと目立つので、除外を1つ足すだけ、という地味な変更が多いはずです。ポリシー名ではなく、変更の中身まで開いて確認してください。
8. 不正アクセスが疑われたら何をするべきか
疑わしいユーザーが見つかったら、次の順番で動きます。
- ログを保全する — 保持は7日か30日です。診断設定で送るか、画面のエクスポートで先に残します。
- パスワードをリセットする — 本人以外が知っている前提で、新しい値にします。
- セッションを取り消す — ユーザーを選び「セッションの取り消し」を実行します。
- MFA を再登録させる — 攻撃者が登録した認証方法を削除してから、本人に登録し直してもらいます。
- デバイスを確認する — 見覚えのない端末は無効化します。
- ほかの痕跡を戻す — 追加された管理者権限、同意されたアプリ、変更された条件付きアクセスを元に戻します。
私の判断では、パスワード変更より先にログ保全を置いています。ログは時間が経つと消え、あとから原因を調べる材料がなくなるからです。作業自体は数分で済みます。
セッションの取り消しは PowerShell でも実行できます。
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "user@contoso.com"注意点が1つあります。アクセストークンは最大で約1時間有効なので、取り消した直後に操作が続いて見えることがあります。CAE に対応したアプリなら、ほぼ即時に失効します。
パスワードを変えただけで安心すると、攻撃者が登録した MFA や同意済みアプリがそのまま残ります。ここまでやって、初めて「閉じた」と言えます。
まとめ
日経新聞社の事例が教えてくれるのは、今の不正アクセスは「ウイルス感染」より「正規ユーザーになりすます」形が主流だということです。この形は、ログを見ないと気付けません。
月に1回でいいので、次の5項目を確認する時間を作ることにしました。
- ✅ サインインログ（場所・時間帯・レガシー認証）
- ✅ MFA の変更
- ✅ デバイスの登録
- ✅ 管理者権限の変更
- ✅ OAuth アプリの追加
条件付きアクセスの変更も、余裕があれば一緒に見ます。Entra ID のログ確認は、侵害の早期発見にいちばん効く方法の一つです。
「ログは見ているつもりだけど、これで足りているのか分からない」「ライセンスやログの保持期間が不安」という場合は、Microsoft パートナー企業の YJK にお気軽にお問い合わせください。Entra ID のログ確認、診断設定によるログ保全、条件付きアクセスや MFA の見直しまで、自社の環境に合わせて一緒に整理します。
この記事が少しでも参考になったら、ぜひシェアしていただけると嬉しいです！
出典
- サイバー攻撃による情報漏洩、不審メールの送信について | 日本経済新聞社
- Microsoft Entra の監査ログのアクティビティ リファレンス | Microsoft Learn
- Microsoft Entra データ保持 | Microsoft Learn
- ID Protection が検出するリスク | Microsoft Learn
- Microsoft Entra ユーザーのアクセスを取り消す | Microsoft Learn
- Detect and remediate illicit consent grants | Microsoft Learn
- Configure the admin consent workflow | Microsoft Learn