こんにちは！日々の開発やインフラの管理、本当にお疲れ様です。「セキュリティの勉強を始めたいけれど、専門用語ばかりで何から手をつければいいか分からない…」そんな風に悩んでいませんか？
今回は、サイバーセキュリティの世界でも特にディープで、映画のハッキングシーンに出てくるような「カーネルモードルートキットの検知」についてお話しします。
「カーネルモード？ルートキット？なんだか難しそう……」と思われるかもしれませんが、大丈夫です！私たちの身近にある「家の防犯」にたとえながら、一歩ずつ優しく紐解いていきましょう。
—
1. カーネルモードルートキットってなに？（身近な例えで理解する）
パソコンのOSには、お家でたとえるなら「リビング（ユーザーモード）」と「絶対に他人を入れない秘密の金庫部屋（カーネルモード）」のような関係があります。
- ユーザーモード（リビング）： 私たちが普段アプリ（ブラウザやメモ帳など）を使う場所です。
- カーネルモード（金庫部屋）： パソコンの心臓部。ハードウェアの制御やセキュリティの根幹を司る、OSの最高責任者がいる場所です。
もし、泥棒があなたの家に侵入して、リビングの防犯カメラに「誰もいない平穏なリビング」の映像をずっと流し続けたらどうでしょう？あなたは泥棒が入ってきたことに全く気づけませんよね。
この「防犯カメラの映像をこっそり書き換えて、自分（悪意あるプログラム）の存在を完全に隠してしまう泥棒」こそが、カーネルモードルートキットです。
彼らはOSの心臓部である金庫部屋（カーネル）に居座るため、普通のウイルス対策ソフトからは姿が見えません。「ここにファイルはないよ」「このプロセスは安全だよ」と、OS自身に嘘をつかせてしまうのです。
—
2. メモリダンプという「現場の証拠保全」
相手がどれだけ上手に姿をくらませていても、パソコンの電源を切ってしまうと、メモリ（RAM）の中にあった証拠はすべて消えてしまいます。これは、犯行現場の足跡が雨で流されてしまうようなものです。
そこで私たちフォレンジック調査員は、パソコンの電源を入れた状態のまま、メモリの中身をごっそりファイルとして保存します。これをメモリダンプと呼びます。
「犯人は金庫部屋のどこをいじったのか？」それをこのメモリダンプから見つけ出すのが、今回のメインテーマになります。
—
3. 狙われる「フックポイント」の正体
カーネルモードルートキットは、OSの連絡網をこっそり書き換えて悪事を働きます。この「連絡網の書き換え」をセキュリティ用語でフック（Hook）と呼びます。
主な標的にされるのは、次の2つの重要なお仕事リストです。
1. SSDT（System Service Descriptor Table）：
アプリがOSにお願い事をするための「窓口の受付表」のようなものです。「ファイルを開いて」というお願いを、裏で別の悪い処理にすり替えます。
2. IDT（Interrupt Descriptor Table）：
キーボードが押されたり、マウスが動いたりしたときの「緊急連絡網」です。パスワードを入力した瞬間のキーボード情報をこっそり盗み見るときに使われます。
これらが改ざんされているかどうかを、私たちはメモリダンプから暴いていきます。
—
4. 実践：メモリからルートキットの影を見つけよう！
ここからは、実際にインシデントレスポンスの現場で使われているオープンソースの解析ツール「Volatility 3」を想定した、調査の流れとサンプルコードを見ていきましょう。
「難しそうだな」と思っても、コメントを読みながら順番に進めれば大丈夫です！
ステップ1：怪しいカーネルモジュール（ドライバー）の列挙
正規のドライバーに化けた悪質なカーネルモジュールが動いていないか、ロードされているドライバーの一覧を確認します。
# Volatility 3を想定した、カーネルモジュール確認の概念スクリプト
# ※実務ではコマンドラインから `vol -f memdump.raw windows.modules` を実行します。
def check_loaded_drivers(memory_image):
"""
メモリダンプから現在ロードされているすべてのカーネルモジュール（ドライバー）をスキャンし、
怪しい名前や正体不明のパスにないかをチェックします。
"""
print("[*] カーネルモジュールのスキャンを開始します...")
# ダミーのモジュールリスト（実際にはメモリのカーネル空間から取得します）
modules = [
{"name": "ntoskrnl.exe", "base": "0xFFFFF80003400000", "path": "\\SystemRoot\\system32\\ntoskrnl.exe", "suspicious": False},
{"name": "safe_driver.sys", "base": "0xFFFFF80004210000", "path": "\\SystemRoot\\system32\\drivers\\safe.sys", "suspicious": False},
{"name": "rootkit_hidden.sys", "base": "0xFFFFF80009990000", "path": "\\??\\C:\\Windows\\Temp\\hidden.sys", "suspicious": True} # ←怪しい！
]
for mod in modules:
if mod["suspicious"]:
print(f"[!] 警告: 異常なカーネルモジュールを検出しました！")
print(f" - モジュール名: {mod['name']}")
print(f" - ベースアドレス: {mod['base']}")
print(f" - 配置パス: {mod['path']}")
else:
print(f"[+] 正常: {mod['name']} (Base: {mod['base']})")
# 実行
# check_loaded_drivers("memdump.raw")このように、本来あるべき場所（System32\drivers など）とは違う不自然な場所からロードされているモジュールは、強力なインシデントの兆候（IoC）となります。
ステップ2：SSDTのフック（書き換え）検出
次に、先ほど説明した「受付表（SSDT）」が不正に書き換えられていないかをチェックします。正規の宛先は通常、OSの基本カーネル（ntoskrnl.exe）のメモリ範囲内に収まるはずです。
# SSDTのポインタ範囲を検証するロジックの例
def verify_ssdt_pointers(ssdt_entries, kernel_base_start, kernel_base_end):
"""
SSDTに登録されている関数ポインタが、正規のOSカーネル領域を指しているか検証します。
もしポインタが全く別の未知のメモリアドレス（悪意あるモジュールの領域）を指していれば、
それはインラインフックやSSDTフックを受けている証拠になります。
"""
print("[*] SSDT（システムサービス記述子テーブル）の整合性をチェック中...")
for index, pointer in enumerate(ssdt_entries):
# ポインタがカーネルの正規アドレス範囲外にあるかチェック
if not (kernel_base_start <= pointer <= kernel_base_end):
print(f"[!] 危険: SSDTインデックス #{index} がハイジャックされています！")
print(f" - 指しているアドレス: {hex(pointer)} (正規の範囲外です)")
else:
# 正常な場合はログに出力しないか、デバッグ出力にする
pass
# 設定例のパラメータ
# 正規のOSカーネルがメモリ上に展開されている範囲
KERNEL_START = 0xFFFFF80003400000
KERNEL_END = 0xFFFFF80003F00000
# テスト用のSSDTエントリ（一部が改ざんされている想定）
mock_ssdt = [
0xFFFFF80003451230, # 正常
0xFFFFF80003487A10, # 正常
0xFFFFF800099955F0 # 異常！未知の領域を指している
]
verify_ssdt_pointers(mock_ssdt, KERNEL_START, KERNEL_END)もしポインタが 0xFFFFF800099... のような見慣れない領域を指していた場合、それは金庫部屋の鍵穴が勝手に付け替えられている状態を意味します。
—
5. まとめとこれからの対策
カーネルモードルートキットの検知は、一見すると非常に難解で圧倒されてしまうかもしれません。しかし、基本の考え方はシンプルです。
1. 「普段の正しい状態（ベースライン）」を知る
2. メモリダンプという証拠を確保する
3. OSの連絡網（SSDTやIDT）やドライバーリストに不自然なズレがないか確認する
この一連の流れを少しずつ理解していくことで、目に見えない脅威に対しても冷静に立ち向かえるようになります。
セキュリティの世界は広大ですが、今日学んだ「金庫部屋と連絡網」のたとえを思い出していただければ、難しい技術書を読むときもぐっと理解しやすくなるはずです。
一歩ずつ、着実にスキルを磨いていきましょう！次回の解説もお楽しみに！
コメント