【ログ解析完全ガイド】Syslog・Apache・Windowsイベントログの構造と不審な挙動の読み解き方

セキュリティエンジニアやサーバー管理者が日々の業務で最も頻繁に向き合うもの、それが「ログ」です。サーバーやネットワーク機器が刻々と出力するログは、システムの健康状態を示すカルテであると同時に、サイバー攻撃を受けた際に何が起きたのかを雄弁に語る「ブラックボックスの記録」でもあります。

情報処理安全確保支援士試験（SC試験）の記述式問題では、長大なログから攻撃の痕跡を見つけ出す問題が頻出します。「なんとなくエラーが出ているのは分かる」というレベルから脱却し、「どのIPアドレスが、いつ、どのような手法で攻撃を試み、それが成功したのか失敗したのか」を正確に読み取るスキルは、合格に直結するだけでなく、実務におけるインシデントレスポンス能力の要となります。

本記事では、主要な3種類のログ（Syslog、Apacheログ、Windowsイベントログ）に焦点を当て、その構造と、攻撃検知に役立つ具体的な読み解き方を徹底解説します。

【SC試験対策】午後問題で差がつく！ログ解析・インシデント検知実戦練習問題（全10問）

情報処理安全確保支援士試験（SC）の午後問題において、「ログから攻撃の痕跡を見つけ出し、攻撃手法と被害状況を特定する」問題は最頻出テーマの一つです。本記事で解説した「Syslog」「Apacheアクセスログ」「Windowsイベントログ」の読み解き方を、実際の試験形式に近い練習問題で確認してみましょう。単に知識として知っているだけでなく、「不審なイベントID」や「攻撃特有のパラメータ」に即座に反応できるか、あなたの実戦力をチェックします。

【演習】ログ解析と不審な挙動の読み解き（全10問）

なぜログ解析がセキュリティの「目」となるのか

ログ解析の最大の目的は、脅威の早期発見と原因究明です。システムに対する不正アクセスや異常な挙動は、必ずと言っていいほどログに痕跡を残します。しかし、ログは膨大です。1日に数ギガバイト、数百万行ものテキストが出力されることも珍しくありません。

この「砂漠の砂」の中から「砂金（攻撃の予兆）」を見つけ出すには、正しい知識とフィルタリングの勘所が必要です。ログには大量のノイズ（正常な動作記録）が含まれており、その中から本当に重要なシグナル（異常な挙動）を抽出する能力が求められます。

膨大な生ログからフィルタリングを経て、重要なインシデント情報を抽出するログ解析のファンネル図

押さえておくべき3大ログ形式の違い

ログには大きく分けてテキスト形式（行指向）とバイナリ形式（DB指向）が存在します。形式による特性を理解することで、効率的な解析が可能になります。

1. Syslog形式

UNIX系OSやネットワーク機器で標準的に使用
テキスト形式で人間が読みやすい
リアルタイム転送に適している
/var/log/messages、/var/log/syslog等に保存

2. Apache/Nginxログ

Webサーバーが出力するテキスト形式
スペース区切りで各フィールドが定義
Combined Log Formatが一般的
HTTPリクエストとレスポンスの詳細を記録

3. Windowsイベントログ

Windows OS固有のバイナリ形式
イベントビューアー等のツールで閲覧
セキュリティ、システム、アプリケーションに分類
イベントIDによる体系的な分類

これらは形式こそ違いますが、「いつ（Timestamp）」「どこで（Host/Source）」「誰が（User/Process）」「何をした（Event/Message）」という5W1Hが基本構成である点は共通しています。この共通性を理解することで、どのログ形式でも効率的に解析できるようになります。

Syslog（UNIX/Linux）徹底解説

Syslogは、Linuxサーバーのシステムログや、ルーター・スイッチなどのネットワーク機器のログ転送プロトコルとして広く利用されています。一般的に /var/log/messages、/var/log/syslog、/var/log/secure などに保存されます。

Syslogの基本構造を理解する

Syslogの標準的な出力形式を詳しく見ていきましょう。一見ただの文字列に見えますが、厳格なルールに基づいて構成されています。

Feb 15 10:23:45 server01 sshd[1234]: Failed password for invalid user admin from 192.168.1.50 port 54321 ssh2

この1行は、以下のように分解できます。

1. タイムスタンプ（Feb 15 10:23:45）

イベント発生時刻を記録
月日時:分:秒の形式
タイムゾーン情報は別途確認が必要

2. ホスト名（server01）

ログを出力した機器の名前
DNS名またはIPアドレス
複数サーバーのログを集約する際の識別子

3. プロセス名とPID（sshd[1234]）

ログを出力したプログラム名
[数字]はプロセスID
同じプログラムでも複数プロセスを識別可能

4. メッセージ本体（Failed password...）

具体的なイベント内容
最も重要な情報が含まれる
パターンマッチングで攻撃を検知

Syslogの1行を構成要素（タイムスタンプ、ホスト名、プロセス、メッセージ）に分解して解説した図

ファシリティとシビアリティ（プライオリティ）の重要性

