Windowsイベントログ調査入門｜インシデント発生時の初動調査

「ログを見てください」——インシデント発生後にこう言われて、どこから手をつければいいかわからなくなったことはありませんか？

Windowsのイベントログには膨大な情報が記録されています。しかし「どのログを」「どの順番で」「何を探しながら」見ればいいかを知らなければ、ログの海に溺れて時間だけが過ぎます。初動調査で重要なのは「すべてを読む」ことではなく「攻撃の痕跡に素早く辿り着く」ことです。

この記事では、インシデント発生時の初動調査として、どのイベントログを・どの順番で・どうやって絞り込むかを実務レベルで解説します。

インシデント対応の全体フローについては「セキュリティインシデント対応入門」を、証跡保全の手順については「証跡保全の基本｜インシデント対応で最初にやること」を先にご覧ください。

イベントログ調査が「初動調査」である理由

インシデント発生時、最初にやるべきことは証跡保全です。そして保全が完了したら、次の問いに答えるための調査が始まります。

• いつから侵害が始まっているか
• どこから侵入されたか
• 何が行われたか
• どこまで広がっているか

Windowsのイベントログはこの4つの問いに答えるための最初の手がかりです。認証の成功・失敗・特権操作・アカウント変更・サービスの起動・停止——これらはすべてイベントログに記録されています。

ただし一点注意があります。イベントログ調査は証跡保全の後に行うことが原則です。調査のためにログを開く操作自体がタイムスタンプを変更するリスクがあります。証跡保全の手順については「証跡保全の基本」を参照してください。

参考：Active Directory の侵害の兆候を監視する | Microsoft Learn

調査前の準備——証跡保全との順番を間違えない

イベントログ調査を始める前に、以下の3点を確認します。

① イベントログの保全が完了しているか wevtutil epl Security コマンドでevtxファイルとしてエクスポートされているか確認します。保全前に調査を始めると、調査操作自体がログに記録されて混入します。

② 監査ポリシーが有効になっているか 監査ポリシーが無効または不十分な場合、調査に必要なイベントが記録されていない可能性があります。auditpol /get /category:* で現在の設定を確認してください。

auditpol（Audit Policy コマンド） 現在の監査ポリシー設定を確認・変更するコマンドラインツール。auditpol /get /category:* で全カテゴリの現在の設定を一覧表示できる。

③ 調査する時間範囲を決める 「いつから調査するか」を決めておくと効率が上がります。監視アラートの発報時刻・ユーザーから異常を報告された時刻・最後の正常確認時刻などを起点に、前後の範囲を設定します。

ADの監査ポリシー設定については「ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド」で詳しく解説しています。

初動調査で最初に確認すべき3つのログ

セキュリティログ——認証・権限操作の痕跡を追う

セキュリティログ（Security Event Log） Windowsが記録する認証・ログオン・権限変更・アカウント操作などのセキュリティ関連イベントの記録。監査ポリシーで有効にした項目のみ記録される。初動調査で最初に確認すべきログ。

セキュリティログは初動調査の中心です。不正アクセス・アカウント操作・特権使用のほぼすべてがここに記録されます。確認すべき主なイベントIDは以下の通りです。

システムログ——サービス・プロセスの異常を確認する

システムログ（System Event Log） WindowsのOS・ドライバ・サービスの起動・停止・エラーを記録するログ。マルウェアがサービスとして登録されていないか・重要サービスが停止されていないかの確認に使用する。

システムログでは以下を中心に確認します。

• イベントID 7045：新しいサービスのインストール。マルウェアがサービスとして登録されると記録される
• イベントID 7036：サービスの開始・停止。セキュリティ関連サービスの停止は攻撃の準備行動の可能性がある
• イベントID 6008：予期しないシャットダウン。攻撃による強制終了やランサムウェアの活動を示す場合がある

アプリケーションログ——業務システムの異常を確認する

アプリケーションログ（Application Event Log） アプリケーション固有のエラー・警告・情報を記録するログ。業務システム・データベース・Webサーバのエラーが記録される。セキュリティログ・システムログの次に確認する。

アプリケーションログ単体では攻撃の痕跡を特定しにくいですが、セキュリティログ・システムログと合わせて「業務システムへの不正アクセスの影響」を確認するために使います。

攻撃の種類別・調査の起点となるイベントID

不正アクセス・アカウント侵害を疑う場合

確認の起点：4625（ログオン失敗）の連続発生

[イベントビューアーでの確認手順]
1. Windowsログ → セキュリティ
2. 右クリック → 「現在のログをフィルター」
3. イベントID：4625 を指定
4. 同一アカウントへの短時間連続失敗を確認
5. 直後に4624（成功）が記録されていないか確認

ブルートフォース攻撃の場合、4625が短時間に大量発生した後に4624が記録されるパターンが典型的です。4625の SubStatus フィールドで失敗理由（パスワード誤り・アカウント無効・時間外ログオン等）を確認することで、攻撃の性質を絞り込めます。

SubStatus（サブステータス） イベントID 4625に含まれるフィールド。ログオン失敗の詳細な理由を数値コードで示す。0xC000006A（パスワード誤り）・0xC0000064（存在しないユーザー名）・0xC000006F（時間外ログオン）などが代表的。

マルウェア感染・横展開を疑う場合

確認の起点：4624（LogonType 3）の多発＋4648の組み合わせ

