メインコンテンツへスキップ
クラウド監査 中級

M365監査ログ演習:深夜のサインインと外部転送ルールを追う

Microsoft 365 統合監査ログを題材に、通常と異なる地理・時刻のサインイン、外部転送を行う收件箱ルールの追加、ロール割当、大量ファイルダウンロードという一連の兆候を時系列で読み解き、アカウント侵害を判定する演習です。

この記事の目次 6項目から選ぶ

SaaS の侵害は、マルウェアではなく「正規の機能の悪用」として現れます。Microsoft 365 のようなクラウドサービスでは、攻撃者が窃取した資格情報でサインインし、メールの転送設定や権限付与、ファイル参照といった通常機能だけで侵害を進めるため、エンドポイントの防御だけでは気づけません。頼りになるのが監査ログ、とりわけクラウド監査ログです。

この演習では、合成の Microsoft 365 統合監査ログを読み、単体では説明がつく操作が時系列でつながったときに何を意味するのかを判断する力を鍛えます。「1行ずつの正常・異常」ではなく「行と行の間の物語」を読むのが監査ログ分析の核心です。

本記事は教育目的の演習であり、登場するデータはすべて合成の例です。実在の組織・人物・ドメインとは関係ありません。

状況設定

状況設定 情シス担当者

あなたは従業員約200名の製造業「Example 株式会社」の情シス担当者です。同社はメールとファイル共有に Microsoft 365 を利用し、情シスはあなたを含めて2名だけです。

7月20日(月)の朝、営業部の田中さん([email protected])から「週末に身に覚えのないサインイン通知が届いた」と連絡がありました。あなたは Microsoft Purview の監査ログ検索で、7月19日〜20日に田中さんのアカウントに紐づくレコードを抽出しました。時刻は UTC で記録されています(日本時間は +9 時間)。

証跡:統合監査ログ(抜粋)