Syslogを理解する上で欠かせないのが「ファシリティ（Facility）」と「シビアリティ（Severity）」です。これらはログの中に明示的にテキストとして書かれることは少ないですが、設定ファイル（rsyslog.confなど）やログサーバー転送時には重要なタグ情報となります。

ファシリティ（ログの種類）

auth/authpriv: 認証・セキュリティ関連（最重要）
cron: cron実行ログ
daemon: デーモンプロセス
kern: カーネルメッセージ
mail: メールシステム
local0～local7: カスタム用途

シビアリティ（重要度レベル）

セキュリティ監視の観点から、各レベルの意味と着眼点を理解しておきましょう。

レベル	名称	意味	セキュリティ的な着眼点
0	emerg	システム利用不可	DoS攻撃やハードウェア障害による停止
1	alert	直ちに対応が必要	データベース破損、RAIDアレイ障害
2	crit	致命的な状態	重要なプロセスの異常終了
3	err	エラー発生	サービスの起動失敗、設定エラー
4	warning	警告	ディスク容量不足の予兆、メモリ逼迫
5	notice	正常だが重要な情報	root昇格、設定変更（監視必須）
6	info	情報	通常のログイン成功、サービス起動
7	debug	デバッグ情報	開発時の詳細ログ（本番では無効化推奨）

試験対策としては、「認証失敗はどのレベルか？」「sudo実行はどのレベルか？」という感覚を持っておくことが大切です。一般的に認証成功やコマンド実行ログは info や notice レベルで記録されますが、認証失敗は warning や err レベルになることが多いです。

実例で学ぶ攻撃検知パターン：SSHブルートフォース

Syslogで最も頻出する攻撃ログの一つが、SSHへのブルートフォース（総当たり）攻撃です。/var/log/secure や /var/log/auth.log に以下のようなログが秒単位で連続して記録されている場合、攻撃を受けていると判断できます。

Feb 15 10:00:01 srv sshd[2001]: Failed password for root from 10.0.0.5 port 44444 ssh2
Feb 15 10:00:03 srv sshd[2005]: Failed password for root from 10.0.0.5 port 44446 ssh2
Feb 15 10:00:05 srv sshd[2009]: Failed password for root from 10.0.0.5 port 44448 ssh2
Feb 15 10:00:07 srv sshd[2013]: Failed password for root from 10.0.0.5 port 44450 ssh2
Feb 15 10:00:09 srv sshd[2017]: Accepted password for root from 10.0.0.5 port 44452 ssh2

着目すべき重要ポイント

同一IPアドレス（10.0.0.5）からの連続アクセス
- 正規ユーザーが短時間に何度もパスワードを間違えることは稀
- 自動化ツールによる攻撃の典型的なパターン
短時間での繰り返し（2秒間隔）
- 人間が手動で入力する速度を超えている
- スクリプトやツールによる自動攻撃
ポート番号の変化（44444→44446→44448...）
- 攻撃者側の送信元ポートが都度変わるのは正常
- TCP接続の仕組み上、必然的に発生
"Failed"から"Accepted"への変化（最重要）
- 大量の失敗ログの直後に成功ログが出現
- 攻撃が成功して侵入されたことを意味する
- 即座にアカウント無効化とログ調査が必要

この「失敗の連続からの成功」という文脈を読み取ることが極めて重要です。単一のログではなく、時系列での変化パターンに注目することで、攻撃の成否を判断できます。

追加の監視ポイント

ログイン試行ユーザー名が「root」「admin」「test」など一般的な名前
辞書攻撃の場合、ユーザー名が次々と変化
成功後にsudoコマンドの実行ログが続く場合、権限昇格を試みている

Apache/Nginxアクセスログの完全解説

Webアプリケーションへの攻撃（SQLインジェクション、XSS、ディレクトリトラバーサルなど）を検知するには、Webサーバーのアクセスログ解析が必須です。ApacheやNginxでは、Combined Log Format（複合ログフォーマット）が標準的に使われます。

Combined Log Formatの詳細構造

典型的なアクセスログの例を詳しく見ていきましょう。

192.168.1.10 - - [15/Feb/2026:10:30:00 +0900] "GET /login.php HTTP/1.1" 200 1534 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)..."

各フィールドの意味と解析のポイントを説明します。

1. クライアントIP（192.168.1.10）

アクセス元のIPアドレス
攻撃者の特定に最も重要な情報
プロキシ経由の場合、X-Forwarded-Forヘッダの確認が必要
ロードバランサ配下では、LBのIPになることがあるため注意

2. 識別子（1つ目のハイフン）

RFC 1413のidentdプロトコルによるユーザー識別
現在はほとんど使用されず、常に-

3. ユーザー名（2つ目のハイフン）

HTTP Basic認証等で認証されたユーザー名
認証なしの場合は-
認証ありの場合、ここでユーザーを特定可能

4. 時刻（[15/Feb/2026:10:30:00 +0900]）

リクエスト受信時刻
日/月/年:時:分:秒タイムゾーン
攻撃の時系列分析に必須

5. リクエストライン（"GET /login.php HTTP/1.1"）

攻撃検知の主戦場
メソッド（GET/POST/PUT/DELETE等）
リクエストURI（パスとクエリパラメータ）
HTTPプロトコルバージョン
SQLインジェクションやXSSのペイロードがここに含まれる

