仮想マシンは「情報の宝庫」：vmemファイルが暴く侵入者の正体
インシデントレスポンスの現場において、多くのエンジニアが「ログ」の解析だけに終始して失敗します。しかし、攻撃者がメモリ上で実行するファイルレスマルウェアや、難読化されたPowerShellスクリプトは、ログには残らず「メモリ」の中にだけ存在しているのです。
特に仮想化基盤（VMwareやHyper-V）を採用している環境では、我々ディフェンダーにとっての「最強の武器」が存在します。それが、ゲストOSのメモリ状態をまるごと切り取った vmem（VMware）や bin（Hyper-V）ファイルです。
今日は、攻撃者がなぜメモリを狙うのか、そして我々がその痕跡をいかにして「狩る」のか、その実務的な勘所を解説します。
—
1. 攻撃者がメモリを悪用する理由（PoC的視点）
攻撃者が標的とするのは「ディスク上のファイル」だけではありません。近年の攻撃者は、メモリ上で直接コードを実行する「インメモリ実行」を好みます。
例えば、Webアプリの脆弱性（RCE等）を突いた後、攻撃者は以下のような手法をとります。
- 反射型DLL注入: 悪意のあるDLLをディスクに書き出さず、メモリ空間に直接マップして実行する。
- ファイルレス・ペイロード:
PowerShell.exe -EncodedCommandを使用し、難読化されたコードをメモリ上で展開する。
これらは、OSが再起動すれば消えます。だからこそ、我々は「侵入直後のスナップショット」を確保する必要があるのです。
—
2. 現場で使える「vmem」解析の最短ルート
VMware環境で調査を行う際、vmss（サスペンド状態）や vmsn（スナップショット）ファイルから vmem を取り出すことは必須スキルです。
解析のステップ
1. 静的確保: 侵害が疑われるVMのスナップショットを取得し、データストアから vmem と vmsn ファイルを物理的にコピーする。
2. 変換: Volatility などのツールで解析できるよう、.vmem をRAW形式へ変換します。
3. プロファイリング: Volatility 3 を使い、メモリ内のプロセスツリーを紐解きます。
# Volatility 3を使用したメモリ内のプロセスリスト出力の例
# -f で抽出したRAWファイルを指定、windows.pslistでプロセスを表示
python3 vol.py -f memory_dump.raw windows.pslistここで powershell.exe や wmic.exe が不自然な親プロセス（例: w3wp.exe や php-fpm）から起動していれば、それが「答え」です。
—
3. インメモリ攻撃を「物理的」に封じ込める実装
メモリ解析で事後対応するのも重要ですが、そもそも「メモリへのコード展開」を難しくする設定が、真のエンジニアの仕事です。以下の対策を環境に適用してください。
① Webサーバ（Nginx）での不正実行防止
WAFやNginxの設定で、Webディレクトリ内での実行権限を徹底的に削ります。攻撃者がメモリ展開用のシェルをアップロードしても、実行できないようにします。
# Nginxの設定: 特定のディレクトリでのスクリプト実行を禁止
location /uploads/ {
# PHPなどの実行を無効化
location ~ \.php$ {
deny all;
}
# 実行権限の排除
add_header X-Content-Type-Options "nosniff";
}② PHPでのメモリ実行を未然に防ぐ防御コード
eval() や assert() は攻撃者の大好物です。これらを監視・制限する設計を心がけてください。
<?php
// 不正な関数呼び出しを検知するラッパー（運用環境での検証用）
function secure_exec($cmd) {
$forbidden = ['eval', 'assert', 'system', 'passthru'];
foreach ($forbidden as $func) {
if (strpos($cmd, $func) !== false) {
// セキュリティログへ記録し、即座に遮断する
error_log("SECURITY ALERT: Attempted to use dangerous function: " . $func);
die("Security Violation");
}
}
return shell_exec($cmd);
}
?>③ クラウドIAM・権限最小化
多くの場合、攻撃者はメモリ上で実行したコードから「メタデータサービス」を叩き、IAMロールを奪取しようとします。これを防ぐには、EC2等のインスタンスメタデータへのアクセスを制限するのが定石です。
IMDSv2（インスタンスメタデータサービス v2）の強制設定:
# AWS CLIを使用して、IMDSv2を必須化（セッションベースの認証を強制）
aws ec2 modify-instance-metadata-options \
--instance-id i-xxxxxxxxxxxxxxxxx \
--http-tokens required \
--http-put-response-hop-limit 1 \
--http-endpoint enabled—
最後に：フォレンジックは「準備」で勝敗が決まる
インシデントが発生した瞬間に「どうやってメモリを吸い出そうか」と調べているようでは遅すぎます。
- 定期的にVMスナップショットの取得プロセスを自動化しているか？
- ログ収集基盤（SIEM等）に
w3wp.exeが子プロセスを起動した際のアラートを仕込んでいるか？
メモリフォレンジックは、攻撃者の「息遣い」を直接捕まえる唯一の手法です。技術を磨くことは、会社とユーザーを守るための「盾」を強固にすることと同義です。
次にまた侵害の予兆を感じたら、まずはログを眺める前に、そのVMの vmem を確保することから始めてみてください。そこには、まだあなたが知らない「攻撃者の痕跡」が眠っているはずです。
コメント