メモリフォレンジックの最前線：ファイルレス攻撃を「可視化」し、その息の根を止める技術
現場でインシデントレスポンスを担当していると、時折「ディスク上には何も落ちていないのに、バックドアが動き続けている」という悪夢のような事態に直面します。これが現代の攻撃者が愛用する「ファイルレスマルウェア」です。
彼らはOSの正当な機能（PowerShellやWMI、あるいは自作のシェルコード）を悪用し、実行コードを物理メモリ（RAM）上だけで展開・実行します。ディスクに痕跡を残さないため、従来のアンチウイルスソフトは軒並みスルー。しかし、メモリを直接覗き込めば、彼らの「残像」は必ず見つかります。
今日は、そんなメモリ上の幽霊をどうやって捕獲し、IDA Proで解析可能な形に引きずり出すか、そしてそれを未然に防ぐための防御策について解説します。
—
1. 攻撃者がメモリに潜む仕組み：VADを狙え
メモリフォレンジックの肝は、Windowsの「VAD (Virtual Address Descriptor)」ツリーにあります。プロセスがメモリを確保する際、OSは「どの範囲のメモリが、どのような属性（読み取り/書き込み/実行可能か）」で使われているかをVADという構造体で管理しています。
攻撃者は、VirtualAllocEx などのAPIを悪用して、「実行可能（PAGE_EXECUTE_READWRITE）」な領域をメモリ上に確保し、そこに暗号化されたペイロードを流し込みます。
メモリダンプからコードを抽出する手順
調査では Volatility 3 を使うのが業界標準です。
1. プロセス特定: windows.pslist で不審な挙動（親プロセスが不自然な powershell.exe など）を見つける。
2. VAD走査: windows.vaddump を使い、プロセスIDを指定して、特に「実行権限がある領域」を個別にダンプする。
3. PE再構築: ダンプしたバイナリは、そのままではIDA Proで読み込んでもセクションヘッダーが壊れていて解析できません。PE-bear などのツールを使い、セクションのオフセットを修正して「リベース」する必要があります。
—
2. ファイルレス攻撃を「完全に」防ぐための実装
ファイルレス攻撃は、突き詰めれば「メモリ上で本来許されない実行」が行われていることが原因です。これを防ぐための現代的な防御アプローチを共有します。
PHP/Webアプリ層での防御
Webアプリケーション経由のRCE（リモートコード実行）から始まる攻撃が多いため、まずは「OSコマンドの実行」を徹底的に制限します。
<?php
/**
* 安全でない関数（exec, shell_exec, system等）を無効化し、
* 必要最小限の操作のみを許可する設計にします。
*/
// 1. PHP設定で危険な関数を完全に殺す（php.ini）
// disable_functions = exec,shell_exec,system,passthru,proc_open,popen
// 2. どうしても外部コマンドが必要な場合は、ホワイトリストで厳格に管理する
function safe_execute($command, $args = []) {
$allowed_commands = ['/usr/bin/convert', '/usr/bin/zip']; // 許可されたバイナリのみ
if (!in_array($command, $allowed_commands)) {
throw new Exception("許可されていないコマンド実行の試行を検知しました。");
}
// 引数をシェルエスケープで無害化
$sanitized_args = array_map('escapeshellarg', $args);
$full_cmd = $command . ' ' . implode(' ', $sanitized_args);
// 実行（戻り値は必ず検証すること）
return shell_exec($full_cmd);
}
?>インフラ層（Nginx/WAF）での防御
攻撃者がペイロードを送り込む際の「怪しい文字列（Base64エンコードされたPowerShellコマンドなど）」をWAFで遮断します。
# Nginxの設定で、怪しいリクエストパラメータを拒否する
# 特にファイルレス攻撃で多用される「powershell」「-e」「hidden」等の文字列を監視
location / {
if ($query_string ~* "powershell|base64|bypass|-e\s+J") {
return 403; # 悪意あるペイロードの送信を即座に遮断
}
}IAM・クラウド側での防御
クラウド環境では、インスタンスのメタデータサービス（IMDS）へのアクセス制限が重要です。多くの攻撃者は侵害したインスタンスからIAMロールを奪取しようとします。
# AWSインスタンスでIMDSv2を強制し、SSRFによるロール奪取を防ぐ
resource "aws_instance" "web_server" {
metadata_options {
http_endpoint = "enabled"
http_tokens = "required" # IMDSv2を強制し、セッショントークンを必須化
http_put_response_hop_limit = 1
}
}—
現場のエンジニアへ伝えたいこと
メモリフォレンジックは、いわば「デジタルな解剖」です。しかし、どれほど高度な解析スキルを持っていても、それはあくまで「起きてしまった後の対処」に過ぎません。
僕がこれまで見てきた侵害案件の9割は、「OSの脆弱性放置」と「不用意なコマンド実行の許可」が原因です。
1. 「動けばいい」コードを書かない: exec() を使うときは、それが本当に必要なのか、他に安全なライブラリはないのかを自問自答してください。
2. 多層防御をサボらない: Webアプリの脆弱性は修正しても、OSの設定が甘ければ、攻撃者はそこから権限昇格を狙います。
3. ログを信じすぎない: ファイルレス攻撃者は、自身の痕跡を消すためにイベントログさえ改ざんします。だからこそ、メモリ上にしか存在しない「真実」を見抜く目を養ってください。
今日紹介した設定は、明日からすぐに反映できる「最低限の防御」です。これを実装していないサーバーがあれば、今すぐセキュリティチェックリストに追加してください。それが、あなたのシステムを「攻撃者にとってコストが見合わない場所」にする第一歩です。
コメント