6. ステータスコード（200）

サーバーの応答結果
攻撃の成否判定に直結
200番台は成功、400番台はクライアントエラー、500番台はサーバーエラー

7. 転送バイト数（1534）

レスポンスボディのサイズ（バイト）
通常と異なるサイズは異常の兆候
データベース全件取得などで急増

8. Referer（"http://example.com/"）

どのページからリンクを辿ってきたか
CSRF攻撃の検知に有効
空欄や不自然なRefererは要注意

9. User-Agent（"Mozilla/5.0..."）

ブラウザやOSの情報
攻撃ツール特有のUAパターンを検知可能
空欄や短すぎるUAは自動化ツールの可能性

Apacheアクセスログの各フィールド（IP、時刻、リクエスト、ステータス、バイト数、UA）を解説した構造図

HTTPステータスコードで攻撃の成否を判定する

ログ解析において、ステータスコードは攻撃が成功したか否かを判断する最重要指標です。各コードの意味とセキュリティ上の解釈を理解しましょう。

2xx番台：成功（Success）

200 OK: リクエスト成功、通常の処理完了
- 危険な兆候: SQLインジェクション攻撃コードを含むリクエストに対して200が返り、かつ転送バイト数が通常と大きく異なる（例：通常1KB→攻撃時50KB）場合、大量のデータを引き抜かれた可能性
- 正常系でも200が返るため、URIとサイズの相関分析が必須
204 No Content: 処理成功だがコンテンツなし
- DELETEリクエストの成功などで使用

3xx番台：リダイレクト（Redirection）

301 Moved Permanently: 恒久的な移動
302 Found: 一時的な移動
- ログイン成功後のリダイレクトで使用されることが多い
- 認証バイパス攻撃の成功でも302が返ることがある

4xx番台：クライアントエラー（Client Error）

400 Bad Request: 不正なリクエスト
- WAF（Web Application Firewall）でブロックされた場合に返されることが多い
- 攻撃の試行を示すが、防御に成功
401 Unauthorized: 認証失敗
- Basic認証へのブルートフォース攻撃時に多発
- 短時間に大量の401が同一IPから発生 → 攻撃の兆候
403 Forbidden: アクセス禁止
- ディレクトリトラバーサル攻撃で、権限のないファイル（/etc/passwdなど）へアクセスしようとしてブロックされた際に記録
- .htaccessによる保護が機能している証拠
404 Not Found: 存在しないファイル
- 脆弱性スキャンツールが、存在しない管理画面（/admin/、/phpmyadmin/、/wp-admin/など）を機械的に探す際に大量発生
- 短時間に多数の異なるパスで404 → 自動スキャンの可能性大

5xx番台:サーバーエラー（Server Error）

500 Internal Server Error: サーバー内部エラー
- 最重要: SQLインジェクション攻撃で構文エラーが発生した場合など、アプリケーションが想定外の入力を処理しきれずに異常終了
- 脆弱性が存在する可能性が極めて高いことを示唆
- 攻撃者は500エラーの応答内容（スタックトレース等）から情報収集を試みる
502 Bad Gateway: ゲートウェイエラー
- バックエンドサーバーの過負荷やDDoS攻撃の影響
503 Service Unavailable: サービス利用不可
- リソース枯渇、DoS攻撃の可能性

具体的な攻撃パターンとログの読み方

SQLインジェクション攻撃

リクエストライン（URIやパラメータ）にSQL文特有の記号が含まれます。

192.168.1.100 - - [15/Feb/2026:14:22:33 +0900] "GET /search.php?q=apple' OR '1'='1 HTTP/1.1" 200 5600 "-" "sqlmap/1.5"

検知ポイント

SQLメタ文字の存在
- シングルクォート（'）
- OR、AND演算子
- UNION、SELECT、INSERT、UPDATE、DELETE
- コメント記号（--、/**/、#）
ステータスコード200 + 異常なサイズ
- 通常の検索結果が1000バイト程度と仮定
- 5600バイトは明らかに異常 → 全データ取得の可能性
User-Agent: sqlmap/1.5
- 自動化ツールの使用が確定
- 攻撃意図が明確

URLエンコードされた攻撃の例

"GET /item.php?id=1%27%20OR%20%271%27%3D%271 HTTP/1.1" 500 2341

%27 = シングルクォート（'）
%20 = スペース
%3D = イコール（=）
ステータス500 → SQL構文エラーで脆弱性確定

ディレクトリトラバーサル攻撃

親ディレクトリを表す../を使って、想定外のファイルにアクセスを試みる攻撃です。

192.168.1.101 - - [15/Feb/2026:14:25:10 +0900] "GET /download.php?file=../../../../etc/passwd HTTP/1.1" 200 2450 "-" "curl/7.68.0"

検知ポイント

ディレクトリトラバーサルのパターン
- ../の繰り返し（../../、../../../../など）
- /etc/passwd、/etc/shadow、C:\Windows\System32\config\SAMなど機密ファイルのパス
ステータス200 + ファイルサイズ
- 2450バイトは/etc/passwdの実際のサイズに近い
- 攻撃が成功してファイル読み出しに成功
User-Agent: curl
- コマンドラインツールの使用
- 手動攻撃の可能性

