11. ログ分析とインシデント対応

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

2026年2月15日

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

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

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

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

ログ解析の最大の目的は、脅威の早期発見と原因究明です。システムに対する不正アクセスや異常な挙動は、多くの場合ログに痕跡を残します（ただし、監査やログ出力の設定が無効だと記録されません）。しかし、ログは膨大です。1日に数ギガバイト、数百万行ものテキストが出力されることも珍しくありません。

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

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

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

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

1. Syslog形式

  • UNIX系OSやネットワーク機器で標準的に使用
  • テキスト形式で人間が読みやすい
  • リアルタイム転送に適している
  • /var/log/messages、/var/log/syslog等に保存
  • Debian 12以降のように既定でrsyslogが入らずjournaldだけの環境もあり、その場合はjournalctlで確認する

2. Apache/Nginxログ

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

3. Windowsイベントログ

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

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

”
FREE PDF
SC午後記述
テンプレート集
登録特典
メール講座 登録で無料プレゼント
「知っているのに書けない」を、型で解消するPDF
設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。SC午後の記述で手が止まらなくなる1冊です。
設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し
無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

登録無料·いつでも配信停止

Syslog（UNIX/Linux）徹底解説

Syslogは、Linuxサーバーのシステムログや、ルーター・スイッチなどのネットワーク機器のログ転送プロトコルとして広く利用されています。一般的に /var/log/messages、/var/log/syslog、/var/log/secure などに保存されます。なお、Debian 12以降は既定でrsyslogがインストールされずjournaldだけでログを管理するため、環境によっては journalctl で確認します。

Syslogの基本構造を理解する

Syslogの代表的な出力形式を詳しく見ていきましょう。次の例は、RFC 3164（BSD syslog）系の従来形式のメッセージをrsyslog等がファイルに書き出したものです。

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

ネットワーク経由で転送されるメッセージでは、先頭に <PRI>（ファシリティ×8＋シビアリティの値）が付きます。また、現行の標準であるRFC 5424では、タイムスタンプが年とタイムゾーンを含むISO 8601形式（例：2026-02-15T10:23:45+09:00）になり、構造化データ（STRUCTURED-DATA）も持てます。

この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など）やログサーバー転送時には重要なタグ情報となります。

用語の混同に注意しましょう。プロトコル上のPRI（Priority）は「ファシリティ×8＋シビアリティ」で計算される1つの値です（例：auth（4）のinfo（6）なら4×8＋6＝38）。一方、syslog.conf／rsyslog.conf のセレクタ（auth.info のような記述）では、ドットの右側のシビアリティを「priority」と呼びます。同じ「プライオリティ」でも指すものが違います。

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

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

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

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

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

注意したいのは、「認証失敗だから重要度が高いレベルで記録される」とは限らない点です。シビアリティはログを出力するプログラムが決めるため、例えばOpenSSHの「Failed password」は既定で info、PAM（pam_unix）の「authentication failure」は notice、sudoの「user NOT in sudoers」は alert（sudoの既定設定）で記録されます。「warning 以上だけを監視する」といったレベルだけのフィルタでは、SSHの認証失敗を取りこぼします。認証関連はファシリティ（auth/authpriv）で絞り込み、メッセージ内容（Failed/Accepted等）で判断するのが基本です。

実例で学ぶ攻撃検知パターン：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

