【実務・中級編】メモリフォレンジックにおけるカスタムプラグイン開発の基礎 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

メモリフォレンジックの深淵へ：既存プラグインで満足しているなら、もう手遅れかもしれない。

現場でインシデント対応をしていると、「既知のツールを回せば解決する」という幻想を抱いている担当者によく出会う。だが、現実は甘くない。最新の標的型攻撃や、ファイルレスマルウェアは、EDRの検知を巧妙に回避し、メモリ空間の「隙間」で息をしている。

Volatility 3のような強力なフレームワークも、結局は「何を探すべきか」を教えなければ、ただのメモリダンプビューアに過ぎない。今回は、現場で戦うエンジニアのために、特定の攻撃プロセスを突き止めるための「カスタムプラグイン開発」の勘所を伝授する。

—

なぜカスタムプラグインが必要なのか？

メモリフォレンジックの真髄は、OSが提供するAPIすらもフックするようなルートキットや、特定の環境変数を悪用してメモリ上にのみ滞留するペイロードを炙り出すことにある。

既存の windows.pslist や windows.netscan だけでは、プロセスが隠蔽されていたり、通信先がメモリ上の動的パッチで隠されている場合、太刀打ちできない。特定の攻撃者の「癖」や「痕跡」を追いかけるためのカスタムプラグインを書くことは、守備側が攻撃者の背後に回り込むための唯一の手段だ。

—

Volatility 3におけるプラグイン開発の基本構造

Volatility 3はPython 3で構築されている。プラグイン開発の基本は、renderers と interfaces を適切に継承することだ。

以下は、特定の文字列がメモリ上のプロセスに含まれているかを簡易的に検索するプラグインのプロトタイプだ。

# 脆弱なプロセスを特定するためのカスタムプラグイン骨子
from volatility3.framework import renderers
from volatility3.framework import interfaces
from volatility3.plugins.windows import pslist

class FindSuspiciousProcess(interfaces.plugins.PluginInterface):
    """メモリダンプから特定の疑わしいシグネチャを探す"""
    
    def run(self):
        # プロセスリストを取得
        processes = pslist.PsList.list_processes(self.context, self.config['layer'], self.config['symbol_table'])
        
        # 検出したい攻撃者の痕跡 (例: 特定のメモリ領域のシグネチャ)
        target_pattern = b"\x4D\x5A\x90\x00\x03" # MZヘッダの断片など
        
        results = []
        for proc in processes:
            # プロセスの仮想メモリ空間をスキャン
            # 実際にはここで proc.read() を使用してメモリを読み出す
            # 非常に重い処理になるため、特定セクションに絞るのがコツだ
            results.append((proc.pid, proc.name))
            
        return renderers.TreeGrid([("PID", int), ("Name", str)], results)

開発のコツ：

1. 対象を絞れ: 全メモリをスキャンするのは自殺行為だ。VAD (Virtual Address Descriptor) を解析し、実行権限（PAGE_EXECUTE_READWRITE）がある領域だけをターゲットにするのが、現場で生き残るための鉄則である。
2. インデックスを活用せよ: 文字列検索は、物理アドレスを追跡する前にシンボル情報を活用して特定のプロセス構造体へ直行させろ。

—

攻撃手法の盲点：ファイルレス実行をどう防ぐか

メモリフォレンジックで「後の祭り」にならないために、開発者やインフラエンジニアが今すぐやるべきは、「メモリに実行可能コードを置かせない」ための設計だ。

多くの攻撃者は、PHP の eval() や JavaScript の eval() を使い、メモリ上で動的にシェルコードを生成・実行する。これを防ぐには、そもそも入力を直接実行させない、あるいはWAFで防御するしかない。

PHPでのセキュアな実装（危険な関数を封じる）

<?php
// 危険な関数の実行を厳格に制限する
// そもそも eval や system は絶対に使わないのが大原則
function executeCommand($input) {
    // ホワイトリスト形式でバリデーション
    $allowed_commands = ['ls', 'whoami'];
    
    if (!in_array($input, $allowed_commands)) {
        // ログを残して即座に終了する
        error_log("不正なコマンド実行の試行: " . $input);
        die("Security Violation");
    }
    
    // shell_exec は危険なので使わないのがベストだが、使うなら厳密にエスケープする
    return shell_exec(escapeshellarg($input));
}
?>

Nginx/WAFでの防御設定（攻撃の入り口を塞ぐ）

メモリ上に悪意あるペイロードを送り込むための「初期侵入」を防ぐ設定だ。

# /etc/nginx/conf.d/security.conf
# ファイルアップロード後の実行を禁止する
location /uploads/ {
    # PHPなどのスクリプト実行を無効化
    location ~ \.php$ {
        deny all;
    }
}

# 疑わしい文字列のブロック（WAFでの設定例）
# SQLiやインジェクションのシグネチャを拒否
if ($query_string ~* "eval\(|base64_decode|cmd\.exe") {
    return 403;
}

—

最後に：フォレンジックは「日常」に宿る

メモリフォレンジックは、事件が起きてから慌ててやるものではない。普段から自分たちのシステムの「正常なメモリの状態」を理解しているエンジニアだけが、異常を即座に検知できる。

カスタムプラグインを書くことは、自分のアプリケーションがどのようなメモリの使い方をしているかを理解する最高の学習プロセスだ。もし君たちが開発者なら、まずは自分の書いたコードがメモリ上でどう動いているか、ダンプをとって眺めてみてほしい。そこには、教科書には載っていない「システムの真実」が隠れているはずだ。

インシデントレスポンスは、準備した者が勝つ。この戦場では、コードこそが最強の盾であり、剣になる。頑張れ。