防御が成功している例

"GET /download.php?file=../../../etc/passwd HTTP/1.1" 403 350

ステータス403 → アクセス禁止
バリデーションまたはWAFがブロック
サイズ350バイト → エラーページのサイズ

クロスサイトスクリプティング（XSS）攻撃

JavaScriptコードを注入して、他のユーザーのブラウザで実行させる攻撃です。

192.168.1.102 - - [15/Feb/2026:14:30:55 +0900] "GET /board.php?comment=<script>alert(1)</script> HTTP/1.1" 200 500 "http://example.com/board.php" "Mozilla/5.0"

検知ポイント

HTMLタグやJavaScriptの存在
- <script>タグ
- alert()、document.cookieなどのJavaScript関数
- onerror=、onload=などのイベントハンドラ
URLエンコードされた例"GET /board.php?comment=%3Cscript%3Ealert%281%29%3C%2Fscript%3E HTTP/1.1" 200 500
- %3C = <
- %3E = >
- %2F = /
ステータス200
- スクリプトがそのまま表示されている可能性
- サニタイジング（エスケープ処理）が不十分

Reflected XSSとStored XSSの違い

Reflected XSS: URLパラメータ経由で即座に反映（上記の例）
Stored XSS: POSTでDBに保存され、後で他ユーザーに表示される（アクセスログだけでは完全な検知が困難）

OSコマンドインジェクション

192.168.1.103 - - [15/Feb/2026:14:35:20 +0900] "GET /ping.php?host=8.8.8.8;cat%20/etc/passwd HTTP/1.1" 200 2800 "-" "python-requests/2.25.1"

検知ポイント

コマンド連結記号
- セミコロン（;）
- パイプ（|）
- &&、||
UNIXコマンド
- cat、ls、wget、curl
- rm、chmod、nc（netcat）
異常なレスポンスサイズ
- ping結果だけなら数百バイト
- 2800バイトは/etc/passwdの内容が含まれている可能性

Windowsイベントログの深層解析

Windows環境では、ログは「イベントログ」として管理されます。テキストエディタで直接開くことはできず、「イベントビューアー」やPowerShellを使って確認します。SC試験や実務で特に重要なのは「セキュリティ」ログです。

3つの主要カテゴリと役割

Windowsイベントログは主に以下の3つに大別されます。

1. System（システムログ）

Windowsコンポーネントのイベントを記録
サービスの起動・停止
ドライバのエラー
ハードウェア障害の兆候
システムの再起動やシャットダウン

2. Application（アプリケーションログ）

アプリケーションが出力するイベント
SQL Serverのエラーや警告
IISのアプリケーションエラー
カスタムアプリケーションのログ

3. Security（セキュリティログ）

セキュリティ解析の中核
監査ログ（ログオン成功・失敗）
ファイルアクセス監査
特権使用の記録
ポリシー変更の履歴

Windowsイベントビューアーの画面構成図。セキュリティログの監査失敗（イベントID 4625）がハイライトされている

イベントID（Event ID）完全マスター

Windowsログ解析は「イベントID」の知識がすべてです。膨大なIDが存在しますが、攻撃検知において監視すべきIDは限られています。主要なイベントIDを体系的に理解しましょう。

ログオン・ログオフ関連（最重要）

ログオン成功・失敗

4624: ログオン成功
- すべての成功したログオンを記録
- ログオンタイプで詳細を判別
- 正常な業務活動も含まれる
4625: ログオン失敗
- 最重要監視対象
- パスワード間違い、アカウントロックなど
- 短時間に大量発生 → ブルートフォース攻撃
- サブステータスコードで失敗理由を特定可能
4634: ログオフ
- ユーザーセッションの終了
- 4624とペアで解析
4647: ユーザーによる明示的なログオフ
- Windowsキー → ログオフを選択
- 4634との違いに注意

特殊なログオン

4648: 明示的な資格情報を使用してログオン
- RunAsコマンドの使用
- runas /user:administrator cmd.exe
- なりすましや特権昇格の疑い
- 攻撃者が管理者権限を取得した可能性
4672: 特権アカウントのログオン
- 管理者権限を持つアカウントのログオン
- 4624の直後に記録される
- 特権を悪用される危険性

アカウント管理（バックドア検知に必須）

アカウント作成・削除

4720: ユーザーアカウントが作成された
- 重要監視対象
- 攻撃者がバックドア用のアカウントを作成した可能性
- 誰が、いつ、どのアカウントを作成したかを確認
4726: ユーザーアカウントが削除された
- 証拠隠滅の可能性
- 正規の退職処理との区別が必要
4738: ユーザーアカウントが変更された
- パスワードリセット、アカウント有効化など
- 攻撃者による設定変更の可能性

グループ管理

4732: ローカルグループにメンバーが追加された
- 特にAdministratorsグループへの追加は最重要
- 権限昇格の決定的な証拠
- net localgroup administrators attacker /addの実行ログ
4733: ローカルグループからメンバーが削除された
- 痕跡消去の可能性
4756: ユニバーサルグループにメンバーが追加された（Active Directory）
- ドメイン管理者グループへの追加など
- AD環境での権限昇格

