Linuxカーネルの深淵：LKMルートキットによるフックとメモリ整合性チェックの現実
おい、ちょっと手を止めてくれ。
お前たちが普段何気なくデプロイしているクラウド上のLinuxインスタンス、その足元が音を立てて抜かれているとしたらどうする？
Webアプリケーションの脆弱性をついて初期侵入に成功した攻撃者が、次に何をするか知っているか？ www-data や nginx といった権限での踏み台工作が終わると、奴らは決まって「特権昇格（Privilege Escalation）」を試みる。そしてrootを奪った瞬間、スマートな侵入者は /etc/passwd を書き換えたりしない。そんな原始的な手口は、現代のEDRやSIEMのログ監視に秒で引っかかるからだ。
プロの攻撃者が好むのは、LKM（Loadable Kernel Module）型ルートキットによるカーネル空間の完全な乗っ取りだ。
今日は、システムコールテーブルやIDT（Interrupt Descriptor Table）がどのようにハイジャックされ、それを我々DFIR（デジタルフォレンジック＆インシデントレスポンス）チームがどうやって暴き出すのか、現場の泥臭い実態を含めて解説しよう。教科書には載っていない、生きたインシデントハンドリングの話だ。
—
1. 攻撃者がカーネルを握る手口：システムコールフックの恐怖
Linuxのカーネルは、ユーザー空間のプロセスとハードウェアやシステムリソースの間の「絶対的な調停者」だ。ファイルを開く(sys_open)、プロセスを一覧する(sys_getdents)、ネットワーク接続を行う(sys_socket)など、すべての特権操作はこのカーネルを経由する。
通常、これらの処理は sys_call_table（システムコールテーブル）という関数ポインタの配列に紐づいている。
もし、攻撃者が悪意あるLKMをカーネルにロードし、このテーブルの特定のポインタを書き換えたらどうなるか？
例えば、sys_getdents（ディレクトリ内のファイル一覧を取得するシステムコール）をフックされた場合を想像してほしい。
攻撃者が特定のファイル（例: バックドアのバイナリや隠しプロセス）をシステム上に配置したとしても、管理者が ls コマンドや ps コマンドを実行した瞬間、カーネル内で改ざんされた偽の関数が実行される。結果として、「そのファイルは存在しない」かのように見せかけられるのだ。
攻撃者目線の簡易PoC（概念実証）のイメージ
実務では、攻撃者は以下のようなアプローチでカーネルメモリの保護をバイパスし、システムコールを書き換える。
1. メモリ保護の解除: 近年のカーネルには CR0 レジスタのWP（Write Protect）ビットや、カーネルテキスト領域の書き込み保護があるが、set_memory_rw() などの関数や直接レジスタをいじって強制的に書き込み可能にする。
2. ポインタのすり替え: 元のシステムコールのメモリアドレスを退避させ、自身の悪意ある関数のアドレスを sys_call_table に上書きする。
3. 処理の委譲（または隠蔽）: 悪意ある処理を実行したあと、オリジナルのシステムコールを呼び出して結果を改変し、ユーザー空間に返す。
プロセスリストやネットワーク接続一覧（netstat や ss）が根底から信用できなくなる瞬間だ。ログを見ても何も記録されていない。これがLKMルートキットの恐ろしさである。
—
2. 現場のDFIR：メモリダンプと整合性チェックによる検出
OSがすでに信頼できない（Compromisedな）状態にあるとき、生きているOS上で lsmod や ps を実行しても無駄だ。ルートキットは lsmod が参照するモジュールのリンクリストからも自身の存在を綺麗に消し去っている（モジュールのアンリンク）。
だからこそ、我々フォレンジック調査員は「メモリイメージ（RAM Dump）」を採取し、オフラインで徹底的な解析を行う。
ここからは、Pythonを用いてメモリダンプからシステムコールテーブルの改ざんや、カーネル関数の異常な置き換わり（フック）を検知するための実践的なアプローチを見ていこう。
実務で使えるメモリ整合性チェッカー（Pythonサンプル）
以下のスクリプトは、Volatility等のフレームワークと連携し、システムコールテーブルのエントリが正当なカーネルテキストセグメントの範囲内を指しているか、あるいは既知のベースラインから外れていないかを検証する監査ツールの概念実装だ。
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Kernel Memory Integrity Checker
システムコールテーブルのポインタが正当なカーネル空間（テキスト領域）を
指しているか検証し、LKMによるフックを検知するための実務向けスクリプト。
"""
import sys
# 模擬的なカーネルのメモリマップ（実際にはVolatilityやLiMEのダンプから取得）
KERNEL_TEXT_START = 0xffffffff81000000
KERNEL_TEXT_END = 0xffffffff82e00000
# 既知の正当なシステムコールハンドラのプレフィックス（例: x86_64標準カーネル）
VALID_FUNCTION_PREFIX = 0xffffffff81
def verify_system_call_table(syscall_table):
"""
システムコールテーブルの各エントリを検証し、
カーネルテキスト領域外を指している（＝フックされている）ものを特定する。
:param syscall_table: dict { syscall_number: memory_address_int }
:return: list of compromised syscalls
"""
anomalies = []
print("[*] システムコールテーブルの整合性チェックを開始します...")
for sys_num, addr in syscall_table.items():
# 1. アドレスがカーネルテキスト領域内にあるかチェック
if not (KERNEL_TEXT_START <= addr <= KERNEL_TEXT_END):
anomalies.append({
"syscall_number": sys_num,
"address": hex(addr),
"reason": "カーネルテキスト領域外を指しています（外部モジュールによるフックの可能性）"
})
continue
# 2. 上位バイトのパターン異常チェック（簡易的なヒューリスティック）
if (addr >> 40) != (VALID_FUNCTION_PREFIX >> 8):
anomalies.append({
"syscall_number": sys_num,
"address": hex(addr),
"reason": "予期しないメモリセグメントを指しています"
})
return anomalies
if __name__ == "__main__":
# 【モックデータ】正常なエントリと、LKMによって外部領域（例: 0xffffffffc0... ＝モジュール領域）に
# フックされた sys_getdents (syscall 217) を想定
mock_syscall_table = {
0: 0xffffffff81123456, # sys_read (正常)
1: 0xffffffff81123a00, # sys_write (正常)
217: 0xffffffffc03fa120 # sys_getdents (異常: LKMのモジュール空間を指している!)
}
detected_hooks = verify_system_call_table(mock_syscall_table)
if detected_hooks:
print("\n[!] 警告: カーネル空間の改ざん（フック）が検知されました！")
for hook in detected_hooks:
print(f" - Syscall #{hook['syscall_number']} | アドレス: {hook['address']} | 判定理由: {hook['reason']}")
sys.exit(1)
else:
print("\n[-] 異常は検知されませんでした。システムは整合性を保っています。")
sys.exit(0)このスクリプトの本質は、「カーネルの正規のコード領域（Text Segment）以外の場所にある関数ポインタを悪とみなす」という点にある。LKMは通常、動的にロードされるため、カーネルのベースイメージとは異なるアドレス空間（モジュール領域）に配置される。そこを突くわけだ。
—
3. 完全防御のためのアーキテクチャとインフラ設定
フォレンジックで検知できた頃には、すでに手遅れ（情報漏洩やランサムウェアの展開完了）であるケースが多い。だからこそ、「そもそも悪意あるLKMをロードさせない」ための多層防御が不可欠だ。
現場のインフラエンジニアやSREに求む。今すぐ以下の対策が本番環境で有効化されているか確認してほしい。
1. カーネルモジュールのロード制限（Kernel Lockdown）
モジュールの動的ロードそのものを禁止、あるいは署名検証を強制する。
/etc/sysctl.conf または専用の設定ファイルに以下を記述し、カーネルのロックダウンモードを有効化または厳格化する。
# カーネルモジュールの動的ロードを禁止する（運用上可能であればこれが最強）
# 注意: 後からドライバを追加する必要がある環境では適用できませんが、
# Webサーバー等のイミュータブルなインフラでは非常に有効です。
kernel.modules_disabled = 12. Secure Bootの強制とモジュール署名（Module Signing）
ハードウェアレベルのSecure Bootを有効化し、さらにLinuxカーネル側で「署名のないモジュールのロードを一切拒否する」設定にする。
カーネルのコンフィグレーション（.config）または起動パラメータで以下を担保する。
# 起動時パラメータ（GRUB_CMDLINE_LINUX等に追加）
module.sig_enforce=1これにより、攻撃者が自前のコンパイル済みLKMを持ち込んでも、信頼された秘密鍵で署名されていない限り、カーネルはロードを拒絶する。
3. ランタイム監視（EDR / IMA / EBPF）
傳統的なファイル整合性監視（FIM）だけではカーネルメモリの改ざんは防げない。
現代のLinuxセキュリティでは、eBPF（Extended Berkeley Packet Filter）を用いたランタイムセキュリティツール（Cilium TetragonやFalcoなど）を導入し、sys_init_module などのカーネルモジュールロード関連のシステムコールが呼び出された瞬間に検知・ブロックする仕組みが必須だ。
—
チーフエンジニアからの総括
LKMによるフックやメモリ改ざんは、インフラストラクチャの信頼の根幹を揺るがす最も厄介な脅威の一つだ。
「rootを取られたら終わり」というのは過去の話になりつつある。現代のインシデントレスポンスでは、root権限奪取後に行われる「カーネル空間の永続化と隠蔽」をいかに見抜くか、そして何より「最初からロードさせない仕組み」をどうインフラに組み込むかが勝負の分かれ目となる。
コードを書くとき、インフラを組むとき、常に疑うことだ。「このOSは、本当に嘘をついていないか？」と。その疑う姿勢こそが、君のシステムを護る最強の盾となる。
コメント