【実務・中級編】メモリフォレンジックにおけるページファイルとハイバネーションファイルの活用 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

物理メモリが消えても「痕跡」は消えない：pagefile.sysとhiberfil.sysを武器にするDFIRの極意

インシデントレスポンスの現場において、「メモリダンプを取りました」という報告を聞くと、多くのジュニアエンジニアは満足げな顔をする。だが、現実はそんなに甘くない。攻撃者は自分が検知されることを知っている。彼らはメモリダンプを試みる直前に、自身の痕跡を消すためにプロセスを強制終了したり、カーネルレベルでメモリの整合性を操作したりするからだ。

ここで諦めてはならない。OSが物理メモリ上のデータをディスクに書き出している領域、すなわち pagefile.sys（仮想メモリ）と hiberfil.sys（休止状態ファイル）こそが、インシデント解析の「最後の聖域」となる。

1. なぜ「ファイル」がメモリの代わりになるのか

物理メモリ（RAM）は揮発性だが、OSはシステムの安定性を保つために、メモリ上のデータを随時ディスクへスワップアウトしている。攻撃者が物理メモリの特定の領域をクリアしても、そのデータが数分前に pagefile.sys に書き出されていれば、そこには「過去の残像」が残る。

特に hiberfil.sys は、PCを休止状態にする際にメモリ内容を丸ごと保存するファイルだ。ここには、攻撃者が実行した悪意のあるシェルコードの断片や、復号されたパスワード、あるいはメモリ上に展開されたローダーの残骸がそのままの状態で眠っていることが多い。

2. 攻撃者の狙い：メモリ上の「生データ」を盗む手法

攻撃者は、OSのAPIを直接叩いてメモリをダンプする手法（MiniDumpWriteDumpなど）を避け、代わりにディスク上のこれらのファイルを直接読み取る手法をとる。

例えば、攻撃者が特権昇格後に pagefile.sys を解析対象としてコピーし、ローカル環境で Volatility などのフレームワークにかけて秘密鍵やセッション情報を抽出するケースは、高度な標的型攻撃では定石だ。

3. 実践：このリスクをどう防ぐか？

インフラ設計者として、この「ディスク上のメモリ残骸」を放置するのは爆弾を抱えているのと同じだ。我々ができる対策は、「機密データのディスクへの書き出しを防ぐ」ことと、「使用後の抹消」である。

A. Nginx/OSレベルでのセキュア設定

まず、OSの仮想メモリ設定を最適化する。Windowsであれば、シャットダウン時にページファイルをクリアするグループポリシーを有効化するのが基本だ。

Windowsグループポリシー設定:
コンピュータの構成 > Windowsの設定 > セキュリティの設定 > ローカルポリシー > セキュリティオプション

シャットダウン: 仮想メモリのページファイルをクリアする を「有効」に設定。

B. アプリケーション設計における防御（Python例）

Webアプリケーション開発において、メモリ上の機密データ（APIキー、暗号化鍵）を扱う際は、OSのスワップアウトを防止する処理を組み込むのが一流のエンジニアの流儀だ。Pythonでは mlock システムコールを使用して、特定のメモリ領域をRAMに固定（ピン留め）し、スワップさせない実装が可能だ。

import mmap
import ctypes

def secure_memory_allocation(size):
    # メモリを確保
    buf = mmap.mmap(-1, size)
    
    # Linux環境であれば、mlockを使用して物理メモリに固定
    # これにより、pagefile.sysへの書き出しを防ぐ
    libc = ctypes.CDLL("libc.so.6")
    if libc.mlock(ctypes.c_void_p(ctypes.addressof(ctypes.c_char.from_buffer(buf))), size) != 0:
        raise OSError("メモリの固定に失敗しました。特権を確認してください。")
    
    return buf

# 使用例
secret_key = secure_memory_allocation(1024)
# ここで機密データを操作する
# ...

C. クラウド環境でのデータ保護

クラウド（AWS/Azure）環境では、ディスク暗号化は必須条件だ。pagefile.sys が存在するOSボリュームが暗号化されていなければ、バックアップから簡単にメモリ情報をサルベージされる。

TerraformによるAWS EBS暗号化の徹底:

resource "aws_ebs_volume" "secure_volume" {
  availability_zone = "ap-northeast-1a"
  size              = 100
  encrypted         = true # 全てのブロックを暗号化
  kms_key_id        = aws_kms_key.data_key.arn # 独自鍵で管理
  
  tags = {
    Name = "Secure-System-Volume"
  }
}

4. 最後に：DFIRの心構え

現場で pagefile.sys を解析する際は、そのファイル自体が「汚染」されている可能性があることを忘れてはならない。ツールで抽出した文字列が、単なるゴミデータなのか、攻撃者の意図的な罠なのかを見極める洞察力が、アナリストには求められる。

技術はあくまで道具に過ぎない。しかし、その道具を「知っているか」「備えているか」の差が、企業を致命的な情報漏洩から救う防波堤となる。今日のコードをデプロイする際、その裏にあるメモリ管理まで意識を巡らせてほしい。それこそが、プロフェッショナルの仕事だ。