プロセス追跡・監査

プロセス実行

4688: 新しいプロセスが作成された
- コマンドライン監査を有効にすれば攻撃コマンドを捕捉可能
- powershell.exe -enc <Base64エンコードされたコマンド>
- cmd.exe /c whoami
- 攻撃者が何を実行したかの直接的な証拠

監査ポリシー変更・ログ削除

4719: システム監査ポリシーが変更された
- 攻撃者が監査を無効化しようとしている
- インシデント対応時に優先的に確認
1102: 監査ログが消去された
- 攻撃者が証拠を消した決定的な痕跡
- イベントビューアーで手動削除、またはコマンド実行
- このログが残っている時点で完全な証拠隠滅には失敗

ファイル・レジストリアクセス

4663: オブジェクトへのアクセス試行
- ファイル、フォルダ、レジストリキーへのアクセス
- 詳細な監査を有効にした場合のみ記録
- 機密ファイルへの不正アクセス検知

ログオンタイプ（Logon Type）の詳細解説

イベントID 4624（ログオン成功）の中には「ログオンタイプ」というフィールドがあり、どの方法でログオンしたかを判別できます。このログオンタイプの理解は、攻撃経路の特定に不可欠です。

主要なログオンタイプ一覧

タイプ	名称	説明	セキュリティ上の意味
2	Interactive	キーボードと画面を使ったローカルログオン	物理的に端末操作、またはKVMスイッチ経由
3	Network	ネットワーク経由のログオン	ファイル共有、IIS、最も一般的
4	Batch	バッチジョブ	タスクスケジューラによる実行
5	Service	サービス起動	Windowsサービスの開始時
7	Unlock	画面ロック解除	スクリーンセーバーからの復帰
8	NetworkCleartext	平文パスワードでネットワークログオン	IIS Basic認証など（非推奨）
10	RemoteInteractive	リモートデスクトップ（RDP）	最重要監視対象
11	CachedInteractive	キャッシュされた資格情報	ドメインコントローラに接続できない場合

攻撃検知の実例

ケース1: 深夜の海外からのRDPログオン

イベントID: 4624
ログオンタイプ: 10 (RemoteInteractive)
アカウント名: Administrator
送信元IPアドレス: 203.0.113.50（中国）
時刻: 2026-02-15 03:30:00

深夜3時30分に管理者アカウントでRDPログオン
送信元が海外IP
RDP総当たり攻撃による侵害の可能性が極めて高い
直前に大量の4625（ログオン失敗）がないか確認

ケース2: ネットワークログオンの異常

イベントID: 4624
ログオンタイプ: 3 (Network)
アカウント名: SYSTEM
送信元: 内部サーバー
時刻: 通常業務時間外

SYSTEMアカウントでのネットワークログオン
内部サーバー間通信だが業務時間外
ラテラルムーブメント（侵害後の横展開）の可能性

ログの相関分析（Correlation Analysis）

単一のログだけでは見えない攻撃の全体像も、複数のログを組み合わせる（突き合わせる）ことで鮮明になります。これを「相関分析」と呼びます。

実践的な攻撃シナリオ解析

Webサーバーへの攻撃を起点とした侵害のシナリオを、3つのログを使って追跡してみましょう。

フェーズ1: Webサーバー侵害（Apacheログ）

[Apacheログ - 2026-02-15 14:00:00]
192.168.100.50 - - [15/Feb/2026:14:00:00 +0900] "POST /upload.php HTTP/1.1" 200 450

ファイルアップロード機能に対するPOSTリクエスト
ステータス200で成功
Webシェル（バックドア）をアップロードされた可能性

フェーズ2: 特権昇格の試行（Syslog - Linux）

[/var/log/secure - 2026-02-15 14:05:00]
Feb 15 14:05:00 webserver sudo: www-data : user NOT in sudoers ; TTY=unknown ; PWD=/tmp ; USER=root ; COMMAND=/bin/bash
Feb 15 14:05:30 webserver kernel: [123456.789] possible SYN flooding on port 80
Feb 15 14:06:00 webserver su: pam_unix(su:auth): authentication failure; logname= uid=33 euid=0 tty= ruser=www-data rhost=  user=root

Apacheのユーザー権限（www-data）から、sudoコマンドを実行しようとしている
sudoersに登録されていないため失敗
その後、suコマンドで直接root昇格を試みるが認証失敗
カーネルエクスプロイトを試している可能性も

フェーズ3: ラテラルムーブメント（Windowsイベントログ - ADサーバー）

[Windows Security Log - 2026-02-15 14:10:00]
イベントID: 4625 (ログオン失敗)
アカウント名: domain_admin
ログオンタイプ: 3 (Network)
送信元IPアドレス: 192.168.100.10 (Webサーバー)
失敗理由: パスワード不一致

[Windows Security Log - 2026-02-15 14:15:00]
イベントID: 4624 (ログオン成功)
アカウント名: domain_admin
ログオンタイプ: 3 (Network)
送信元IPアドレス: 192.168.100.10 (Webサーバー)

