Linuxメモリフォレンジックの真実：LiMEとVolatilityが暴くカーネル空間の痕跡
インシデントレスポンスの現場において、ストレージのフォレンジック（死体検視）だけで事足りる時代はとうに終わった。昨今の高度な攻撃者は、侵入後にディスク上の痕跡を巧みに消し去り、すべての悪意あるペイロードやC2通信のセッション情報を揮発性メモリ（RAM）上だけで完結させる。いわゆる「ファイルレス攻撃」や、メモリ上での動的なコードインジェクションである。
特に標的となるLinuxサーバー環境において、カーネル空間の深いレイヤまで踏み込んだフォレンジックを行えなければ、真の侵害範囲（Blast Radius）を特定することは不可能だ。本稿では、Linuxカーネルモジュールである LiME（Linux Memory Extractor）を用いた極めて確実なメモリダンプの取得手法と、その生データを Volatility によって如何に料理し、隠蔽されたプロセスやRootkitの痕跡を暴き出すか、その実務的なノウハウを深掘りする。
—
1. なぜLinuxメモリフォレンジックは難しいのか？
Windows環境であれば、高度なEDRや DumpIt のようなツールが手軽に揮発性メモリをキャプチャしてくれる。しかし、Linuxの多様なディストリビューションとカーネルバージョンの組み合わせは、フォレンジクス・エンジニアにとって常に頭痛の種だ。
カーネル構造体（task_struct など）のオフセットは、カーネルのビルドごとに異なる。さらに、クラウドネイティブな環境ではコンテナ技術（cgroups や名前空間）が絡み合い、プロセスツリーの境界線が曖昧になる。この混沌とした環境で確実な証拠保全を行うためには、ターゲットシステムのカーネルと完全に同期したメモリ抽出が不可欠となる。そこで登場するのが、カーネルモジュールとして直接メモリマップにアクセスする LiME である。
—
2. LiMEを用いた安全かつ確実なメモリダンプの取得
LiME は、指定したフォーマット（Raw、Lime、DDなど）でカーネルメモリをファイルとして書き出すオープンソースのLKM（Loadable Kernel Module）だ。しかし、本番環境にライブでカーネルモジュールをロードする行為自体が、既存のフォレンジック証拠（メモリ上の揮発データ）をわずかに汚染するリスク（Heisenberg Effect）を孕んでいる。したがって、ビルドとロードのプロセスは極限まで洗練されていなければならない。
2.1 ターゲット環境でのビルドの罠
多くの初心者が陥る罠は、フォレンジック対象の稼働サーバー上で直接 LiME をビルドしようとすることだ。侵害された、あるいは不安定な本番環境でコンパイラを走らせたり、不要なパッケージを入れたりすることは、インテグリティを破壊する最悪の選択肢である。
正解は、ターゲットと完全に同一のカーネルバージョンを持つビルドコンテナ（あるいは隔離された同等環境）でモジュールをクロスコンパイルすることだ。
以下は、安全にモジュールをビルドするためのMakefileの調整と、ロードスクリプトの実務的アプローチである。
# ターゲットサーバーのカーネルヘッダーとバージョンを確認
uname -r
# 出力例: 5.15.0-88-generic
# 開発用ワークステーション（同一カーネル環境）でLiMEのソースを取得
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
# ソースコード内のメモリマッピング処理を確認しつつ、makeを実行
# ターゲットのカーネルパスを明示的に指定してビルドする
make -C /lib/modules/$(uname -r)/build M=$(pwd)2.2 ネットワーク経由でのダンプ出力（証拠の汚染防止）
ローカルのディスクにメモリダンプを書き出すと、貴重なフォレンジックターゲットの領域を上書きしてしまう恐れがある。そのため、実務では netcat を併用し、ネットワーク経由で安全なフォレンジックステーションへストリーミング転送するのが鉄則だ。
フォレンジック端末側（リスナー側）の操作：
# 4444番ポートで待ち受け、送られてきたメモリイメージをファイルとして保存する
nc -l -p 4444 > /evidence/target_server_memory.limeターゲットサーバー側での LiME のロードと送信：
# insmodを用いてLiMEカーネルモジュールをロード
# "format=raw" または "format=lime" を指定し、ネットワーク経由でフォレンジック端末へプッシュする
# 以下の例では、IPアドレス 192.168.100.50 のポート 4444 へ送信している
insmod lime-5.15.0-88-generic.ko "path=tcp:192.168.100.50:4444 format=raw"このコマンドを実行した瞬間、カーネル空間の全物理メモリが暗号化されていない状態でネットワークを流れるため、セキュアな閉域網（またはSSHトンネル等の暗号化経路）上で行うことがセキュリティ上の必須条件となる。
—
3. Volatilityによるカーネル空間の深層解析
取得した巨大なバイナリダンプ（target_server_memory.lime）を解析するのが Volatility（あるいはPython 3対応の Volatility 3）だ。ここからがアナリストの真価が問われるフェーズとなる。
3.1 シンボルテーブル（Intermediate Symbol Files: ISF）の準備
Volatility 3では、解析対象のLinuxカーネルに対応したシンボルファイルが必要となる。これがないと、単なる数字の羅列（オフセットの不一致）となり、カーネル構造体を正しく解釈できない。
# ターゲットのディストリビューションに応じたDWARFデバッグ情報を元に、
# Volatility 3用のISFファイルを生成する（dwarfdumpやvolatilityのcontribスクリプトを使用）
# 生成したファイルを Volatility 3 の symbols ディレクトリに配置する
cp ubuntu5.15.0-88-generic.json /path/to/volatility3/volatility3/symbols/linux/3.2 隠蔽プロセスの検出（linux.pslist vs linux.psscan）
マルウェアや高度なRootkitは、OSのプロセスリスト（task_struct の双方向連結リスト）から自身のポインタを切り離す「Direct Kernel Object Manipulation (DKOM)」を行い、通常の ps コマンドや一般的な監視ツールから身を隠す。
しかし、メモリ上のプール（Pool）には、プロセスの実体が残骸として、あるいはカーネルのキャッシュとして残っている。
# 1. 連結リストを辿る通常のプロセス列挙（隠蔽されたプロセスは表示されない）
python3 vol.py -f /evidence/target_server_memory.lime linux.pslist
# 2. プールスキャンによるプロセス構造体の総当たり検索（DKOMの検知）
python3 vol.py -f /evidence/target_server_memory.lime linux.psscanもし linux.pslist の結果には存在しないが、linux.psscan の結果には存在するPID（プロセスID）があれば、それは確実に 悪意あるプロセスがカーネル空間で隠蔽工作を行っている 決定的証拠である。直ちにそのプロセスのメモリ領域をダンプし、解析に回さなければならない。
3.3 ネットワークコネクションの網羅的検証（linux.netstat）
攻撃者がC2サーバーとどのようなプロトコル、どのポートで確立しているかを特定する。ユーザーランドの netstat や ss コマンドは改ざん（ライブラリインジェクションやバイナリの差し替え）を受けている可能性が高いが、メモリ上のカーネル構造体（sock 構造体など）を直接スキャンする Volatility なら、偽装不可能な真実を映し出す。
# カーネルメモリからソケット構造体を走査し、アクティブな接続を列挙する
python3 vol.py -f /evidence/target_server_memory.lime linux.netstatここで、不明な外部IPへの確立されたコネクション（ESTABLISHED）や、親プロセスが不審なデーモンのソケットを見つけた場合、侵害の起点を特定する強力な手がかりとなる。
—
4. チーフホワイトハッカーが実践する実務上の教訓とリスク管理
現場でLinuxメモリフォレンジックを指揮するにあたり、教科書通りにいかないリスクが存在する。
1. カーネルパニック（Kernel Panic）のリスク:
脆弱なカーネルや、すでに未知のRootkitによってカーネルメモリが破損している状態で LiME のようなLKMをロードすると、高確率でカーネルパニックを引き起こし、ターゲットシステムがクラッシュする。本番環境で実行する前には、ビジネス影響の評価と、可能な限り仮想環境（スナップショット）等での事前検証が求められる。
2. メモリ容量の肥大化:
近年のエンタープライズサーバーは数百GBからTB単位のRAMを搭載している。全メモリのダンプはネットワーク帯域やストレージを圧迫するため、インシデントの初期段階では、あらかじめターゲットを絞ったプロセスダンプや、重要なカーネル領域のみの抽出を検討する柔軟性が必要だ。
インシデントレスポンスとは、技術の正確性はもちろんのこと、証拠の完全性（Chain of Custody）を維持しながら、秒単位で変化する戦況を制圧する知的な格闘技である。LiMEとVolatilityを使いこなし、攻撃者が隠した痕跡をカーネルの深淵から引きずり出すスキルこそが、現代のセキュリティアーキテクトに求められる真の防衛力なのだ。
コメント