着目すべき重要ポイント

  1. 同一IPアドレス（10.0.0.5）からの連続アクセス
    • 正規ユーザーが短時間に何度もパスワードを間違えることは多くない
    • 自動化ツールによる攻撃でよく見られるパターン（ただし、保存済みの古いパスワードで自動再接続するクライアントなどでも起こり得る）
  2. 短時間での繰り返し（2秒間隔）
    • 人間が手動で入力するには速い間隔
    • スクリプトやツールによる自動化を疑う材料（平常時のログと比べて判断する）
  3. ポート番号の変化（44444→44446→44448...）
    • 攻撃者側の送信元ポートが都度変わるのは正常
    • 接続ごとに一時ポート（エフェメラルポート）が割り当てられるため変わる（1つの接続内で複数回パスワードを試す場合は同じポートになる）
  4. "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アドレス
  • 攻撃者の特定に最も重要な情報
  • ロードバランサやリバースプロキシ配下では、LBのIPになることがあるため注意
  • Combined Log Formatは既定でX-Forwarded-For（XFF）を記録しない。実クライアントIPを残すには、書式に%{X-Forwarded-For}iを加えるか、mod_remoteipで記録する
  • XFFはクライアントが偽装できるため、信頼できるプロキシが付けた値だけを使う

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

  • RFC 1413のidentdプロトコルによるユーザー識別
  • 通常は-（mod_identでident取得を有効にした場合は値が入ることがある）

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プロトコルバージョン
  • URIに含まれるSQLインジェクションやXSSの攻撃文字列を確認できる（POSTの本文などは標準のアクセスログには残らない）

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: 不正なリクエスト
    • 構文が不正なリクエスト（不正な形式のヘッダ・URIなど）に対して返される
    • 攻撃ツールが送る不正な形式のリクエストで発生することがある（なお、WAF（Web Application Firewall）がブロックした場合は403が返されることが多い）
  • 401 Unauthorized: 有効な認証資格情報がない
    • 資格情報を送っていない最初の要求（認証を求める正常な応答）や、認証失敗のときに返る
    • Basic認証へのブルートフォース攻撃時に多発
    • 短時間に大量の401が同一IPから発生 → 攻撃の兆候を疑う（初回の認証要求による401は正常にも起きる）
  • 403 Forbidden: アクセス禁止
    • ディレクトリトラバーサル攻撃で、権限のないファイル（/etc/passwdなど）へアクセスしようとしてブロックされた際に記録
    • .htaccess、アプリケーションの入力チェック、WAF（Web Application Firewall）などのアクセス制御が機能している可能性
  • 404 Not Found: 存在しないファイル
    • 脆弱性スキャンツールが、存在しない管理画面（/admin/、/phpmyadmin/、/wp-admin/など）を機械的に探す際に大量発生
    • 短時間に多数の異なるパスで404 → 自動スキャンの可能性大

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

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

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

SQLインジェクション攻撃

攻撃文字列がURIのクエリパラメータに含まれる場合、リクエストラインにSQL文特有の記号が現れます（POSTの本文で送られた場合、標準のアクセスログには残りません）。次の例は読みやすさのためデコードして表記しています（実際のログでは %27・%20 などURLエンコードされた形で記録されることが多い）。

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"

検知ポイント

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

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"

検知ポイント

  1. ディレクトリトラバーサルのパターン
    • ../の繰り返し（../../、../../../../など）
    • /etc/passwd、/etc/shadow、C:\Windows\System32\config\SAMなど機密ファイルのパス
  2. ステータス200 + ファイルサイズ
    • 2450バイトは/etc/passwdとしてあり得るサイズだが、サイズは環境で変わり、エラーページでも同程度になり得る
    • ファイルの読み出しに成功した可能性を疑う手がかり。レスポンス内容、アプリケーションログ、ファイルアクセスの記録で裏付ける
  3. User-Agent: curl
    • コマンドラインツールの使用
    • 手動攻撃の可能性

拒否された応答の例

"GET /download.php?file=../../../etc/passwd HTTP/1.1" 403 350
  • ステータス403 → アクセスが拒否された応答
  • バリデーションやWAFが拒否した可能性があるが、どの仕組みが拒否したか、他のリクエストで成功していないかは、アプリケーションログやWAFのログで確認する
  • サイズ350バイト → エラーページの可能性（403や404は存在を隠すためにも使われるため、応答コードだけで攻撃の失敗を確定しない）

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

JavaScriptコードを注入して、他のユーザーのブラウザで実行させる攻撃です。次の例も読みやすさのためデコードして表記しています（実際のログでは %3C・%3E などで記録されることが多い）。

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"

検知ポイント

  1. HTMLタグやJavaScriptの存在
    • <script>タグ
    • alert()などの関数や、document.cookieなどのプロパティ
    • onerror=、onload=などのイベントハンドラ
  2. URLエンコードされた例"GET /board.php?comment=%3Cscript%3Ealert%281%29%3C%2Fscript%3E HTTP/1.1" 200 500
    • %3C = <
    • %3E = >
    • %2F = /
  3. ステータス200
    • 200だけでは、スクリプトが実行可能な形で反映されたかは判断できない（エスケープされて無害化されていても200は返る）
    • レスポンス内容の確認などで、エスケープ処理が不十分かどうかを裏付ける

Reflected XSSとStored XSSの違い

  • Reflected XSS（反射型）: リクエストに含まれた入力が、そのまま応答に反映される（例：上記のURLパラメータ。POSTの入力でも成立する）
  • Stored XSS（蓄積型）: 保存された入力が、後の応答に含まれて他ユーザーに表示される（例：掲示板の投稿をDBに保存。POST本文は標準のアクセスログに残らないため、アクセスログだけでは検知が困難）

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

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