WebサーバーのIPアドレスから、ドメイン管理者アカウントへのログオン試行
最初は失敗（4625）が複数回記録
最終的に成功（4624）
Webサーバーが侵害された後、内部ネットワークへ感染拡大
ドメイン管理者権限を奪取され、組織全体が制圧される危機的状況

攻撃の全体ストーリー

14:00 - Webサーバーの脆弱性を突いてWebシェルをアップロード
14:05 - Webシェル経由でLinuxサーバー内での特権昇格を試みる（失敗）
14:10 - 内部ネットワークのActive Directoryサーバーへ横展開を開始
14:15 - ドメイン管理者アカウントを奪取し、組織全体を制圧

このように、Webログだけを見ていては「ファイルがアップロードされた」ことしか分かりませんが、SyslogとWindowsログを合わせることで「Webシェル経由で侵入され、内部ネットワークへ感染拡大している」というストーリーが見えてきます。

相関分析を成功させる前提条件

1. 時刻同期（NTP）の重要性

相関分析を行う前提条件として、すべてのサーバーの時刻が正確に同期されていることが必須です。

Webサーバー: JST（日本時間）
DBサーバー: UTC（協定世界時）
ADサーバー: ローカルタイム（9時間のズレ）

上記のように時刻がバラバラだと、突き合わせ作業に多大な労力を要し、インシデント対応の遅れに直結します。

NTP設定の確認方法

# Linux
timedatectl status
ntpq -p

# Windows
w32tm /query /status
w32tm /query /peers

2. ログの集約（SIEM導入）

複数サーバーのログを手動で突き合わせるのは現実的ではありません。SIEM（Security Information and Event Management）ツールを導入することで、自動的に相関分析が可能になります。

主要なSIEMツール

Splunk
Elastic Stack（ELK: Elasticsearch, Logstash, Kibana）
IBM QRadar
ArcSight
Microsoft Sentinel（旧Azure Sentinel）

実践的ログ調査テクニック

SC試験の午後問題や実務では、生のログファイルから該当行を抽出するスキルも問われます。Linuxのコマンドラインツールを使った基本的な調査手法を習得しましょう。

grepによるパターンマッチング

grepは特定の文字列を含む行を抽出するコマンドです。ログ解析の基本中の基本です。

基本的な使い方

# "error" という文字列を含む行を表示（大文字小文字を区別）
grep "error" /var/log/httpd/access_log

# 大文字小文字を無視して検索（-i オプション）
grep -i "error" /var/log/httpd/access_log

# 特定のIPアドレスからのアクセスのみ抽出
grep "192.168.1.50" /var/log/secure

# 行番号も表示（-n オプション）
grep -n "Failed password" /var/log/secure

# マッチした行の前後も表示（-A: After, -B: Before, -C: Context）
grep -A 5 -B 2 "Failed password" /var/log/secure

正規表現を使った高度な検索

# IPアドレスのパターンマッチング
grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" access_log

# 複数のキーワードのいずれかにマッチ（OR検索）
grep -E "error|warning|critical" /var/log/messages

# ログオン成功と失敗の両方を検索
grep -E "Accepted|Failed" /var/log/secure

除外検索（-v オプション）

# "200 OK"を含まない行（エラーレスポンスのみ）を表示
grep -v " 200 " /var/log/httpd/access_log

# 特定のIPアドレスからのアクセスを除外
grep -v "192.168.1.100" access_log

awkによるフィールド抽出と集計

awkは空白などで区切られた特定の列（フィールド）を取り出すのに便利です。

基本的なフィールド抽出

# Apacheログから、アクセス元のIPアドレス（1列目）だけを抽出
awk '{print $1}' /var/log/httpd/access_log

# IPアドレスとリクエストURI（7列目）を抽出
awk '{print $1, $7}' /var/log/httpd/access_log

# ステータスコードが500番台のログのみ抽出
awk '$9 ~ /^5/ {print $0}' /var/log/httpd/access_log

条件付き抽出

# ステータスコードが200以外のログを抽出
awk '$9 != 200 {print $0}' access_log

# 転送バイト数が10000バイト以上のアクセスを抽出
awk '$10 > 10000 {print $1, $7, $10}' access_log

# 特定の時間帯（14時台）のログのみ抽出
awk '$4 ~ /14:/ {print $0}' access_log

sortとuniqによる集計分析

これらを組み合わせることで、「攻撃頻度の高いIPランキング」を作成できます。

IPアドレスのアクセス頻度集計

# IPアドレスを抽出し、ソートして、重複をカウントし、多い順に表示
awk '{print $1}' access_log | sort | uniq -c | sort -nr | head -10

出力例

   5234 192.168.1.50
   2891 10.0.0.100
    456 203.0.113.25
    123 198.51.100.10
     89 192.0.2.5

このコマンドの結果、特定のIPアドレス（192.168.1.50）が5000回以上アクセスしてきていることが分かれば、それをFirewallでブロックするという迅速な判断が可能になります。

リクエストURIのアクセス頻度

# どのURIが最も多くアクセスされているか
awk '{print $7}' access_log | sort | uniq -c | sort -nr | head -10

ステータスコード別の集計

# ステータスコードごとの件数を集計
awk '{print $9}' access_log | sort | uniq -c | sort -nr

User-Agentの集計（攻撃ツール検知）

