不正アクセスをログで調査する方法｜認証・操作・データ取得の痕跡

不正アクセスのログ調査では、誰のIDで、いつ、どの機能を使い、何のデータを取得したかを、認証・操作・Webサーバーのログを時刻順につないで確かめる。

不正アクセスのログ調査で決める対象期間と証拠保全

不正アクセスのログ調査では、残っている最も古いログから気づいた時点までを期間とし、疑わしいIDが使えるシステムのログを、消える前に複製する。

不正アクセス調査の対象期間と資産

期間は最初の不審な記録から気づいた時点までだが、始まりは調べるまで分からないので、残っているログの最も古い日から見る。JPCERT/CCは『高度サイバー攻撃への対処におけるログの活用と分析方法』で、保存期間が足りないといつから攻撃を受けていたかを判断しにくいとし、参考値として1年分の保存を推奨している。

対象は疑わしいアカウントが使える範囲で決める。会員サイトの管理者IDなら、次の記録を集める。

• そのIDのログインを記録する認証ログ（VPN、クラウドのサインイン、管理画面）
• 管理画面でのユーザー追加・権限変更・データ出力を記録するアプリの操作ログ
• Webサーバーのアクセスログと、社外への通信を記録するプロキシやファイアウォールのログ

ログごとに、置き場所、残っている日数、取り出せる担当者を一覧にする。日数が調査期間より短いログは、ここで分かる。

アクセスログの保全：上書き防止と保管

調べる前に、疑わしい機器の電源を切ったり初期化したりしない。個人情報保護法サイバーセキュリティ連絡会の『不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点』は、調査を予定する機器について、ネットワーク隔離はしてよく、電源オフや初期化などはしてはいけない措置に挙げている。

保全は、ログを別の場所に複製し、複製が元と同じことを確かめるまでを指す。NISTの『フォレンジック技法をインシデント対応に組み込むためのガイド』とOWASPの『ロギング チートシート』に沿うと、次の順になる。

不正アクセスのログ調査で照合する認証・操作・データ取得

不正アクセスのログ調査では、侵入に使われたIDのログイン成功を起点に、その後の操作とデータ取得を、利用者IDとセッションIDで時刻順につなぐ。大量のログイン失敗は試行の記録で、侵入の後に何が起きたかは成功より後の記録に残る。

並べる前に、協定世界時（UTC）と日本時間が混ざったログは時刻をそろえる。JPCERT/CCは、機器の時刻のずれで複数のログを付き合わせにくくなるとし、NTPの利用を勧めている。

アクセスログ解析で照合する認証・接続元・管理操作

OWASPが記録すべき出来事に挙げる認証の成否、権限の変更、データの出力を、次の順で追う。

1. 認証ログで、疑わしいIDのログイン成功の時刻・接続元・端末を抜き出し、直前に失敗が続いていないかを見る。海外や深夜の接続は、その利用者のふだんの接続元・時間帯と比べてから不審とする。
2. 同じIDやセッションIDで、アプリの操作ログを時刻順に並べる。
3. ユーザーの追加、権限の変更、多要素認証の設定変更、APIキーの発行など、パスワードを変えた後でも再び入れる状態を作る操作を探す。
4. 権限を変えられたIDや新しく作られたIDがあれば、そのIDについて1〜3を繰り返す。

起点のログイン成功が無いこともある。JPCERT/CCは2026年10月の注意喚起で、国内で相次いだ漏えいの手口に、既知の脆弱性の探索、公開アプリを解析して特定した管理用APIへの不正なリクエスト、他のシステムから盗んだAPIキーの使用を挙げている。この場合はWebサーバーのアクセスログから入る。設定ファイルやバックアップファイル、画面からは呼ばれない内部APIへの要求と、エラー応答の急増を探し、その時刻から3の操作へつなぐ。

