【実務・中級編】 Volatility Framework 3を用いたプロセスツリーの異常検知と親プロセス偽装の特定 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

【DFIR最前線】その lsass.exe は偽物だ：Volatility 3で見抜く親子関係の欺瞞

現場でインシデントレスポンスを担当していると、攻撃者がいかに「正当なプロセス」の皮を被ることに執着しているか、痛感させられる。特にWindows環境において、lsass.exe（Local Security Authority Subsystem Service）や services.exe といったシステムプロセスの名前を騙る手口は、もはや古典的だが依然として極めて強力だ。

今日は、Volatility 3を使い、彼らが仕掛けてくる「親子関係の偽装（PPIDスプーフィング）」をどう見破るか、そしてそもそもなぜそんなことが許されるのか、その根底にあるエンジニアリングの欠陥について話そう。

—

1. なぜ「親プロセス」を確認するのか？

Windowsのプロセス生成ルールにおいて、本来 lsass.exe や services.exe は wininit.exe から起動されるべきものだ。もし、これらが全く無関係なユーザープロセス（例えば cmd.exe や powershell.exe）から起動されていたり、逆に怪しいプロセスがこれらを親に持っていたら、それはもう「異常」のサインだ。

攻撃者は UpdateProcThreadAttribute というAPIを用いて、プロセスの生成時に「親プロセスID（PPID）」を明示的に指定することで、プロセスツリーを意図的に歪める。これにより、EDRの自動検知を回避したり、ログ上の不整合を狙ったりするわけだ。

2. Volatility 3 pstree での検知フロー

現場では、まずメモリダンプを採取し、以下のコマンドでプロセスツリーを視覚化する。

# Volatility 3のpstreeプラグインを実行してプロセスツリーをダッシュボード的に確認
python3 vol.py -f memory.dmp windows.pstree

この出力結果の中で、以下の点に注目してほしい。

  • PPIDの不整合: lsass.exe の親PIDが wininit.exe ではない。
  • 不自然な親子関係: 本来、サービスプロセスであるはずの services.exe が、ユーザー空間の explorer.exe や cmd.exe から呼び出されている。
  • 名前の微妙な違い: lsass.exe ではなく lssass.exe （sが一つ多い）といったタイポスクワッティング手法。

—

3. 【防御の実装】アプリケーション層で何ができるか？

そもそも、なぜPPIDスプーフィングが可能なのか。それは、多くのアプリケーションが「プロセスを生成する権限」を安易に与えすぎているからだ。

特に、Webサーバー上でバックグラウンドタスクを叩く際、不適切な実行権限を与えると、攻撃者はその権限を悪用して親プロセスを偽装する。これを防ぐには、プロセスの起動権限を最小化し、サンドボックス化するのが鉄則だ。

以下は、Pythonで外部コマンドを実行する際に、最低限の権限で、かつ親子関係を監視可能な形で実行するためのセキュアな実装例だ。

import subprocess
import os

def run_secure_command(cmd_args):
    """
    外部コマンド実行時のセキュアな実装例
    1. shell=True を使用しない（シェルインジェクション対策）
    2. 環境変数をクリーンに保つ
    """
    try:
        # 実行パスを厳密に制限し、パスハイジャックを防ぐ
        safe_env = {"PATH": "/usr/local/bin:/usr/bin"}
        
        # subprocess.runで実行（shell=Falseはデフォルトだが明示的に記述）
        result = subprocess.run(
            cmd_args,
            shell=False,
            env=safe_env,
            capture_output=True,
            text=True,
            check=True
        )
        return result.stdout
    except subprocess.CalledProcessError as e:
        # エラーログに詳細なPPIDや実行ユーザーを出力し、後から追跡可能にする
        print(f"Audit Log: Failed execution by PID {os.getpid()}: {e}")
        return None

# 利用例
# run_secure_command(["/usr/bin/python3", "/opt/app/task.py"])

4. インフラレベルでの防御：WAFとEDRの連携

アプリ側の対策に加え、Nginx等のゲートウェイ層で、怪しいプロセス起動を誘発するようなリクエストをブロックする必要がある。

# Nginxでシェルコマンドに関連する文字列をブロックする設定例
# Webアプリの脆弱性を突いてプロセス起動を試みる攻撃を遮断
location / {
    if ($query_string ~* "(cmd\.exe|powershell\.exe|lsass\.exe|proc_open)") {
        return 403;
    }
}

—

最後に：エンジニアが持つべき「疑いの目」

いいかい、メモリフォレンジックは「答え合わせ」に過ぎない。インシデントレスポンスの真髄は、その前の設計段階で「このプロセスが偽装されたらどうやって検知するか？」を考慮できているかにある。

もし君が開発したシステムで pstree を叩いたとき、期待通りの静かなツリーが表示されるなら、それは良い設計ができている証拠だ。だが、少しでも「なぜここにこのプロセスが？」という違和感を感じたら、即座にメモリをダンプし、Volatilityで深掘りしてほしい。

技術は常に攻撃者とのいたちごっこだ。だが、その追跡のログを残すという「泥臭い努力」だけは、何年経っても色褪せない最強の武器になる。現場からは以上だ。

スポンサーリンク

コメント

タイトルとURLをコピーしました