Windowsイベントログ重要ID一覧｜セキュリティ調査で使うIDまとめ

「ログ、取ってます」「どこに何が記録されてるか、わかりますか？」——現場でこう聞くと、意外と沈黙が返ってきます。

ログを「取ること」と「読めること」は別物です。いざインシデントが起きたとき、どのイベントIDを確認すればいいか迷っていると、証跡が上書きされたり、攻撃の痕跡を見逃したりします。

この記事では、セキュリティ調査で実際に使う重要なWindowsイベントIDを厳選して整理します。「何を見ればいいか」が一目でわかる保存版として活用してください。

イベントIDとは——Windowsが記録する「出来事の番号」

イベントID（Event ID） Windowsがシステムの動作・操作・エラーをログに記録する際に付与する識別番号。番号ごとに意味が異なり、セキュリティ調査の起点になる。

Windowsはシステム上で発生した出来事をイベントログとして記録しています。ログオンの成功・失敗、アカウントの作成・削除、プロセスの起動——これらすべてに固有の番号（イベントID）が割り振られています。

セキュリティ調査では、この番号を手がかりに「何が起きたか」「誰が操作したか」を追います。ただし、WindowsのデフォルトではすべてのイベントIDが記録されるわけではありません。監査ポリシーで有効化されていないカテゴリは記録されない点が、現場でよく見落とされるポイントです。

監査ポリシーの設定方法については、「ADイベントログ監査」で詳しく解説しています。

まず知っておくべきログの種類

イベントビューアーを開くと、ログはいくつかのカテゴリに分かれています。セキュリティ調査で主に参照するのは次の4種類です。

セキュリティ調査の中心はセキュリティログですが、攻撃者がサービスを悪用したり、PowerShellで横移動したりするケースでは、システムログやPowerShellログが決定的な証拠になることもあります。

【保存版】セキュリティ調査で使う重要イベントID一覧

認証・ログオン系——不正アクセスの起点を追う

認証ログは攻撃調査の入口です。「誰が」「いつ」「どのマシンに」ログオンしたかを記録しています。特に4625（ログオン失敗）の連続は、ブルートフォース攻撃の兆候として真っ先に確認すべきIDです。

4648の読み方：通常のログオンとは異なり、別のアカウント資格情報を指定してアクセスしたことを示します。管理者がrunasコマンドを使う正当な操作でも発生しますが、マルウェアが横移動するときにも同様のログが残ります。前後のイベントと合わせて判断することが重要です。

Pass-the-Hash攻撃など、認証系の攻撃手法の詳細については「AD攻撃手法と要塞化」を参照してください。

アカウント操作系——権限昇格・不正作成を見抜く

攻撃者がドメイン内に足場を築くとき、必ずといっていいほど何らかのアカウント操作を行います。突然のグループ追加や、業務時間外のアカウント作成は要注意です。

現場あるある：退職処理の際に「アカウントを無効化したが削除していなかった」ケースでは、後から4722（有効化）が発生していないか定期確認することが有効です。ADのユーザーとグループ管理の設計については「ADのユーザーとグループ管理」を参照してください。

ポリシー・設定変更系——監査設定の改ざんを検知する

攻撃者は侵入後、自分の痕跡を消すために監査ポリシーを無効化することがあります。このカテゴリのIDが記録されていたら、操作者と変更内容を必ず確認してください。

プロセス・実行系——マルウェアの実行痕跡を探す

プロセス作成監査（Process Creation Audit） Windowsが新しいプロセスを起動した際に記録する監査機能。デフォルトでは無効なため、グループポリシーで明示的に有効化が必要。

マルウェアや攻撃ツールの実行は必ずプロセスとして記録されます。ただしこのカテゴリはデフォルトで無効のため、あらかじめ監査ポリシーで有効化しておかないと、いざというときにログが存在しません。

4688ではProcessCommandLineフィールドを確認することで、実行時の引数（スクリプトのパスやオプション）が把握できます。powershell.exe -EncodedCommandのようなBase64エンコードされた引数が見られた場合は特に注意が必要です。

サービス登録系——マルウェアの永続化を見つける

サービス登録（Service Installation） Windowsのサービスとしてプログラムを登録する操作。マルウェアは再起動後も自動起動するためにサービス登録を悪用する。

