虚構の境界線：Windowsメモリ管理の深淵とページテーブルによる「真実」の再構築
インシデントレスポンスの現場において、多くの駆け出しアナリストが犯す最大のミスは、OSが提供するAPIや標準ツール（tasklistやnetstat）が返す「綺麗な」情報を鵜呑みにすることだ。攻撃者がカーネルレベルで活動している場合、それらのツールが参照するデータ構造は既に改ざんされている可能性が高い。
真のフォレンジックとは、OSの皮を剥ぎ、物理メモリの生データ（Raw Memory Dump）の中に潜む「物理アドレス」と「仮想アドレス」の対応関係を、ページテーブルの構造を辿って自力で再構成することに他ならない。本稿では、Windowsのメモリ管理の心臓部であるページテーブル解析に焦点を当て、攻撃者の痕跡を暴く技術的アプローチを解説する。
1. なぜページテーブル解析が「最後の砦」なのか
Windowsの仮想メモリ空間（VAD: Virtual Address Descriptor）は非常に洗練されているが、攻撃者はしばしば「ページングの隙間」を突く。例えば、通常のプロセスがアクセスしないメモリ領域に不正コードをインジェクトし、ページテーブルエントリ（PTE）を直接操作して、物理メモリ上の特定のページを保護フラグ（RWX等）と共にマッピングする手法だ。
OS標準のメモリダンプ解析ツールは、しばしば「有効」とマークされたページのみを抽出するが、攻撃者はページを「無効」あるいは「スワップアウト」状態に偽装し、メタデータから隠蔽する。我々が知るべきは、CR3レジスタから始まるページディレクトリ階層を解析し、PTEの Present Bit や PFN (Page Frame Number) を直接読み解く能力である。
2. ページテーブル解析のアーキテクチャ（x64環境）
x64アーキテクチャでは、4段階（または5段階）のページ変換階層が存在する。
1. PML4 (Page Map Level 4)
2. PDPT (Page Directory Pointer Table)
3. PD (Page Directory)
4. PT (Page Table)
この階層を解析する際、重要なのは PFN から物理アドレスを計算し、そのメモリセグメントが実際にどのプロセス空間に属しているかを特定することだ。
実務における解析コードの断片（Python / Volatility 3 Pluginのロジック）
Volatility 3などのフレームワークを用いて、特定の仮想アドレスからPTEを特定するロジックは、以下のような構造を持っている。
# 仮想アドレスから物理アドレスを逆算するための概念的なエミュレーション
def translate_virtual_to_physical(cr3, virtual_address):
# CR3レジスタからPML4のベースアドレスを取得
pml4_base = cr3 & 0xFFFFFFFFFF000
# 仮想アドレスを各層のインデックスに分割（ビットシフトとマスク）
pml4_idx = (virtual_address >> 39) & 0x1FF
pdpt_idx = (virtual_address >> 30) & 0x1FF
# ここで各テーブルエントリを読み取る
# PTEのPresent Bit (Bit 0) が0なら、そのページは物理メモリに存在しない
pte = read_memory_at(pml4_base + (pml4_idx * 8))
if not (pte & 0x1):
# ページがスワップアウトされているか、不正なアクセスである可能性
raise Exception("Page not present in physical memory")
# PFNを取り出し、物理アドレスへ変換するロジックを続行
physical_page = (pte & 0x000FFFFFFFFFF000)
return physical_page3. フォレンジックの現場：断片化されたデータの再構築
物理メモリから抽出した断片化されたデータ（例えば、メモリ上に散らばったシェルコードの断片）を再構築する際、単に文字列を探す（stringsコマンド）だけでは不十分だ。
攻撃者がファイルレスでペイロードを保持している場合、ページテーブルを辿ることで、「本来メモリ上に存在してはならないコード」がどの物理アドレスにマッピングされ、どのプロセスと紐付いているかを特定できる。この「紐付け」こそが、インシデントの根本原因（Root Cause）を特定する決定的な証拠となる。
4. 次世代の防衛：ガードレイルの設計
この低レイヤの解析を理解すると、我々が設計すべき防御層のアーキテクチャが見えてくる。
- カーネル保護: ページテーブルの完全性を監視するHVCI（Hypervisor-Protected Code Integrity）の導入は必須だが、さらなる一歩として、カーネルモードのページテーブル変更を検知する専用のハイパーバイザ・モニタリングを設計すること。
- AIによる異常検知のガードレイル: 生成AIを攻撃の補助に用いる（プロンプトインジェクションによる悪意あるコード生成など）試みに対し、LLMの出力結果をサンドボックスで実行する際、ページテーブルのアクセスパターンを監視するエージェントを配置する。特定のメモリ領域への不自然なRWX権限の付与を、カーネル構造のレベルで即座に遮断するモデルが必要だ。
結論：技術の深淵を覗く者へ
インシデントハンドラーの役割は、OSが提供する抽象化レイヤの中で踊らされることではない。ページテーブルのビット一つひとつに隠された攻撃者の意図を読み解き、論理的な矛盾を見つけ出すことだ。
もし貴方が、画面に表示された「プロセス一覧」を見て満足しているなら、それはまだ調査の入り口にすら立っていない。メモリダンプのバイナリを直接見つめ、CR3からPTEに至る変換プロセスを脳内で再現できるようになって初めて、貴方は「最高峰の防衛者」として議論のテーブルに着く資格を得る。
次回の調査では、是非、標準ツールを閉じて、オフセットとビットマスクの海に飛び込んでみてほしい。そこには、攻撃者が必死に隠した「真実」が、無機質な16進数となって刻まれているはずだ。
コメント