こんにちは！デジタルフォレンジックの世界へようこそ。インシデントレスポンスの現場で日々、サイバー攻撃の痕跡を追いかけているセキュリティアナリストです。
今回は、少しドキッとするテーマ、「メモリダンプからの暗号鍵抽出：BitLockerおよびTLSセッションキーの復元」についてお話しします。「なんだか難しそう……」と思われるかもしれませんが、大丈夫です。一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう！
—
1. そもそも「メモリ（RAM）」ってどんな場所？（家の鍵の例え）
皆さんは、自宅の鍵をどこに置いていますか？普段はカバンの中やキーフックにしまっていますよね。では、家に出入りするときはどうでしょうか。鍵を鍵穴に挿して、ガチャっと回しますよね。この「鍵穴に鍵が挿さっている瞬間」や「玄関のテーブルの上に一時的に鍵を置いている状態」、これがパソコンでいうメモリ（RAM）の役割なんです。
パソコンのハードディスク（HDDやSSD）は、いわば「頑丈な金庫」です。中身を見られないようにカチッと暗号（BitLockerなど）をかけてしまえば、泥棒がやってきても簡単には開きません。
しかし、パソコンを使っている最中、CPUは計算をするために、金庫を開けるための「暗号の鍵」をメモ用紙に書いて、机の上（＝メモリ）に広げっぱなしにしています。なぜなら、わざわざ毎回金庫の奥底から鍵を探し出すのは時間がかかりすぎて、パソコンの動きがカクカクになってしまうからですね。
私たちフォレンジック調査員は、まさにこの「犯人がパソコンを使っている最中、あるいは直後」に、机の上（メモリ）に残されたメモ用紙（暗号鍵）をごっそりコピーし、金庫の鍵をこっそり手に入れるという調査を行うのです。
—
2. なぜメモリから鍵が見つかるのか？
「電源を切ったら、メモリの中身は消えるんじゃないの？」
その通りです。RAM（Random Access Memory）は「揮発性メモリ」と呼ばれ、電気をプツンと切ると、記憶がきれいさっぱり消え去る性質を持っています。まるで黒板に書いた文字が、消しゴムでサッと消えるようなものですね。
しかし、現場のインシデントレスポンスでは、次のような状況に直面します。
- 攻撃を受けてパニックになり、慌てて電源コードを引き抜いた（ダンプファイルが残るケース）
- Windowsの「休止状態（ハイバネーション）」機能が使われており、メモリの中身がそのままハードディスクの
hiberfil.sysというファイルに保存されていた - ライブフォレンジック（パソコンが動いている状態）で、メモリの複製ツールを実行してダンプを採取できた
特にWindowsの休止状態では、次にパソコンをすぐ起動できるように、電源を切る瞬間のメモリの中身が丸ごとストレージに書き出されます。ここに、BitLocker（ドライブ暗号化）のボリュームマスターキー（VMK）や、通信を守るためのTLSセッションキーが、そのままの形で眠っていることがあるのです。
—
3. 実践！メモリダンプからBitLockerの鍵を探す手順
それでは、実際にインシデントレスポンスの現場でどのように鍵を探すのか、その手順を覗いてみましょう。今回は、オープンソースの強力なメモリフォレンジックフレームワークである Volatility 3 を使ったアプローチを例に解説します。
実務でメモリ解析を行う際、まずはダンプファイル（例: memory.dmp や hiberfil.sys）のプロファイルや基本情報を確認します。
ステップ1: ボラティリティによるプロセスや情報の確認
まずは、メモリダンプファイルからOSのバージョンや基本構造を特定し、怪しい挙動をしていないかスキャンします。
# Volatility 3を使用してメモリダンプの基本情報を確認するコマンド例
python3 vol.py -f memory.dmp windows.infoステップ2: キーマテリアルのスキャン（BitLockerのケース）
BitLockerで保護されたボリュームの鍵（VMKなど）は、メモリ上の特定のパターン（プールタグなど）として存在しています。これを見つけるために、専用のプラグインやキーワードスキャンを行います。
現場では、以下のようにPythonスクリプトやツールを組み合わせて、AESの鍵構造（キーシグネチャ）をメモリ空間から総当たり、あるいはパターンマッチングで炙り出すことが多いです。
# 概念実証（PoC）としてのメモリ上から特定のバイト列（鍵の候補）をスキャンする簡易Pythonスクリプト例
import re
def search_potential_keys(dump_file_path):
# AES-128 / AES-256 の鍵らしい特徴的なパターンを正規表現やバイナリパターンで探索
# ※実際の現場ではVolatilityのプラグインや専用の解析スクリプトを使用します
print(f"[*] 対象のメモリダンプをスキャン中: {dump_file_path}")
# ダンプファイルをバイナリモードで読み込む
with open(dump_file_path, "rb") as f:
chunk_size = 1024 * 1024 # 1MBずつ読み込み
offset = 0
while True:
chunk = f.read(chunk_size)
if not chunk:
break
# ここにAESの鍵特有のヘッダー構造がないかをチェックするロジックが入ります
# 例として、特定のバイト列がヒットした仮の処理
if b"\x00\x01\x02\x03bitlocker_marker" in chunk:
print(f"[+] 潜在的な鍵の痕跡をオフセット周辺で発見しました！")
offset += len(chunk)
# 実行関数
if __name__ == "__main__":
# 実務ではここに取得したメモリダンプのパスを指定します
search_potential_keys("hiberfil.sys")このようにして抽出された鍵の候補（ボリュームマスターキー）を、別のツール（bdefs や専用の復元ユーティリティ）に食わせることで、暗号化されていたハードディスクのロックを解除し、中身のログやマルウェアのバイナリを丸裸にすることができるのです。
—
4. TLSセッションキーの復元：HTTPS通信の裏側を覗く
もう一つの重要なターゲットが、TLSセッションキーです。
「HTTPSを使っているから、通信は暗号化されていて安全だよね？」と思っていませんか？確かに通信経由で傍受（パケットキャプチャ）しても、暗号化されているため中身はメチャクチャな暗号文にしか見えません。
しかし、もし攻撃者が端末のメモリを読み取る権限（管理者権限や脆弱性）を奪っていたらどうなるでしょうか？
ブラウザ（ChromeやFirefoxなど）やサーバーアプリケーションが、通信の暗号化・復号を行うために使っている「共通鍵（セッションキー）」が、やはりメモリ上に存在しています。
これを抜き出すことができれば、過去にキャプチャした暗号化通信のパケット（.pcapファイル）と組み合わせて、「あとから通信の中身をすべて丸見えにする」ことが可能になります。
Wiresharkなどのパケット解析ツールには、こうした復元したセッションキー（SSLKEYLOGFILE 環境変数などから出力されたログ）を読み込ませる機能が備わっています。
# TLSセッションキーのログフォーマット例（このような形式のテキストがメモリ上やログファイルから復元されます）
CLIENT_RANDOM 7e5b2a... (中略) ... 3f8a1c...インシデントレスポンスの現場では、通信の不正な持ち出し（データExfiltration）が疑われる際、このTLSセッションキーを復元してパケットを復号し、「実際に彼らが何を送信したのか」を法的に証明可能な証拠として固めることがあります。
—
5. 私たちが取るべき「一歩進んだ対策」とは？
ここまで読んで、「メモリを見られたら、暗号化していても意味がないじゃないか！」と絶望されたかもしれません。でも、安心してください。攻撃者がメモリにアクセスするためには、「すでに端末の管理者権限を奪っている」か、「物理的にパソコンを触れる状態にある」という高いハードルを越えなければなりません。
現場のエンジニアや開発者として、私たちが今日から実践できる防御策をいくつか挙げておきます。
1. 休止状態（Hibernation）の適切な管理
ラップトップなどで機密情報を扱う場合、不要な休止状態ファイルを有効にしたまま放置しない、あるいはBitLockerと組み合わせてストレージ全体を強力に保護する。
2. メモリダンプやデバッグポートの保護
企業内の端末で、不要なカーネルメモリダンプの採取や、物理的なJTAG/FireWireなどの不正アクセス経路をポリシー（グループポリシー等）で無効化する。
3. 最小権限の原則（Principle of Least Privilege）の徹底
万が一、普段使いのアカウントがマルウェアに感染しても、メモリ上の重要な秘密（他のアプリの鍵など）に簡単にアクセスできないよう、アプリケーションごとに実行権限を分離する。
セキュリティは「完璧な防御」を目指すのではなく、「攻撃者のコストをどこまで引き上げるか」のゲームです。仕組みを正しく理解し、一つずつ堅牢なインフラを作っていきましょう！
それでは、また次回のフォレンジック解説でお会いしましょう。安全な開発・運用ライフを！
コメント