横展開（Pass-the-Hash等）では、一般PCから複数サーバへのネットワーク認証（LogonType 3）が短時間に連続します。通常業務では発生しにくいパターンのため、このログの組み合わせが横展開の手がかりになります。

[確認すべき組み合わせパターン]
① 4624（LogonType=3）が複数の宛先サーバに短時間に連続
② 4648（明示的資格情報）が通常使われない端末から発生
③ 7045（新規サービス登録）がドメイン参加端末に記録される

合わせてシステムログの7045（新しいサービスのインストール）も確認します。横展開のツールがサービスとして登録されるケースがあります。

Pass-the-Hashの仕組みと対策については「AD攻撃手法と要塞化」で詳しく解説しています。

内部不正・権限昇格を疑う場合

確認の起点：4728/4732（グループへのメンバー追加）＋4672（特権割り当て）

業務時間外・承認フロー外でのDomain Adminsへの追加は、内部不正または攻撃者による特権昇格の典型的なパターンです。

[確認すべきフィールド（イベントID 4728）]
- Subject: AccountName  → 追加操作を行ったアカウント
- Member: AccountName   → 追加されたアカウント
- Group Name            → 変更されたグループ名
- Workstation Name      → 操作が行われた端末

イベントビューアーを使った実務的な絞り込み方

フィルター機能でイベントIDを絞る

イベントビューアーの右クリックメニュー「現在のログをフィルター」から複数のイベントIDをカンマ区切りで指定できます。

例：認証関連を一括確認する場合
イベントID：4624, 4625, 4648, 4672

時間範囲を絞って前後関係を追う

フィルター画面の「ログの日付」で時間範囲を指定します。「異常が報告された時刻の前後2時間」のように範囲を決めて調査を始め、手がかりが見つかったら範囲を広げていく方法が効率的です。

PowerShellで大量ログを効率的に処理する

イベントビューアーのGUIは視認性が高い反面、大量のログを処理するには限界があります。PowerShellを使うと条件を組み合わせた絞り込みが効率的に行えます。

# 特定のイベントIDを時間範囲で絞り込む例
$startTime = "2026-04-30 00:00:00"
$endTime   = "2026-04-30 23:59:59"

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = @(4624, 4625, 4648)
    StartTime = $startTime
    EndTime   = $endTime
} | Select-Object TimeCreated, Id, Message |
  Export-Csv -Path "auth_log.csv" -NoTypeInformation -Encoding UTF8

Get-WinEvent PowerShellでWindowsイベントログを取得するコマンドレット。フィルターハッシュテーブルを使うことでイベントID・時間範囲・ログ名を組み合わせた効率的な検索が可能。

よくある失敗パターン

① ログを「読む」前に「消す」操作をしてしまう

調査のつもりでログをクリアしたり、対象端末を再起動したりするケースがあります。調査は必ず保全済みのevtxファイルに対して行い、稼働中のシステムのログを直接操作しないことが原則です。

② イベントIDを1つずつ目視で確認して時間を浪費する

フィルターを使わずに全ログをスクロールして読もうとするケースがあります。数十万件のログを目視で確認するのは現実的ではありません。まず確認すべきイベントIDを絞り、PowerShellで抽出してからCSVで確認する方が効率的です。

③ 1台のログしか確認しない

インシデントの影響が複数端末に及んでいる場合、1台のログだけを見ると横展開の全体像が把握できません。DCのセキュリティログ・感染疑いの端末・重要サーバの3点は最低限確認してください。

④ ログの保存期間が短くて必要な期間が残っていない

デフォルトのセキュリティログ最大サイズ（20MB）では、アクティブな環境では数時間〜数日分しか残りません。インシデント発生後に「2週間前のログが必要なのに残っていない」という事態を防ぐために、平常時からログサイズを1GB以上に設定しておくことが重要です。

初動調査チェックリスト

調査前の確認

• イベントログの保全（evtxエクスポート）が完了している
• 調査は保全済みファイルに対して行っている
• 監査ポリシーの設定状況を確認した
• 調査する時間範囲を決めた

セキュリティログの確認

• 4625（ログオン失敗）の連続発生を確認した
• 4624（LogonType 3）の多発を確認した
• 4728/4732（グループへのメンバー追加）を確認した
• 4672（特権割り当て）を業務外時間帯で確認した
• 4720（アカウント作成）を確認した

システムログの確認

• 7045（新規サービス登録）を確認した
• 7036（サービスの停止）でセキュリティ関連サービスの停止を確認した

記録

• 調査で発見した事象・イベントIDを記録した
• 調査の時間範囲・確認した端末を記録した
• 次のアクション（封じ込め・上長報告等）を決定した

まとめ——ログは「読める状態」にして初めて意味を持つ

Windowsイベントログの初動調査は「すべてを読む」ことが目的ではありません。「攻撃の起点・時刻・範囲」を素早く特定することが目的です。そのために、確認すべきイベントIDを知っておくこと・フィルターとPowerShellで効率的に絞り込む方法を知っておくことが重要です。

今日確認すべきことは1つです。現在管理しているWindowsサーバのセキュリティログの最大サイズを確認してください。デフォルト（20MB）のままであれば、インシデント発生時に必要なログが残っていない可能性があります。

次のステップは、M365環境でのログ調査です。「M365 Purview入門｜監査ログの取り方と活用」（公開予定）で、クラウド環境でのインシデント調査手順を解説します。

あわせてご覧ください

• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方
• 証跡保全の基本｜インシデント対応で最初にやること
• ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• 最小権限の原則とは？実務での考え方と設計例