IPアドレスだけでつなぐと、別人の操作を混同しうる。Apache HTTP Serverの公式文書は、間にプロキシがあればアクセスログに残るのはプロキシのアドレスだと説明している。上の注意喚起も、Torの出口ノードやレジデンシャルプロキシ経由のアクセスを確認している。記録同士は、利用者IDとセッションIDでつなぐ。

不正アクセスの痕跡となるデータ取得・外部通信

取得されたデータは、ログの種類で分かる細かさが違う。

Apacheの標準の書式では、返したデータの大きさは応答ヘッダーを除いたバイト数で記録される。JPCERT/CCは、持ち出しが疑われる場合に組織外への著しく大量の送信をプロキシのログで分析するよう挙げている。データ量で候補を絞り、どの情報だったかはアプリの操作ログで確かめる。

JPCERT/CCは『侵入型ランサムウェア攻撃を受けたら読むFAQ』で、攻撃者の窃取の主張が事実でないケースがあり、漏えいの有無はログを調べながら判断するとしている。

ログが無い期間や記録していない操作は、取得の有無を判断できない。個人情報保護委員会は漏えいの「おそれ」の段階でも報告の対象とし、不正な目的のおそれがある場合の確報を発覚から60日以内としている。我々は、ログで取得を否定できない範囲は、おそれのある範囲として影響に数えると考える。

集めた認証・操作・データ取得のログをAIに読ませて候補を拾い、元のログと照合して確かめる手順は、AIによるログ解析の記事で扱っている。

不正アクセスのログ調査から自動化を推定する手がかり

不正アクセスのログ調査では、要求の量・順序・対象の広がりから、自動化された操作かどうかを推定する。

短時間の連続操作と自動化の手がかり

MITRE ATT&CKは総当たり攻撃（T1110）の検知の観点に、大量の認証失敗の後の成功や、多数の利用者への短い間隔の試行を挙げている。ログでは次の点を見る。

• 人の手では出ない件数の要求が短時間に続いているか
• 接続元が変わっても、同じ認証トークンやAPIキーの要求が続いているか
• 連番のURLや会員IDを順に取得しているか

間隔がそろうのは単純なスクリプトの特徴で、応答を見て手を変える自動化ではそろわないこともある。ばらつきだけで人の操作とは決めない。

バックアップや他のシステムとの連携など、正規の自動処理も同じ形の記録を残す。登録済みの自動処理のアカウント・実行時刻と突き合わせ、一致しないものを攻撃の候補にする。

AI利用の推定と証拠の限界

JPCERT/CCは2026年10月15日の公式ブログで、上の連続事案の攻撃基盤を調べ、攻撃者がAIを使って脆弱性のスキャンやAPI経由の攻撃をしていたことを確認したと報告している。被害を受けた側のログに残る要求の量と順序は、AIを使わないスクリプトでも同じ形になる。

ログからの結論は「自動化された操作の可能性が高い」までにとどめ、AIの利用は公的機関などの発表がある場合に限って書くと我々は考える。

不正アクセスの調査で不足するログと依頼時の引き継ぎ

不正アクセスの調査の区切りや調査会社への依頼の前には、確かめた経過、確かめられなかった区間、不足するログを分けて書き出す。この区別が、次に調べる範囲を決める。

1. 調査期間と、疑われるID・機器、不審な動きに気づいた時刻
2. 確かめた経過：ログイン成功、管理操作、データ取得を、時刻・ログの名前・該当する行と一緒に
3. 確かめられなかった区間：ログが無い期間、記録していない操作、攻撃者に消されたログ
4. 保全したログ：ファイル名、取得日時、取得者、ハッシュ値、時刻の基準
5. すでに行った対応：パスワードの変更、アカウントの停止、機器の再起動など

連絡会の資料は調査会社への依頼の利点に、専門家の客観的な報告書を関係者への説明に使えることや、証拠を保全して訴訟に備えられることを挙げ、法令上の報告に必須ではないともしている。我々は、次のいずれかなら依頼を考える。

3の区間が残るかどうかで、説明できる影響の範囲が変わる。