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は以下の通りです。
| イベントID | 内容 | 注目すべきポイント |
|---|---|---|
| 4624 | ログオン成功 | LogonType・時刻・送信元端末 |
| 4625 | ログオン失敗 | 短時間の連続失敗はブルートフォースの疑い |
| 4648 | 明示的な資格情報使用 | Pass-the-Hash横展開の手がかり |
| 4728/4732 | セキュリティグループへのメンバー追加 | Domain Adminsへの不審な追加 |
| 4720 | アカウント作成 | 業務外・承認なしの作成 |
| 4740 | アカウントロックアウト | 特定アカウントへの集中攻撃 |
| 4672 | 特別な特権の割り当て | 管理者アカウントのログオン |
調査で使うIDの一覧は「Windowsイベントログ重要ID一覧｜セキュリティ調査で使う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 UTF8Get-WinEvent
PowerShellでWindowsイベントログを取得するコマンドレット。フィルターハッシュテーブルを使うことでイベントID・時間範囲・ログ名を組み合わせた効率的な検索が可能。
よくある失敗パターン
ログを「読む」前に「消す」操作をしてしまう
調査のつもりでログをクリアしたり、対象端末を再起動したりするケースがあります。調査は必ず保全済みのevtxファイルに対して行い、稼働中のシステムのログを直接操作しないことが原則です。
イベントIDを1つずつ目視で確認して時間を浪費する
フィルターを使わずに全ログをスクロールして読もうとするケースがあります。数十万件のログを目視で確認するのは現実的ではありません。まず確認すべきイベントIDを絞り、PowerShellで抽出してからCSVで確認する方が効率的です。
1台のログしか確認しない
インシデントの影響が複数端末に及んでいる場合、1台のログだけを見ると横展開の全体像が把握できません。DCのセキュリティログ・感染疑いの端末・重要サーバの3点は最低限確認してください。
ログの保存期間が短くて必要な期間が残っていない
デフォルトのセキュリティログ最大サイズ（20MB）では、アクティブな環境では数時間〜数日分しか残りません。インシデント発生後に「2週間前のログが必要なのに残っていない」という事態を防ぐために、平常時からログサイズを1GB以上に設定しておくことが重要です。
ログの保存期間設定についての詳細は、「Windowsイベントログの保存期間と設定方法｜GPOで全端末に一括適用する実務手順」で解説しています。
初動調査チェックリスト
調査前の確認
- [ ] イベントログの保全（evtxエクスポート）が完了している
- [ ] 調査は保全済みファイルに対して行っている
- [ ] 監査ポリシーの設定状況を確認した
- [ ] 調査する時間範囲を決めた
セキュリティログの確認
- [ ] 4625（ログオン失敗）の連続発生を確認した
- [ ] 4624（LogonType 3）の多発を確認した
- [ ] 4728/4732（グループへのメンバー追加）を確認した
- [ ] 4672（特権割り当て）を業務外時間帯で確認した
- [ ] 4720（アカウント作成）を確認した
システムログの確認
- [ ] 7045（新規サービス登録）を確認した
- [ ] 7036（サービスの停止）でセキュリティ関連サービスの停止を確認した
記録
- [ ] 調査で発見した事象・イベントIDを記録した
- [ ] 調査の時間範囲・確認した端末を記録した
- [ ] 次のアクション（封じ込め・上長報告等）を決定した
ログは「読める状態」にして初めて意味を持つ
Windowsイベントログの初動調査は「すべてを読む」ことが目的ではありません。「攻撃の起点・時刻・範囲」を素早く特定することが目的です。そのために、確認すべきイベントIDを知っておくこと・フィルターとPowerShellで効率的に絞り込む方法を知っておくことが重要です。
現在管理しているWindowsサーバのセキュリティログの最大サイズを確認してください。デフォルト（20MB）のままであれば、インシデント発生時に必要なログが残っていない可能性があります。
M365環境でのログ調査については「M365 Purview入門｜監査ログの取り方とインシデント調査への活用」でクラウド環境でのインシデント調査手順を解説しています。
ここまで読んで「実際に手を動かしてみたい」と思った方へ。
AD環境の構築から、OU・GPO・グループ設計、Tierモデルによる防御、そして実際の攻撃までを段階を踏んで体験できる演習シリーズを公開しています。
この記事の内容は、AD演習編 Vol.1〜5で実際に手を動かして体験できます。「構築する」から「検知する」まで、一本のストーリーで学べるシリーズが完結しました。
AD演習編 Vol.1〜5
完全セット
構築 → 設計 → 攻撃 → 検知
VirtualBox上にAD環境をゼロから構築し、Tierモデルの実装・Kerberoasting/DCSyncの攻撃体験・PowerShell/Hayabusaによる検知分析までを一貫して学習。スクリーンショット付き手順書・環境設定リファレンス（Excel）付き。
単体で気になる巻から始めたい方は演習コンテンツ一覧もご覧ください。
あわせてご覧ください
コメント