【実務・中級編】 Windowsカーネルオブジェクトの不整合検知によるRootkit特定 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

カーネルの深淵を覗く：RootkitによるSSDT/IDT改ざんをメモリダンプから暴く

現場で数々のインシデントを見てきたが、OSのカーネル層を制圧する「Rootkit」ほど厄介な代物はない。彼らはログを消すのではなく、OSが「ログを記録する機能そのもの」を騙す。システムがどれだけ正常を装っていても、メモリ上では確実に異変が起きている。

今回は、カーネルレベルの侵害、特にSSDT（System Service Descriptor Table）やIDT（Interrupt Descriptor Table）の改ざんを、どうやってフォレンジック的に検知するかという「泥臭い戦場」の話をしよう。

なぜRootkitはカーネルを狙うのか

通常のアプリケーション（User Mode）で動くマルウェアは、OSのAPIを呼び出す必要がある。しかし、Rootkitがカーネル権限（Ring 0）を得れば、APIの入り口であるSSDTを書き換え、特定のシステムコールを「自分に都合の良い関数」へ転送できる。

例えば、NtQueryDirectoryFileという関数を改ざんすれば、特定のファイル名を含むディレクトリ一覧をOS自体に隠蔽させることが可能だ。ファイルシステム上の探索ツールがどれほど優秀でも、OSが「そんなファイルは存在しない」と嘘をつく以上、発見は不可能に近い。

メモリフォレンジックによる検知の基本戦術

メモリダンプ（raw形式など）を入手したら、まずは Volatility Framework を使ってカーネルの整合性をチェックする。

SSDTのフック検知: ssdt プラグインで、カーネルアドレス空間外（通常は ntoskrnl.exe の範囲外）を指している関数ポインタがないかを探す。
IDTのフック検知: idt プラグインで、割り込みハンドラが不審なモジュールを指していないか確認する。

これらが「OSのベースアドレスから異常に離れた場所」を指していたら、即座に侵害を疑うべきだ。

実践的防御：カーネルを守るための「多層防御」設計

正直に言おう。一度Rootkitにカーネルを握られたら、そのOSは「信頼できない」とみなして再構築するのが鉄則だ。しかし、そこに到達させないための「事前の防御」こそがエンジニアの腕の見せ所だ。

特にクラウド環境（AWS/GCP/Azure）では、カーネルレベルの保護機能を有効にすることが最大の防御になる。

1. カーネル保護設定（Linux/ハードウェアレベル）

Linux環境であれば、kernel.modules_disabled を有効にし、実行中のモジュールロードを禁止する設定が有効だ。

# /etc/sysctl.conf に追記
# カーネルモジュールの動的ロードを禁止し、Rootkitの埋め込みを物理的に阻害する
kernel.modules_disabled = 1

2. WAF/IAMによる攻撃経路の遮断

Rootkitは「遠隔からの権限昇格」をトリガーにすることが多い。攻撃者が脆弱なWebアプリ経由でシェルを奪取するのを防ぐため、WAFで不正なコマンド実行パターンを弾くのが基本だ。

AWS WAF (JSON形式のレート制限/カスタムルール例)

{
  "Name": "Block-System-Command-Injection",
  "Priority": 1,
  "Action": { "Block": {} },
  "Statement": {
    "ByteMatchStatement": {
      "SearchString": "/proc/self/mem",
      "FieldToMatch": { "AllQueryArguments": {} },
      "TextTransformations": [{ "Priority": 0, "Type": "URL_DECODE" }]
    }
  }
}

※ /proc/self/mem を直接操作しようとする試みは、カーネルメモリ書き換えを狙う典型的な攻撃の兆候だ。

Webアプリ開発者が知っておくべき「最後の一線」

Webアプリケーションの脆弱性（RCE等）がカーネル侵害の入り口になることは珍しくない。PHP等で外部コマンドを実行する際は、シェルを直接呼ばず、可能な限り引数をサニタイズし、実行ユーザーの権限を最小化すること。

セキュアなコマンド実行サンプル（PHP）

<?php
/**
 * 危険な system() や exec() を避け、引数を厳密に制御する
 * Rootkitの侵入経路を作らないための最小権限原則
 */
function secure_execute_command($cmd, array $args) {
    // 許可されたコマンド以外は即座に拒否
    $allowed_commands = ['/usr/bin/git', '/usr/bin/zip'];
    if (!in_array($cmd, $allowed_commands)) {
        throw new Exception("不正なコマンド実行の試行を検知しました。");
    }

    // escapeshellarg で引数をクォートし、シェルインジェクションを完全に防ぐ
    $escaped_args = array_map('escapeshellarg', $args);
    $command_string = $cmd . ' ' . implode(' ', $escaped_args);

    // 実行結果をキャプチャし、エラーハンドリングを徹底する
    exec($command_string, $output, $return_var);
    
    if ($return_var !== 0) {
        error_log("コマンド実行失敗: " . $command_string);
        return false;
    }
    return $output;
}
?>

最後に：エンジニアとしての矜持

カーネルオブジェクトの不整合は、システムの「深層心理」に現れる。表層的なログだけを見て「異常なし」と判断するのは、患者の脈拍を見ずに「顔色が良さそうだから健康だ」と言うのと同じだ。

システムを運用する諸君には、常に「OSもアプリケーションも、いつかどこかで騙されるかもしれない」という疑念を持ち続けてほしい。その疑念こそが、最も強固なセキュリティ防御壁となるのだから。

もし不審な挙動があれば、まずはメモリダンプを取得し、SSDTの指し先を自分の目で確認すること。それが、プロのDFIRアナリストとしての第一歩だ。