【実務・中級編】 Windowsカーネルオブジェクト（EPROCESS, ETHREAD）の構造解析 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

APIフックの裏をかく悪意：EPROCESSとETHREADの深層を覗く

おい、最近のEDR（Endpoint Detection and Response）やセキュリティ製品は優秀だから安心していなか？「プロセスリストを取得するAPIを監視していれば、怪しい動きはすべて検知できる」なんて考えているとしたら、インシデントレスポンスの現場を知る人間から言わせてもらえば、それは致命的な油断だ。

高度なマルウェアやカーネルレベルのルートキットは、ユーザーモードのAPIなんて端から信用していないし、使ってもいない。彼らが狙うのは、Windowsカーネルの心臓部である EPROCESS や ETHREAD といったデータ構造そのものだ。今回は、OSの目をあざむく彼らの手口と、それを暴くためのメモリフォレンジックの真髄を叩き込む。

現場のエンジニアとして、なぜOSのAPIを介さない「直接解析」が必要なのか、その泥臭い現実を紐解いていこう。

—

なぜAPI監視は破綻するのか？（カーネルオブジェクトの闇）

Windows上で動作するプロセスは、すべてカーネル空間に存在する EPROCESS（Executive Process）という巨大な構造体によって管理されている。この中には、プロセスの識別子である UniqueProcessId、仮想アドレス空間の管理テーブル、そして親プロセスを指す InheritedFromUniqueProcessId など、システムが生きるために必要なすべての情報が詰まっている。

さらに、そのプロセス内で動くスレッドは ETHREAD（Executive Thread）構造体によって制御されている。

通常、タスクマネージャーやセキュリティツールの多くは、Windowsが提供する EnumProcesses などのAPIや、PSAPIを使ってプロセス情報を取得する。しかし、カーネルモードへ昇格（あるいは脆弱性を悪用）した攻撃者は、以下のような手口を使ってこの仕組みをハッキングする。

1. DKOM（Direct Kernel Object Manipulation）:
カーネルメモリ（System プロセスなどの物理/仮想アドレス空間）を直接書き換え、アクティブなプロセスリスト（ActiveProcessLinks）の二重連結リストから自らのプロセスエントリを外し（Unlinking）、OSのAPIから「存在しない」ように見せかける。
2. プロセス名や親IDの偽装:
EPROCESS 内のイメージ名（ImageFileName）や親プロセスのポインタを書き換え、信頼されたシステムプロセス（例えば explorer.exe や svchost.exe）のふりをする。

APIを叩くだけの表層的な監視では、この「リストから消された幽霊プロセス」を絶対に捉えられない。だからこそ、我々DFIRアナリストは、ダンプされたメモリイメージを直接スキャンし、カーネル構造体のオフセットをハッキングして真実を暴き出す必要があるのだ。

—

脆弱なシステム設計と攻撃の構図

ここで、「そんなカーネルレベルの話はインフラエンジニアの仕事だろ？」と思ったWebアプリやシステム開発者の方々に警告しておく。攻撃者がカーネルに到達する足がかりは、大抵の場合、あなたが日々書いているWebアプリケーションの脆弱性や、不適切な設定のバックエンドAPIなのだ。

例えば、ファイルのアップロード処理において拡張子チェックが甘く、任意のスクリプトが実行可能な環境を作ってしまったとしよう。そこから権限昇格（LPE: Local Privilege Escalation）の脆弱性を突かれ、SYSTEM権限を奪われた瞬間、あなたのサーバーの EPROCESS は完全に敵の掌の上となる。

防御のためのセキュアな実装と設定

インシデントを未然に防ぐためには、まずアプリケーション層での侵入口を完全になくすこと。そして、万が一侵入された際に被害を最小限に抑える（コンテナの特権隔離など）設計が不可欠だ。

以下に、ファイルアップロード機能を持つWebアプリケーションにおいて、OSコマンドインジェクションや不正な実行ファイルの配置を完全にブロックするセキュアなPHPの実装サンプルを示す。現場でそのままコピペして使える堅牢な設計にしてある。

<?php
/**
 * セキュアなファイルアップロード処理のサンプル
 * 
 * 脆弱な実装（拡張子のブラックリスト方式や、ユーザー入力をそのままファイル名にするなど）は、
 * リモートコード実行（RCE）からカーネル権限奪取への致命的な足がかりとなります。
 * 以下のホワイトリスト方式と厳格なバリデーションでこれを完全に阻止します。
 */

declare(strict_types=1);

// エラー出力の本番環境向け抑制（詳細なパス情報を露出させない）
ini_set('display_errors', '0');
error_reporting(E_ALL);

