メモリフォレンジックの真実：pagefile.sysとhiberfil.sysが語る「消えた痕跡」
現場でインシデント対応をしていると、よく「メモリダンプさえ取れれば勝てる」と盲信する新人アナリストに出くわす。だが、現実は甘くない。攻撃者は巧妙で、メモリ上の痕跡を消すためにプロセスを強制終了したり、あるいはそもそもメモリダンプを奪う前にシステムを再起動させて証拠を飛ばそうとする。
そんな時、我々が最後に頼るのが、ストレージの片隅で静かに息を潜めている pagefile.sys（仮想メモリ）と hiberfil.sys（休止状態ファイル）だ。これらは単なる「古いファイル」ではない。攻撃者がメモリ上で展開した悪意あるコードや、復号されたパスワード、セッションキーの「墓場」であり、同時に「宝庫」でもある。
なぜページファイルとハイバネーションファイルが重要なのか？
OSは物理メモリが枯渇すると、使用頻度の低いメモリ領域をストレージへ退避させる。これが pagefile.sys だ。また、PCが休止状態に入るとき、メモリ内容を丸ごと hiberfil.sys に書き出す。
攻撃者がメモリ上で実行していたシェルコードや、難読化を解除した後のペイロードは、物理メモリから消えても、これらのファイルにフラグメント（断片）として残っていることが多い。メモリダンプという「瞬間」だけでなく、これらのファイルは「過去の一定期間」のメモリ状態を保存しているため、フォレンジックにおいては物理メモリ以上の情報量を持つことがある。
攻撃者は何を見ているか：メモリ上のパスワードと平文
攻撃者が狙うのは、メモリ上に一時的に置かれる「平文のクレデンシャル」だ。Webアプリケーション開発者が config.php や環境変数から読み取ったAPIキーやDBパスワードは、一度メモリにロードされれば、そこをダンプすることで容易に盗み出される。
もし君たちが書いたコードが、メモリ上で不用意に機密情報を保持し続ける設計であれば、攻撃者は hiberfil.sys を解析するだけで、その組織の全権限を奪うマスターキーを手に入れることになる。
実務で使える防御策：機密情報のメモリライフサイクルを制御する
「メモリに情報を置くな」というのは無理な話だ。だが、その寿命を極限まで短くし、かつページファイルへの書き出しを抑制する設計は可能である。ここでは、機密情報を扱う際のPythonとPHPでの実装指針を示す。
1. Pythonでの機密情報の扱い（ctypesによるメモリ確保）
Pythonの文字列はイミュータブル（不変）であるため、一度メモリに作られるとガーベジコレクションが回収するまで残り続ける。機密情報を扱う際は、ctypes を使ってメモリを明示的に確保・解放するのがプロの作法だ。
import ctypes
import os
def secure_store(secret_data):
# 秘密鍵などの機密情報を固定サイズのメモリ領域に確保
size = len(secret_data)
buffer = ctypes.create_string_buffer(secret_data.encode('utf-8'))
try:
# ここで処理を実行
print(f"処理中: {buffer.value}")
finally:
# 処理が終わったら直ちにゼロ埋めしてメモリを解放
ctypes.memset(buffer, 0, size)
print("メモリを安全にクリアしました")
# 利用例
secure_store("super-secret-api-key-12345")2. Nginx設定によるメモリ情報の流出リスク軽減
hiberfil.sys に機密情報が書き込まれるのを防ぐ究極の対策は、そもそも機密情報をOSの仮想メモリに依存させないことだ。しかし、Webサーバの設定レベルでは、以下のように「バッファの最小化」を意識すべきだ。
# /etc/nginx/nginx.conf の設定例
# 大きなバッファはメモリ不足を招き、ページファイルへのスワップを誘発する
client_body_buffer_size 16k;
client_header_buffer_size 1k;
client_max_body_size 1m;
# セッションIDをメモリに長時間保持させないための設定
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m; # 短く設定してメモリ上の滞留時間を減らすインシデントレスポンスの現場からの提言
君たちが開発したWebアプリケーションが攻撃の標的になったとき、侵入者はまず pagefile.sys を探す。そして、そこに残された君たちの「平文のセッションデータ」や「設定ファイルの中身」を吸い上げる。
現場での教訓を一つだけ伝えておく。
「メモリはクリアされるものだと思わず、常にログとして残っていると思え」。
物理メモリのダンプだけを頼りにするアナリストは二流だ。OSがストレージに書き出した「負の遺産」までを完璧に追跡し、そこから攻撃者の足跡を再現できて初めて、君たちは一流のDFIRエンジニアになれる。
もし、サーバーが休止状態（ハイバネーション）を許可している環境なら、今すぐポリシーを見直せ。それが、君たちの組織を守る最初の、そして最も重要な第一歩になるはずだ。
コメント