合同会社小村ソフト
相談する
メニュー

Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる

· 更新日: · · Windows, セキュリティ, イベントログ, 監査ポリシー, ログ設計, PowerShell, 情報システム

更新履歴(7件・最終更新 2026年09月07日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

技術的な主張と条件はそのままに、監査設定を整える人とログを調べる人の読み順を分け、記録先とイベントの見方、ログの容量と保持、保全してから解析する手順、コマンドラインへの機密混入の注意を小見出しで追いやすく整理した。
知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
仕組みの説明を図で追えるよう、Mermaid図を20点追加しました。イベントビューアーで直面する2つの現実、監査ポリシー2系統の使い分け、auditpolで見える結果のポリシー、全部有効が悪手である理由、大量イベント系サブカテゴリの扱い、4624/4625の読み方、ロックアウト調査の手順、失敗の証跡が残るマシン、グループ種類とイベントIDの対応、4688のコマンドライン記録、4698による持続化の検知、1102によるログ消去の切り分け、ログの容量設計と満杯時の挙動、調査手段の使い分け、EventDataを引き抜く整形の型、ログ保全から解析までの流れ、コマンドライン記録有効化の順番、時刻同期と突合調査の前提を図にしています。本文の文章とコード、参考リンクは変えていません。
初版公開
この記事を引用する(DOI: 10.5281/zenodo.22054219)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村 豪(2026)「Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる」合同会社小村ソフト. https://doi.org/10.5281/zenodo.22054219 https://comcomponent.com/blog/windows-security-audit-policy-guide/

DOI(最新版)
10.5281/zenodo.22054219
DOI(この版)
10.5281/zenodo.22637273

「昨夜からあるアカウントがロックアウトを繰り返している。原因を調べてほしい」「退職者のアカウントで誰かがサインインを試みていないか確認したい」「このサーバー、いつ誰が何を実行したか分かる？」── 中小企業の情シス担当者や、客先にシステムを納めている開発者が、ある日突然受け取る依頼です。そして頼みの綱になるのが、WindowsのSecurityイベントログです。

ところが実際にイベントビューアーを開くと、そこには2つの現実が待っています。見たいイベントが記録されていない(監査ポリシーが有効になっていない)か、大量のイベントに埋もれて読めない(ノイズだらけで肥大化している)かです。セキュリティ監査は「有効にすれば録れる」ものですが、何をどこまで録るかを設計しないと、いざというとき役に立ちません。

イベントビューアーで待つ2つの現実イベントビューアーを開くと、監査ポリシーが有効になっておらず見たいイベントが記録されていないか、ノイズだらけで肥大化し大量のイベントに埋もれて読めないかの2つの現実があり、何をどこまで録るかの設計が必要になる録れていない埋もれているイベントビューアーを開く待っている現実は?見たいイベントが未記録大量のイベントで読めない監査ポリシーが無効ノイズだらけで肥大化何をどこまで録るかを設計

図1: 「録れていない」か「埋もれて読めない」か。どちらも、録る範囲を設計していないことが原因。

この記事では、「調査に必要なログを残すための設定」と「残ったログから原因を調べる手順」を分けて整理します。 監査ポリシーの仕組み(基本と詳細の2系統)、中小規模環境で最低限有効化すべきサブカテゴリ、4624/4625/4740/4688の読み方、Securityログの容量設計、PowerShellでの調べ方を扱います。技術的な説明は2026年8月時点の一次情報にもとづくものです。

当サイトで扱ってきたNTLM監査・SMB署名・BitLocker・ファイアウォールの各記事が「守りを固める」話だとすれば、本記事は「何が起きたかを後から確かめられるようにする」話であり、それらを束ねる続編です。

1. まず結論

調査できるログにするには、「必要なものを記録する」「正しいマシンの正しい項目を読む」「消える前に保全する」の3つを揃えます。 監査の有効化だけで終わりにしないことが大切です。

これから設定する人: 詳細側に統一し、必要なものだけ記録する

  • 監査ポリシーには「基本」と「詳細(Advanced Audit Policy)」の2系統があり、混ぜてはいけません。両方を使うと監査結果が予期しない状態になるとMicrosoftが明記しています。詳細側(40以上のサブカテゴリ)で統一します。1
  • 現状確認は auditpol /get /category:* です。GPO・ローカルどちら由来かに関係なく、いま効いている監査設定が一覧できます。2
  • 「全部有効」はやってはいけません。大量のイベントを生むサブカテゴリを有効にすると、肝心のイベントがノイズに埋もれ、性能にも影響します。Microsoftのベースライン推奨を出発点に、必要なものだけ足します。34

いま調べる人: イベントIDだけでなく、記録先とフィールドを確認する

  • サインインの成功は4624、失敗は4625です。4624はログオンタイプ(2=対話、3=ネットワーク、10=リモートデスクトップなど)で「どんなサインインか」を読み分けます。5
  • 4625はStatus/Sub Statusコードで失敗理由が分かります。0xC0000064=存在しないユーザー名、0xC000006A=パスワード誤り、0xC0000072=無効化済みアカウント、0xC0000234=ロックアウト中、が定番です。6
  • イベントは「どのマシンに記録されるか」が決まっています。4624/4625はアクセスされた側のマシン、資格情報の検証(4776)は資格情報に対して権威を持つマシン(ドメインアカウントならドメインコントローラー)、Kerberos事前認証失敗(4771)はドメインコントローラーです。見るマシンを間違えると「ログがない」と誤診します。678

どちらにも必要: ログの保持と、機密情報の扱いを設計する

  • Securityログは器の設計(最大サイズと保持)が半分です。保持が上書きモードなら古いイベントから消えていきます。Get-WinEvent -ListLog Security で最大サイズと件数を確認し、必要な保持日数から逆算して拡張します。910
  • プロセス作成(4688)のコマンドライン記録は強力ですが、機密がログに平文で載るリスクと引き換えです。有効化前にスクリプト類の点検を。1112

目的・症状から読む場所を選ぶ

いま知りたいこと 先に押さえること 読む場所
監査設定を整えたい 実際に効いている設定とログ容量を確認してから、必要なサブカテゴリを選ぶ 2章: 設定の確認、5章: 容量と保持、3章: 判断表
サインインの成功・失敗を読みたい 成功はログオンタイプ、失敗はStatus/Sub Statusを見る 4.1: 4624、4.2: 4625
ロックアウトを繰り返す原因を知りたい 4740で発生源を探し、失敗の証跡はアクセス先やDCでも確認する 4.3: 4740
誰が何を実行したかを調べたい 4688の親プロセスや、4698のタスク定義を読む。コマンドライン記録の追加には事前点検が必要 4.5: 4688、4.6: 4698、7章: 注意点
見たいログがない・すぐ消える 記録先、監査設定、実際に残っている期間を確認する 2章、5章、7章
ログをまとめて調べたい 先にevtxで保全し、IDと期間で絞って抽出する 6.3: 保全、6.2: PowerShell

すでに調査依頼を受けている場合は、6.3でログを保全し、7章の記録先と時刻同期の注意を確認してから、4章の該当イベントを読みます。 設定を整える場合は、2章と5章で現状を確認してから3章へ進んでください。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全34件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 監査ポリシーの基礎 ── 「基本」と「詳細」を混ぜない

2.1. 設定場所と粒度の違いを押さえる

Windowsの監査ポリシーは2系統あります。1

  • 基本の監査ポリシー: 「ローカルポリシー > 監査ポリシー」にある9個のカテゴリ設定。Windows Vistaより前からある古い系統です。
  • 詳細な監査ポリシー(Advanced Audit Policy Configuration): 「セキュリティの設定 > 監査ポリシーの詳細な構成」にある40以上のサブカテゴリ設定。基本の1カテゴリを複数のサブカテゴリに分解したもので、たとえば基本の「アカウントログオンイベントの監査」1つに対して、詳細側には4つのサブカテゴリがあります。基本側で1カテゴリを有効にすることは、対応するサブカテゴリを全部有効にするのと同じであり、興味のないイベントまで大量に記録されます。1

2.2. 詳細側に統一し、基本側による上書きを防ぐ

重要なのは、この2系統は互換ではないことです。Microsoftは「基本と詳細の両方を使うな。監査結果が予期しない状態になる」と明記しています。

グループポリシーで詳細な監査ポリシーを適用すると、そのコンピューターの既存の監査設定はいったんクリアされたうえで詳細側の設定が適用され、以後は詳細側でしか確実に制御できません。

詳細側を使う環境では、セキュリティオプション「監査: 監査ポリシーサブカテゴリの設定を強制する」を有効にして、基本側の設定が上書きしてこないようにしておきます(スタンドアロン機では既定で有効です)。14

基本と詳細の監査ポリシーの関係基本の監査ポリシーと詳細な監査ポリシーは互換ではなく、両方を使うと監査結果が予期しない状態になるため、詳細側に統一しサブカテゴリ設定の強制を有効にして基本側の上書きを防ぐはいいいえ基本の監査ポリシー（9カテゴリ）両方を使う?詳細な監査ポリシー（40超のサブカテゴリ）監査結果が予期しない状態詳細側で統一サブカテゴリの設定を強制するを有効化基本側の設定による上書きを防ぐ

図2: 2系統は互換ではない。詳細側に統一し、「強制する」設定で基本側の上書きを防ぐ。

2.3. auditpolで「結果として効いている設定」を確認する

現状の確認はコマンド1本です。管理者のコマンドプロンプトで実行します。2

次の例は、現状表示・変更前のバックアップ・復元という別々の操作です。まず表示を確認し、変更前にはバックアップを取ります。/restore の行は復元が必要なときに実行するもので、現状確認のために続けて実行する手順ではありません。

rem いま効いている監査設定をサブカテゴリ単位で一覧表示
auditpol /get /category:*

rem 変更前のバックアップ(CSV)と復元
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

auditpol の出力は、GPO由来かローカル設定由来かに関係なく「結果として効いているポリシー」です。GPOで配っているはずの設定が反映されていないときの突き合わせにも使えます。

なお、監査設定自体が変更されるとイベント4719が記録されるので、「いつの間にか監査が無効になっていた」も後から追えます。12

auditpolで見えるのは結果のポリシーauditpolの出力はGPO由来かローカル設定由来かに関係なく結果として効いている監査ポリシーであり、GPOの設定が反映されないときの突き合わせに使え、監査設定自体の変更はイベント4719で後から追えるGPOで配った設定結果として効いているポリシーローカルの設定auditpol /get で一覧GPO未反映時の突き合わせに使える監査設定自体の変更4719が記録され後から追える

図3: auditpolは由来を問わず「効いている設定」を返す。監査設定の変更自体は4719に残る。

3. 最低限有効化すべきサブカテゴリの判断表

3.1. 「全部有効」にしない理由

「とりあえず全部有効」が悪手である理由は明確です。たとえば特権使用系のサブカテゴリを成功まで監査すると、イベント量が膨大になって他のエントリを探すのが困難になり、性能への影響も出るとMicrosoftが警告しています。4 ログの器(5章)は有限なので、ノイズを録るほど本当に必要なイベントの保持日数が削られます。監査設計とは「何を録らないか」を決めることです。

全部有効が悪手である理由すべてのサブカテゴリを有効にすると大量のイベントが生まれ、肝心のイベントがノイズに埋もれて性能にも影響し、有限なログの器では必要なイベントの保持日数も削られるすべてのサブカテゴリを有効化大量のイベントが発生肝心のイベントが埋もれる性能への影響保持日数が削られる何を録らないかを決めるのが監査設計

図4: 「全部有効」は肝心のイベントを埋もれさせる。録らないものを決めるのが監査設計。

3.2. ベースラインを出発点に、必要な記録を選ぶ

Microsoftはワークステーション/サーバー別にベースライン推奨と強化推奨を公開しており、これが出発点になります。3 そのうえで、中小規模環境の「インシデント時に最低限これが読みたい」という観点で整理したのが次の表です。Microsoftの推奨を出発点とした本記事の判断表であり、すべての環境へ一律に適用する設定一覧ではありません。

サブカテゴリ(カテゴリ) 主なイベントID 何が分かるか 中小規模での推奨
ログオン(ログオン/ログオフ) 4624 / 4625 サインインの成功・失敗、ログオンタイプ、送信元 成功+失敗。Windows 10 1809以降は既定でも成功・失敗が有効3
特殊なログオン(同) 4672 / 4964 管理者特権付きサインインの発生 成功
アカウントロックアウト(同) 4625 ロックアウト中のアカウントへのログオン失敗 失敗(4625は失敗イベント。このサブカテゴリに成功イベントは存在しない)13
ユーザーアカウントの管理(アカウント管理) 4720 / 4726 / 4738 / 4740 アカウントの作成・削除・変更・ロックアウト 成功+失敗
セキュリティグループの管理(同) 4728 / 4732 / 4756(追加)、4729 / 4733 / 4757(削除) 管理者グループ等へのメンバー追加・削除(グローバル/ローカル/ユニバーサル) 成功(このサブカテゴリに失敗イベントは存在しない)14
資格情報の検証(アカウントログオン) 4776 NTLM認証の成否。ドメインアカウントはDC側に記録7 成功+失敗
Kerberos認証サービス(同・DCのみ) 4768 / 4771 TGT発行と事前認証失敗(パスワード誤り等)8 DCで成功+失敗
プロセス作成(詳細追跡) 4688 誰が・どの親プロセスから・何を起動したか 成功。コマンドライン記録は7章の注意を読んでから
その他のオブジェクトアクセスイベント(オブジェクトアクセス) 4698 スケジュールされたタスクの作成(攻撃の持続化の定番)15 成功を検討
監査ポリシーの変更(ポリシーの変更) 4719 監査設定自体の変更 成功+失敗

3.3. 大量に記録されるものは、対象と期間を絞る

逆に、ファイルシステムやレジストリのオブジェクトアクセス監査、特権使用、パケットフィルター系(5152など)は既定では手を出さないのが無難です。これらは対象を絞ったSACL設定や切り分け期間限定でこそ役立つもので、常時全開にするとログを食い潰します。4

大量イベント系サブカテゴリの扱いファイルシステムやレジストリのオブジェクトアクセス監査、特権使用、パケットフィルター系は常時全開にするとログを食い潰すため、対象を絞ったSACL設定や切り分けの期間限定でこそ役立つ常時全開対象を絞ったSACL切り分けの期間限定大量イベント系サブカテゴリどう有効化する?オブジェクトアクセス監査特権使用・パケットフィルター系ログを食い潰す役立つ役立つ

図5: オブジェクトアクセスや特権使用は常時全開にしない。対象と期間を絞ってこそ役立つ。

4. 定番イベントIDの読み方

「どのイベントか」「どのマシンに残るか」「どのフィールドを見るか」を一組で確認します。 サインインは4.1・4.2、ロックアウトは4.3、アカウント変更は4.4、実行された処理は4.5・4.6が入口です。実際の調査では、先に6.3の方法で保全してください。

4.1. 4624 ── サインイン成功はログオンタイプで読み分ける

4624は「アカウントが正常にログオンしました」で、ログオンセッションが作られたマシン(アクセスされた側)に記録されます。5 大量に記録されるイベントなので、読むときはログオンタイプでまず仕分けます。5

ログオンタイプ 名称 実務での意味
2 Interactive そのPCのコンソールでのサインイン
3 Network ネットワーク経由のアクセス(共有フォルダー、管理ツール等)。台数分出るので最も多い
4 Batch バッチ実行(スケジュールされたタスク等)
5 Service サービスの起動(サービス制御マネージャー)
7 Unlock 画面ロックの解除
8 NetworkCleartext パスワードが平文のまま認証パッケージに渡されたネットワークログオン
9 NewCredentials 別資格情報の複製(runas /netonly 相当)
10 RemoteInteractive リモートデスクトップ
11 CachedInteractive キャッシュされた資格情報でのサインイン(DCに接続できない状態)

タイプで仕分けたあと、アカウント・送信元・権限を見る

あわせて見るフィールドは、「新しいログオン」のアカウント名、「ネットワーク情報」の送信元アドレス、「認証パッケージ」(NTLMかKerberosか)、そして「昇格されたトークン」(管理者特権セッションか)です。管理者特権のサインインだけを追いたいなら、同じログオンIDで記録される4672(特殊な特権の割り当て)も使えます。5

4624を読み分ける手順大量に記録される4624はまずログオンタイプで仕分け、アカウント名と送信元・認証パッケージ・昇格されたトークンを確認し、管理者特権のサインインは同じログオンIDの4672と突き合わせる4624 サインイン成功ログオンタイプで仕分け主要フィールドを確認アカウント名と送信元認証パッケージ昇格されたトークン管理者特権の追跡同じログオンIDの4672

図6: 4624はログオンタイプで仕分けてからフィールドを読む。特権サインインは4672と相関させる。

4.2. 4625 ── 失敗理由はStatus/Sub Statusコードで確定する

4625は「アカウントがログオンに失敗しました」で、ログオンが試行されたマシンに記録されます。6 「失敗の理由」欄の文言よりも、Status/Sub Statusの16進コードで読むのが確実です。定番は次のとおりです。6

まずStatus/Sub Statusで失敗理由を読む

  • 0xC0000064: 存在しないユーザー名。短時間に連続していたらアカウント列挙攻撃の兆候
  • 0xC000006A: パスワード誤り。特定アカウントに連続していたらパスワード推測攻撃の兆候
  • 0xC000006D: ユーザー名または認証情報が不正
  • 0xC000006F: 許可された時間帯の外
  • 0xC0000070: 許可されていないワークステーションから
  • 0xC0000072: 管理者によって無効化されたアカウント(退職者アカウントへの試行はここに出る)
  • 0xC000015B: このマシンで要求されたログオンタイプが許可されていない
  • 0xC0000193: 期限切れアカウント
  • 0xC0000234: ロックアウト中

対象アカウント・送信元・失敗理由を組み合わせる

「誰が・どこから・なぜ失敗したか」は、対象アカウント+送信元(ワークステーション名/IPアドレス)+このコードの3点セットで確定します。6.2に、この3点を一括抽出するPowerShellを載せています。

4625の失敗理由を確定する流れ4625の失敗理由はStatus/Sub Statusの16進コードで確定し、コードの傾向から攻撃の兆候を読んだうえで、対象アカウントと送信元を合わせた3点セットで特定する0xC0000064の連続0xC000006Aの連続0xC00000724625 サインイン失敗Sub Statusコードを確認コードの傾向は?アカウント列挙の兆候パスワード推測の兆候退職者アカウント試行3点セットで確定対象アカウント+送信元+コード

図7: 失敗理由はコードで確定し、対象アカウント・送信元と合わせた3点セットで読む。

4.3. 4740 ── ロックアウトの発生源は「呼び出し元コンピューター名」

発生源を探す: 4740の呼び出し元コンピューター名

4740は「ユーザーアカウントがロックアウトされました」です(サブカテゴリはユーザーアカウントの管理)。このイベントの主役は「呼び出し元コンピューター名(Caller Computer Name)」フィールドで、ロックアウトの引き金になったログオン試行がどのコンピューターから来たかが記録されています。16 ここで発生源の端末を特定し、その端末に残っている古い資格情報を洗う、が定石です。

原因はパスワード変更後も古い資格情報を使い続ける何か(保存済み資格情報、切断されたままのRDPセッション、古いパスワードのサービスやタスク)であることがほとんどです。

アカウントロックアウト調査の定石4740の呼び出し元コンピューター名で発生源端末を特定し、その端末に残る保存済み資格情報、切断されたままのRDPセッション、古いパスワードのサービスやタスクを洗う4740 ロックアウト発生呼び出し元コンピューター名を確認発生源の端末を特定古い資格情報を洗う保存済み資格情報切断されたままのRDPセッション古いパスワードのサービスやタスク

図8: 4740の「呼び出し元コンピューター名」から発生源を特定し、その端末の古い資格情報を洗う。

失敗の証跡を探す: 発生源ではなく、受け付けた側も見る

注意点がひとつあります。4625が記録されるのはログオン試行を受け付けた側のコンピューターです。発生源端末からファイルサーバー等へのネットワークログオンが原因の場合、発生源端末自身のSecurityログには4625が残らず、アクセス先サーバーの4625や、ドメインアカウントならDC側の4776(NTLM)/4771(Kerberos事前認証失敗)に証跡が残ります。78 「発生源端末のログに何もない」ときは、受け付けた側を見に行ってください。

調査の流れは、4740の呼び出し元で発生源を探す → アクセス先の4625やDCの4776/4771を時刻順に突き合わせる → 発生源端末の保存済み資格情報・サービス・タスクなどを確認する、と整理できます。発生源を探すことと、失敗イベントの記録先を探すことは別です。

失敗の証跡が残るマシンネットワークログオンの失敗は発生源端末自身には残らず、ログオン試行を受け付けたアクセス先サーバーの4625に記録され、ドメインアカウントならDC側の4776や4771にも証跡が残るネットワークログオンドメインアカウントの認証発生源端末（自身に4625は残らない）アクセス先サーバー4625が記録されるドメインコントローラー4776（NTLM）/4771（Kerberos）

図9: 4625は受け付けた側に残る。発生源端末に何もなければ、アクセス先サーバーとDC側を見る。

4.4. 4720系 ── アカウントの作成・変更・グループ追加

アカウントの変更と、グループのメンバー変更を分ける

アカウント管理系は番号が並んでいます。4720(ユーザーアカウントの作成)17、4726(削除)、4738(変更)、そしてグループ側のメンバー追加/削除です。

グループのメンバー変更はグループの種類でイベントIDが分かれる点に注意してください。ローカルグループが4732/4733、グローバルグループが4728/4729、ユニバーサルグループが4756/4757です。14 Domain Adminsはグローバルグループなので、そこへの追加は4728に記録されます ── 4732だけをアラート条件にすると、いちばん見たい事象を取りこぼします。

予期しない管理者グループへの追加は、単発でも調べる

日常的にはヘルプデスク作業の記録ですが、「標準ユーザーが管理者グループに突然追加された」「誰も知らないアカウントが作られた」は単発でも即調査対象です。Microsoftも、特権グループへの予期しないメンバー追加を単発アラートの例に挙げています。3

グループ種類とメンバー追加イベントグループへのメンバー追加はグループの種類でイベントIDが分かれ、ローカルは4732、グローバルは4728、ユニバーサルは4756に記録されるため、グローバルグループのDomain Adminsへの追加は4728を見るローカルグローバルユニバーサルグループへのメンバー追加グループの種類は?4732に記録4728に記録4756に記録Domain Adminsへの追加はここ4732だけの監視は取りこぼす

図10: メンバー追加のイベントIDはグループの種類で分かれる。Domain Adminsへの追加は4728。

4.5. 4688 ── プロセス作成。コマンドライン記録は別スイッチ

プロセス作成の監査で分かること

4688は「新しいプロセスが作成されました」で、プロセス作成のたびに、作成したアカウント、新しいプロセスの実行ファイルパス、親プロセス、トークン昇格タイプが記録されます。11 「このサーバーで誰が何を実行したか」に答えられる、調査価値の高いイベントです。

コマンドラインを残すには、別の設定と事前点検が必要

ただし既定ではコマンドライン引数は記録されません。「プロセス作成イベントにコマンドラインを含める」というグループポリシー(管理用テンプレート > システム > プロセス作成の監査)を別途有効にして初めて、4688の「プロセスのコマンドライン」フィールドに引数が入ります。1112 powershell -EncodedCommand ... のような不審な起動を追うには事実上必須の設定ですが、7章で述べる機密混入のリスクを理解してから有効化してください。先に7章を読み、引数で機密を渡している箇所を直してから設定します。

4688とコマンドライン記録の関係プロセス作成の監査を有効にすると4688にアカウント・実行ファイルパス・親プロセスが記録されるが、コマンドライン引数は別のグループポリシーを有効にして初めて記録され、機密が平文で載るリスクがある既定のままGPOを追加有効化プロセス作成の監査を有効化4688が記録されるアカウント・パス・親プロセス引数も見たい?コマンドラインは空引数が記録される機密が平文で載るリスク

図11: 4688のコマンドライン記録は別スイッチ。有効化には機密混入リスクの点検が先。

4.6. 4698 ── スケジュールされたタスクの作成

4698は「スケジュールされたタスクが作成されました」で、タスク名とタスク定義のXML全文(実行コマンドを含む)が記録されます。マルウェアが再起動後も生き残るための常套手段がタスク登録であるため、Microsoftはタスク作成イベントの監視を推奨しています。15 業務でタスクを多用する環境でも、作成は日常的に起きるものではないので、ノイズは小さめです。

タスク登録による持続化と4698マルウェアは再起動後も生き残るためにスケジュールされたタスクの登録を常套手段とするため、タスク作成で記録される4698を監視すれば実行コマンドを含むタスク定義まで追えるマルウェアの持続化タスクを登録して生き残る4698が記録される実行コマンドを含むXML全文タスク作成の監視で検知作成は日常的でなくノイズ小

図12: 持続化の常套手段であるタスク登録は4698に残る。定義XML全文から実行コマンドまで追える。

ログ自体が消去されたかは、1102も確認する

もう1つ覚えておきたいのが1102「監査ログが消去されました」です。Securityログのクリアは必ずこのイベントを残すので、「ログが空になっている」ときに事故か操作かを切り分けられます。18

1102によるログ消去の切り分けSecurityログのクリアは必ず1102を残すため、ログが空になっているときは1102の有無を確認することで、消去の操作だったのか事故なのかを切り分けられるあるないログが空になっているクリアは必ず1102を残す1102はあるか?消去の操作があった事故の可能性を疑う

図13: Securityログのクリアは必ず1102を残す。空のログは1102の有無で事故か操作かを切り分ける。

5. ログの器の設計 ── 最大サイズと保持

5.1. 満杯時に「古い記録」と「新しい記録」のどちらが失われるか

監査ポリシーを増やす前に、受け皿を確認します。Securityログには最大サイズと保持モードがあり、上書きモード(既定的な構成)では、最大サイズに達すると新しいイベントが最も古いイベントを上書きします。逆に保持モード(上書きしない)では、ログが満杯になると新しいイベントのほうが破棄されます。10 どちらの挙動も「気づいたらログがない」の原因になるため、現状把握が先です。

5.2. 実際に残っている日数から、必要な容量を考える

# Securityログの器を確認: 保持モード・最大サイズ・現在の件数
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# いま実際に何日分残っているか(最古イベントの日時)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog はログの構成と件数をまとめて返します。9 「最古イベントの日時」と現在の差が実際の保持日数で、これが自社の要件(インシデント調査で遡りたい日数)に足りなければ最大サイズを広げます。設定は wevtutil sl Security /ms:<バイト数> またはグループポリシーで配布できます。10

容量は「何日分を残したいか」から考えます。 監査サブカテゴリを増やすとイベント量も増えるため、設定変更後には実際に残っている日数を再確認してください。上書きされる前に定期エクスポートするか、別マシンへ集約する運用も必要です。

保持日数から逆算する容量設計Get-WinEventのListLogで構成と件数を確認し、最古イベントの日時から実際の保持日数を求め、インシデント調査で遡りたい日数に足りなければ最大サイズを広げる足りる足りないListLogで構成と件数を確認最古イベントの日時を確認実際の保持日数を算出要件に足りる?現状のサイズを維持最大サイズを広げるwevtutil slかGPOで設定

図14: 実際に残っている日数を確かめ、遡りたい日数から逆算して最大サイズを決める。

5.3. CrashOnAuditFailは、容量不足を解決する設定ではない

なお、セキュリティオプションには「監査: セキュリティ監査のログを記録できない場合は直ちにシステムをシャットダウンする」(いわゆるCrashOnAuditFail)という設定があります。有効時に監査を記録できなくなると、STOPエラー C0000244 でシステムが停止します。監査証跡を絶対に落とせない認証要件のための設定で、既定は無効です。

攻撃者が大量のイベントを発生させて意図的にサーバーを止めるDoSに転化しうるとMicrosoft自身が注意しており、一般的な中小規模環境で安易に有効化すべきものではありません。19

ログ満杯時の挙動保持の構成は上書きモードと上書きしないモードの2通りで、上書きしないモードで監査を記録できなくなったとき、別枠の設定であるCrashOnAuditFailが有効ならSTOPエラーC0000244でシステムが停止する上書きモード上書きしないはいSecurityログが最大サイズに到達保持の構成は?最も古いイベントが上書きされる新しいイベントが破棄されるどちらも気づいたらログがないの原因CrashOnAuditFailも有効?STOPエラー C0000244で停止

図15: 保持の構成は上書きか破棄の2通り。CrashOnAuditFailは別枠の設定で、記録できないときに停止させる。

6. 調べ方の実務 ── フィルター、Get-WinEvent、エクスポート

実際に手を動かす順番は「6.3で保全 → 6.1または6.2で解析」です。 ここでは調査手段ごとに説明します。単発ならイベントビューアー、件数が多い・繰り返す調査ならPowerShellを使います。

6.1. イベントビューアーでの絞り込み

単発の調査ならイベントビューアーで十分です。Securityログを開き、「現在のログをフィルター」でイベントID(例: 4625)と期間を指定します。繰り返し見る条件は「カスタムビューの作成」で保存しておくと、次回から1クリックです。イベントIDだけでなく特定アカウントなどで絞りたい場合は、フィルターダイアログのXMLタブでXPathクエリを直接編集できます。

6.2. Get-WinEventでの抽出

件数が多い調査・複数条件・定期実行は、PowerShellの Get-WinEvent に切り替えます。ポイントはフィルターをサーバー側で効かせる -FilterHashtable を使うことです。9

調査手段の使い分け単発の調査はイベントビューアーのフィルターで足り、繰り返し見る条件はカスタムビューに保存し、件数が多い調査や複数条件・定期実行はGet-WinEventに切り替える単発繰り返し見る条件大量・複数条件・定期どんな調査?イベントビューアーで絞り込みカスタムビューに保存Get-WinEventに切り替えFilterHashtableで絞り込み

図16: 単発はイベントビューアー、繰り返すならカスタムビュー、件数が多ければGet-WinEvent。

IDと期間で絞り、対象アカウント・送信元・失敗理由を取り出す

次の前半は直近24時間の4625を取得します。後半はXMLの各フィールドを取り出し、アカウント・Status・SubStatus・送信元の組み合わせごとに件数を集計する例です。最後の表は個々のイベントの時刻順一覧ではなく、同じ組み合わせが何件あったかを多い順に表示します。

# 直近24時間のサインイン失敗(4625)を取得
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# 「誰が・どこから・なぜ」を表に整形する
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

XMLから必要なフィールドを読む型を、ほかのイベントにも使う

イベントのXML表現からEventDataを引き抜くこの型を1つ持っておくと、4624でも4688でも同じ要領で使い回せます。Get-WinEvent の絞り込み設計(FilterHashtableとXPathの使い分け、遅いクエリの直し方)は「Get-WinEventでイベントログを実務的に調べる」で詳しく扱っています。

EventDataを引き抜く整形の型Get-WinEventで取得したイベントをXML表現に変換し、EventDataの各フィールドを引き抜いて表に整形するこの型は、4625に限らず4624や4688でも同じ要領で使い回せるGet-WinEventで取得イベントをXML表現に変換EventDataを引き抜く表に整形して集計4624や4688でも同じ要領

図17: XML表現からEventDataを引き抜いて表にする型は、イベントIDが変わっても使い回せる。

6.3. wevtutilでのエクスポート

調査対象マシンのログは、上書きで消える前にまずエクスポートして確保するのが原則です。10

rem Securityログを丸ごとevtxで保全
wevtutil epl Security C:\logs\security-20260801.evtx

rem 4625だけをXPathで絞ってエクスポート
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

保存したevtxを、別マシンで解析する

エクスポートした .evtx は、別マシンで Get-WinEvent -Path C:\logs\security-20260801.evtx として同じように解析できます。9 保全してから解析する習慣は、クラッシュ調査で「まずダンプを確保する」のと同じ発想です(「Windowsクラッシュダンプ収集入門」参照)。

保全してから解析する流れ調査対象マシンのSecurityログをwevtutil eplでevtxファイルにエクスポートして確保し、別マシンでGet-WinEventのPath指定により同じように解析する調査対象マシンwevtutil eplでevtxに保全別マシンへ持ち出しGet-WinEvent -Pathで解析上書きで消える前に確保

図18: まず保全、それから解析。evtxに確保すれば別マシンで同じように調べられる。

7. 落とし穴 ── 現場で踏みやすい4つ

7.1. 4688のコマンドラインに機密が乗る

コマンドライン記録を有効にすると、すべてのプロセスの引数がSecurityログに平文で入ります。Microsoftは「セキュリティイベントの読み取りアクセス権を持つ全ユーザーが、あらゆるプロセスのコマンドライン引数を読める。引数にはパスワード等の機密が含まれうる」と明記しています。12 myapp.exe /user:admin /password:P@ssw0rd のような起動をしている業務アプリ・スクリプトが1つでもあれば、それはログ閲覧者全員への機密公開です。

有効化の前に、機密を引数渡ししている箇所を洗い出して直すこと。ログの保全・転送先でも同じ扱いレベルが必要になります。

コマンドライン記録を有効化する順番4688のコマンドライン記録は有効化の前に機密を引数渡ししている業務アプリやスクリプトを洗い出し、該当箇所を直してから有効化する順番を守り、ログの保全・転送先にも同じ扱いレベルを求めるあるない機密の引数渡しを洗い出す該当はある?渡している箇所を直すコマンドライン記録を有効化保全・転送先も同じ扱いレベル

図19: コマンドライン記録は「洗い出して直してから有効化」。順番を逆にすると機密公開になる。

7.2. ログ満杯時の挙動を知らずに運用している

上書きモードなら古い証跡が黙って消え、上書きしない設定なら新しいイベントが破棄され、CrashOnAuditFail有効ならシステムごと止まります(5章)。1019 どの挙動を選んでいるかを把握し、「消える前に集める」仕組み(定期エクスポートやログ収集基盤)を用意するのが本筋です。

7.3. ドメインコントローラーと端末で見るべきログが違う

4624/4625はアクセスされたマシンに記録されます。56 一方、ドメインアカウントの資格情報の検証(NTLMの4776)は資格情報に対して権威を持つマシン、つまりドメインアカウントならDCに記録され7、Kerberosの事前認証失敗(4771)はDCにしか記録されません。8 「ファイルサーバーに4625がない=攻撃がなかった」ではなく、DC側の4776/4771も突き合わせて初めて全体像になります。どの認証プロトコルがどう流れるかは「図解でわかるNTLMとKerberos」を参照してください。

7.4. 時刻同期がずれていると突合できない

複数マシンのログを並べて「この4740の直前にどの端末で4625が出たか」を追う作業は、各マシンの時計が合っていることが前提です。ドメイン環境ではKerberos自体がクロックのずれに上限(既定5分)を設けており、それを超えると認証そのものが失敗し始めます。20 調査の観点では5分どころか数秒のずれでも前後関係を誤読させるので、w32timeの同期状態の確認を調査手順の最初に入れておくこと。

また、イベントの記録時刻はUTCで保存され、表示は閲覧マシンのタイムゾーンに従うため、海外拠点やUTC設定のサーバーから持ってきたevtxを読むときはタイムゾーンの読み替えを忘れないでください。

時刻同期と突合調査の前提複数マシンのログを時刻順に突き合わせる調査は各マシンの時計が合っていることが前提で、数秒のずれでも前後関係を誤読させ、既定5分を超えるずれではKerberos認証自体が失敗するため、w32timeの同期確認を調査手順の最初に入れる合っている数秒のずれ既定5分を超える複数マシンのログを突合時計が合っていることが前提時計のずれは?時刻順に追える前後関係を誤読Kerberos認証が失敗w32timeの確認を手順の最初に

図20: 複数マシンの突合は時計合わせが前提。数秒のずれでも前後関係の誤読につながる。

8. まとめ

WindowsのSecurityログを調査に使うには、記録する範囲、読む場所と項目、保全する仕組みを一緒に設計します。

設定を整えるとき

監査ポリシーは「基本」と「詳細」を混ぜず、詳細側で統一します。auditpol /get /category:* で現状を確認し、Microsoftのベースライン推奨を出発点に、ログオン・アカウント管理・プロセス作成を軸とした3章の判断表から始めてください。「全部有効」にするとノイズと肥大化で調査が難しくなります。

ログの器(最大サイズ・保持モード)は監査設計の半分です。実際に残っている日数を確認し、要件から逆算してサイズを決め、消える前にエクスポートまたは集約します。4688のコマンドライン記録は、機密混入のリスクを点検してから有効にします。

調査するとき

まず保全、それから解析です。wevtutil epl で確保し、マシンごとの記録先と時刻同期を確認してから読み始めます。単発はイベントビューアーのフィルター、繰り返す調査は Get-WinEvent -FilterHashtable を使います。

読むときの急所は、4624はログオンタイプ、4625はStatus/Sub Status、4740は呼び出し元コンピューター名、4688は親プロセスとコマンドラインです。イベントIDだけで判断せず、どこに記録された何の情報かを確かめ、必要なログを突き合わせてください。

関連記事

関連する相談領域

合同会社小村ソフトでは、Windows環境の監査ポリシー・ログ設計の相談、イベントログにもとづく「いつ・誰が・何をしたか」の調査、業務アプリが認証・監査まわりで起こすトラブルの原因解析を扱っています。「ログを見てくれと言われたが、どこから手を付けるべきか」の段階からで構いません。

参考リンク

  1. Microsoft Learn, Advanced security auditing FAQ. 基本の監査ポリシー(ローカルポリシー配下の9設定)と詳細な監査ポリシーの違い、基本の1カテゴリ有効化が対応するサブカテゴリ全有効化と等価であること、両者に互換性がなく併用すると監査結果が予期しない状態になるため混ぜてはいけないこと、グループポリシーで詳細側を適用すると既存の監査設定がクリアされること、「監査: 監査ポリシーサブカテゴリの設定を強制する」を有効にすべきこと、イベント量を最小化するには重要なリソース・活動・ユーザーを特定して絞ることについて。 ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. auditpol コマンドがシステム監査ポリシーの表示(/get)・設定(/set)・CSVへのバックアップ(/backup)・復元(/restore)・クリア(/clear)を行えることについて。 ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. ワークステーション/サーバー別のWindows既定値・ベースライン推奨・強化推奨の一覧表、推奨はあくまで出発点であり各組織が脅威とリスク許容度に応じて検討・テストすべきこと、ログオンサブカテゴリがWindows 10 1809以降は成功・失敗とも既定で有効であること、サーバーだけでなくワークステーションの監視も重要であること、特権グループへの予期しないメンバー追加など単発でアラートすべきイベントの例、失敗ログオンの急増をベースライン比較で検知する考え方について。 ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. 40以上の監査サブカテゴリで精密に管理できること、この設定を有効のままにするのがベストプラクティスでクライアント・メンバーサーバー・DCの有効既定値がEnabledであること、特権使用サブカテゴリ全有効化のような大量イベントを生む設定はセキュリティログから他のエントリを見つけにくくし性能にも大きな影響を与えうるという警告について。 ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. 4624がログオンセッション作成時にアクセスされた側のコンピューターに記録されること、ログオンタイプの一覧(2=Interactive、3=Network、4=Batch、5=Service、7=Unlock、8=NetworkCleartext、9=NewCredentials、10=RemoteInteractive、11=CachedInteractive)、昇格されたトークン(Elevated Token)フラグ、認証パッケージ(NTLM/Kerberos/Negotiate)とNTLMのPackage Name(NTLM V1/V2/LM)、ログオンIDによる4672等との相関について。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. 4625がログオン試行の行われたコンピューター(ユーザー端末での試行なら端末)に記録されること、サブカテゴリがアカウントロックアウトとログオンであること、Status/Sub Statusコードの意味(0xC0000064=不正なユーザー名、0xC000006A=パスワード誤り、0xC000006D=ユーザー名または認証情報の不正、0xC000006F=許可時間帯外、0xC0000070=未許可ワークステーション、0xC0000072=無効化されたアカウント、0xC000015B=ログオンタイプ未許可、0xC0000193=期限切れアカウント、0xC0000234=ロックアウト)と、連続する0xC0000064がアカウント列挙攻撃の兆候でありうることについて。 ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. 4776がNTLM認証での資格情報検証のたびに記録されること、記録されるのは資格情報に対して権威を持つコンピューターのみであり、ドメインアカウントならドメインコントローラー、ローカルアカウントならローカルコンピューターであること、成功・失敗の両方が記録されることについて。 ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. 4771がKDCによるKerberos TGT発行の失敗(パスワード誤り・期限切れ等)のたびに記録されること、このイベントはドメインコントローラーでのみ生成されることについて。 ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). -ListLog によるログ構成(LogMode・MaximumSizeInBytes・RecordCount)の取得、-FilterHashtable によるLogName・Id・StartTime等のハッシュテーブル指定での効率的なフィルタリング、-Path による保存済み.evtxファイルの読み取り、-Oldest / -MaxEvents による古い順・件数指定の取得について。 ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. set-log(sl)による最大サイズ(/ms)・保持モード(/rt)の設定、保持モードがtrueだとログ満杯時に既存イベントが保持され新しいイベントが破棄されること、falseだと新しいイベントが最も古いイベントを上書きすること、export-log(epl)によるイベントログのファイルへのエクスポートと/qオプションによるXPathクエリでの絞り込み、query-events(qe)によるクエリ実行について。 ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. 4688が新しいプロセスの開始ごとに記録されること、作成者アカウント・新プロセスの実行ファイルパス・作成元(親)プロセス名・トークン昇格タイプが含まれること、Process Command Lineフィールドは既定で空であり「プロセス作成イベントにコマンドラインを含める」グループポリシーを有効にして初めて記録されることについて。 ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. コマンドライン記録には詳細な監査ポリシーのプロセス作成の監査と「プロセス作成イベントにコマンドラインを含める」(管理用テンプレート > システム > プロセス作成の監査、既定は未構成)の両方が必要なこと、有効化するとすべてのプロセスのコマンドライン情報がセキュリティイベントログに平文で記録され、読み取りアクセス権を持つ全ユーザーがパスワード等の機密を含みうる引数を読めるという注意、詳細な監査ポリシーが基本設定に上書きされるとイベント4719が記録され「強制する」設定で防げることについて。 ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. アカウントロックアウトサブカテゴリがロックアウト中のアカウントへのログオン失敗を監査すること、生成されるイベントが4625(F)であること、このサブカテゴリに成功イベントは存在せず成功監査を有効化する意味がないこと、全コンピューター種別で失敗の監査が推奨されることについて。 ↩

  14. Microsoft Learn, Audit Security Group Management. セキュリティグループの作成・変更・削除とメンバー追加・削除を監査するサブカテゴリであること、メンバー追加/削除のイベントIDがローカルグループ4732/4733・グローバルグループ4728/4729・ユニバーサルグループ4756/4757とグループ種類で分かれること、4728等のドメイングループ専用イベントがあること、このサブカテゴリに失敗イベントは存在せず全コンピューター種別で成功の監査が推奨されることについて。 ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. 4698がスケジュールされたタスクの作成ごとに記録されること、サブカテゴリがその他のオブジェクトアクセスイベントであること、タスク名と実行コマンドを含むタスク定義XML全文が記録されること、マルウェアが再起動後の持続化にタスクを常用するため特に重要マシンでのタスク作成イベント監視が推奨されることについて。 ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. 4740がユーザーアカウントのロックアウトごとに記録されること、サブカテゴリがユーザーアカウントの管理であること、Caller Computer Nameフィールドにロックアウトを引き起こしたログオン試行の受信元コンピューター名が記録されることについて。 ↩

  17. Microsoft Learn, 4720(S): A user account was created. 4720が新しいユーザーオブジェクトの作成ごとにドメインコントローラー・メンバーサーバー・ワークステーションで記録されること、サブカテゴリがユーザーアカウントの管理であることについて。 ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. イベント1102がWindowsセキュリティ監査ログの消去のたびに記録されることについて。 ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. この設定が有効な場合にセキュリティ監査を記録できないとSTOPメッセージ C0000244 {Audit Failed} でシステムが停止すること、既定値がDisabledであること、大量のセキュリティイベントを発生させて意図的にシャットダウンを強制するDoSに転化しうること、突然の停止によりアプリケーションデータが使用不能になるおそれがあることについて。 ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. Kerberos v5がリプレイ攻撃対策としてタイムスタンプを用いるため、クライアントとドメインコントローラーの時計のずれに最大許容差(既定・推奨とも5分)が設定されており、これを超えるとタイムスタンプが真正と見なされないことについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