# User-Agentを抽出して集計（フィールド12以降を結合）
awk '{for(i=12;i<=NF;i++) printf $i" "; print ""}' access_log | sort | uniq -c | sort -nr | head -20

sedによるログの整形

sedはストリームエディタで、ログの加工や特定パターンの置換に使います。

基本的な置換

# IPアドレスをマスク（プライバシー保護）
sed 's/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/XXX.XXX.XXX.XXX/g' access_log

# 特定の文字列を削除
sed 's/Mozilla\/5.0//g' access_log

特定の行範囲の抽出

# 100行目から200行目までを抽出
sed -n '100,200p' /var/log/messages

# 特定のパターンから別のパターンまでを抽出
sed -n '/Start/,/End/p' logfile

組み合わせ技：実践的なワンライナー

SQLインジェクション攻撃の検知

# URIに'（シングルクォート）を含むアクセスを抽出し、IP別に集計
grep -E "'" /var/log/httpd/access_log | awk '{print $1}' | sort | uniq -c | sort -nr

SSHブルートフォース攻撃の検知

# ログイン失敗を含む行から、IPアドレスを抽出して集計
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20

時間帯別のアクセス分布

# 時刻フィールドから時(hour)のみを抽出して集計
awk '{print substr($4,14,2)}' access_log | sort | uniq -c | sort -k2

404エラーのURI一覧

# ステータスコード404のリクエストURIを抽出
awk '$9 == 404 {print $7}' access_log | sort | uniq -c | sort -nr | head -20

PowerShellによるWindowsイベントログ解析

Windowsではコマンドラインでの解析にPowerShellを使用します。

基本的なイベントログ取得

# セキュリティログから最新100件を取得
Get-EventLog -LogName Security -Newest 100

# ログオン失敗（イベントID 4625）のみ抽出
Get-EventLog -LogName Security | Where-Object {$_.EventID -eq 4625}

# 過去24時間のログオン失敗
$StartTime = (Get-Date).AddDays(-1)
Get-EventLog -LogName Security -After $StartTime | Where-Object {$_.EventID -eq 4625}

# 特定のユーザー名を含むイベント
Get-EventLog -LogName Security | Where-Object {$_.Message -like "*administrator*"}

集計とCSVエクスポート

# ログオン失敗を集計してCSVに出力
Get-EventLog -LogName Security | 
  Where-Object {$_.EventID -eq 4625} | 
  Select-Object TimeGenerated, EventID, Message | 
  Export-Csv -Path "C:\logs\failed_logons.csv" -NoTypeInformation

ログローテーションへの対応

実際の運用では、ログは定期的にローテーション（アーカイブ）されます。

圧縮ログの検索

# 圧縮されたログファイルも一緒に検索（zgrep）
zgrep "Failed password" /var/log/secure*

# 複数の日付にまたがるログを一括検索
for file in /var/log/secure*; do
  echo "=== $file ==="
  grep "192.168.1.50" "$file"
done

過去1週間のログを結合して解析

# ローテーションされたログを全て結合
cat /var/log/httpd/access_log{,.1,.2,.3,.4,.5,.6,.7} | \
  awk '{print $1}' | sort | uniq -c | sort -nr | head -50

ログ解析のベストプラクティス

実務で効果的にログ解析を行うためのベストプラクティスを紹介します。

ベースライン（正常状態）の確立

攻撃を検知するには、まず「正常な状態」を知る必要があります。

平時のログパターンを把握

通常の業務時間帯のアクセス量
よく使われるUser-Agent
定期的に実行されるバッチ処理のログ
社内ネットワークからのアクセスIPレンジ

異常検知の基準

アクセス量が通常の10倍以上（DDoS攻撃の可能性）
深夜・休日のアクセス（内部不正、外部侵入）
海外IPからのアクセス（グローバルサービスでない限り）
見慣れないUser-Agent（攻撃ツール）

優先度付けとトリアージ

すべてのログを精査するのは非現実的です。優先度を付けて調査しましょう。

優先度：高（即座に対応）

イベントID 1102（監査ログ削除）
ログオン成功（4624）の直前に大量のログオン失敗（4625）
ステータスコード500の急増
Administratorsグループへのメンバー追加（4732）

優先度：中（定期的に確認）

404エラーの増加（スキャン活動）
ログイン失敗の散発的な発生
新規アカウント作成（4720）

優先度：低（傾向分析）

通常のアクセスログ
正常なサービス起動・停止
定期バッチの実行ログ

ログ保管期間とコンプライアンス

法令や規格により、ログの保管期間が定められている場合があります。

主要な規制・規格

GDPR（EU一般データ保護規則）: 個人データの処理記録
PCI DSS: クレジットカード情報を扱う場合、最低1年間の保管
e-文書法: 電子帳簿保存法による保存義務
サイバーセキュリティ基本法: 重要インフラ事業者の記録保存

一般的な保管期間の目安

セキュリティログ: 最低6ヶ月～1年
Webアクセスログ: 3ヶ月～6ヶ月
アプリケーションログ: 1ヶ月～3ヶ月

ログの改ざん防止

書き込み専用の権限設定
リモートログサーバーへの転送
タイムスタンプ署名（RFC 3161）
WORM（Write Once Read Many）ストレージの使用