マルウェアが「再起動しても動き続ける」仕掛けを作るとき、しばしばWindowsサービスとして自身を登録します。イベントID 7045はその記録です。

実行パスがC:\Users\username\AppData\Local\Temp\配下を指している場合は、正規ソフトウェアのインストールではなくマルウェアの永続化を強く疑ってください。

PowerShell実行系——攻撃者が好む経路を可視化する

攻撃者はPowerShellを使った「Living off the Land（環境寄生型）」攻撃を好みます。OSに標準搭載されているため怪しまれにくく、強力なコマンドを短時間で実行できるためです。

参考：about_Logging – Windows PowerShell 5.1（Microsoft Learn）

これらのログもデフォルトでは無効です。グループポリシーで「スクリプトブロックのログ記録を有効にする」を設定してください。GPOの設定手順については「GPO設計入門」を参照してください。

よくある失敗パターン——重要IDを見逃す現場の落とし穴

① 監査ポリシーを有効化していない

最も多い失敗です。「イベントビューアーを開いたが、肝心なIDが1件も記録されていない」という状態がこれです。プロセス作成（4688）やPowerShellスクリプトブロック（4104）は、監査ポリシーの詳細設定で明示的に有効化しないと記録されません。インシデントが起きる前に設定を確認してください。

② ログの保存期間が短すぎて上書きされていた

デフォルトのセキュリティログの最大サイズは20MBに設定されており、大規模環境ではあっという間に上書きされます。「インシデント発覚時には3日前までのログしかなかった」というケースは珍しくありません。最低でも90日分は保持できる設定を推奨します。

③ ドメインコントローラーのログだけ見ていた

ドメインコントローラー（DC）のログは重要ですが、Pass-the-Hashのような横移動攻撃では、侵害されたメンバーサーバーや端末のログも同時に確認する必要があります。DCだけ監視していると攻撃経路の一部が見えなくなります。

④ 正常ログと異常ログの区別がついていない

4648（明示的な資格情報）や4672（特権付与）は、管理者が通常業務でも発生させるIDです。「このIDが出た＝攻撃」と即断せず、発生頻度・時間帯・アカウント名・接続元IPをセットで確認する習慣をつけてください。

実務チェックリスト——調査開始前に確認すること

監査設定の確認

• [ ] セキュリティログの監査ポリシーが有効化されているか（特にログオン・アカウント管理・プロセス作成）
• [ ] PowerShellスクリプトブロックのログ記録が有効か
• [ ] ログの最大サイズと保持期間が適切に設定されているか（上書き防止設定）

調査開始時の確認

• [ ] 調査対象の端末・サーバーのログを最初に保全（コピー）したか
• [ ] タイムゾーンの設定を確認したか（UTCとJSTのズレに注意）
• [ ] DCとメンバーサーバー、端末の3点セットでログを確認したか

確認すべきIDの優先順位

• [ ] まず4625（ログオン失敗）の連続発生を確認
• [ ] 4720・4728でアカウント・グループの不正変更がないか確認
• [ ] 7045で見覚えのないサービスが登録されていないか確認
• [ ] 4688で不審なプロセス（powershell.exe -Enc等）がないか確認

ログの証拠保全の具体的な手順については「証跡保全の基本」で詳しく解説しています。

【早見表】カテゴリ別 重要イベントID まとめ

参考：Windowsセキュリティ監査のイベント（Microsoft Learn）

まとめ——今日確認すべきことは1つです

今日やることは1つだけです。自分の環境でイベントID 4625と7045が記録される設定になっているか、確認してください。

この2つが記録されていれば、ブルートフォースと不審なサービス登録という、現場で最も多い初動サインを拾えます。まだ設定が不十分であれば、今日中に監査ポリシーを見直してください。

監査設定をADのグループポリシーで一元管理する方法は「ADイベントログ監査」で、インシデント発生時の初動対応全体の流れは「セキュリティインシデント対応入門」で解説しています。

あわせてご覧ください

• Windowsイベントログ調査入門｜インシデント発生時の初動調査
• ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド
• 証跡保全の基本｜インシデント対応で最初にやること
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方
• グループポリシー（GPO）設計入門｜セキュリティ設定をADで一括管理する方法