おい、そこ。今、デスクトップの端っこでコーヒーをすくいながら「うちのEDRは全台導入済みだからファイルレス攻撃なんて対岸の火事だ」なんて思っていないか？
甘い。現場の最前線をなめてもらっては困る。
私たちが日々アサインされるインシデントレスポンスの現場では、ディスクのタイムラインを綺麗に整え、MFTを舐め回すように解析しても、肝心の悪性バイナリなど一向に見つからないケースがざらにある。そこにあるのは、痕跡を綺麗に消し去った「ファイルレスマルウェア」の爪痕、すなわち揮発性メモリ（RAM）の中にしか実体を残さない亡霊だ。
今日は、攻撃者がどのようにディスクをバイパスしてメモリ上でコードを暴れさせ、私たちDFIRアナリストがそれをどうやって物理メモリ（RAM）のダンプから引きずり出し、復元するのか。その泥臭くてエキサイティングな裏側のロジックを、実務に直結するコードとともにお前の脳みそに叩き込んでやろう。
—
1. なぜ「ファイルレス」は私たちの目を眩ませるのか？
従来のマルウェア対策は、ディスク上に生成された .exe や .dll のハッシュ値を計算し、シグネチャと突合させることで検知していた。セキュリティ製品のベンダーも、「怪しいファイルを隔離しました」というアラートでユーザーを安心させるのが得意だ。
だが、プロの侵入者や高度な脅威グループ（APT）は、もはやディスクにファーストバイトを書かない。彼らが使うのは、主に以下の2つの手口だ。
- Reflective DLL Injection（リフレクティブDLLインジェクション）
自らをメモリ上にロードするための独自のローダーを備えたDLLを、標的プロセス（explorer.exe や svchost.exe など）の仮想アドレス空間に直接書き込み、通常の LoadLibrary APIをバイパスしてエントリポイントを無理やりキックする手法。
- Process Hollowing（プロセスのハローイング）
正当なプロセス（例えば notepad.exe や svchost.exe）をサスペンド状態で起動し、そのプロセスが持っている正当なコード領域（ImageBase）を綺麗にくり抜いて（Hollow）、そこに悪意あるペイロードを流し込み、サスペンドを解除して実行させる手法。
ディスク上には「正常なファイル」しか存在しないか、あるいはそもそも痕跡がない。EDRのログをいくら眺めても、親プロセスから正当なプログラムが起動しているようにしか見えない。ここに、夜も眠れなくなるようなインシデントの罠がある。
—
2. メモリダンプからの「亡霊の抽出」：DFIRの現場アプローチ
では、この目に見えない脅威をどうやって暴くのか。答えはシンプルだ。「CPUが実行しているその瞬間、RAMは嘘をつかない」。
私たちはインシデント発生時、対象マシンの物理メモリを丸ごとダンプ（LiME, FTK Imager, あるいはクラウド環境なら DumpIt や仮想マシンのスナップショット）し、Volatility 3などのフォレンジックフレームワークを使って解析する。
現場でよく使うコマンドの流れを思い出してほしい。
# プロセスリストを走査し、不審な挙動（親プロセスとパスの不一致など）を探す
python3 vol.py -f mem_dump.raw windows.pslist.PsList
# プロセスのアドレス空間からVAD（Virtual Address Descriptor）を抽出し、
# 保護属性が PAGE_EXECUTE_READWRITE (PAGE_EXECUTE_READ) でありながら、
# ディスク上のファイルにマッピングされていない（MM_VADのFileObjectがNULL）領域を探す
python3 vol.py -f mem_dump.raw windows.vadinfo.VadInfo --pid <不審なPID>こうした調査の過程で、「おや？」と思う仮想メモリ領域にブチ当たる。ディスク上のファイルパスが紐づいていないにもかかわらず、その領域のメモリ保護フラグが実行可能（RX または RWX）になっている領域だ。そここそが、ファイルレスマルウェアの心臓部、インメモリで蠢くリフレクティブDLLやシェルコードが潜む巣窟に他ならない。
—
3. 【実践】メモリダンプから不審なコード領域を切り出すPythonスクリプト
現場では専用のフォレンジックツールを使うが、裏側のメカニズムを理解するために、メモリダンプファイルから指定したプロセスのアドレス空間の特定領域（スライス）をプログラム的に抽出し、解析用のファイルとして切り出すPythonの自動化スクリプトのサンプルを提示しよう。
実務のオートメーションや、カスタムのトリアージツールを作る際のベースとしてそのまま活用してくれ。
import os
import sys
def extract_memory_region(dump_path, output_path, start_offset, size):
"""
物理メモリダンプ（RAWイメージ）の指定されたオフセットから、
インメモリで実行されているペイロードの領域を抽出し、ファイルとして保存する。
:param dump_path: 取得したメモリダンプのファイルパス
:param output_path: 抽出したバイナリの出力先パス
:param start_offset: 抽出を開始する物理/仮想オフセット（VAD解析等で特定した値）
:param size: 抽出するバイトサイズ
"""
print(f"[*] メモリ抽出を開始します: オフセット 0x{start_offset:x}, サイズ {size} バイト")
if not os.path.exists(dump_path):
print(f"[!] エラー: メモリダンプが見つかりません -> {dump_path}", file=sys.stderr)
return False
try:
# メモリダンプをバイナリ読み込みモードで開く
with open(dump_path, 'rb') as dump_file:
# 指定されたオフセットまでシーク
dump_file.seek(start_offset)
# 指定サイズ分のペイロードを読み込む
payload_data = dump_file.read(size)
if len(payload_data) < size:
print(f"[!] 警告: 要求されたサイズ（{size}バイト）に満たないデータしか読み込めませんでした（実際: {len(payload_data)}バイト）。", file=sys.stderr)
# 抽出したバイナリをファイルに書き出す（静的解析・リバースエンジニアリング用）
with open(output_path, 'wb') as out_file:
out_file.write(payload_data)
print([+] 正常にペイロードを抽出しました: {output_path}")
return True
except Exception as e:
print(f"[!] 予期せぬエラーが発生しました: {e}", file=sys.stderr)
return False
if __name__ == "__main__":
# 【実務上の使用例】
# Volatility等で特定した不審なVAD領域のオフセットとサイズをここに代入する
# 例: 仮想アドレス 0x7ffd90000000 が物理オフセット 0x1a2b3c400 に対応すると仮定
DUMP_FILE = "./evidence/incident_ram_dump.raw"
OUTPUT_PAYLOAD = "./extracted_artifacts/injected_payload.bin"
# 調査によって特定されたオフセットとダンプサイズ（例として4KBを指定）
TARGET_OFFSET = 0x1A2B3C400
TARGET_SIZE = 4096
extract_memory_region(DUMP_FILE, OUTPUT_PAYLOAD, TARGET_OFFSET, TARGET_SIZE)このスクリプトによって抽出された injected_payload.bin を、今度は Ghidra や IDA Pro などのリバースエンジニアリングツールに投げ込み、エントリポイントのプレリュード（PUSH EBP や MOV RBP, RSP など）を解析することで、彼らが何を企んでいたのか（C2サーバーへの通信、クレデンシャルのダンプ、横展開など）の全貌を暴くのだ。
—
4. 完全に防御するための設計ルール：インメモリ攻撃を許さないインフラストラクチャ
インシデントレスポンスで証拠を掴むのはアナリストの醍醐味だが、プロのセキュリティエンジニアの真価は「そもそもそんな手間のかかるフォレンジックをさせない堅牢な環境」を作ることにある。
ファイルレスマルウェアやリフレクティブインジェクションを根絶するためには、OSの深層防御（Defense-in-Depth）とハードニングが不可欠だ。
① WAF・Webアプリケーション層でのインジェクション予防
ファイルレス攻撃の多くは、Webアプリケーションの脆弱性（RCEやデシリアライゼーションの不備）を踏み台にして初期侵入が行われる。例えば、PHPなどの動的言語環境やバックエンドAPIへのペイロード投入を防ぐため、NGINXとWAFのレイヤーで不審なプロセス起動コマンドや難読化されたスクリプトのインジェクションをブロックする設定を施せ。
以下は、リバースプロキシ（Nginx）における基本的なセキュリティヘッダーおよびリクエスト制限のセキュアな設定例だ。
# /etc/nginx/conf.d/security_headers.conf
# セキュリティヘッダーと不審なリクエストの遮断設定
server {
listen 443 ssl;
server_name api.internal.corp;
# SSL/TLSのハードニング
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
# クライアントからのリクエストボディサイズを厳格に制限（メモリ枯渇やバッファオーバーフロー対策）
client_body_buffer_size 16k;
client_max_body_size 2m;
# 不審な文字列（システムコマンドの断片や難読化されたスクリプトの痕跡）を含むリクエストの拒否
# ※実際の環境ではModSecurityなどのWAFと併用して正規表現チューニングを行ってください
if ($query_string ~* "(base64_decode|eval\(|system\(|exec\(|passthru|shell_exec)") {
return 403;
}
location /api/v1/ {
# 内部APIへの不正なHTTPメソッドの制限
limit_except GET POST {
deny all;
}
# セキュリティヘッダーの強制
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Content-Security-Policy "default-src 'self'" always;
try_files $uri $uri/ =404;
}
}② OS・エンドポイント層でのW^X（Write XOR Execute）の徹底とASLR
OSレベルでは、メモリ上のデータ領域からのコード実行を防ぐ仕組みが命綱になる。
Linuxであれば PaX/Grsecurity やモダンカーネルの NX（No-Execute）bit、Windowsであれば DEP（Data Execution Prevention） および ASLR（Address Space Layout Randomization） が完全に有効化されていることを確認しろ。
特に、プロセスがメモリを確保する際に RWX（読み取り・書き込み・実行が同時に許可された危険な領域）をアロケートする挙動自体を監視・ブロックするEDRのポリシー（Attack Surface Reduction: ASR ルールなど）を必ず適用すること。攻撃者が VirtualAlloc や VirtualProtect を使ってメモリの保護属性を PAGE_EXECUTE_READWRITE に変更しようとした瞬間、カーネルレベルでそのプロセスを即座に強制終了（Terminate）させる設定が、現代のインフラにおける最低限の防衛ラインだ。
—
5. チーフからの最後のメッセージ
メモリフォレンジックの世界は奥が深い。ディスクを見ているだけでは気づけないサイバー攻撃の「生きた悪意」が、揮発性のRAMの海にはダイレクトに息づいている。
だが、どれほど巧妙にファイルを隠そうとも、コードがCPUで実行される以上、メモリのどこかに足跡を残さざるを得ないのがコンピュータの物理的な宿命だ。その足跡を正確に見つけ出し、ダンプからコードを復元し、逆解析して脅威の正体を暴く――これこそが、私たちDFIRエンジニアのロマンであり、誇りである。
後輩諸君、ツールに依存するな。挙動の原理を理解し、コードの裏側にあるOSの挙動を想像しろ。お前のその手で、組織のインフラを鉄壁のものに守り抜けよ。以上だ、席に戻って仕事を続けろ。
コメント