ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド

「ログは取ってます」——では、そのログを最後に開いたのはいつですか？

Windowsのイベントログは、デフォルトでも一定の情報を記録しています。ところが「取れている」と「読める状態になっている」はまったく別の話です。ログが存在していても、どのイベントIDが何を意味するか、何が正常で何が異常かを把握していなければ、攻撃が始まっても気づけません。

この記事では、ADのセキュリティ監査に必要なイベントログの基礎から、監査ポリシーの設定方法・重要なイベントID・攻撃の兆候の読み方まで、実務で使える形で解説します。

ADの全体像については「Active Directoryとは？Windows認証基盤の仕組みと設計の基本」を先にご覧ください。特権アカウントの操作ログについては「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」とあわせて読むと理解が深まります。

ログを「取るだけ」で終わっている現場のリスク

「監査ログは有効にしてあります」という現場でも、実態を確認すると3つの問題が潜んでいることが多くあります。

保存期間が短すぎる。 Windowsのイベントログはデフォルトで最大サイズが小さく設定されており、数日分のログしか残っていないケースがあります。インシデント発生後に調査しようとしても、問題のログがすでに上書きされています。

監査ポリシーが初期設定のままになっている。 デフォルトの監査ポリシーでは記録されないイベントが多く、特権グループへの変更・ログオン失敗・アカウント操作が記録されていない状態になっています。

ログを定期的に確認する運用がない。 取得しているだけで誰も見ていない状態では、攻撃の兆候が記録されていても発見が遅れます。

これら3つはすべて設計と運用で解決できます。最小権限の設計と同様、ログも「設定するもの」ではなく「読める状態に設計するもの」です。最小権限の考え方については「最小権限の原則とは？実務での考え方と設計例」で解説しています。

ADのイベントログとは何か——どこに・何が記録されるか

セキュリティログ・システムログ・アプリケーションログの役割分担

Windowsのイベントログは複数の種類があり、ADの監査で中心になるのはセキュリティログです。

セキュリティログ（Security Event Log） Windowsが記録する認証・権限変更・アクセス失敗などのセキュリティ関連イベントの記録。監査ポリシーで有効にした項目のみ記録される。イベントビューアーの「Windowsログ→セキュリティ」で確認できる。

ADの監査においてセキュリティログが最重要です。ただしセキュリティログは監査ポリシーで有効にした項目しか記録されないため、設定が不十分だと肝心なイベントが残りません。

参考：Windows セキュリティ イベント ログの概要 | Microsoft Learn

ADで特に重要なイベントIDの全体像

イベントID（Event ID） Windowsイベントログの各記録に付与される番号。イベントの種類を識別するために使用する。セキュリティ関連のイベントIDは4000番台が多い。

イベントIDはカテゴリで分けて覚えると実務で使いやすくなります。

まず有効にすべき監査ポリシーの設定

GPOで監査ポリシーを一括適用する方法

監査ポリシーはGPOで設定し、DCとメンバーサーバー全体に一括適用します。個別に設定すると設定漏れが発生するため、必ずGPOで管理してください。

GPO設計の基礎については「グループポリシー（GPO）設計入門｜セキュリティ設定を一括管理する方法」を参照してください。

設定パスは以下の通りです。

コンピューターの構成
└── Windowsの設定
    └── セキュリティの設定
        └── 高度な監査ポリシーの構成
            ├── アカウント ログオン
            ├── ログオン/ログオフ
            ├── アカウント管理
            ├── ポリシーの変更
            └── 特権の使用

高度な監査ポリシー（Advanced Audit Policy） Windows Server 2008 R2以降で利用可能な、より細かい粒度で監査設定を行う仕組み。従来の「基本的な監査ポリシー」より詳細な制御が可能で、現在はこちらの使用が推奨される。

設定すべき監査カテゴリと推奨値

また、ログの保存期間も合わせて設定します。セキュリティログのサイズは最低でも1GB以上、保存方法は「必要に応じてイベントを上書きする」ではなく「アーカイブして保存」する設計を推奨します。

参考：監査ポリシーの推奨事項 | Microsoft Learn

正常と異常を見分ける——重要イベントID一覧

認証・ログオン系（4624・4625・4648）

4624——ログオン成功

LogonType（ログオンタイプ） イベントID 4624に含まれるフィールド。どの方法でログオンが行われたかを数値で示す。タイプ2は対話型（直接操作）、タイプ3はネットワーク経由、タイプ10はリモートデスクトップ。

4624はすべてのログオン成功を記録します。単体では「正常」ですが、以下の場合は注意が必要です。

• LogonType 3（ネットワーク）が深夜・休日に大量発生している
• LogonType 3 でDomain Adminsアカウントが一般PCにログオンしている
• 普段アクセスしないサーバへのログオンが記録されている

4625——ログオン失敗

ログオン失敗そのものは日常的に発生しますが、短時間に同一アカウントへの失敗が連続する場合はブルートフォース攻撃の兆候です。また、存在しないアカウント名への失敗が多発している場合はアカウント列挙が行われている可能性があります。

4648——明示的な資格情報を使ったログオン

明示的な資格情報（Explicit Credentials） 現在ログオン中のユーザーとは異なる資格情報を明示的に指定してリソースへアクセスする操作。runasコマンドや管理ツールでの権限昇格時に記録される。

4648はPass-the-Hash攻撃の横展開検知に有効です。通常業務では発生頻度が低いため、多発している場合は精査が必要です。

特権・グループ操作系（4728・4732・4756）

特権グループへの変更は業務外時間・承認なしの追加が発生していないか常時監視する対象です。「AD特権アカウントの設計」で解説したJIT運用と組み合わせ、追加・除外のたびにアラートを飛ばす設計が理想です。

