メモリの深淵を覗く：VADツリーから暴くインジェクションの「死角」
インシデントレスポンスの現場で最も不毛な時間は、侵害の予兆をSIEMのログだけで追おうとする時だ。攻撃者はとっくにディスクレスで動いている。VirtualAllocExやWriteProcessMemoryを駆使したインジェクションは、今やマルウェアの「挨拶」に過ぎない。
彼らがどんなに巧妙にAPIをフックしようとも、OSのカーネルが管理するメモリ構造――特にVAD (Virtual Address Descriptor) ツリー――まで偽装することは極めて困難だ。今回は、メモリフォレンジックの最前線から、インジェクションの痕跡を物理的に特定する技術的アプローチを掘り下げる。
1. なぜ「VADツリー」が最後の砦なのか
Windowsにおいて各プロセスはVADツリーを保持している。これは、プロセスが割り当てた仮想メモリ領域の範囲や属性（読み取り専用、書き込み実行可能など）を管理する基幹データ構造だ。
攻撃者が Reflective DLL Loading を行う際、標的プロセスのメモリ空間に不正なコードを書き込む。このとき、メモリページは通常 PAGE_EXECUTE_READWRITE (RWX) として割り当てられる。これが最初の「綻び」だ。正当なDLLはディスク上のファイルとマッピングされているが、インジェクションされたコードはファイルと紐づかない「Private Memory」としてVAD上に浮き上がる。
2. インジェクション特定のためのディープ・スキャンロジック
Volatility Frameworkを活用し、単なるリストアップではなく、VADの異常値を抽出するスクリプトの一例を提示する。以下は、保護属性とマッピング状態の不整合を叩き出すためのロジックだ。
# Volatility 3を使用したVAD異常抽出の概念コード
# 目的: ファイルと紐づいていないにも関わらず、実行権限を持つ領域を特定する
import volatility.framework.interfaces as interfaces
from volatility.plugins.windows import vadinfo
def detect_suspicious_vad(proc):
# プロセスの全VADエントリを走査
for vad in proc.get_vad_root():
# 保護属性がPAGE_EXECUTE_READWRITEであるか
if vad.get_protection() == "PAGE_EXECUTE_READWRITE":
# ファイルマッピングがない、かつプライベートメモリであるかを検証
if not vad.get_file_name():
print(f"[!] 警告: 不審なRWX領域を検出: {hex(vad.get_start())}")
# ここで領域の先頭数バイトをダンプしてPEヘッダーを確認する処理へ繋ぐ
dump_memory_region(vad.get_start(), 0x1000)
# 日本語コメント: インジェクションされたコードの多くは、
# メモリ確保直後にMZヘッダー（'MZ'）が先頭に現れるため、
# 該当アドレスのダンプとシグネチャ照合が次のステップとなる。3. 攻撃者の盲点：メモリの「非対称性」を突く
攻撃者が VirtualProtect を使って実行後に RWX から RX に属性を変更したとしても、VADツリーには依然として「ファイルと紐づいていない実行可能領域」という不自然なエントリが残る。
ここが防衛側としての腕の見せ所だ。私たちは以下の3点を複合的に監査しなければならない。
- VADの保護属性遷移: 過去に
RWXだった形跡がVADのフラグ管理に残っていないか。 - バックエンドの不在:
vad.get_file_name()がNoneであるにもかかわらず、そのメモリ領域にIMAGE_DOS_HEADER構造体が存在するか。 - スレッド開始アドレスとの乖離:
CreateRemoteThreadで呼び出された先が、VADツリー上のどのセクションにも属さない、あるいはPrivate領域を指していないか。
4. アーキテクチャ上のガードレイル：耐量子・耐メモリ改ざんへ
今後、インジェクション手法はさらに巧妙化し、AIを利用した動的なコード難読化や、カーネルレベルでのVAD偽装（DKOM：Direct Kernel Object Manipulation）へと進化するだろう。
これに対する我々の次世代防御アーキテクチャの指針は以下の通りだ。
1. EDRにおけるメモリインテグリティの強制: CFG (Control Flow Guard) や CET (Control-flow Enforcement Technology) をハードウェアレベルで有効化し、インジェクション時の不正なジャンプ先を即座に遮断する。
2. メモリ・フォレンジックの自動化: 定期的にプロセスのVADツリーをハッシュ化し、ベースラインとの差分を監視する（FIMのメモリ版）。
3. ガードレイルの適用: LLMを用いたプロンプトインジェクション防御と同様に、APIコールの「コンテキスト」を評価する。例えば、WriteProcessMemory が呼び出された際、呼び出し元のスレッドが署名済みバイナリか、あるいは過去に不審なネットワーク通信を行っていないかを動的に判定する。
最後に：フォレンジックは「物語」を紡ぐことだ
メモリ上のインジェクションを追うことは、消えゆく電位の痕跡から攻撃者の意図を再構成する作業だ。ログの文字列を追うだけでは、彼らの「息遣い」は聞こえてこない。
カーネル構造の深淵を見つめ、不自然なデータ構造の揺らぎに気づくこと。それこそが、高度な侵害を食い止める唯一の、そして最も泥臭い「チーフホワイトハッカー」の矜持である。
技術は常に攻撃者の方が半歩先を行く。だが、OSという巨大なシステムが持つ「物理的な制約」までを覆すことは、彼らにとっても容易ではない。その半歩を埋めるのが、我々DFIRスペシャリストの役割だ。
コメント