Windowsイベントログ・Sysmon・auditdの読み方
侵害の証拠は、すでにログの中にある。攻撃者がそれを消してしまう前に、実務者目線で「読み解く」技術を身につけましょう。
📋 この記事の目次
侵害を受けたとき、多くの初動対応者がまず口にするのは「何が起きたか分からない」という言葉です。けれど実際には、Windowsのイベントログにも、Sysmonにも、Linuxのauditdにも、攻撃者の行動は驚くほど詳細に記録されています。問題は「ログが無い」ことではなく「どこを見ればいいか」「何が異常か」を知らないことです。本記事は、実務者向けDFIR/OSINTハブの一角として、3つの代表的なログ源をイベントID単位で読み解き、単発のログでなく複数ログを時系列で繋いで侵害のストーリーを組み立てる方法を解説します。読んだあとは、体験型教材「ログ調査官」で実際に10件の事案を捜査し、身についたかどうかを試してみてください。
本記事は、自分が管理者権限・監視権限を持つシステムのログを読み解くための、防御目的の教育コンテンツです。監査ポリシーの変更・Sysmonやauditdの導入は、必ず自分の検証環境や、正式な権限を持つ業務システムで行ってください。他者のシステムのログを無断で取得・閲覧する行為は、不正アクセス禁止法等に抵触する可能性があります。
🧭 なぜ「ログが読める」ことが生命線なのか
調査は推測ではなく、証拠から始まります
「たぶんこうだろう」で調査を進めない
侵害調査の失敗の多くは、ログを見ずに印象で犯人像・原因を決め打ちしてしまうことから始まります。Windows標準ログ・Sysmon・Linux auditdは、それぞれ見ている角度が違うだけで、いずれも「実際に何が起きたか」を裏付ける一次証拠です。まずはこの3つが何を担当しているかを整理しましょう。
📊 3つのログ源の役割分担マップ
ログは「消される前提」で保存場所を分離する
攻撃者は侵入の最終段階で、しばしば証跡を消そうとします（後述のEvent ID 1102が代表例）。端末本体だけにログを置くと、この一手で調査の手がかりが消えてしまいます。SIEMやログ専用サーバへ常時転送しておくのが、実務での基本的な備えです。
🖥 Windows編：まず見るべき9つのイベントID
標準の「セキュリティ監査ログ」だけで見える範囲
「誰が・いつ・何に」を記録する層
Windowsを追加設定なしで動かしても、イベントビューアーの「セキュリティ」ログには、ログオンの成功・失敗やアカウント操作が既定である程度記録されています。まずはこの標準ログだけで拾える9つのイベントIDを押さえましょう。
📋 まず見るべき9つのセキュリティイベントID
| Event ID | 名称 | 見るべきポイント |
|---|---|---|
4624 | ログオンの成功 | LogonTypeを必ず確認(下表)。深夜のType10(RDP)は要注意 |
4625 | ログオンの失敗 | 短時間に大量発生＝ブルートフォース攻撃の典型的な兆候 |
4648 | 明示的な資格情報でのログオン | runas等、別アカウントへの切り替え＝横展開の兆候 |
4672 | 特権(管理者権限)の割り当て | 想定外のアカウントでの発生＝権限昇格の確認ポイント |
4688 | 新しいプロセスの作成 | 既定では引数(コマンドライン)まで見えない。監査ポリシーで別途有効化が必要 |
4720 | ユーザーアカウントの作成 | 心当たりのない新規アカウント＝バックドア設置の兆候 |
4732 | セキュリティグループへの追加 | 一般ユーザーが管理者グループに追加＝権限昇格の実行 |
1102 | 監査ログのクリア | 正当な理由がほぼ無い。証跡隠滅の最重要フラグ |
5140 | ネットワーク共有へのアクセス | 短時間に複数共有への大量アクセス＝データ持ち出しの兆候 |
※ Event ID 4688の引数まで記録するには、監査ポリシーで「コマンドライン プロセス作成イベントを含める」を別途有効にする必要があります。
🔑 LogonTypeの読み方（4624/4625に付随）
| LogonType | 意味 |
|---|---|
| 2 | 対話的ログオン（コンソールの前に人が座って操作） |
| 3 | ネットワークログオン（ファイル共有・SMBアクセス等） |
| 10 | リモートデスクトップ(RDP)ログオン |
▲ 読み方：同一アカウントへの4625が短時間に連続し、直後に4624（LogonType 3=ネットワーク経由）が記録されたら、総当たり攻撃が成功した可能性が高いサインです。
Event ID 1102が出たら、疑うのではなく「即行動」
本番環境のセキュリティログを意図的にクリアする正当な業務理由は、ほぼ存在しません。1102を見つけたら、クリアされた時刻の前後の他ログ(Sysmon・ネットワーク機器・他サーバ)を優先的に確認してください。
🧩 Sysmon編：標準ログの死角を埋める目
プロセスと通信の詳細を記録する追加の監視レイヤー
標準ログだけでは「死角」が残る
4688でプロセス作成は分かっても、既定ではネットワーク通信や詳しい親子プロセスの関係までは追えません。この死角を埋める無料ツールが、Microsoft Sysinternals製のSysmonです。
🔍 侵害調査でよく使う5つのSysmon Event ID
| Event ID | 名称 | 見るべきポイント |
|---|---|---|
1 | プロセス作成 | 親プロセス・コマンドライン・ハッシュ値まで記録。winword.exeの子にpowershell.exe等は要注意 |
3 | ネットワーク接続 | どのプロセスが・どのIP/ポートと通信したか。見慣れないプロセスの外部通信を確認 |
10 | プロセスアクセス | あるプロセスが別プロセスのメモリを覗く動作。lsass.exeへのアクセスは資格情報窃取の代表的な検知ポイント |
11 | ファイル作成 | 不審な場所（一時フォルダ等）への実行ファイル・スクリプトの作成 |
22 | DNSクエリ | ランダムな文字列のドメイン等、DGA（ドメイン生成アルゴリズム）を疑う名前解決 |
設定はゼロから書かない
Sysmonは導入しただけでは全イベントが素通りで大量に出力されます。有志が公開している設定テンプレート（SwiftOnSecurity氏の設定などが有名）を土台にし、自組織のノイズをexcludeで除外していくのが、実務での定番の進め方です。
▲ 読み方：正規のプロセスではないSourceImageがlsass.exeをTargetImageとしてアクセスしている時点で、資格情報ダンプツール（Mimikatz等）の典型的な挙動と一致します。
🐧 Linux auditd編：syscallレベルの記録
「誰が・何を」をカーネルの一段下から記録する
Linuxの「特権監査」＝auditd
Windowsのセキュリティ監査に相当する仕組みが、Linuxカーネルのauditサブシステムです。デーモンauditdと、ルールを管理するauditctl、ログを検索するausearchの3つがセットで動きます。
▲ -wは「このファイルを監視して」、-a always,exit -Sは「このシステムコールが呼ばれたら記録して」という意味。-kで付けたキーが、後で検索するときの目印になります。
▲ -kで先ほど付けたキーを指定して検索、-i（interpret）を付けるとUIDやシステムコール番号を人間が読める形式に変換してくれます。
▲ type=SYSCALLが「誰の権限で・成功したか」、type=EXECVEが「実際に打たれたコマンドと引数」。この2行は同じ操作を指すペアとして必ずセットで出力されます。
auid（ログインUID）が”本当の実行者”を教えてくれる
uidはsudoやsuで切り替わりますが、auidは最初にログインしたときのユーザーIDのまま変わりません。uid=0（root）による操作でも、auidを見れば「元々どのアカウントでログインした人物か」を辿れます。
🧭 auidはsudoを跨いでも変わらない
🎯 実践編：3つのログを繋いで読み解く
単発のログでなく、時系列の相関で侵害を見抜く
1行だけでは「たまたま」に見える
ここまで見てきたイベントは、1件だけ見ると誤検知や偶然に見えることがあります。しかし時系列で繋ぐと、明確な侵害ストーリーになります。以下は、Windows・Sysmonの両方を横断する一例です。
4625が47回、同一アカウントに連続
2分間で同一アカウントへのログオン失敗が大量発生。ブルートフォース攻撃の開始。
48回目に4624（成功）＋4672（特権割当）
攻撃者がパスワードを突破し、しかも管理者相当の権限でログオン。
Sysmon Event 1：難読化されたPowerShell起動
Base64エンコードされたコマンドでpowershell.exeが起動。人間にはすぐ読めない＝何かを隠している合図。
Sysmon Event 10：lsass.exeへのアクセス
そのPowerShellプロセスが認証情報を管理するlsass.exeのメモリを覗く。資格情報窃取の実行。
Sysmon Event 3：外部IPへの定期的な通信
盗んだ認証情報を持って、一定間隔で外部と通信。C2ビーコンの疑い。
1102：監査ログがクリアされる
攻撃者が証跡を消して離脱。この1行が出た時点で、消される直前までのログを他の保存先（SIEM等）から追う必要がある。
4625の大量発生だけでも、正規ユーザーのパスワード入力ミスの繰り返しや、設定を誤ったバッチ処理である可能性はゼロではありません。アカウントロックや通信遮断といった対応に踏み切る前に、必ず本セクションのように複数のログを時系列で相関確認し、誤検知でないかを確かめてください。
この一連の流れ、実際に捜査できます
「複数ログを繋いで侵害を見抜く」感覚は、文章で読むだけでなく実際に手を動かすと定着します。体験型教材「ログ調査官」では、これと同じ構造の複合ケースを含む全10事案を、実在のイベントIDを使って捜査できます。
🗺 MITRE ATT&CK対応表
イベントIDと攻撃者の行動を、共通言語で結びつける
🎯 イベントID → 攻撃者の行動 → MITRE ATT&CK対応表
| ログ・イベント | 攻撃者の行動 | MITRE ATT&CK技術 | 戦術 |
|---|---|---|---|
| 4625連発→4624 | 総当たりでの侵入成功 | T1110 Brute Force | Credential Access |
| 4672 / 4732 | 管理者権限への昇格 | T1078 Valid Accounts | Privilege Escalation |
| Sysmon 1（難読化コマンド） | 難読化されたコマンド実行 | T1059.001 PowerShell | Execution |
| Sysmon 10（lsassアクセス） | 資格情報のダンプ | T1003.001 LSASS Memory | Credential Access |
| Sysmon 3（外部定期通信） | C2サーバとの通信 | T1071 Application Layer Protocol | Command and Control |
| 1102（監査ログクリア） | 証跡の消去 | T1070.001 Clear Windows Event Logs | Defense Evasion |
| auditd execve（root権限の不審実行） | Linux側での不正なコマンド実行 | T1059.004 Unix Shell | Execution |
※ MITRE ATT&CKの技術・戦術分類の詳細は、MITRE ATT&CK連載まとめで解説しています。
⚙ 今日からできる設定チェックリスト
読んだだけで終わらせないための最初の一歩
📋 環境別・設定チェックリスト
- Windows：ローカルセキュリティポリシーで「ログオンイベントの監査」「プロセス作成の監査」を有効化する
- Windows：プロセス作成の監査に「コマンドラインを含める」設定を追加で有効化する（既定オフ）
- Windows：セキュリティログの保存サイズを既定値から拡張する（上書きで消えるのを防ぐ）
- Sysmon：未導入なら公式配布元から導入し、有志の設定テンプレートを土台に自組織向けへ調整する
- Linux：
systemctl status auditdで稼働を確認し、重要ファイル・execveの監視ルールを追加する - 共通：ログは端末本体だけに置かず、SIEMやログ専用サーバへ転送する（1102のような消去リスクに備える）
- 共通：平時から「正常な状態のログ」を見ておく。異常の基準は、正常を知って初めてわかる
📚 まとめ・FAQ・次に読む
読んだら、実際にログを覗いてみる
①Windows標準ログは「誰が・いつ」、Sysmonは「何を・どこと」、auditdは「Linuxでのsyscallレベルの真実」を教えてくれる。②単発のログでなく複数ログを時系列で繋いだときに初めて「侵害のストーリー」が見える。③ログは消される前提で、本体以外の場所にも転送しておく。
ログ調査官
実在するイベントID（4625/4672/1102等、Sysmon Event 10等）を使った全10事案を、証拠タップ→確信度ベット→事後対応クイズの流れで捜査するゲーム。侵害8件・正常2件の誤検知トラップ入り。
今すぐ調査官になる →ログの保存期間はどれくらいが目安ですか？
侵害から発覚まで数か月かかることも珍しくないため、最低でも90日、可能なら1年以上の保存が望ましいとされます。容量の制約がある場合は、まず重要なセキュリティイベント（4624/4625/4672/1102等）だけでも長期保存する、という優先順位のつけ方が現実的です。
Sysmonを入れるとパフォーマンスに影響はありますか？
設定を絞らずに全イベントを記録すると、ログ量・ディスクI/Oともに増えます。有志の設定テンプレートで不要なノイズを除外し、必要なイベントIDに絞ることで、一般的な業務用途では体感できるほどの負荷にはなりにくいとされています。導入前に検証環境で確認するのが安全です。
個人のPCでもここまで設定すべきですか？
個人利用であれば、まずはWindows標準の監査ログを意識するだけでも十分な第一歩です。Sysmonやauditdの本格導入は、自宅ラボでの学習や、業務でサーバー・重要な端末を管理する立場になったときに検討すると良いでしょう。
ログを見て「これは不審」という基準がわかりません
一番の近道は、平時の「正常な状態」を先に見ておくことです。異常は正常との比較でしか判断できません。加えて本記事のようなイベントID単位の知識と、実際に手を動かす練習を組み合わせると、基準の感覚が身についていきます。
Windows/Sysmon/auditd以外に見るべきログはありますか？
PowerShellの詳細な実行内容を記録するイベントID4104（スクリプトブロックログ）、ファイアウォールやプロキシの通信ログ、クラウド環境ならAWS CloudTrailやAzureのアクティビティログなど、環境によって重要なログ源は広がります。まずは本記事の3つを足がかりにするのがおすすめです。
DFIR完全ロードマップ
この記事が位置づけられている、実務者向けDFIRハブの全体像。
インシデント対応プレイブック完全ガイド
ログから侵害に気づいた後の初動7原則と対応手順。
Sigma検知ルール完全入門
本記事で読んだイベントIDを、自動検知ルールに変換する次のステップ。
Velociraptor入門
複数端末のログ・アーティファクトを横断的にハンティングするツール。
MFT・inode・auditdコマンド編
auditdを含む各OSのフォレンジックコマンドそのものの一覧はこちら。
📚 参考・出典（一次情報）
- Microsoft Learn – Windows セキュリティ監査イベントのリファレンス（4624/4625/4688/4672/1102 等の公式説明）
- Microsoft Learn / Sysinternals – Sysmon公式ドキュメント（Event ID定義・設定スキーマ）
- Red Hat Enterprise Linux ドキュメント – Auditシステムの設定・監視ガイド（auditctl/ausearch）
- MITRE ATT&CK – 攻撃者の戦術・技術の共通辞書（本記事のイベントID対応表で参照）
コメント