検知ポイント

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

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

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

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

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

1. System（システムログ）

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

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

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

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

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

このほかに Setup（セットアップ）・Forwarded Events（転送されたイベント）のログもあります。また、「アプリケーションとサービスログ」配下のログも調査では重要です。たとえば PowerShell の Microsoft-Windows-PowerShell/Operational（スクリプトブロックログのイベントID 4104）や、導入していれば Sysmon のログが、攻撃者の実行内容を追う手がかりになります。

イベントビューアーのセキュリティログの例。左のツリーでWindowsログのセキュリティを選び、右の一覧には2026/02/03 14:10:52から14:10:57まで1秒ごとに「監査の失敗」のイベントID 4625（ログオン）が6件続き、14:10:58に「監査の成功」の4624が記録されている。短時間に4625が連続した直後の4624は、侵入成功の可能性があることを示している。図の下部には「※同じ対象ホスト・アカウント・送信元かは、各イベントの詳細で照合する」という注記がある。アカウント・送信元は図の一覧に表示されていないため、各イベントの詳細で照合する

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

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

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

ログオン成功・失敗

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

特殊なログオン

  • 4648: 明示的な資格情報を使用したログオンが試行された
    • RunAsコマンドの使用（runas /user:administrator cmd.exe）など、現在のログオンとは別の資格情報を指定したときに記録
    • 正規の運用（RunAs、タスクスケジューラ、サービスなど）でも記録されるため、これだけで攻撃とは言えない
    • 普段使われないアカウントと接続先の組み合わせや、不審なプロセス名で絞り込むと、横展開（ラテラルムーブメント）の手がかりになる
  • 4672: 新しいログオンに特殊な特権が割り当てられた
    • 管理者権限など特権を持つアカウントのログオン
    • 4624の直後に記録される
    • 特権を悪用される危険性

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

アカウント作成・削除

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

グループ管理

  • 4732: ローカルグループにメンバーが追加された
    • 特にAdministratorsグループへの追加は最重要
    • 正規の変更でなければ、権限昇格・永続化の強い痕跡
    • net localgroup administrators attacker /add を実行すると記録される（コマンドの実行そのものは4688で記録される）
  • 4733: ローカルグループからメンバーが削除された
    • 痕跡消去の可能性
  • 4756: ユニバーサルグループにメンバーが追加された（Active Directory）
    • Enterprise Adminsなどへの追加
    • AD環境での権限昇格（なお、Domain Admins（グローバルグループ）への追加は 4728「セキュリティが有効なグローバルグループにメンバーが追加された」で記録される）

プロセス追跡・監査

プロセス実行

  • 4688: 新しいプロセスが作成された
    • 既定では記録されない。まず監査ポリシーで「プロセス作成の監査」を有効にする
    • コマンドラインまで残すには、さらに「プロセス作成イベントにコマンドラインを含める」の設定も必要（この2段階を設定すれば攻撃コマンドを捕捉できる）
    • powershell.exe -enc <Base64エンコードされたコマンド>
    • cmd.exe /c whoami
    • 攻撃者が何を実行したかの直接的な証拠

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

  • 4719: システム監査ポリシーが変更された
    • 監査ポリシーが変更されたことを示す。正規の変更でなければ、攻撃者による監査の無効化を疑う
    • インシデント対応時に優先的に確認
  • 1102: 監査ログが消去された
    • セキュリティログが消去されたことを示す決定的な痕跡（正規の作業でなければ、攻撃者による証拠隠滅を強く疑う）
    • イベントビューアーでの手動消去や、wevtutil cl Security などのコマンドで消去すると記録される
    • なお、システムログなどセキュリティログ以外のログを消去した場合は、システムログにイベントID 104が記録される
    • このログが残っている時点で完全な証拠隠滅には失敗

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

  • 4663: オブジェクトへのアクセスが試行された
    • ファイル、フォルダ、レジストリキーなどに対してアクセス権が実際に使用されたことを記録（失敗のイベントはない）
    • 該当する監査ポリシー（ファイルシステム／レジストリの監査）に加え、対象オブジェクトのSACL（システムアクセス制御リスト）の設定が必要
    • 失敗したアクセス要求を調べるときは、4656（オブジェクトへのハンドルが要求された）なども確認する
    • 機密ファイルへの不正アクセス検知

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

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

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

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

