中小企業のWindowsイベントログ監視入門｜不正アクセスの痕跡を情シス1人で見抜く実践ガイド

Windowsのイベントログ、ちゃんと見ていますか？

「セキュリティのことは気になっているけれど、毎日ログを確認する余裕はない」「何かあったときにどこを見ればいいか正直わからない」——そんな声を情シス担当の方からよく聞きます。

実は、不正アクセスやランサムウェアの感染前後には、Windowsイベントログに必ず痕跡が残ります。問題は「どのイベントIDを見ればよいか」「どう絞り込めばよいか」が体系的に整理されていないことです。

この記事では、中小企業の情シス担当者が1人でも実践できるWindowsイベントログ監視の基本を、重要なイベントIDと具体的な確認手順をセットで解説します。難しいツールがなくても、今日から始められます。

Windowsイベントログとは？なぜ不正アクセス調査に欠かせないのか

Windowsイベントログとは、OSやアプリケーション、セキュリティの動作を自動的に記録するログ機能です。イベントビューアー（Event Viewer）から確認でき、以下の3種類のログが特に重要です。

・セキュリティ（Security）ログ: ログイン・ログオフ、権限変更、アカウント操作など。不正アクセス調査の主役
・システム（System）ログ: OSや各種サービスの起動・停止・エラー。不審なサービス起動を検知できる
・アプリケーション（Application）ログ: アプリの動作記録。マルウェアが引き起こすエラーが残ることがある

攻撃者はネットワークに侵入した後、必ず「どこから入ったか」「何をしたか」の痕跡をWindowsのセキュリティログに残します。侵害されてから数週間後に調査する場合でも、ログが残っていれば攻撃の全容を把握できます。

裏を返せば、ログを確認していない企業は、侵害されていても気づかないまま放置している可能性があるということです。IPAの報告では、侵害の発覚まで200日以上かかる事例が国内外で多数確認されています。ログ監視はその発覚までの時間を大幅に縮める、最もコストが低い手段です。

攻撃者が必ず残す痕跡——敵の動きを知る

攻撃者がWindowsシステムに侵入したとき、具体的にどのような行動をとるのか理解しておくことが、ログ監視の第一歩です。

典型的な攻撃の流れを見てみましょう。

①初期侵入
フィッシングメールの添付ファイルを開いた、VPNの認証情報を盗まれた、RDPへのブルートフォース攻撃で突破された——これらは全てイベントログに痕跡が残ります。RDPへの不正ログイン試行は「イベントID 4625（ログオン失敗）」として大量に記録されます。

②内部探索（偵察）
侵入後、攻撃者はどのサーバーやファイル共有があるか調べます。「イベントID 4624（ログオン成功）」で普段と違う時間帯・IPアドレスからのログインが確認できます。

③権限昇格
一般ユーザーから管理者権限を奪取しようとします。「イベントID 4672（特権の割り当て）」「イベントID 4728（セキュリティグループへのメンバー追加）」がそのサインです。

④横移動（ラテラルムーブメント）
1台のPCから別のPCへと侵害を広げます。Pass-the-Hash攻撃など、複数のホストへの短時間でのログイン成功がログに残ります。

⑤目的の実行
ファイルの暗号化、データの外部送信、バックドアの設置など。これらも各ステップでログが記録されます。

このように、攻撃の各段階でWindowsイベントログに痕跡が残ることがわかります。定期的にログを確認しているだけで、攻撃を早期に発見できる可能性が格段に上がります。

監視すべき重要なイベントID一覧

では、具体的にどのイベントIDを優先的に監視すればよいのでしょうか。中小企業の情シス担当者が最低限押さえておくべきIDを整理します。

1. 認証・ログイン関連（最優先）

2. 特権昇格・アカウント操作関連

3. システム・ポリシー変更関連

具体的な監視・確認手順

イベントIDの知識があっても、実際にどうやってログを確認するかがわからなければ意味がありません。ここでは、現場で使える具体的な手順を解説します。

1. イベントビューアーの基本操作

まず、Windowsのイベントビューアーを開く方法から確認しましょう。

# 「ファイル名を指定して実行」（Win+R）で eventvwr.msc を実行
# または スタートメニューを右クリック → 「イベントビューアー」

# セキュリティログの場所:
# イベントビューアー → Windowsログ → セキュリティ

特定のイベントIDで絞り込む手順は以下の通りです。

・右側の「現在のログをフィルター」をクリック
・「イベントID」欄に確認したいID（例: 4625）を入力
・期間（「ログの日付」）を直近1週間などに設定して「OK」

これだけで、特定のイベントIDに絞った一覧が表示されます。大量のログの中から不審なものを効率よく探すための第一歩です。

2. PowerShellで効率的にログを抽出する

