証跡保全の基本｜インシデント対応で最初にやること

「とりあえず再起動してみました」——インシデント対応の現場でこの一言を聞くと、背筋が凍ります。

再起動はメモリ上の情報をすべて消去します。攻撃者がどこから侵入したか・どんなツールを使ったか・いつから潜伏していたか——その手がかりがすべて失われます。善意の「まず直そう」という行動が、原因究明と再発防止を不可能にすることがあります。

インシデント対応において、証跡保全は「最初にやること」です。封じ込め・復旧・原因調査のすべては、証跡が残っていることを前提に成り立ちます。この記事では、何を・どの順番で・どうやって保全するかを実務レベルで解説します。

インシデント対応の全体フローについては「セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方」を先にご覧ください。

なぜ証跡保全が最優先なのか

インシデント発生時、現場では「早く直したい」というプレッシャーがかかります。しかし復旧を急ぐあまり証跡を失うと、以下の3つの問題が発生します。

原因が特定できなくなる。 「どこから侵入されたか」がわからなければ、同じ手口で再侵害される可能性が残ります。穴を塞がないまま復旧しても意味がありません。

影響範囲が把握できなくなる。 「何が持ち出されたか・どこまで汚染されているか」を把握するには、攻撃者の行動ログが必要です。証跡がなければ影響範囲を過小評価するリスクがあります。

法的・コンプライアンス対応ができなくなる。 個人情報漏洩等のインシデントでは、当局への報告や顧客への通知が法的に義務づけられる場合があります。証跡がなければ報告内容を裏付けられません。

デジタルフォレンジック（Digital Forensics） インシデントの原因・経路・影響範囲を特定するためにデジタル証跡を収集・分析する調査手法。証跡の完全性と信頼性を保つため、収集手順と保管方法に厳密さが求められる。

証跡の種類と揮発性——何から保全するか

証跡には「時間が経つと失われるもの」と「時間が経っても残るもの」があります。揮発性の高いものから優先して保全することが原則です。

揮発性（Volatility） デジタル証跡がどれだけ短時間で失われるかを示す性質。電源断・再起動・時間経過によって消える情報ほど揮発性が高い。

この順番を覚えておくだけで、現場での判断が変わります。「まずメモリを取得する→ネットワーク接続を記録する→ログを保全する→ディスクイメージを取得する」という流れが基本です。

実務で使える証跡保全の手順

① メモリダンプの取得

メモリダンプ（Memory Dump） 実行中のプロセス・暗号化キー・ネットワーク接続情報・マルウェアの動作状況など、RAMに展開されている情報をそのままファイルとして保存したもの。再起動前に必ず取得する。

メモリダンプはWindowsに標準搭載のツールでは取得できません。以下のようなツールを事前に準備しておくことを推奨します。

• WinPmem（無料・オープンソース）
• Magnet RAM Capture（無料）
• FTK Imager（無料版あり）

# WinPmemを使ったメモリダンプ取得の例
winpmem_mini_x64.exe memory.raw

取得したダンプファイルは外部メディア（USBや外付けHDD）に保存します。対象端末のローカルディスクに保存すると、後の証拠として使えなくなる可能性があります。

② ネットワーク接続状態の記録

再起動前に現在のネットワーク接続状態を記録します。攻撃者がC2サーバ（指令サーバ）と通信している場合、その接続情報が確認できます。

C2サーバ（Command and Control Server：指令サーバ） 攻撃者がマルウェアに感染した端末を遠隔操作するために使用するサーバ。感染端末はC2サーバからの命令を受けて動作する。

# 現在のネットワーク接続を記録（コマンドプロンプト）
netstat -ano > netstat_記録日時.txt

# DNSキャッシュの記録
ipconfig /displaydns > dns_cache_記録日時.txt

③ 実行中プロセスの記録

不審なプロセスが動いていないかを記録します。

# 実行中プロセスの一覧を記録
Get-Process | Export-Csv -Path process_list_記録日時.csv -NoTypeInformation  -Encoding UTF8

# プロセスの詳細（実行ファイルのパス含む）
Get-WmiObject Win32_Process | Select-Object Name, ProcessId, ExecutablePath |
  Export-Csv -Path process_detail_記録日時.csv -NoTypeInformation -Encoding UTF8

④ イベントログの保全

Windowsのイベントログはサイズ上限に達すると古いものから上書きされます。早期に保全しないと重要な認証ログ・操作ログが失われます。

