【テクニカル・上級編】プロセス環境ブロック(PEB)の解析による隠蔽プロセスの特定 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

幽霊を暴く：PEB隠蔽を無効化するメモリフォレンジックの深淵

インシデントレスポンスの現場で、最も神経をすり減らすのは「見えているもの」ではなく「見えていないもの」だ。EDRのダッシュボードが平穏を装っているとき、攻撃者は既にカーネルの深淵で息を潜めている。

特に、高度なマルウェアやステートスポンサー系の脅威アクターは、EPROCESS構造体のActiveProcessLinks（二重連結リスト）を操作して、自身のプロセスをリストから切り離す。タスクマネージャーや一般的なフォレンジックツールが参照する「プロセスリスト」から自身の姿を消す、古典的だが極めて有効な手法だ。

今日は、表層的な解析では決して辿り着けない、PEB（Process Environment Block）の偽装と、それを物理メモリの断片から暴くためのアーキテクチャについて語ろう。

—

1. 攻撃者が狙う「リスト」の脆弱性

Windowsのプロセス管理は、EPROCESS構造体がカーネルメモリ内に鎖のようにつながっていることで成立している。攻撃者は、この鎖（ActiveProcessLinks）の前後を繋ぎ変えるだけで、OSのAPIがプロセスを見失うように仕向ける。

しかし、カーネルは「見ていない」かもしれないが、プロセッサは「実行」している。ここがDFIRの勝負所だ。

Direct Kernel Object Manipulation (DKOM): リンクを外す手法。
PEBの偽装: プロセスリストから消えても、PEB内には実行イメージのパスや環境変数が残る。攻撃者はPEB構造体そのものを改ざんし、親プロセスを偽装したり、パスを別のシステムプロセスにすり替えたりする。

2. 隠蔽プロセスを炙り出す「照合」のロジック

隠蔽されたプロセスを見つける唯一の解は、「リスト」を信じず、「カーネルが無視できない構造」を掘り起こすことだ。以下の3点をクロスチェックする。

1. スレッドリストの走査: EPROCESSがリンクから外れていても、プロセッサのコンテキストスイッチを維持するために、各プロセスのスレッドはカーネル内のスケジューラに登録され続けている。ETHREAD構造体をスキャンし、所属するプロセスID（PID）を逆引きする。
2. ハンドルテーブルの解析: すべてのプロセスは、何らかのリソース（ファイル、レジストリ、ミューテックス）にアクセスする。ハンドルテーブルをダンプし、存在しないはずのPIDが所有しているハンドルを特定する。
3. PTE（Page Table Entry）の解析: プロセスがメモリ上に存在しコードを実行している以上、必ず物理メモリ上にページテーブルが存在する。

実装のヒント：Volatility 3 によるメモリ解析コード

Volatility 3を利用して、pslist（ActiveProcessLinksベース）とpsscan（メモリ上の構造体スキャン）の結果を比較する手法が基本だが、カスタムプラグインを書くなら以下のようなロジックが必要になる。

# 概念実証: 隠蔽プロセス検出のためのスレッドベースの抽出ロジック
# Volatility 3 のシンボル空間を利用する前提

def find_hidden_processes(context, layer_name, symbol_table):
    # スケジューラ内のスレッドからPIDを抽出する関数の簡易実装
    thread_list = context.modules[layer_name].get_threads()
    
    seen_pids = set()
    for thread in thread_list:
        # スレッドの属するプロセスIDを取得
        pid = thread.get_process_id()
        if pid not in seen_pids:
            # ここで pslist に存在しない PID があれば、それは隠蔽の疑いがある
            yield pid
            seen_pids.add(pid)

# 実際の解析では、pslistの結果とこのPIDリストを突き合わせる
# 差分（ActiveProcessLinksにないがスレッドが存在するPID）を抽出する

—

3. 防御層の設計とアーキテクチャの未来

今後、耐量子暗号（PQC）への移行や、生成AIによる自動脅威分析が普及しても、この「メモリという物理的制約」は変わらない。我々が構築すべき防衛層には、以下の観点が不可欠だ。

ハードウェアベースの完全性検証

Intel VT-xやAMD-Vを利用した「ハイパーバイザ保護」が重要だ。カーネルメモリの特定の領域（EPROCESSのリスト操作など）に対して、ハイパーバイザレベルで書き込みアクセスを監視する（EPT: Extended Page Tablesを利用したガード）。

メモリの「不変性」を監視するアーキテクチャ

ガードレイルとしての監視システムは、単にログを拾うのではなく、カーネルの「セルフチェック」を定周期で実行するべきだ。

カーネル・インテグリティ・モニタリング: ActiveProcessLinksが整合性を保っているかを、ローカルCPUの特権レベルで常に検証する。
エントロピー監視: メモリ内の実行可能領域に注入されるコードの、静的エントロピーを監視し、PEB改ざんを伴うコードインジェクションの兆候をAIが検知する。

—

結びに：泥臭い解析こそが最強の防壁

洗練されたGUIツールがどれだけ進化しようとも、最終的に幽霊を追い出すのは、メモリの断片を凝視する人間の目だ。

攻撃者は「OSの仕様」を突いて隠れる。我々は「物理的なメモリの挙動」というOSの裏側を覗き込むことで、それを無力化する。プロンプトインジェクションへのガードレイルも、メモリフォレンジックも、本質は同じだ。「システムが想定する『真実』と、実際にメモリ上で起きている『事実』の乖離をどこまで突き止められるか」。

この視点を忘れない限り、君たちはどのような隠蔽工作も暴くことができるはずだ。現場の泥を恐れるな。メモリダンプの奥底には、必ず攻撃者の足跡が残っている。