メモリの残滓を読み解く：C2通信の痕跡を「クローズされたSocket」から復元する深淵
インシデントレスポンスの現場において、多くのエンジニアが陥る罠がある。それは「netstat や ss コマンドで現在アクティブな接続だけを見て安心してしまうこと」だ。だが、腕利きの攻撃者は、ペイロードの実行後に即座にコネクションを遮断し、自身の存在をメモリの海へと溶け込ませる。
我々が追うべきは、システムが忘却しようとしている「過去のネットワーク接続の残骸」だ。メモリフォレンジックは、単なるスナップショットの採取ではない。それは、OSがカーネル構造体の中にひっそりと残した「亡霊」を叩き起こし、C2（コマンド＆コントロール）サーバーとの通信履歴を再構成する作業に他ならない。
1. カーネル構造体の深淵：_TCP_ENDPOINT とそのライフサイクル
Windowsメモリフォレンジックにおいて、TCP接続の痕跡を追う鍵は _TCP_ENDPOINT 構造体にある。通常、接続が終了すると、その構造体はメモリ上から解放される……はずだ。しかし、メモリの再利用タイミングによっては、構造体の一部、特に _ADDRESS_OBJECT や _CONNECTION_OBJECT の断片がページ内に残存する。
攻撃者が動的コード注入（Reflective DLL Injectionなど）を行い、メモリ上で直接ソケットを操作した場合、OS標準のログ（Sysmon等）には記録が残らないことが多い。ここで、Volatility等のツールを用い、tcpip.sys のメモリ空間を直接ダンプして解析する価値が生まれる。
2. Volatility 3を用いたクローズド・ソケットの探索
単に windows.netscan を実行するだけでは不十分だ。我々が知りたいのは、既に「CLOSED」状態となったエントリを含めた、メモリ上に残留するソケット構造体のリストである。
以下のコマンドは、カーネルメモリからソケット関連の構造体をスキャンし、接続の痕跡を抽出するための思考プロセスの一部だ。
# Volatility 3を使用して、カーネルメモリからソケット構造体を抽出する
# 実際には、カーネルオブジェクトのプールを再帰的にスキャンし、
# 構造体のシグネチャ（Tag: 'TcpE' など）を頼りにマッチングを行う
python3 vol.py -f memory.dmp windows.netscan --include-closedここで重要なのは、抽出されたデータを「相関分析」にかけることだ。特定のプロセスID（PID）が、なぜそのIPに対して、どのタイミングでパケットを投げたのか。メモリ上の「バッファ」に残るパケットの断片（Raw Data）を解析することで、C2サーバーとの通信プロトコル仕様がHTTP/Sなのか、あるいは独自に難読化されたTCPストリームなのかが見えてくる。
3. C2通信の相関分析：時間軸とメモリ整合性のジレンマ
通信の残骸を見つけたら、次は「いつ、誰が」を確定させる必要がある。ここで役立つのが、_ETHREAD 構造体との相関だ。
- タイムライン分析: ソケットの
CreateTimeと、プロセスのExitTime、およびCreateTimeを比較する。 - コンテキストの特定: 該当ソケットを所有していたスレッドが、どのメモリ領域から呼び出されていたか。もし、その領域が
PAGE_EXECUTE_READWRITE（RWX）属性を持つ未割り当て領域であれば、そこは悪意あるコードの拠点である。
実践的解析フロー（擬似コード的思考）
# メモリダンプから抽出したネットワーク接続情報の相関ロジック例
def analyze_c2_connection(socket_data, process_list):
for socket in socket_data:
# クローズされた接続の痕跡を追跡
if socket.state == 'CLOSED':
# ソケットに関連付けられたメモリ領域を特定
owner_thread = find_owner_thread(socket.address)
# そのスレッドがメモリ上のどこを指しているかを確認
memory_region = get_memory_region(owner_thread.start_address)
if memory_region.protection == 'RWX':
print(f"[!] 警告: 不正なRWX領域からの通信痕跡を発見: {socket.remote_ip}")
# ここで通信の内容（ペイロード）をカーネルプールからダンプする
dump_payload(socket.buffer_address)4. 次世代への備え：耐量子暗号とガードレイルの視点
今後、我々が対峙する脅威は、AIによる動的なプロトコル生成や、耐量子暗号（PQC）を用いたC2通信へと進化するだろう。暗号化された通信がメモリ上に「暗号化されたまま」展開されている場合、従来のシグネチャベースのIDSでは太刀打ちできない。
だからこそ、アーキテクトには「メモリ上での復号プロセス」を監視するガードレイルの設計が求められる。生成AIを用いた攻撃（プロンプトインジェクションによる内部情報の流出など）に対しても、LLMの推論プロセスがメモリをどのように操作しているか、その「動的なメモリフットプリント」を監視する技術が、次世代のDFIRの要となる。
結びに：泥臭い現場こそが真実を語る
高度な自動化ツールは強力な武器だが、最後は「なぜそのバイト列がそこに存在するのか」という執拗な問いかけが調査の成否を分ける。メモリは嘘をつかない。たとえ攻撃者が痕跡を消し去ったつもりでも、システムは物理的なメモリセルの中に、実行された命令の記憶を刻み込んでいる。
君たちが今見ている netstat の結果は、氷山の一角に過ぎない。その下の冷たく暗いメモリの海にこそ、真実が沈んでいるのだ。調査の手を止めるな。カーネル構造体が語りかけてくるその声を、論理的に翻訳し続けることこそが、我々防衛側の責務である。
コメント