「メモリは嘘をつかない」——法廷に持ち込めるメモリフォレンジックの極意
現場でインシデントに遭遇したとき、多くのエンジニアは「とりあえずログを見よう」と考える。だが、高度な攻撃者はログを消し、痕跡を隠す。そんな時、最後の砦となるのがメモリ（RAM）だ。実行中のマルウェア、暗号化キー、メモリ上にしか存在しないファイルレス攻撃の断片。これらはディスクには残らない。
しかし、メモリダンプを「適当に取った」だけでは、それは法廷で証拠として認められない。今日は、インシデントレスポンスの現場で、攻撃者の息遣いまでをも証拠化するための「証拠保全の流儀」を伝授しよう。
—
1. なぜ「チェーン・オブ・カストディ」が不可欠なのか
メモリフォレンジックにおける最大の敵は、「証拠の改ざん」という疑念だ。法廷で「そのデータは調査中に変更されたのではないか？」と問われたとき、明確な回答ができなければ、どんなに決定的な証拠もゴミ屑になる。
ここで必要になるのがチェーン・オブ・カストディ（保管の連鎖）だ。
誰が、いつ、どのツールで、どんな手順で取得し、そのデータが「改ざんされていないこと（完全性）」をどう担保したか。これを論理的に証明する必要がある。
証拠能力を担保する3つの鉄則
1. 取得プロセスの記録: 全てのコマンド操作、実行時刻、環境の状態をログとして残す。
2. ハッシュ値の即時算出: 取得直後に SHA-256 などのハッシュ値を算出し、記録する。
3. 不変性の確保: 取得したダンプファイルは即座に読み取り専用（Read-only）のストレージへ転送し、以後の解析は必ずコピーに対して行う。
—
2. 攻撃者が仕掛ける罠：メモリダンプの「死角」
攻撃者は、フォレンジックツールを検知してメモリを破壊したり、ダンププロセス自体をフックして偽のデータを流し込んだりする。これを防ぐには、OSの標準的なAPIだけに頼らない、カーネルレベルの信頼できる取得手法が必要だ。
現場で推奨されるのは AVML (Acquire Volatile Memory Linux) のような、外部依存が少なく、静的にリンクされたツールを使うことだ。
—
3. 【実務的実装】証拠保全の自動化スクリプト
手作業はヒューマンエラーの温床だ。以下は、Linux環境でメモリダンプを取得し、同時にハッシュ値を生成して「保全ログ」を作成するPythonスクリプトのテンプレートだ。
import subprocess
import hashlib
import datetime
import os
# 証拠保全のための設定
OUTPUT_FILE = "mem_dump.raw"
LOG_FILE = "chain_of_custody.log"
def generate_hash(file_path):
"""取得したダンプファイルのSHA-256ハッシュを計算"""
sha256 = hashlib.sha256()
with open(file_path, "rb") as f:
while chunk := f.read(8192):
sha256.update(chunk)
return sha256.hexdigest()
def secure_capture():
start_time = datetime.datetime.now().isoformat()
# メモリダンプ取得コマンド (avmlを使用する想定)
# --compress オプションを外してRAW形式で保存するのが基本
cmd = ["./avml", OUTPUT_FILE]
print(f"[*] 保全開始: {start_time}")
subprocess.run(cmd, check=True)
# 完全性の証明（ハッシュ値の保存）
file_hash = generate_hash(OUTPUT_FILE)
end_time = datetime.datetime.now().isoformat()
# チェーン・オブ・カストディ記録
with open(LOG_FILE, "a") as log:
log.write(f"--- 証拠保全ログ ---\n")
log.write(f"取得開始: {start_time}\n")
log.write(f"取得終了: {end_time}\n")
log.write(f"ファイル名: {OUTPUT_FILE}\n")
log.write(f"SHA-256ハッシュ: {file_hash}\n")
log.write(f"取得者: forensic_admin\n")
print(f"[+] 保全完了。ハッシュ値: {file_hash}")
if __name__ == "__main__":
secure_capture()—
4. Webアプリエンジニアが知るべき「メモリ保護」の視点
インシデントレスポンスの現場に立つと、Webアプリケーションの脆弱性がメモリ上の攻撃に直結していることがよく分かる。特に、eval() や unserialize() の乱用は、メモリ上で任意のコードを実行される入り口となる。
もし、貴方のWebアプリがセッション情報をメモリ上に保持する設計なら、以下のような設定で「ダンプからの漏洩」を最小限に抑える必要がある。
PHPのセッション管理設定例 (php.ini)
メモリ上に残るセッション情報を保護するため、ディスクへの書き出しを制限し、かつメモリ内の寿命を短く設定する。
; セッションデータをメモリ上に保持する（memcachedやRedisを使用）
session.save_handler = memcached
session.save_path = "127.0.0.1:11211"
; メモリ内のセッション有効期限を短くする
session.gc_maxlifetime = 1440
; セッションクッキーをセキュアに設定
session.cookie_httponly = 1 ; JavaScriptからのアクセスを禁止
session.cookie_secure = 1 ; HTTPSのみで送信—
最後に：フォレンジックは「準備」が9割
現場で「さあ、メモリを取ろう」と思ったときに、ツールをダウンロードしたり依存関係を解決したりしていては手遅れだ。攻撃者はその間に痕跡を消し去る。
今回紹介したような、ハッシュ値による完全性の担保とログによる手順の記録を、平時の運用手順（Runbook）に組み込んでほしい。そして、何より重要なのは、「いつか必ず自分たちのシステムも侵入される」という前提で、証拠を保全するための環境を整備しておくことだ。
それが、セキュリティチーフエンジニアとして、君たちに最も伝えたい「防衛の極意」だ。質問があればいつでも持ってこい。現場で一緒に検証しよう。
コメント