# セキュリティログをevtxファイルとしてエクスポート
wevtutil epl Security C:\保全先\Security_記録日時.evtx

# システムログ・アプリケーションログも合わせて保全
wevtutil epl System C:\保全先\System_記録日時.evtx
wevtutil epl Application C:\保全先\Application_記録日時.evtx

ADのイベントログの読み方と攻撃の兆候については「ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド」を参照してください。

⑤ ディスクイメージの取得

ディスク全体をイメージファイルとして保存します。時間がかかるため優先度は低いですが、詳細なフォレンジック調査には必要です。

ディスクイメージ（Disk Image） ディスク全体をビット単位でコピーしたファイル。削除済みファイルの復元・ファイルシステムの詳細調査が可能になる。FTK ImagerやDD（Linuxコマンド）で取得できる。

取得には対象ディスクの容量と同等以上の外部ストレージが必要です。本番環境では業務停止を避けるため、ライブフォレンジック（電源を落とさずに取得する手法）を選択するケースもあります。

参考：証拠保全ガイドライン第10版 | デジタル・フォレンジック研究会

証跡保全で絶対にやってはいけないこと

証跡保全において「やってしまいがちだが絶対にNG」な行動があります。

① 再起動・電源断 最も多い失敗です。「再起動したら直るかも」という判断が、メモリ上の全証跡を消去します。再起動はメモリダンプ・プロセス一覧・ネットワーク接続状態のすべてを失います。

② ウイルス対策ソフトによるフルスキャン 善意の対応ですが、マルウェアを「駆除」する過程で証跡ファイルが削除・変更されます。スキャンは証跡保全が完了した後に実施してください。

③ 対象端末上でファイルを操作する 不審なファイルを開く・移動する・削除するといった操作は、ファイルのタイムスタンプ（更新日時）を変更します。タイムスタンプはいつ攻撃が行われたかを示す重要な証跡です。

④ 証跡ファイルを対象端末のローカルに保存する 保全した証跡を対象端末のCドライブに保存すると、ディスクイメージを取得した際に「保全作業の痕跡」が混入します。必ず外部メディアに保存してください。

保全記録（チェーン・オブ・カストディ）の重要性

証跡を取得しても「誰が・いつ・何を・どうやって取得したか」の記録がなければ、証拠としての信頼性が担保できません。

チェーン・オブ・カストディ（Chain of Custody：証拠保管の連鎖） 証拠が収集されてから分析・提出されるまでの過程で、誰が・いつ・どこで・どのように扱ったかを記録する手続き。証拠の完全性と信頼性を担保するために必要。

保全記録に含めるべき最低限の情報は以下の通りです。

特にハッシュ値の記録は重要です。取得直後と調査時のハッシュ値を照合することで、「取得後に改ざんされていない」ことを証明できます。

# ファイルのSHA-256ハッシュ値を取得
Get-FileHash -Path memory.raw -Algorithm SHA256

証跡保全チェックリスト

保全前の確認

• 再起動・電源断をせずに保全作業を開始できる状態か確認した
• 外部保存先（USBや外付けHDD）を用意した
• 保全記録用のメモ・シートを準備した

揮発性の高い情報から順に保全

• メモリダンプを取得した
• ネットワーク接続状態（netstat）を記録した
• DNSキャッシュを記録した
• 実行中プロセス一覧を記録した
• Windowsイベントログ（Security・System・Application）をエクスポートした
• 必要に応じてディスクイメージを取得した

保全記録

• 取得日時・作業者・対象システムを記録した
• 使用ツール・保存先を記録した
• 取得した各ファイルのハッシュ値を記録した

まとめ——「直す前に残す」が証跡保全の鉄則

証跡保全の原則は一言で表せます。「直す前に残す」。

インシデント発生時に「早く直したい」という気持ちは自然です。しかし復旧を急ぐあまり証跡を失うと、原因不明のまま同じ被害が繰り返されます。揮発性の高いものから順に保全し、取得した証跡にはハッシュ値を記録する——この手順を知っているだけで、インシデント対応の質が大きく変わります。

今日確認すべきことは1つです。メモリダンプ取得ツール（WinPmemなど）が手元に準備されているか確認してください。インシデントが起きてから準備しても遅いです。

次のステップは、保全した証跡からWindowsイベントログを使った初動調査です。「Windowsイベントログ調査入門｜インシデント発生時の初動調査」（公開予定）で詳しく解説します。

あわせてご覧ください

• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方
• ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド
• AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
• 最小権限の原則とは？実務での考え方と設計例