こんにちは！日々のインフラ運用やセキュリティ対策、本当にお疲れ様です。
システムを管理していると、「本当にうちのシステムは安全だろうか」「目に見えないところでこっそり悪さをされているんじゃないか」と、夜も眠れなくなるような不安に駆られることってありますよね。
今回は、そんなセキュリティ担当者を絶望のどん底に突き落とすこともある、少し怖いけれど非常に重要なテーマ「WindowsカーネルのDirect Kernel Object Manipulation（DKOM）攻撃」についてお話しします。
「カーネル？」「オブジェクト？」と聞いただけで、難しそうな壁を感じてしまうかもしれませんが、大丈夫です！私たちの身近にある「合鍵」や「マンションの管理台帳」の例えを使いながら、一歩ずつ優しく紐解いていきますので、ぜひリラックスして読み進めてくださいね。
—
1. そもそもDKOM攻撃ってなに？ 身近な例えで理解しよう
まずは、攻撃者がやろうとしていることを、私たちが住んでいるマンションの防犯に置き換えて考えてみましょう。
マンションの「管理台帳」と「住人」の関係
あなたが管理しているマンションには、今誰が住んでいるかを記録する「住民台帳（＝Windowsのプロセスリスト）」がありますよね。管理人は、この台帳を見て「お、何号室の〇〇さんは今ロビーにいるな」と把握します。
通常、不審者が勝手に部屋に居座ろうとすると、警察や管理人がすぐに駆けつけて追い出します。これが通常のセキュリティソフト（EDRやアンチウイルス）の働きです。タスクマネージャーを開いて「怪しいアプリが動いているな」と気づいて強制終了できるのも、この住民台帳（プロセスリスト）がきちんと機能しているからなんですね。
攻撃者はどうやって目を盗むのか？
ところが、狡猾なハッカー（攻撃者）は、住民台帳そのものを書き換えてしまう技を覚えました。
実際に部屋（メモリ）の中にはいすわり続けているのに、「住民台帳のページから自分の名前をキレイに消しゴムで消してしまう」のです。
管理人が台帳を見ても「あれ、この部屋は空室のはずだぞ？」となってしまい、誰も不審者に気づきません。このように、OSの根幹（カーネル）にある管理データ構造を直接書き換えて、自分の存在を完全に隠してしまう手口。これがDKOM（Direct Kernel Object Manipulation：ダイレクト・カーネル・オブジェクト操作）と呼ばれる攻撃の正体です。
—
2. Windowsの裏側で何が起きているのか？（少しだけ技術のお話）
Windowsの内部では、すべてのプロセスやファイル、通信などが「オブジェクト」というひとまとまりのデータとして管理されています。そして、それらは「リンクリスト（連結リスト）」という、電車のごとく車両同士がフックで繋がったような構造で管理されています。
通常、プロセスA、プロセスB、プロセスCが次のように繋がっているとします。
[プロセスA] <---> [怪しいプロセスB] <---> [プロセスC]
DKOM攻撃を行うマルウェアは、カーネルモード（OSの超強力な特権エリア）で動作し、このフックをこっそりと付け替えます。
[プロセスA] <---> [プロセスC] （あれっ、プロセスBが外された！）
これで、Windowsの標準的なAPI（タスクマネージャーなど）はプロセスBを見つけられなくなります。しかし、プロセスB自体はメモリ上にしっかりと存在し、CPUの時間を奪って悪さ（データの窃盗やマイニングなど）を続けられるのです。まさに「幽霊プロセス」ですね。
—
3. 隠された幽霊を見つけ出せ！メモリフォレンジックの基本
「そんなの、隠されたらもう見つけられないじゃないか！」と思われるかもしれませんが、私たちフォレンジック調査員には強力な味方がいます。それが「メモリダンプの解析（メモリフォレンジック）」です。
生きているOSの目をごまかすことはできても、その瞬間をパシャリと写真に撮った「メモリの全容量データ（メモリダンプ）」を別の安全な環境で解析すれば、ごまかしの綻びがハッキリと見えてきます。
不整合（インコンシステンシー）を見つける
DKOMの最も大きな弱点は、「繋ぎ替えのミス」や「情報の食い違い」にあります。
先ほどのリンクリストの例で、プロセスBは表向きのリストから外されましたが、カーネルの別の場所にある「ActiveProcessLinks」や、プロセスが持つ別のポインタには、まだ消しきれない痕跡が残っていることが多いのです。
現場でよく使われるオープンソースのメモリ解析ツール Volatility（ボラティリティ） を使った基本的な調査コマンドを覗いてみましょう。
# 1. 現在メモリ上に存在するプロセスを通常のリスト（ActiveProcessLinks）から探す
volatility -f memory_dump.raw --profile=Win10x64_19041 psscan
# 2. プロセスが持つ別の管理構造（プロセスIDのハッシュテーブルなど）から隠されたプロセスを探す
volatility -f memory_dump.raw --profile=Win10x64_19041 pslist
# 3. pslist（通常の台帳）と psscan（実際の部屋の総数チェック）の結果を比較するもし、psscan（メモリの隅々までスキャンして見つけたプロセス）の結果には存在するのに、pslist（管理台帳）の結果には名前がないプロセスがあったとしたら……？
ビンゴです。それがまさにDKOMによって隠蔽された幽霊プロセス（マルウェア）です！
—
4. 実務で役立つ！インシデントレスポンスのステップ
もし、実際のインフラや開発環境でこのような不審な兆候に気づいたとき、私たちエンジニアはどのように動けばよいのでしょうか。現場の泥臭い手順を少しだけ共有しますね。
1. 慌てて電源を落とさない（重要！）
- パソコンの電源をプツッと切ってしまうと、メモリ（RAM）に載っていた貴重な証拠（DKOMの痕跡やマルウェアのコード）がすべて消えてしまいます。まずはネットワークケーブルを抜く（物理的な隔離）だけに留めましょう。
2. ライブレスポンスまたはメモリダンプの取得
DumpItやFTK Imager Liteなどの信頼できるツールを使って、物理メモリのイメージを安全な外部ストレージに吸い出します。
3. オフライン環境での解析
- 抽出したメモリダンプを、調査用の隔離されたPCに移し、
Volatilityなどのフォレンジックツールでじっくりと整合性を検証します。
4. 根本原因の特定と再発防止
- なぜカーネルモードでコードを実行されたのかを調べます。多くの場合、脆弱なサードパーティ製ドライバ（BYOVD: Bring Your Own Vulnerable Driver 攻撃など）が悪用されています。古いドライバのアップデートや、エンドポイントセキュリティ（EDR）のシグネチャ見直しを行いましょう。
—
おわりに：セキュリティは「疑うこと」から始まる
DKOM攻撃のような高度な手口を聞くと、「自分たちには太刀打ちできないのではないか」と不安になるかもしれません。でも、仕組みを少しずつ紐解いていけば、攻撃者がどこで足跡を残してしまうのか（不整合の発生）が見えてきます。
日頃から「もしかしたら見えないところで台帳が書き換えられているかもしれない」という視点を持ち、定期的なログ監視やメモリの健全性チェックを行うこと。それが、私たちのシステムを守る一番の近道になります。
難解な技術も、一歩ずつ噛み砕いていけば必ず理解できます。これからも一緒に、安全で頼もしいシステムエンジニアを目指して頑張っていきましょう！
コメント