イベントビューアーのGUI操作は直感的ですが、定期的な確認や複数サーバーのログ集計にはPowerShellが有効です。以下のコマンドで、直近24時間のログオン失敗を確認できます。

# 直近24時間のログオン失敗（ID 4625）を表示
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-Table -Wrap

# 直近1週間のアカウント作成（ID 4720）を表示
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4720
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Message | Format-Table -Wrap

# 監査ログのクリア（ID 1102）を直近30日で確認
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 1102
    StartTime = (Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Message

ログオン失敗が特定のIPアドレスから短時間に大量に記録されていれば、ブルートフォース攻撃を疑いましょう。その場合の初動対応については、不正アクセスの10の兆候｜アカウント侵害を見抜くチェックリストと初動対応も参考にしてください。

3. 定期的なログ確認ルーティンを作る

「毎日確認する」が理想ですが、1人情シスではそれが難しい場合もあります。現実的な運用として、以下のルーティンを提案します。

・毎朝（5分）: ID 4625のフィルターで、直近12時間に異常な失敗が集中していないか確認
・週1回（15分）: ID 4720（アカウント作成）、ID 4728（グループへの追加）を確認し、不審なアカウント操作がないかチェック
・月1回（30分）: ID 1102（ログクリア）、ID 4719（監査ポリシー変更）を確認し、証拠隠滅の痕跡がないかチェック

このルーティンをカレンダーに登録しておくだけで、重大なインシデントの見落としを大幅に減らせます。

Microsoft 365をご利用の方は、Azure AD（Entra ID）のサインインログも合わせて確認することで、クラウド側の不審なアクセスも把握できます。詳細は中小企業のMicrosoft 365セキュリティ設定をご覧ください。

中小企業でも今日からできること

完全なSIEM環境を構築するのはコストも手間もかかります。まずは以下の3つから始めましょう。

・ログの保存期間を延ばす: Windowsのデフォルトでは、セキュリティログは最大サイズ（20MB）に達すると古いものから上書きされます。グループポリシーでログサイズを200MB程度に拡大し、保存期間を長くしましょう。インシデント発生後に「ログが消えていた」では調査が始められません
・監査ポリシーを正しく設定する: デフォルト設定では一部のイベントが記録されないことがあります。「ローカルセキュリティポリシー」→「監査ポリシー」でログオン成功・失敗、アカウント管理、特権使用の監査を「成功と失敗」に設定してください
・定期確認の仕組みを作る: 前述のPowerShellスクリプトをタスクスケジューラで定期実行し、結果をメールで受け取る仕組みを作ると、確認漏れを防げます

将来的に予算が確保できれば、SIEM（セキュリティ情報・イベント管理）を導入することで、複数サーバーのログを集約して自動検知する体制が整えられます。ただし、まずは「イベントビューアーとPowerShellで定期確認する」というシンプルな習慣から始めることが重要です。

よくある誤解と注意点

【注意】「ログを見ていれば安全」は誤り
ログの確認はあくまで「何かあったことを知る」ための手段です。攻撃を防ぐためには、多要素認証の導入やパッチ適用など、予防的な対策が不可欠です。ログ監視は「後から気づく仕組み」として、予防策と組み合わせて機能します。

【注意】「ログが残っていれば完全に復元できる」は誤り
攻撃者がID 1102（監査ログクリア）を実行してしまうと、その前の痕跡は消えてしまいます。重要なサーバーのログは外部のシステムに転送して保存する「集中ログ管理」が理想です。Linuxサーバーでの集中ログ管理については、姉妹サイトLinuxMaster.JPでも関連技術を解説しています。

【注意】「ID 4624が大量にあれば不正アクセス」は誤り
ログオン成功（4624）は正常な業務でも大量に発生します。重要なのは「発生した時間」「送信元IPアドレス」「対象アカウント」の組み合わせです。深夜に管理者アカウントでログインしているなど、文脈を読んで判断してください。

【注意】イベントID 4688（プロセス作成）は監査設定が必要
ID 4688はデフォルトでは記録されないケースがあります。コマンドラインの引数まで記録するには、グループポリシーの「プロセス作成の監査」を有効化したうえで、「プロセス作成イベントにコマンドラインを含める」も設定してください。これで不審なPowerShellコマンドの実行も記録できます。

セキュリティインシデントが実際に発生した場合、ログは法的証拠にもなりえます。むやみに削除・変更せず、適切に保全することが重要です。

本記事のまとめ

Windowsイベントログは、適切に設定して定期的に確認するだけで、不正アクセスの早期発見に大きく役立ちます。高価なツールがなくても、イベントビューアーとPowerShellで今日から始められます。まずは監査ポリシーの設定確認とログサイズの拡大から、一歩踏み出してみてください。