見えない敵を暴け：DKOMによるプロセス隠蔽とメモリフォレンジックの最前線
現場でインシデント対応をしていると、時折「プロセス一覧には何もいないのに、不審な通信だけが続いている」という悪夢のような状況に遭遇する。タスクマネージャーも ps コマンドも、あるいは tasklist すらも何も教えてくれない。これが、攻撃者がカーネルレベルで仕掛ける「DKOM（Direct Kernel Object Manipulation）」の真骨頂だ。
今回は、彼らがどうやってOSの視界から消え、我々はどうやってその隠れ家を暴き出すのか。現場の知見を交えて深掘りしていく。
—
1. なぜ「隠蔽」が可能なのか：DKOMのメカニズム
OS（特にWindows）は、実行中のプロセスを管理するために、カーネルメモリ内に「EPROCESS」という構造体のリストを保持している。通常、私たちがコマンドでプロセスを見る際、OSはこのリストを辿って表示を行っている。
ここで攻撃者はカーネル権限を奪取した後、このリストの「前後のプロセスへのポインタ（Flink/Blink）」を直接書き換える。リストの鎖から特定のプロセスを切り離すわけだ。OS本体はプロセスを動かし続けるが、リストを辿るAPIは、切り離されたその存在を「そもそも存在しないもの」として無視するようになる。これがDKOMによる隠蔽の仕組みだ。
現場の視点：APIを信じるな
「psコマンドで出てこないからセーフ」という判断は、インシデントレスポンスにおいて致命的な慢心だ。「APIはOSが提供する『正解』ではなく、OSが『そう見せたい姿』に過ぎない」ということを常に意識してほしい。
—
2. メモリフォレンジックで「隠れ家」を特定する
では、OSが嘘をついているなら、どこを見ればいいのか。答えは「メモリダンプ（物理メモリの生の塊）」そのものだ。
隠されたプロセスであっても、CPUがコードを実行するためには、メモリ上のどこかに必ず EPROCESS 構造体が存在している。メモリフォレンジックツール（Volatility等）を使うと、リストを辿るのではなく、メモリ全体をスキャンして EPROCESS のパターン（シグネチャ）を力技で探し出す。
実務で使う Volatility のコマンド例
# 隠蔽されたプロセスをリストアップするプラグイン
# リストを辿るpslistではなく、構造体をスキャンするpsscanを使用する
python3 vol.py -f memory.dmp windows.psscanもし pslist（リスト参照）の結果と psscan（メモリ走査）の結果が食い違っていれば、そこにほぼ間違いなく「隠された悪意」が潜んでいる。
—
3. 防御の最前線：カーネルを守るための技術的アプローチ
DKOMのような高度な隠蔽を防ぐためには、そもそも「カーネルモードにコードを注入させない」ことが重要だ。Webアプリケーションやシステム管理の観点から、以下の防衛ラインを構築してほしい。
① カーネルモードコード署名の強制（Driver Signature Enforcement）
攻撃者は隠蔽のために悪意あるドライバをロードすることが多い。これを防ぐには、Windowsの「カーネルモードコード署名」を厳格化し、署名のないドライバのロードを物理的にブロックする。
# 管理者権限で実行し、署名なきドライバのロードを禁止する設定
bcdedit /set nointegritychecks off
bcdedit /set testsigning off② EDRによるメモリ保護機能の活用
近年のEDRは、プロセスの不審なメモリ操作を検知する「メモリ保護（Memory Protection）」機能を備えている。特に、システムコールをフックし、カーネル空間への書き込みを試みる挙動を監視する設定は必須だ。
③ Webアプリ開発側でのセキュアな設計
Webサーバーがカーネルレベルの攻撃を受ける入り口は、往々にして「ファイルアップロード」や「脆弱なプラグイン」だ。PHPで言えば、危険な関数を封じ込める設定が基本となる。
php.ini のセキュア設定例:
; 危険な関数を実行不可にする
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
; ファイルアップロードの制限（最小限に絞る）
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 1
; 意図しないディレクトリの参照を防ぐ
open_basedir = /var/www/html:/tmp—
4. 最後に：エンジニアとしての心構え
「見えているもの」だけを信じるのは簡単だ。しかし、インシデントレスポンスの現場では、「見えないもの」をどうやって可視化するかに真価が問われる。
DKOMによる隠蔽は、OSの根本的な信頼性を逆手に取った非常に巧妙な攻撃だ。しかし、メモリという「物理的な証拠」を改ざんすることは極めて困難である。もしシステムに異常を感じたなら、まずはAPIの出力に疑問を持ち、必要であればメモリダンプを取得し、rawデータのレベルで調査を試みてほしい。
君たちの手元にあるそのサーバーは、今この瞬間も本当に「正しい姿」を表示しているだろうか？ その問いを忘れない限り、君たちは最強のディフェンダーになれるはずだ。
コメント