現場の冷徹な現実：物理メモリダンプはなぜ「嘘」をつくのか
インシデントレスポンスの現場において、ファーストレスポンダーが最初に犯す致命的なミスの一つは、「Live Responseツールで取得した物理メモリダンプ（.rawや.dmp）がマシンの全貌を語っている」という神話への過信だ。
現代のOS、特にWindows環境におけるメモリ管理は、限られた物理RAM（Random Access Memory）の枯渇を防ぐために極めてアグレッシブな仮想メモリページングを行っている。つまり、アナリストが DumpIt や WinPmem などのツールを叩いて取得した物理メモリは、その瞬間にRAM上に存在していた「スナップショット」に過ぎない。数分前、あるいは数時間前に実行され、現在は非アクティブ状態にある悪意あるコード、難読化されたシェルコードの原典、あるいはメモリ上からパージされたセッションクッキーや復号鍵は、すでにディスクの深淵――すなわち pagefile.sys や hiberfil.sys へと追い出されているのだ。
高度なAPTグループやランサムウェアのオペレーターは、このメモリの揮発性とOSのページングメカニズムを熟知している。彼らはメモリインジェクション（Process HollowingやAtomBombingなど）を行った後、意図的にアイドル時間を挟むか、あるいは意図的なメモリプレッシャーをかけて自らの痕跡をディスク上の仮想メモリ領域へスワップアウトさせ、ライブメモリ上のフォレンジックアーティファクトを最小限に抑え込もうとする。
この泥沼のインシデントにおいて、物理メモリダンプ単体での解析に固執することは、パズルのピースの半分を自ら捨てているに等しい。我々は、ディスクという巨大な「もう一つのメモリ空間」から失われた断片を回収し、完全なタイムラインを再構築しなければならない。
—
ページファイル（pagefile.sys）とハイバネーションファイル（hiberfil.sys）のアーキテクチャ
これら二つのシステムファイルは、単なるストレージの拡張領域ではない。OSのカーネルが管理する仮想アドレス空間の裏側にある、いわば「物理メモリの不揮発化された影」である。
1. pagefile.sys（ページングファイル）の動的挙動
Windowsのメモリマネージャ（ntoskrnl.exe の内部ルーチン）は、物理RAMの空き容量が低下するか、プロセスのワーキングセット（Working Set）が縮小された際、ページフレームをディスク上の pagefile.sys へ書き出す（Page-out）。この際、データの構造は物理メモリ上の配置とは異なり、チャンク単位で断片化して記録される。
フォレンジック上の最大の難所は、pagefile.sys が動的に上書きされるという点だ。ファイル自体は静的に存在していても、OSが稼働し続ける限り、古いメモリページは新たなデータで容赦なく上書き（Overwriting）されていく。したがって、侵害発覚後のトリアージにおいて、電源を切断する前にライブイメージングを行うか、あるいはディスクイメージそのものを保全することが絶対条件となる。
2. hiberfil.sys（ハイバネーションファイル）の圧倒的な情報量
一方、ノートPCなどで見られる休止状態（Hibernation）や、近年のWindowsにおける高速スタートアップ（Fast Startup）で使用される hiberfil.sys は、文字通り物理RAMの全内容の圧縮スナップショットである。
ここには、カーネルのデータ構造、ドライバのメモリ空間、すべてのユーザースペースプロセスの仮想メモリ、そして通常はアクセスが極めて困難なセキュアな領域の残骸が含まれている。特筆すべきは、Windows 10以降のハイバネーションファイルは Xpress または LZX アルゴリズムで圧縮されている点であり、単なるバイナリビューアでの覗き見を拒絶する構造になっていることだ。
—
実践的フォレンジック：Volatility 3 を用いたディスクベースメモリの抽出と解析
ここからは、実際のインシデントハンドリングの現場を想定し、不完全な物理メモリダンプを pagefile.sys と hiberfil.sys によって補完する具体的なワークフローを解説する。
ステップ 1: hiberfil.sys のデコードと変換
ハイバネーションファイルが取得できた場合、まずはこれを Volatility 3 や専用ツールで解析可能な生（Raw）のメモリイメージに変換する必要がある。Microsoftの古いユーティリティである powercfg を用いるか、オープンソースの解析ツールを使用する。
現代のDFIRでは、Python環境で動作する volatility3 と、hiberfil.sys のヘッダーを解析してRawイメージに復元するサードパーティ製スクリプト（例: volatility の旧バージョンに含まれていた hiber2bin や、カスタムのパーススクリプト）を組み合わせるアプローチが主流だ。
以下のPythonスニペットは、カスタム環境において hiberfil.sys のチャンクヘッダーを解析し、ダンプを再構築するための概念実証（PoC）的なアプローチを示す。
import sys
import struct
def parse_hiberfil_header(file_path):
"""
hiberfil.sysのヘッダー構造を解析し、圧縮タイプとチャンク情報を検証する関数
※実際の解析ではVolatility 3のプラグインや専用パーサーを利用することを推奨
"""
try:
with open(file_path, 'rb') as f:
# Hiberfilのシグネチャ確認 (例: 'POCL' や 'hibr' などのヘッダー構造)
signature = f.read(4)
print(f"[*] ファイルシグネチャ検出: {signature}")
if signature not in [b'POCL', b'hibr', b'HIBR']:
print("[-] 警告: 既知のハイバネーションシグネチャと一致しません。ファイルが破損しているか、暗号化されている可能性があります。")
return False
# ヘッダー情報の読み込み（オフセットやサイズ）
header_data = f.read(60)
uncompressed_size, compressed_size = struct.unpack_from('<QQ', header_data, 16)
print(f"[+] 予測非圧縮サイズ: {uncompressed_size / (1024*1024*1024):.2f} GB")
print(f"[+] 圧縮データサイズ: {compressed_size / (1024*1024*1024):.2f} GB")
return True
except Exception as e:
print(f"[-] エラー発生: {str(e)}")
return False
if __name__ == "__main__":
if len(sys.argv) < 2:
print("Usage: python parse_hiber.py <path_to_hiberfil.sys>")
sys.exit(1)
parse_hiberfil_header(sys.argv[1])ステップ 2: ページファイルからのカーネルプール・プロセスクレデンシャルのサルベージ
物理メモリダンプの解析において、特定のプロセスがすでに終了（Terminated）している場合、そのプロセスの _EPROCESS 構造体はメモリのフリーリストに回され、上書きの危険にさらされる。しかし、pagefile.sys 内には、そのプロセスが使用していたプライベートページがそのまま残存している確率が高い。
Volatility 3 を用いて、ページファイルやハイバネーションファイルから特定のアーティファクトをスキャンするコマンドラインの例を挙げる。
# 1. ページファイルを対象としたプロセスリストの再構築
python3 vol.py -f /mnt/evidence/pagefile.sys windows.pslist.PsList
# 2. 終了したプロセスやスワップアウトされたメモリ領域からのLSASSクレデンシャル（抽出の試行）
python3 vol.py -f /mnt/evidence/hiberfil.sys windows.lsass.Lsassここで重要なのは、Volatility 3 はデフォルトではライブの物理メモリダンプを前提としているが、-f オプションに pagefile.sys や変換済みの hiberfil.sys を指定することで、仮想アドレス空間のオフセットを再計算し、あたかも生メモリであるかのように解析を続行できる点だ。
—
高度な脅威ハンティング：ディスク・メモリ複合解析の盲点と対策
攻撃者がメモリフォレンジックやディスクフォレンジックの双方を検知し、その回避（Anti-Forensics）を試みるケースが増えている。例えば、彼らは以下のような手法を用いる。
1. ページファイルのゼロクリア設定の悪用:
Windowsのグループポリシー（Clear virtual memory pagefile）が有効化されている環境では、シャットダウン時に pagefile.sys が自動的にゼロ埋めされる。フォレンジシャンが電源を落とした瞬間に証拠が消滅する仕組みだ。これを防ぐには、ライブレスポンス時に物理メモリとディスクイメージを同時に、かつ安全にキャプチャするパイプラインを構築しておく必要がある。
2. ファイルレスマルウェアのページファイル残留:
ディスク上に実体を残さず、PowerShellやWMI、あるいは正当なプロセス（msbuild.exe や regsvcs.exe）のメモリ空間内で直接実行されるファイルレス攻撃は、物理メモリ上では揮発性高く存在するが、OSがメモリプレッシャーを検知してスワップアウトした瞬間、pagefile.sys のなかにその「悪意あるコード片」のコピーが永続化される。
ここを突くことで、ライブ時にキャプチャし損ねたシェルコードの断片を、ディスクフォレンジックとのクロスオーバー解析によって完全に復元することが可能となる。
—
結びに代えて：完璧なフォレンジックなど存在しないという前提
インシデントレスポンスにおいて、「完璧な証拠」を最初から手に入れられることは稀だ。物理メモリダンプが不完全であったり、破損していたりすることは日常茶飯事である。
しかし、オペレーティングシステムの内部構造（Virtual Memory Managerの挙動、ページングのメカニズム、ハイバネーションの圧縮アルゴリズム）の深部にまで踏み込んだ知識を持つアナリストにとって、pagefile.sys や hiberfil.sys は単なる「ゴミ箱の残りかす」ではなく、攻撃者の最も生々しい足跡が刻まれた宝の山である。
ツールが吐き出す結果をうのみにするのではなく、OSがそのデータをどこへ追いやり、どのように隠蔽しようとしたのかを逆算する――それこそが、真のセキュリティエンジニアとチェイスを繰り広げる攻撃者との間に立つ、圧倒的な防衛の差なのだ。
コメント