まとめ：ログは沈黙の証人

ログは、システムの声であり、攻撃者の足跡であり、インシデントの真実を語る唯一の証人です。正常な状態のログ（ベースライン）を知らなければ、異常なログに気づくことはできません。

本記事で解説した3大ログの要点

Syslog解析のポイント

プロセス名とメッセージ本体に着目
認証の成否（Failed/Accepted）を見逃さない
同一IPからの連続した失敗ログ → ブルートフォース攻撃
ファシリティとシビアリティで重要度を判断

Apache/Nginxログ解析のポイント

リクエストURI内の特殊文字（'、<script>、../）に注目
ステータスコード200 + 異常なサイズ = 攻撃成功の可能性
User-Agentで自動化ツールを検知
404の大量発生 = スキャン活動

Windowsイベントログ解析のポイント

セキュリティログのイベントID 4624（成功）、4625（失敗）を最優先監視
ログオンタイプ10（RDP）は特に重要
イベントID 4688でコマンドライン実行を追跡
イベントID 1102（ログ削除）は証拠隠滅の決定的な証拠

相関分析の重要性

単一のログだけでは攻撃の全体像は見えない
時刻同期（NTP）が相関分析の大前提
WebログとSyslog、Windowsログを組み合わせる
攻撃ストーリーを時系列で再構築

実践的スキルの習得

grep、awk、sort、uniqの基本コマンドをマスター
ワンライナーで効率的にログを集計
PowerShellでWindowsログを解析
ベースライン（正常状態）を確立し、異常を検知

SC試験では、これらの知識を組み合わせて「攻撃ストーリー」を再構築する力が問われます。試験対策だけでなく、実務でのインシデント対応能力を高めるために、以下のステップで学習を進めてください。

学習ロードマップ

自分の環境で実験: 管理下にあるPCやサーバーのログを実際に見て、「自分が今行った操作がどう記録されたか」を確認する
攻撃シミュレーション: テスト環境で意図的にログイン失敗を繰り返し、ログにどう記録されるか観察
過去問演習: SC試験の午後問題でログ解析問題に挑戦し、解答プロセスを身につける
SIEM導入検討: ログの手動解析に限界を感じたら、SIEMツール（Splunk、ELK等）の学習へ

ログ解析は、地道で根気のいる作業です。しかし、その地道な確認作業こそが、最強のセキュリティ監視スキルを養う近道です。ログを読み解く力は、あなたを「単なるシステム管理者」から「システムの守護者」へと進化させるでしょう。

次のステップとして、これらのログを集約・分析するSIEM（Security Information and Event Management）の概念、さらにはSOAR（Security Orchestration, Automation and Response）による自動対応へと学習を深めていくことで、より高度なセキュリティ監視の全体像が見えてくるはずです。

参考情報

Apache HTTP Serverドキュメント: https://httpd.apache.org/docs/
rsyslogドキュメント: https://www.rsyslog.com/doc/
Microsoft - Windowsイベントログリファレンス: https://docs.microsoft.com/en-us/windows/security/threat-protection/
IPA - 情報処理安全確保支援士試験: https://www.ipa.go.jp/

ログと向き合い、システムの声に耳を傾けることから、真のセキュリティ対策が始まります。

【ログ解析完全ガイド】Syslog・Apache・Windowsイベントログの構造と不審な挙動の読み解き方

【SC試験対策】午後問題で差がつく！ログ解析・インシデント検知 実戦練習問題（全10問）

なぜログ解析がセキュリティの「目」となるのか

押さえておくべき3大ログ形式の違い

Syslog（UNIX/Linux）徹底解説

Syslogの基本構造を理解する

ファシリティとシビアリティ（プライオリティ）の重要性

実例で学ぶ攻撃検知パターン：SSHブルートフォース

Apache/Nginxアクセスログの完全解説

Combined Log Formatの詳細構造

HTTPステータスコードで攻撃の成否を判定する

具体的な攻撃パターンとログの読み方

SQLインジェクション攻撃

ディレクトリトラバーサル攻撃

クロスサイトスクリプティング（XSS）攻撃

OSコマンドインジェクション

Windowsイベントログの深層解析

3つの主要カテゴリと役割

イベントID（Event ID）完全マスター

ログオン・ログオフ関連（最重要）

アカウント管理（バックドア検知に必須）

プロセス追跡・監査

ファイル・レジストリアクセス

ログオンタイプ（Logon Type）の詳細解説

ログの相関分析（Correlation Analysis）

実践的な攻撃シナリオ解析

相関分析を成功させる前提条件

実践的ログ調査テクニック

grepによるパターンマッチング

awkによるフィールド抽出と集計

sortとuniqによる集計分析

sedによるログの整形

組み合わせ技：実践的なワンライナー

PowerShellによるWindowsイベントログ解析

ログローテーションへの対応

ログ解析のベストプラクティス

ベースライン（正常状態）の確立

優先度付けとトリアージ

ログ保管期間とコンプライアンス

まとめ：ログは沈黙の証人

【SC試験対策】午後問題で差がつく！ログ解析・インシデント検知実戦練習問題（全10問）