攻撃検知の実例

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

イベントID: 4624
ログオンタイプ: 10 (RemoteInteractive)
アカウント名: Administrator
送信元IPアドレス: 203.0.113.50（海外のIPと仮定。国はGeoIP等で別途調べる）
時刻: 2026-02-15 03:30:00
  • 深夜3時30分に管理者アカウントでRDPログオン
  • 送信元が海外IP
  • RDP総当たり攻撃などによる侵害を強く疑うべき状況
  • 直前に大量の4625（ログオン失敗）がないか確認（NLA（ネットワークレベル認証）が有効な場合、RDPの認証失敗はログオンタイプ10ではなく3として記録されるため、タイプ3の4625も含めて確認する）

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

イベントID: 4624
ログオンタイプ: 3 (Network)
アカウント名: svc_backup（バックアップ用サービスアカウント）
送信元: 普段は接続してこない内部サーバー
時刻: 通常業務時間外
  • サービスアカウントが、通常と異なる送信元からネットワークログオン
  • 内部サーバー間通信だが、送信元・時間帯が平常時のパターンと異なる
  • ラテラルムーブメント（侵害後の横展開）の可能性

ログの相関分析（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が返った
  • アクセスログだけでは、ファイル保存の成否や内容は分からない（入力エラーを200で返す実装もある）
  • Webシェル（バックドア）をアップロードされた可能性を疑い、他のログやサーバー上のファイルで確認する

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

[Syslog（/var/log/auth.log ほか） - 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昇格を試みるが認証失敗
  • 間に記録されたkernelの「possible SYN flooding」はSYNフラッド（またはアクセス集中）の兆候で、権限昇格の試行とは別系統のイベント。相関分析では、無関係なノイズを切り分ける視点も重要

フェーズ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サーバーが侵害され、そこから内部ネットワークへ横展開された可能性
  • ドメイン管理者の資格情報が奪われた可能性があり、組織全体に被害が広がるおそれがある危機的状況

これらのログから推定する攻撃仮説

  1. 14:00 Webサーバーの脆弱性を突いてWebシェルをアップロードした（アクセスログだけではアップロード内容は分からない）
  2. 14:05 Webシェル経由でLinuxサーバー内での特権昇格を試みた（失敗）
  3. 14:10 内部ネットワークのActive Directoryサーバーへ横展開を開始した
  4. 14:15 ドメイン管理者アカウントでのログオンに成功した

これはあくまで仮説です。アップロードされたファイルの実物、Webシェルの実行記録（プロセス作成やWebサーバーのエラーログ）、ADでの操作記録などを追加で確認して裏付けます。

このように、Webログだけを見ていては「アップロード機能へのPOSTに200が返った」ことしか分からず、ファイル保存の成否や内容も分かりませんが、SyslogとWindowsログを合わせることで「Webシェル経由で侵入され、内部ネットワークへ横展開している」という仮説が立ち、次に何を確認すべきかが見えてきます。

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

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

相関分析で正確な時系列を組み立てるには、すべてのサーバーの時刻同期とタイムゾーンの把握が重要です。既知の時刻差なら補正して分析できますが、補正の手間と誤りの余地が増えます。

  • Webサーバー: NTPで同期済み、JST（日本時間）で記録
  • DBサーバー: UTC（協定世界時）で記録（JSTと9時間の差）
  • ADサーバー: NTPが機能しておらず、時計が数分ずれている

上記のように時刻がバラバラだと、突き合わせ作業に多大な労力を要し、インシデント対応の遅れに直結します。タイムゾーンの違いは変換で補正できますが、時計そのもののずれは後から正確に補正するのが困難です。NTPによる時刻同期と、タイムゾーンの統一（またはUTCでの記録と変換ルールの明確化）をセットで行いましょう。

NTP設定の確認方法

# Linux
timedatectl status
ntpq -p          # ntpdを使用している場合
chronyc sources  # chronyを使用している場合

# 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
  • OpenText ArcSight
  • Microsoft Sentinel（旧Azure Sentinel）

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

実務では、生のログファイルから該当行を抽出するスキルが欠かせません。試験でもログの読み取りが問われるため、コマンドでログを絞り込む感覚を身につけておくと理解が深まります。Linuxのコマンドラインツールを使った基本的な調査手法を習得しましょう。

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

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

基本的な使い方

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

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

# 特定のIPアドレスからのSSHログを抽出（. は任意の1文字に一致するため [.] と書き、後ろの " port " で境界を付ける）
grep -E 'from 192[.]168[.]1[.]50 port ' /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 " を含まない行（ステータス200以外）を表示する簡易版
# ※転送バイト数がちょうど200の行なども除外されるため、厳密にはawkで$9を判定する
grep -v " 200 " /var/log/httpd/access_log

# 特定のIPアドレスからのアクセスを除外（1列目のIPアドレスを完全一致で判定）
awk '$1 != "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時台）のログのみ抽出
# （/14:/ だけだと「10:14:05」のような14分台も拾うため、時:分:秒の位置で判定する）
awk '$4 ~ /:14:[0-9][0-9]:[0-9][0-9]$/ {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）のアクセスが突出していることが分かれば、調査の優先対象になります。ただし、正規の高頻度利用者や、多数の利用者が共有するプロキシ・NATのIPアドレスの場合もあります。対象期間、アクセス先のURI、認証失敗やエラー応答の有無、共有IPかどうかを確認したうえで、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を抽出して集計（ダブルクォートで区切ると6番目がUser-Agent）
awk -F'"' '{print $6}' 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インジェクション攻撃の検知

# 行内に'（シングルクォート）またはURLエンコードされた%27を含むアクセスを抽出し、IP別に集計
grep -Ei "'|%27" /var/log/httpd/access_log | awk '{print $1}' | sort | uniq -c | sort -nr

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

# ログイン失敗を含む行から、"from" の直後のIPアドレスを抽出して集計
# （行末からの位置で取ると、末尾に [preauth] などが付く形式でIP以外を拾うため、"from <IP> port" の並びを手がかりにする。ユーザー名が "from" の場合も誤抽出しない）
grep "Failed password" /var/log/secure | awk '{for(i=1;i+2<=NF;i++) if($i=="from" && $(i+2)=="port"){print $(i+1); break}}' | 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を使用します。セキュリティログの読み取りには管理者権限が必要です。

なお、以下の Get-EventLog は従来からある基本的なコマンドレットですが、Windows PowerShell 5.1までで利用でき、PowerShell 7以降では使えません。現在は Get-WinEvent が推奨されています（例は後述）。

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

# セキュリティログから最新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

Get-WinEventによる取得（推奨）

# ログオン失敗（4625）を過去24時間分だけ取得（取得時にフィルタするため高速）
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)}

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

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