// 設定定数
const UPLOAD_DIR = '/var/www/secured_uploads/';
const MAX_FILE_SIZE = 2 * 1024 * 1024; // 2MB制限

// 許可するMIMEタイプのホワイトリスト（拡張子だけに頼らない）
$allowedMimeTypes = [
    'image/jpeg' => 'jpg',
    'image/png'  => 'png',
    'application/pdf' => 'pdf'
];

try {
    // リクエストメソッドの検証
    if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
        throw new \RuntimeException('無効なリクエストメソッドです。');
    }

    // アップロードエラーのチェック
    if (!isset($_FILES['userfile']) || $_FILES['userfile']['error'] !== UPLOAD_ERR_OK) {
        throw new \RuntimeException('ファイルのアップロードに失敗しました。エラーコード: ' . ($_FILES['userfile']['error'] ?? '不明'));
    }

    $file = $_FILES['userfile'];

    // ファイルサイズの検証
    if ($file['size'] > MAX_FILE_SIZE) {
        throw new \RuntimeException('ファイルサイズが制限（2MB）を超過しています。');
    }

    // 1. finfoを用いた実際のMIMEタイプの判定（拡張子の偽装を防止）
    $finfo = new \finfo(FILEINFO_MIME_TYPE);
    $mimeType = $finfo->file($file['tmp_name']);

    if (!array_key_exists($mimeType, $allowedMimeTypes)) {
        throw new \RuntimeException('許可されていないファイル形式（MIMEタイプ）です。');
    }

    $extension = $allowedMimeTypes[$mimeType];

    // 2. 推測不可能な安全なファイル名の生成（パス traversal 攻撃の防止）
    $safeFilename = bin2hex(random_bytes(16)) . '.' . $extension;
    $destination = UPLOAD_DIR . $safeFilename;

    // ディレクトリトラバーサル対策の最終確認
    $realUploadDir = realpath(UPLOAD_DIR);
    if ($realUploadDir === false) {
        throw new \RuntimeException('アップロードディレクトリが存在しません。');
    }

    // 3. ファイルの移動とパーミッションの厳格化
    if (!move_uploaded_file($file['tmp_name'], $destination)) {
        throw new \RuntimeException('ファイルの保存中にエラーが発生しました。');
    }

    // 実行権限を剥奪（万が一のWebシェル実行を阻止するため、読み取り専用に設定）
    chmod($destination, 0644);

    // 正常終了レスポンス
    http_response_code(200);
    echo json_encode([
        'status' => 'success',
        'message' => 'ファイルは安全にアップロードされました。',
        'filename' => $safeFilename
    ], JSON_UNESCAPED_UNICODE);

} catch (\RuntimeException $e) {
    // セキュリティ上の理由から、詳細なシステムパスなどはログにのみ記録し、ユーザーには汎用メッセージを返す
    error_log('[Security Alert] Upload Error: ' . $e->getMessage());
    
    http_response_code(400);
    echo json_encode([
        'status' => 'error',
        'message' => $e->getMessage()
    ], JSON_UNESCAPED_UNICODE);
}

—

フォレンジック現場からの実践アドバイス

もし、あなたが運用するWindowsサーバーがすでに侵害され、カーネルレベルの改ざんが疑われる状況に直面したとしたら、以下の手順でメモリ解析を行え。

1. メモリイメージの採取:
生きているOS上で DumpIt や WinPmem などの信頼できるツールを使い、物理メモリの正確なダンプを取得する（※可能であればライブレスポンスによる電源断前の取得が望ましい）。
2. Volatility Frameworkを活用したEPROCESSスキャン:
オープンソースのメモリフォレンジックフレームワークである Volatility 3 を用いて、隠蔽されたプロセスを炙り出す。

# プロセスリストをカーネルプールから直接スキャンする（DKOM検知の基本）
   python3 vol.py -f memory.raw windows.pslist
   
   # APIからは見えないが、EPROCESS構造体がメモリ上に残っているものをスキャン
   python3 vol.py -f memory.raw windows.psscan

3. 親プロセス偽装の特定:
windows.pslist の結果から、PID と PPID（親プロセスID）の関係性を精査する。例えば、lsass.exe の親プロセスが正規の wininit.exe ではなく、不審なパスにある実行ファイルになっていれば、それはほぼ間違いなくインシデントの証拠だ。

セキュリティとは、単にツールを導入して安心することではない。「OSやミドルウェアの裏側で何が起きているのか」というデータ構造のレベルまで理解を深めることこそが、真のインシデントレスポンスの第一歩なのだ。日々の開発やインフラ設計において、この視点を忘れないでほしい。