ログ解析｜攻撃の痕跡をテキストから読む
フォレンジック編の第3回。サーバーが記録する「すべての足跡」であるログを読み解き、ブルートフォース攻撃から侵入・情報持ち出しまでの一連の流れをテキストから再構築する技術を体験します。
📋 目次
📋 ログとは何か｜サーバーが記録する「すべての足跡」
誰が・いつ・何をしたかが、すべて記録されている
ログ = サーバーの「行動記録」
Webサーバー・アプリケーション・OSは、発生したすべての出来事（リクエスト・ログイン試行・エラーなど）をログファイルとして記録しています。「誰が（IPアドレス）」「いつ（タイムスタンプ）」「何を（リクエスト内容）」「結果はどうだったか（ステータスコード）」がすべて残るため、インシデント発生後に何が起きたかを再構築する唯一の手がかりになることが多いです。
代表的なログの種類には、Webサーバーへのすべてのリクエストを記録するアクセスログ、エラー発生時の詳細を記録するエラーログ、ログイン試行を記録する認証ログなどがあります。今回は最も基本的な「アクセスログ」を読み解いていきます。
ログは「唯一の証拠」だが、万能ではない
HTTPS通信の本文（パスワードや送信データの内容）はログに残らないことが多く、巧妙な攻撃者はログそのものを消去・改ざんすることもあります。ログ解析は強力な手法ですが、「ログに残っていない＝何もなかった」と即断するのは危険です。
🔎 ログの「形式」を読み解く
1行に詰まった情報を分解する
Webサーバーの代表的なログ形式（Apache/Nginxの「combined」形式）は、一見暗号のように見えますが、決まった順番で情報が並んでいるだけです。
| 項目 | 意味 | 例 |
|---|---|---|
| 送信元IP | リクエストを送った相手 | 203.0.113.77 |
| タイムスタンプ | リクエストが発生した日時 | [15/Jan/2026:10:24:22 +0900] |
| メソッド + パス | 何を要求したか | "POST /login HTTP/1.1" |
| ステータスコード | 結果（成功/失敗等） | 200=成功 401=認証失敗 403=拒否 404=存在しない |
| User-Agent | 使用したブラウザ/ツール | "curl/7.68.0" |
🕵️ 攻撃の痕跡パターンを見抜く
「いつもと違う」を見つけるのがログ解析の本質
| パターン | ログの特徴 | 意味 |
|---|---|---|
| ブルートフォース | 同一IPから短時間に多数の401/403 | ログイン総当たり攻撃 |
| SQLインジェクション | URLに' OR UNION SELECT等 | データベースへの不正クエリ試行 |
| パストラバーサル | URLに../が連続 | ファイルシステムの不正アクセス試行 |
| ディレクトリスキャン | 同一IPから様々なパスへ多数の404 | 存在するページの探索 |
| 異常なUser-Agent | curl python-requests sqlmap nikto等 | 自動化ツールの利用（即悪意とは限らない） |
🧩 CTFで使うログ調査テクニック3選
大量のログを効率的に絞り込む
ステータスコードで絞り込む
まず401や403、500のような異常系のステータスコードだけを抜き出すと、攻撃の手がかりが一気に見えてきます。正常な200ばかりのログの中から異常を見つけるのは、人間の目では非効率です。
IPアドレスでグルーピングする
異常なステータスコードが見つかったら、その送信元IPアドレスで全体を再フィルターします。同じIPの行動を時系列で追うことで、「いつ失敗し、いつ成功し、その後何をしたか」という攻撃の全体像が見えてきます。
時系列で並べてストーリーを組み立てる
ログは基本的に発生順に記録されています。怪しいIPの行動を時系列順に読むことで、「総当たり攻撃 → 成功 → 管理画面アクセス → データ持ち出し」のような攻撃のストーリー全体を再構築できます。実務ではgrepやawk、大規模な環境ではSIEM（Splunkなど）がこの作業を助けてくれます。
🧩 5分CTFチャレンジ：ログから攻撃者の侵入経路を追え
21件のアクセスログに紛れた攻撃の全貌を暴け
下のログビューアには、ある日のアクセスログ21件が記録されています。この中に、ログイン総当たり攻撃から始まり、最終的に機密データを持ち出すまでの一連の攻撃が紛れ込んでいます。フィルターを使って攻撃者のIPを特定し、その後の行動を時系列で追ってください。
チャレンジの手順
① フィルター欄に401と入力し、認証失敗が連続しているIPアドレスを特定する → ② フィルターをそのIPアドレスに変更し、そのIPの全行動を時系列で確認する → ③ 401の連続→200成功→管理画面アクセスという流れを確認する → ④ その後のリクエストのURLに含まれるフラグを読み取る！
攻撃者のIPを特定し、その後のリクエストURLに含まれるフラグを入力してください。
フィルターに401と入力すると、同じIPアドレスから6回連続でログイン失敗していることが分かります。そのIPアドレスをコピーしてください。
フィルターをそのIPアドレスに変更すると、6回の失敗の後に200（成功）、続いて/admin/dashboard、最後に/admin/export?secret=CTF{...}へのアクセスが見つかります。そのURLの中にフラグが書かれています。
📝 まとめ＋FAQ＋次回予告
今回のポイントを振り返ろう
第17話では、サーバーのアクセスログの形式を読み解き、ブルートフォース攻撃から侵入、データ持ち出しまでの一連の流れをテキストから再構築する技術を学びました。ステータスコードでの絞り込み、IPアドレスでのグルーピング、時系列での整理という3つの基本テクニックは、実際のインシデント対応でもそのまま使われます。
・ログはサーバーが記録する「誰が・いつ・何をしたか」のすべての足跡
・アクセスログはIP・タイムスタンプ・リクエスト・ステータス・User-Agentの順で構成される
・同一IPから多数の401/403が続くのはブルートフォース攻撃の典型例
・ステータスコードで絞り込み→IPでグルーピング→時系列で並べるのが基本の調査手順
・ログは強力な証拠だが、消去・改ざんされる可能性もあり万能ではない
Q. 本物のサーバーログはどこに保存されているのですか？
Apacheなら/var/log/apache2/access.log、Nginxなら/var/log/nginx/access.logが一般的です。Windowsサーバーではイベントビューアーに記録されます。ディスク容量の都合上、一定期間で古いログが自動的に削除・ローテーションされることが多い点も実務では重要です。
Q. ログを見るだけで全ての攻撃が分かりますか？
いいえ。HTTPS通信の本文の内容はログに残らないことが多く、巧妙な攻撃者はログ自体を改ざん・削除して痕跡を消すこともあります。ログはあくまで証拠の1つであり、他の調査手法（第15・16話のファイル調査等）と組み合わせる必要があります。
Q. 大量のログをどうやって効率的に調べるのですか？
コマンドラインではgrepやawkでパターンを絞り込みます。大規模な組織では、Splunkやエラスティックスタック（ELK Stack）のようなSIEM（ログ集約・分析）ツールを使い、複数サーバーのログを一括で検索・可視化します。
Q. ログの改ざんは可能ですか？
攻撃者がサーバーへの十分な権限を獲得した場合、ログファイルを削除・書き換えて痕跡を消すことがあります。これを防ぐため、ログをリアルタイムで別の安全なサーバーへ転送する「集中ログ管理」が、セキュリティ対策のベストプラクティスとされています。
ネットワークフォレンジック入門｜パケットの中身を読む
フォレンジック編の第4回。通信そのものを記録した「パケットキャプチャ」の基礎を学び、次回のWireshark実践への準備をします。
📚 参考情報
- Apache HTTP Server「Log Files」公式ドキュメント
- OWASP「Logging Cheat Sheet」
- IPA「インシデントレスポンスにおけるログ分析の基礎」
コメント