json Microsoft 365 統合監査ログ(抜粋・合成。時刻はUTC) 黄枠 = 注目行
{"CreationTime":"2026-07-19T00:02:11Z","Operation":"UserLoggedIn","UserId":"[email protected]","ClientIP":"198.51.100.24","ResultStatus":"Success","Workload":"AzureActiveDirectory","LogonType":"0","ExtendedProperties":{"Location":"JP/Tokyo","UserAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64)"}}
{"CreationTime":"2026-07-19T00:15:40Z","Operation":"FileAccessed","UserId":"[email protected]","ClientIP":"198.51.100.24","Workload":"SharePoint","ObjectId":"https://example.sharepoint.com/sites/sales/Reports/weekly.docx"}
{"CreationTime":"2026-07-19T01:30:02Z","Operation":"UserLoggedOut","UserId":"[email protected]","ClientIP":"198.51.100.24","Workload":"AzureActiveDirectory"}
{"CreationTime":"2026-07-19T17:11:48Z","Operation":"UserLoginFailed","UserId":"[email protected]","ClientIP":"203.0.113.77","ResultStatus":"Failed","Workload":"AzureActiveDirectory","ExtendedProperties":{"Location":"US/unknown","LogonError":"InvalidGrant"}}
{"CreationTime":"2026-07-19T17:12:05Z","Operation":"UserLoggedIn","UserId":"[email protected]","ClientIP":"203.0.113.77","ResultStatus":"Success","Workload":"AzureActiveDirectory","ExtendedProperties":{"Location":"US/unknown","UserAgent":"python-requests/2.31.0"}}
{"CreationTime":"2026-07-19T17:12:51Z","Operation":"New-InboxRule","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"Exchange","Parameters":{"Name":"Cleanup rule","ForwardTo":"[email protected]","DeleteMessage":"false"}}
{"CreationTime":"2026-07-19T17:13:20Z","Operation":"UpdateInboxRules","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"Exchange","ResultStatus":"Success"}
{"CreationTime":"2026-07-19T17:14:03Z","Operation":"Add member to role.","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"AzureActiveDirectory","ModifiedProperties":{"Role.DisplayName":"User Administrator"},"ObjectId":"[email protected]"}
{"CreationTime":"2026-07-19T17:15:30Z","Operation":"Add app role assignment to service principal","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"AzureActiveDirectory"}
{"CreationTime":"2026-07-19T17:16:12Z","Operation":"FileDownloaded","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"SharePoint","ObjectId":".../Finance/budget-2026.xlsx"}
{"CreationTime":"2026-07-19T17:16:40Z","Operation":"FileDownloaded","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"SharePoint","ObjectId":".../HR/salary-master.xlsx"}
{"CreationTime":"2026-07-19T17:17:02Z","Operation":"FileDownloaded","UserId":"[email protected]","ClientIP":"203.0.113.77","Workload":"SharePoint","ObjectId":".../Design/product-blueprint-v3.pdf (他 41 件の FileDownloaded が 17:16〜17:19 に集中)"}
{"CreationTime":"2026-07-20T00:10:55Z","Operation":"UserLoggedIn","UserId":"[email protected]","ClientIP":"198.51.100.24","ResultStatus":"Success","Workload":"AzureActiveDirectory","ExtendedProperties":{"Location":"JP/Tokyo"}}

問いかけ

Q1 5行目のサインイン成功(7/19 17:12 UTC、203.0.113.77)だけを見て、攻撃と断定できるか?
要追加調査

単独では断定できません。海外出張中や VPN 経由の可能性があるため、サインイン元の地理だけでは良性の説明も成り立ちます。ただし不審点は多く、調査を深めるべきシグナルです。

  • 17:12 UTC は日本時間で午前2時12分。9時始業の営業職が深夜にサインインするのは通常と異なります。
  • 直前の4行目に同一IPからのログオン失敗があり、資格情報を試行した形跡が残っています。
  • UserAgent が python-requests で、ブラウザではなくスクリプトからのアクセスです。業務利用ではほぼあり得ません。
  • 田中さんは同日の日中(1行目、198.51.100.24 = 東京)にもサインインしており、東京と米国を数時間で移動することは物理的に不可能です。いわゆるインポッシブル・トラベルの検知条件に合致します。

つまり「攻撃と断定」ではなく「侵害の可能性が高く、直後の操作を必ず確認する」が正しい姿勢です。

Q2 6行目の New-InboxRule(外部ドメインへの転送ルール追加)は何を意味するか?
攻撃の可能性大

これは侵害後の典型的な横展開・情報収集行為です。受信トレイルールメール転送ルール)で届いたメールを外部アドレスへ自動転送させる手口は、アカウント乗っ取り後に攻撃者が継続的に情報を盗む定番であり、BEC(ビジネスメール詐欺)の前段としても広く観測されています。

判断の根拠は次の通りです。

  • 転送先 [email protected] は社内ドメイン example.jp とも取引先ドメインとも一致しない外部アドレスで、しかも自社ドメインの綴り違いを装っています。
  • ルール名が「Cleanup rule」と、一見無害な名前に偽装されています。ユーザーが設定画面を開いても気づきにくくする意図が読み取れます。
  • 作成タイミングが、異常なサインイン成功の46秒後です。正規ユーザーが深夜にサインイン直後に転送ルールを作る業務上の理由は考えにくい。

なお、外部転送ルールには「新人が私用メアドに転送した」といった良性ケースも存在します。だからこそ、地理・時刻・UserAgent という文脈と併せて評価することが重要です。

Q3 8行目のロール割当と10〜12行目の大量ダウンロードを含め、一連の流れ全体をどう判定するか?
攻撃の可能性大

侵害と判定します。個々の操作には良性の説明が付き得ても、時系列で並べると攻撃のチェーンとして完全に筋が通ります。

  1. 初期アクセス:窃取した資格情報でのサインイン成功(MITRE ATT&CK T1078 Valid Accounts)。失敗→成功の試行痕跡とスクリプト系 UserAgent がそれを裏付けます。
  2. 持続化・収集の準備:外部転送ルールの追加(T1098 Account Manipulation 系の操作、メール転送による収集経路の確保)。
  3. 権限昇格・持続化:別アカウント [email protected] への「User Administrator」ロール割当(T1098)。田中さんのアカウントが停止されても、攻撃者はこのサービスアカウントで管理者権限を維持できます。
  4. 収集:17:16〜17:19 のわずか3分間に財務・人事・設計データを40件超ダウンロード(T1530 Data from Cloud Storage)。これは明確なデータ持ち出し行為です。

「1つの怪しいイベント」ではなく「正規機能を使った侵害の一連の物語」として検知するのが、SaaS 監査ログ分析の要点です。

観察ポイントの解説

サインインの異常:地理・時刻・クライアント

サインインログでは ResultStatus の成功・失敗だけでなく、少なくとも次の3点を確認します。

  • 地理と移動の物理可能性:短時間に離れた地域からサインインが成立していれば、どちらか(あるいは両方)が第三者です。Microsoft Entra ID Protection の「見慣れない場所」「不可能な移動」も同じ発想で検知しています。
  • 時刻:そのユーザーの業務時間帯と照らし合わせます。深夜・休日の成功ログは優先的に掘る対象です。
  • UserAgent / クライアント種別:ブラウザ以外(スクリプト、レガシー認証、見慣れないツール)からのサインインは自動化された攻撃の兆候です。

收件箱ルール:転送先と偽装

Exchange の監査ログでは New-InboxRule / Set-InboxRule 操作に、ルール名・転送先・条件などのパラメータが記録されます。見るべきは、転送先が外部ドメインか、ルール名が偽装されていないか、既存ルールの改ざん(UpdateInboxRules)を伴わないか、の3点です。なお Microsoft は新規テナントで外部への自動転送を既定で無効化していますが、個別の收件箱ルールによる転送は別の経路として残り得るため、ログでの監視が不可欠です。

権限付与:誰が・誰に・何のロールを

「Add member to role.」や「Add app role assignment to service principal」は、侵害の持続化を示す重要イベントです。特に、管理者ロールの割当先が普段使われていないサービスアカウントや新規アカウントの場合は高リスクです。最小権限の観点から、ロール割当は条件付きアクセスや特権管理のワークフロー経由に限定し、それ以外の経路での割当をアラート化するのが定石です。

大量ダウンロード:量・速度・対象の機微性

SharePoint / OneDrive の FileDownloaded は通常業務でも大量に発生します。異常と見る基準は、短時間あたりの件数、普段アクセスしない部門のフォルダ(営業職が給与マスタや設計図を参照するなど)、勤務時間外の実行、の組み合わせです。単一閾値では誤検知が多いため、SIEM や UEBA でユーザーごとの平時ベースラインからの逸脱として検知するのが現実的です。

時系列で繋げる

本演習の最大の教訓は、どのイベントも単体では「要調査」止まりでも、同一アカウント・同一クライアントIP・数分間隔で並ぶと侵害チェーンになることです。監査ログの相関分析では、アカウント × IP × 時間窓でイベントをグルーピングし、「サインイン → 設定変更 → 権限付与 → データアクセス」という遷移パターンを検知ルールに落とし込みます。

判定と初動アクション

判定:アカウント侵害(侵害確実・即時対応)

初動でやること:

  • 田中さんアカウントの全セッション・リフレッシュトークンの失効とパスワードリセット、MFA 登録情報の確認(攻撃者が MFA 要素を追加していないか)
  • 不正な收件箱ルールの削除と、同様の外部転送ルールが他アカウントに作られていないかの横展開調査
  • [email protected] へのロール割当の剥奪と、同アカウントの資格情報・シークレットのローテーション
  • ダウンロードされたファイルの特定(対象44件の ObjectId を保全)と、機密情報の流出範囲の評価
  • 監査ログ・サインインログの証跡保全(保持期限切れ前のエクスポート)と、インシデント対応プロセスの起動、経営層・必要に応じて関係機関への報告
  • 侵入経路の特定:パスワードスプレーやフィッシングの痕跡をサインインログで遡り、再発防止(条件付きアクセスによる地理・クライアント制限、レガシー認証の遮断など)を実施

初動でやらないこと:

  • 証跡を消す操作を先にやらない:アカウント削除やログの不用意なクリアは、影響範囲の特定を不可能にします。まず保全、次に遮断です。
  • 本人への通知なしに業務アカウントを長期停止しない:ただし侵害確実な場合はセッション失効を優先し、業務影響は代替手段で調整します。
  • 外部転送先へ連絡・反撃しない:転送先ドメイン(本演習の例では hxxps://examp1e[.]net)への接続確認や接触は行わず、ブロックと監視に留めます。

参考情報

ESC