圧縮ログの検索

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

# 複数の日付にまたがるログを一括検索（圧縮ファイルも読めるようzgrepを使う）
for file in /var/log/secure*; do
  echo "=== $file ==="
  zgrep -E 'from 192[.]168[.]1[.]50 port ' "$file"
done

ローテーション済みログを結合して解析

# ローテーションされたログを全て結合
# ※ローテーション後のファイル名（.1／日付付き／.gz圧縮）は環境により異なる。圧縮済みならzcatを使う
# ※世代数と期間の対応はローテーションの設定（日次・週次・サイズ基準）次第。期間で絞るなら日時の条件も加える
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レンジ

異常検知の基準

  • アクセス量が平常時を大きく上回る（DDoS攻撃の可能性。何倍で警告するかの閾値は、自組織のベースラインから決める。例：平常時の数倍）
  • 深夜・休日のアクセス（内部不正、外部侵入）
  • 海外IPからのアクセス（グローバルサービスでない限り）
  • 見慣れないUser-Agent（攻撃ツール）

優先度付けとトリアージ

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

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

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

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

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

優先度：低（傾向分析）

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

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

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

主要な規制・規格

  • PCI DSS v4.0.1（現行）要件10.5.1: クレジットカード情報を扱う場合、監査ログを最低12か月保管し、直近3か月分はすぐに分析できる状態にしておく
  • GDPR（EU一般データ保護規則）: ログの保管期間を一律に定めた規定はない。個人データを含むログは「保存制限の原則」により、目的に必要な期間を超えて保管しない
  • 国内: 法律でセキュリティログの保管期間を一律に義務付けたものはなく、業界ガイドライン・契約・社内規程で保管期間を定めるのが一般的

ログの改ざん防止

  • 追記のみ（append-only）の属性設定と、閲覧・削除権限の最小化
  • リモートログサーバーへの転送
  • タイムスタンプ署名（RFC 3161）
  • WORM（Write Once Read Many）ストレージの使用

SC試験対策のポイント

ここまで解説したログの読み方は、情報処理安全確保支援士試験でもインシデント対応の題材を通じて扱われる分野です。令和8年度からSC試験はCBT方式となり、旧午後に当たるのは科目Bです。科目Bでは、問題文に示されたログを読み取り、何が起きたかを説明させる設問が考えられます。

ログの読み取りで押さえる手順

ログが提示されたら、次の順に読むと整理しやすくなります。

  1. 時刻をそろえる: 複数のログが出てきたら、タイムゾーンと時刻のずれを確認して時系列に並べる
  2. 送信元と対象を特定する: どのIPアドレス・アカウントが、どのサーバー・URIに対して操作したかを押さえる
  3. 成否を判断する: 同じアカウント・送信元のFailed→Accepted、4625→4624、ステータスコードとレスポンスサイズの組み合わせで、攻撃が成功した可能性を評価する
  4. その後の行動を追う: 権限昇格（sudo、4732）、横展開（ログオンタイプ3の4624・4648）、痕跡の消去（1102）が続いていないかを確認する

断定しすぎないことも採点の観点になる

ログから言えることと言えないことを区別するのも重要です。User-Agentは偽装でき、ステータス200だけでは攻撃の成功を確定できません。解答では「〜の可能性が高い」「〜で裏付けを取る」のように、根拠となるログの項目と、追加で確認すべきログを合わせて書けるようにしておきましょう。

前提となる設定を問われる

ログは設定しなければ記録されません。4688（プロセス作成）やコマンドラインの記録は既定で無効であること、相関分析にはNTPによる時刻同期とタイムゾーンの把握が重要であること、ログの改ざん対策としてリモートのログサーバーへ転送することなど、「どの設定が欠けていたためにログから追えなかったか」という観点も押さえておきましょう。

【演習】ログ解析と不審な挙動の読み解き 理解度チェック（全10問）

科目A-2（旧午前II）では、Syslogのファシリティとシビアリティ、WindowsのイベントIDやログオンタイプといった用語の意味が4択で、科目B（旧午後）では、提示されたログから攻撃手法や成否、攻撃者の次の行動を読み取って説明させる形で問われることが考えられます。定番のひっかけは、「warning以上だけ監視すれば認証失敗を拾える」「1102はログローテーションでも出る」「4625はログオン成功」「ステータス200なら攻撃は成功と断定できる」といった思い込みです。以下の練習問題で本記事の理解度を確認してみましょう。

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

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

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

本記事で解説した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ログを解析
  • ベースライン（正常状態）を確立し、異常を検知

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

学習ロードマップ

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

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

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

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

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

  • RFC 5424「The Syslog Protocol」（https://www.rfc-editor.org/rfc/rfc5424）
  • RFC 3164「The BSD syslog Protocol」（https://www.rfc-editor.org/rfc/rfc3164）
  • rsyslogドキュメント（https://docs.rsyslog.com/）
  • Apache HTTP Server「Log Files」（https://httpd.apache.org/docs/2.4/logs.html）
  • Microsoft Learn「イベント4624（Windowsセキュリティ監査イベントのリファレンス）」（https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624）
  • Microsoft Learn「4648(S): A logon was attempted using explicit credentials」（https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4648）
  • Microsoft Learn「Get-WinEvent」（https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent）
  • IPA「応用情報技術者試験、高度試験及び情報処理安全確保支援士試験におけるCBT方式での実施について」（https://www.ipa.go.jp/shiken/2026/ap_koudo_sc-cbt.html）
”
FREE PDF
SC午後記述
テンプレート集
登録特典
メール講座 登録で無料プレゼント
「知っているのに書けない」を、型で解消するPDF
設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。SC午後の記述で手が止まらなくなる1冊です。
設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し
無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

登録無料·いつでも配信停止
自社のセキュリティ対策に不安はありませんか？
BKサクセスでは、専任の情シスがいない中小企業様向けに、伴走型のセキュリティ対策支援を行っています。
まずは無料相談から、お気軽にご連絡ください。
✉️ セキュリティ対策について相談する（無料）

▼ 本気で難関資格を狙うなら、攻略法から

資格スクエア

▼ 理想の転職へ。まずはプロに相談

  • この記事を書いた人

Kenta Banno

元CIOの窓際サラリーマン（50代）。プライム上場企業の片隅で、情報処理安全確保支援士の合格を目指して奮闘中！ 現在はAI（Gemini/Claude）を「壁打ち相手」として徹底活用し、日々の学習の備忘録とアウトプットを兼ねて記事を投稿しています。同じ資格を目指す初学者の参考になれば嬉しいです。

-11. ログ分析とインシデント対応