監査ポリシーを何も設定していないのに、Securityログに4624や4625が記録されているのはなぜですか？
Windowsには既定で有効な監査サブカテゴリがあるためです。たとえば「ログオン」サブカテゴリは、Windows 10 バージョン1809以降では成功・失敗の両方が既定で有効なので、何も設定しなくても4624(成功)と4625(失敗)は記録されます。ただし既定のままでは、資格情報の検証(4776)やプロセス作成(4688)など、調査で欲しくなるイベントの多くは記録されません。自分の環境で何が有効かは auditpol /get /category:* で確認できます。そのうえで、足りないサブカテゴリを詳細な監査ポリシー側で明示的に有効化するのが実務の型です。
サインイン失敗を調べたいのに、対象サーバーのSecurityログに4625が見当たりません。どこを見ればよいですか？
まず、4625は「ログオンが試行されたコンピューター」に記録されるという原則を確認してください。ユーザーの端末でのサインイン失敗なら端末側、ファイルサーバーへのアクセス失敗ならファイルサーバー側です。次に auditpol /get /category:* で「ログオン」サブカテゴリの失敗の監査が有効かを確認します。ドメインアカウントの場合は、ドメインコントローラー側の資格情報の検証(4776)やKerberos事前認証失敗(4771)に記録が残っていることも多く、端末を特定できないときはむしろDC側から調べるほうが早道です。それでも見つからなければ、ログの上書きで過去分が消えていないか(ログの最大サイズと最古イベントの日時)を確認してください。
プロセス作成(4688)のコマンドライン記録は有効化すべきですか？
調査価値は非常に高い一方、リスクを理解してから有効化すべき設定です。有効化すると、すべてのプロセスのコマンドライン引数がSecurityログに平文で記録されます。コマンドラインにパスワードやAPIキーを渡すスクリプトや業務アプリが1つでもあると、その機密はSecurityログを読める全員に見える状態になります。Microsoft自身がこの注意点を明記しています。まず自社のスクリプト類が機密をコマンドライン引数で渡していないかを点検し、渡している箇所を直してから有効化する、という順番をお勧めします。
Securityログの最大サイズはどのくらいにすべきですか？
「何日分を手元に残したいか」から逆算するのが正攻法で、万能の数値はありません。現在の設定と実績は Get-WinEvent -ListLog Security で確認でき、最古イベントの日時と現在の日時の差が「いま実際に残っている日数」です。監査サブカテゴリを増やすとイベント量も増えるので、設定変更後に必ずこの実残存日数を再確認してください。インシデント対応では数週間〜数か月前のログが必要になることが珍しくないため、上書きで消える前に定期的にエクスポートするか、ログ収集の仕組みで別マシンに集約しておくと安心です。
アカウントロックアウト(4740)の原因はどうやって調べますか？
4740イベントの「呼び出し元コンピューター名(Caller Computer Name)」フィールドが最初の手がかりです。ここに、ロックアウトの引き金になった失敗ログオンの発生元コンピューターが記録されています。ただし、失敗の記録そのもの(4625)は発生源ではなくログオン試行を受け付けた側に残る点に注意してください。ネットワークログオン由来なら、アクセス先サーバーの4625や、ドメインアカウントならドメインコントローラーの4776/4771を時刻順に追います。そのうえで発生源として特定した端末側では、パスワード変更後も古い資格情報を持ち続けているもの、つまり保存済み資格情報、切断されたままのリモートデスクトップセッション、古いパスワードで構成されたサービスやスケジュールされたタスクを洗います。ロックアウトが繰り返される場合は、時刻同期がずれていないかも合わせて確認してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る