4672——特別な特権の割り当て

特別な特権（Special Privileges） SeDebugPrivilege・SeTcbPrivilegeなど、システムレベルの操作が可能な高危険度の権限。Domain Adminsでのログオン時に必ず記録される。

4672はDomain Adminsアカウントがログオンするたびに記録されます。このイベントが想定外の端末・時間帯に記録されている場合は特権アカウントの不正使用を疑います。

アカウント操作系（4720・4722・4725・4740）

4740（ロックアウト）は特定アカウントへのブルートフォースを示す直接的なサインです。どの端末から試行されたかは Caller Computer Name フィールドで確認できます。

参考：セキュリティ監査イベントの詳細 | Microsoft Learn

攻撃の兆候をログで追う——実務パターン

ブルートフォース攻撃の兆候——4625の連続発生

パターン：短時間に同一アカウントへのイベントID 4625が多発し、その後4624（成功）が記録される。

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

ロックアウトポリシーが適切に設定されていれば4740が発生して攻撃は止まりますが、設定が甘い環境では成功まで試行が続きます。GPOでのロックアウトポリシー設定については「グループポリシー（GPO）設計入門」を参照してください。

Pass-the-Hash・横展開の兆候——4624 LogonType3＋4648

パターン：一般PCから複数サーバへのLogonType 3が連続し、4648（明示的資格情報）が伴う。

Pass-the-Hash攻撃では、侵害した端末から別のサーバへネットワーク認証（LogonType 3）を使って横展開します。通常業務ではあまり発生しない組み合わせのため、検知の手がかりになります。Pass-the-Hashの仕組みについては「AD攻撃手法と要塞化」（公開予定）で詳しく解説します。

特権昇格の兆候——Domain Adminsへの不審な追加

パターン：業務時間外にイベントID 4728が発生し、Domain Adminsにアカウントが追加される。

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

承認フロー外でのDomain Admins追加は、攻撃者による特権昇格または内部不正の疑いがあります。JITの手動運用を行っている環境では、このイベントが発生するたびにアラートを設定することを推奨します。

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

ログ管理でよくある失敗パターン

① ログのサイズ上限が小さくて上書きされている

デフォルトのセキュリティログの最大サイズは20MBです。アクティブなAD環境では数時間で上書きされます。インシデント発生後に「ログが残っていない」という事態を防ぐために、最低1GB以上・保存方法はアーカイブに変更してください。

② 監査ポリシーを設定したが適用されているか確認していない

GPOで監査ポリシーを設定しても、適用対象のOUが正しくなかったり、ローカルポリシーと競合していたりして有効になっていないケースがあります。gpresult /r または auditpol /get /category:* コマンドで実際に適用されているポリシーを必ず確認してください。

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

③ DCのログしか見ていない

認証イベントはDCに記録されますが、ログオンイベント（4624）やアカウント操作はメンバーサーバーにも記録されます。DCのみ監視していると横展開の痕跡を見逃します。重要なメンバーサーバーのログも収集対象に含めてください。

④ ログの確認が属人化している

「ログを見るのはAさんだけ」という状態は、Aさんの不在時に誰もログを見ない状態を生みます。確認手順を文書化し、定期レビューをスケジュール化することが重要です。イベントビューアーだけでなく、Windows Event Forwardingを使ってログを集約サーバに転送する構成も検討してください。

Windows Event Forwarding（WEF） 複数のWindowsマシンのイベントログを中央のコレクターサーバに転送・集約する仕組み。各サーバを個別に確認する手間を省き、集中監視を実現できる。

参考：Active Directory をセキュリティで保護するためのベスト プラクティス | Microsoft Learn

参考：侵入検出に役立つ Windows イベント転送の使用｜Microsoft Build 2026

監査ポリシー設定チェックリスト

監査ポリシー設定

• 高度な監査ポリシーをGPOで設定し、DCとメンバーサーバーに適用している
• ログオン/ログオフ（成功・失敗）を有効にしている
• アカウント管理（成功・失敗）を有効にしている
• セキュリティグループ管理（成功）を有効にしている
• 特権の使用（成功・失敗）を有効にしている
• auditpol /get /category:* で適用結果を確認している

ログ管理

• セキュリティログの最大サイズを1GB以上に設定している
• ログの保存方法を「アーカイブして保存」に設定している
• ログの定期レビュー手順が文書化されている
• Windows Event Forwardingまたはログ集約の仕組みがある

監視・アラート

• Domain Adminsへの追加（4728）をアラート対象にしている
• 4625の連続発生をアラート対象にしている
• 4740（ロックアウト）をアラート対象にしている
• Break Glassアカウントの使用（4624）をアラート対象にしている

まとめ——ログは「取る」より「読める状態にする」ことが目的

ADのイベントログ監査は「記録すること」がゴールではありません。何が正常で何が異常かを判断できる状態にし、攻撃の兆候に気づける運用を作ることが目的です。

今日確認すべきことは2つです。まず auditpol /get /category:* を実行して、現在の監査ポリシーが意図通り有効になっているか確認してください。次にセキュリティログの最大サイズを確認し、デフォルト（20MB）のままであれば拡張してください。この2つだけで、監査の基盤が大きく改善されます。

次のステップは、AD環境に対する具体的な攻撃手法とその対策です。「AD攻撃手法と要塞化」（公開予定）で、Pass-the-Hash・Kerberoasting・GoldenTicketなどの手法と防御設計を解説します。

あわせてご覧ください

• Active Directoryとは？Windows認証基盤の仕組みと設計の基本
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
• グループポリシー（GPO）設計入門｜セキュリティ設定を一括管理する方法
• ADのユーザーとグループ管理｜最小権限を実現する設計パターン
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• 最小権限の原則とは？実務での考え方と設計例
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド