こんにちは！セキュリティやインフラの勉強を始めると、次から次へと聞き慣れない難しい言葉が出てきて、頭がクラクラしてしまいますよね。
「メモリフォレンジック」「カーネル」「GDT」「IDT」……。なんだか呪文のようですが、大丈夫です！一歩ずつ、私たちの身近な「おうちの防犯」に置き換えながら、一緒に紐解いていきましょう。
今回は、サイバー攻撃者がパソコンの「一番偉い権限（カーネルモード）」をこっそり乗っ取るために使う、ちょっとずる賢い手口と、それを探偵のように見つけ出す「メモリフォレンジック」の世界にご案内します。
—
1. 家の鍵と泥棒に例える「GDT」と「IDT」の仕組み
まずは、パソコンの頭脳であるOS（オペレーティングシステム）の中身を、大きなお家に例えてみましょう。
私たちのパソコンには、安全を守るために「普段私たちが生活するリビング（ユーザーモード）」と、「絶対に一般の人が入ってはいけない秘密の金庫室（カーネルモード）」という、厳格な部屋の区切りがあります。
このお家には、重要なルールブックや連絡帳が2つあります。それが GDT と IDT です。
GDT（グローバル記述子テーブル）＝「お部屋の通行手形チェック係」
GDTは、CPUに対して「このメモリの領域は誰が触っていいよ」「ここは絶対に立ち入り禁止のVIPルームだよ」という境界線を教えるための、いわば「お部屋の通行手形リスト」です。
攻撃者は、このリストをこっそり書き換えて、「一般人の部屋から、秘密の金庫室へ自由に行き来できるようにしちゃえ！」と企むことがあります。これがGDTの改ざんです。
IDT（割り込み記述子テーブル）＝「緊急時のインターホン対応マニュアル」
IDTは、パソコンの画面がカチッと動いたり、キーボードが押されたりしたときに、「今すぐこれに対応して！」とCPUにお知らせする「緊急時のインターホン対応表」です。
通常、インターホンが鳴ったら警察（OSの正規の処理）が対応しますが、もし悪者（攻撃者）がこの対応表を書き換えていたらどうでしょう？
「ピンポーン」と鳴った瞬間に、警察ではなく泥棒が直接ドアを開けて中に入ってくるような状態になってしまいます。これがIDTの改ざん（システムコールフック）です。
—
2. 攻撃者はどうやって裏口を作るのか？（フック手法の正体）
攻撃者がやりたいことはただ一つ、「普通の一般ユーザーのふりをしたまま、パソコンの最高権限（管理者よりも強いカーネル権限）をこっそり手に入れること」です。
彼らは正規のIDTやGDTを直接壊すのではなく、その「連絡先（ジャンプ先）」を自分の作った悪いプログラムへとすり替えます（フック）。
たとえば、あなたがキーボードで文字を入力するたびに、裏でその悪意あるプログラムがこっそり実行され、パスワードを盗んだり、自分自身をパソコンの「神様（最高管理者）」に昇格させたりしてしまうのです。
現場のセキュリティアナリスト（私たち）は、攻撃者が残したこうした「不自然なすり替え」を見つけ出すために、パソコンのメモリ（脳みそ）の全データをガッツリと保存し、怪しいところがないか健康診断を行います。これがメモリフォレンジックという作業になります。
—
3. 探偵の眼：IDT/GDTの改ざんをどうやって見つけるの？
では、実際にインシデントレスポンスの現場で使われている、怪しいフックを見つけるためのアプローチを覗いてみましょう。
ボランティアや新人エンジニアの皆さんが、「あれ、このサーバーなんだかおかしいぞ？」と思ったときに、メモリの診断を行うための基本的な考え方と、解析ツール（Volatile SystemsのVolatilityなど）で使われる概念をコード例を交えて見ていきます。
解析ツールのイメージ：IDTのエントリを覗き見する疑似スクリプト
もし私たちが、Pythonを使ってWindowsのメモリからIDT（割り込み記述子テーブル）のリストを読み出し、そのジャンプ先（ハンドラーアドレス）が正当な領域を指しているかチェックするプログラムを書くとしたら、こんなイメージになります。
# 【教育用サンプル】メモリ上のIDTエントリが安全な領域にあるかチェックする概念コード
import struct
def check_idt_integrity(idt_entries, kernel_base, kernel_size):
"""
IDTのエントリが正規のカーネルコード領域を指しているか検証する関数
:param idt_entries: メモリから抽出したIDTエントリのリスト
:param kernel_base: OSのカーネルがロードされているメモリの開始アドレス
:param kernel_size: カーネル領域のサイズ
"""
suspicious_count = 0
print("[*] IDT (割り込み記述子テーブル) の整合性チェックを開始します...")
for index, entry in enumerate(idt_entries):
handler_address = entry['handler_address']
# ジャンプ先のアドレスがカーネルの正規の範囲内にあるかチェック
# もし範囲外（例：見知らぬドライバーの領域や、怪しいヒープ領域）を指していたらフックされている可能性大！
if not (kernel_base <= handler_address <= (kernel_base + kernel_size)):
print(f"[!] 警告: IDT #{index} が不正なアドレスを指しています！")
print( f" -> ハンドラーアドレス: 0x{handler_address:X}")
print( f" -> 期待される範囲: 0x{kernel_base:X} - 0x{(kernel_base + kernel_size):X}")
suspicious_count += 1
else:
# 正常な場合は静かにパス
pass
if suspicious_count == 0:
print("[+] IDTの改ざんは検出されませんでした。安全です。")
else:
print(f"[!] 危険: 合計 {suspicious_count} 件の怪しいフック（改ざん）を検出しました！即座に隔離が必要です。")
# 実行シミュレーション用のダミーデータ
# 実務ではVolatilityなどのフォレンジックツールがこのデータをメモリから抽出してくれます
dummy_kernel_base = 0xFFFFF80002200000
dummy_kernel_size = 0x00A00000 # 10MB
mock_idt_list = [
{'index': 0, 'handler_address': 0xFFFFF80002250123}, # 正常（カーネル内）
{'index': 1, 'handler_address': 0xFFFFF80002284567}, # 正常（カーネル内）
{'index': 2, 'handler_address': 0xFFFFFA8003111000}, # 【異常】カーネルの外（不審なドライバ領域）を指している！
]
# チェックの実行
check_idt_integrity(mock_idt_list, dummy_kernel_base, dummy_kernel_size)このように、現場のエンジニアは「本来あるべき場所（正規のカーネル空間）」と「実際に指している場所（ジャンプ先）」を見比べて、ルールからはみ出た不正な道（フック）がないかを隅々までチェックしていくのです。
—
4. 現場からのアドバイス：一歩ずつ対策を学んでいきましょう！
GDTやIDTの改ざん、そしてシステムコールフックといった高度な手口を聞くと、「自分には無理だ……」と圧倒されてしまうかもしれません。でも、安心してください。セキュリティのプロたちも、最初は皆さんと同じように「なんだこれ？」という疑問からスタートしています。
実務やインフラ構築において、私たちが今日からできる有効な対策も挙げておきますね。
1. 不要なサードパーティ製ドライバを入れない
- カーネルモードをいじる攻撃の多くは、脆弱性のある古い独自ドライバ（BYOVD攻撃：Bring Your Own Vulnerable Driver）を悪用してGDT/IDTを書き換えます。信頼できない野良ドライバは絶対にインストールしないこと。
2. OSやセキュリティパッチを常に最新にする
- 近年のOSには、KPP（Kernel Patch Protection / パッチガード）という、Windows自身がGDTやIDTの改ざんを常時監視して、異常があれば即座にブルースクリーン（強制終了）で身を守る強力な仕組みが備わっています。アップデートをサボらないことが最高の防犯になります。
3. EDR（Endpoint Detection and Response）の導入
- 単なるウイルス対策ソフトだけでなく、メモリの挙動を監視してくれるEDR製品を導入することで、こうしたカーネルレベルの不審な動きを早期に察知できるようになります。
難解な技術も、本質（おうちの防犯）を捉えれば怖くありません。日々の小さな「なぜ？」を大切にしながら、一歩ずつ頼もしいエンジニアへの階段を登っていきましょう！
コメント