こんにちは！SOC（セキュリティ・オペレーション・センター）で日々、怪しい通信やサイバー攻撃の痕跡と格闘しているアナリストです。
インシデントレスポンスの現場にいると、「うわっ、完全に通信が暗号化されていて中身が見えない……！」という壁にぶつかることがよくあります。最近のウェブやC2（コマンド＆コントロール）通信は、ほぼすべてがTLS（HTTPS）で暗号化されていますよね。泥棒が金庫に鍵をかけて中身を隠しているようなものです。
でも、安心してください。私たちフォレンジック調査員には、「犯人がこっそり残していった合鍵（セッションキー）」をメモリから見つけ出し、暗号化された通信を丸裸にするという強力な技があります。
今回は、PCAP（パケットキャプチャ）データとメモリダンプを組み合わせて、TLSハンドシェイクの裏側を暴く手法を、身近な例えを交えながら優しく紐解いていきましょう！一歩ずつ対策を学んでいきましょうね。
—
1. 泥棒の金庫と「合鍵（セッションキー）」の仕組み
まず、私たちが普段使っているHTTPS通信が、現実世界でどのように守られているのかイメージしてみましょう。
あなたが自宅の玄関に、頑丈な「特殊な鍵」をかけているとします。これがTLS暗号化です。郵便屋さん（ルーターやプロバイダ）がやってきても、鍵が閉まっているので中の荷物は絶対に見えません。安全ですよね。
通信が始まるとき、あなたのパソコンとサーバーの間で「今回の通信だけで使う特別な合鍵」をこっそり作ります。これが「セッションキー」です。通信が終われば、この鍵はポイッと捨てられる仕組みになっています。
インシデント発生！ 鍵はどこにある？
さて、ここで問題発生です。マルウェアに感染した端末から、怪しい外部サーバーへ暗号化された通信（HTTPS）が飛び交っているログ（PCAP）を手に入れました。
「通信の中身を見たい！ パスワードやC2からの指示コマンドが書かれているはずだ！」と思っても、パケットの中身は暗号化の暗号でグチャグチャです。
ここで諦めてはいけません。通信に使われた「合鍵（セッションキー）」は、その瞬間、パソコンのメモリ（RAM）上にちゃっかり存在しています。犯人が通信を終えて鍵を捨てる前に、パソコンの脳みそ（メモリ）をまるごと保存（メモリダンプ）しておけば、その中から合鍵をゲットできるのです！
—
2. メモリから SSLKEYLOGFILE を見つけ出す
では、実際にどうやって合鍵を見つけるのでしょうか。
実は、ブラウザや一部のアプリケーションには、デバッグや開発の目的で「今どんな合鍵を使って通信しているか」をテキストファイルに書き出す機能があります。これが環境変数 SSLKEYLOGFILE です。
攻撃者が利用したマルウェアや、あるいは調査のために私たちが仕込んだ環境では、このセッションキーの履歴がメモリ上に残ることがあります。
メモリダンプ（例: memdump.raw）からこのキーの痕跡を探すには、Pythonのオープンソースツールである Volatility や、テキスト抽出の定番コマンドである strings を組み合わせます。
実際のターミナル（Linux環境など）での作業を覗いてみましょう。
# メモリダンプファイルから、TLSのセッションキーが始まりそうな文字列（CLIENT_RANDOMなど）を抽出する
strings memdump.raw | grep "CLIENT_RANDOM" > extracted_keys.txt
# 抽出されたファイルの中身を確認する
head -n 5 extracted_keys.txtこの extracted_keys.txt の中身は、以下のようなフォーマットになっています。
# これがTLS通信の合鍵（セッションキー）のリストです
CLIENT_RANDOM 5d41402abc... (中略) ... 7c56b1032d
CLIENT_RANDOM 3a285d7bcd... (中略) ... 9f41a021c3「おっ、これこそが、あの通信の合鍵だ！」と分かれば、大成功です。
—
3. Wiresharkに合鍵を読ませて、暗号化通信を丸裸にする
合鍵が手に入ったら、次はパケットキャプチャファイル（.pcap や .pcapng）の出番です。みんな大好き、ネットワーク分析の王様 Wireshark を使います。
通常のWiresharkでは、HTTPSの通信を見ても Encrypted Handshake Message と表示されるだけで、中身は真っ暗闇です。でも、先ほど抽出した合鍵ファイル（extracted_keys.txt）を読み込ませることで、Wiresharkが魔法のように復号してくれます。
Wiresharkでの設定手順
1. Wiresharkで対象の pcap ファイルを開きます。
2. 上部メニューの [編集 (Edit)] ＞ [設定 (Preferences)] を開きます。
3. 左側のツリーから [Protocols] ＞ [TLS] を選択します。
4. [(Pre)-Master-Secret log filename] の項目で、先ほど抽出した extracted_keys.txt を指定します。
5. [OK] をクリックします。
たったこれだけの設定で、パケット一覧画面の表示が一変します。これまで「TLS」としか見えなかった通信が、HTTPやJSON、あるいは怪しい独自のコマンドのやり取りとして、生データ（Plaintext）で読めるようになるのです！
—
4. 現場のアナリストが直面する「リアルな落とし穴」
教科書通りにいけばこれで一件落着……と言いたいところですが、実際のインシデント現場はもう少し泥臭いです。ここで、私たちがよくハマる「落とし穴」をいくつか共有しておきますね。
- メモリの取得タイミングが遅すぎた
マルウェアがすでに終了していたり、端末が再起動されていたりすると、メモリ上のセッションキーはきれいに消え去っています。ライブレスポンス（端末が起動している状態での証拠保全）のスピードが命になります。
- Perfect Forward Secrecy (PFS) の壁
現代のWeb通信の多くはPFS（完全前方秘匿性）をサポートしています。これは「過去のセッションキーが万が一バレても、過去の通信全体は復号できない」ように毎回鍵を使い捨てる仕組みです。この場合、単純な CLIENT_RANDOM だけでは過去のすべての通信が復号できないケースもあり、調査員を悩ませます。
—
一歩ずつ対策を学んでいきましょう！
今回は、メモリフォレンジックとパケット解析を組み合わせた「TLS復号」の世界をご紹介しました。
「暗号化されているから安全」「HTTPSだから中身は見えないはず」というのは、あくまで正常なセキュリティの前提です。しかし、インシデントレスポンスの現場では、「エンドポイント（メモリ）」と「ネットワーク（PCAP）」のピースを組み合わせることで、隠された真実を暴くことができるという強力なアプローチが存在します。
最初は難しく感じるかもしれませんが、手を動かしてパケットが復号された瞬間は、セキュリティアナリストにとって最高の瞬間でもあります。
日々の運用や学習の中で、少しずつ知識を深め、組織の安全を守るスキルを磨いていきましょう！それでは、また次の調査現場でお会いしましょう。
コメント