【実務・中級編】メモリ上の環境変数とコマンドライン引数の解析による攻撃者の意図特定 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

痕跡は「揮発性」の中に宿る：メモリフォレンジックで暴く攻撃者の本心

現場でインシデント対応をしていると、よく「ログを消されたので手詰まりです」という報告を受ける。だが、プロの視点から言わせてもらえば、それは「証拠を捨てる場所を間違えている」だけだ。攻撃者がどれほど巧妙にディスク上のログを削除し、タイムスタンプを偽装しようとも、彼らが実行した「生のコマンド」や「復号されたスクリプト」は、必ずプロセスのメモリ上にその姿を晒している。

今日は、攻撃者が隠したがる「メモリ上の環境変数とコマンドライン引数」をどう特定し、彼らの意図を暴くか、そしてそれを許さないシステム設計について深掘りしていく。

なぜ攻撃者は「メモリ」に逃げるのか

攻撃者は、PowerShellを用いたファイルレス攻撃を好む。例えば、以下のような難読化されたワンライナーを実行するケースだ。

# 攻撃者がよく使う難読化の例
powershell.exe -e JABzACAAPQAgAE4AZQB3AC0ATwBiAGoAZQBjAHQA...

この -e (EncodedCommand) は、Base64でエンコードされたスクリプトを実行する。ディスクにはスクリプトの実体は残らない。だが、OSがこのプロセスを起動する瞬間、メモリ内には「デコード後のコマンド」が引数として展開される。

ここで我々がメモリフォレンジックツール（Volatility等）を使ってプロセス情報をダンプすると、_EPROCESS 構造体や PEB (Process Environment Block) を辿ることで、実行時の生引数をいとも簡単に引き出せる。攻撃者が「環境変数」に HTTP_PROXY や AWS_ACCESS_KEY を一時的にセットしていれば、それすらも丸見えだ。

攻撃者の意図を特定する「泥臭い」調査手法

攻撃者の意図を特定する際、我々が見ているのは「引数」だけではない。特に注目すべきは 「環境変数の不自然な上書き」 だ。

例えば、攻撃者が特定のツールを実行する際に COMPLUS_Version や PSModulePath を書き換えて、自身が用意した悪意あるDLLを読み込ませる（DLLハイジャック）手法がある。メモリ上の環境変数を解析すれば、「どのパスを優先的に見に行こうとしたか」が明白になる。これが、単なる侵入なのか、それとも特定のデータベースを狙ったデータ窃取なのかを判断する決定的な証拠となる。

「引数に機密を入れない」ための堅牢な実装

「メモリを解析すれば分かる」ということは、逆に言えば 「OSの引数に機密情報を渡すな」 という鉄則に繋がる。システムエンジニアが陥りやすい罠は、スクリプト内でパスワードを直接引数として渡してしまうことだ。

❌ やってはいけない実装（Python）

import subprocess
# 絶対にダメ。psコマンドでパスワードが丸見えになる
password = "supersecretpassword"
subprocess.run(f"db_backup.sh --password {password}", shell=True)

これを防ぐには、環境変数や引数ではなく、標準入力（stdin）や一時ファイル経由で安全に渡すのが定石だ。

✅ セキュアな実装（Python）

import subprocess
import os

# 環境変数を汚さず、安全に渡す
password = os.environ.get("DB_PASSWORD") # 安全な場所から取得

# subprocess.runの引数にリスト形式で渡す（shell=Trueを避ける）
# これにより、プロセス引数の解析からパスワードが漏れるリスクを最小化する
subprocess.run(["/usr/bin/db_backup.sh"], input=password, text=True)

インフラ層での防御：WAFとプロセス監視

アプリケーション側での対策に加え、インフラ側でも「コマンドライン引数」の監視を強制すべきだ。

Nginxやクラウド環境であれば、怪しいリクエストが実行された際の「実行ユーザー」と「実行環境」を紐付ける監査ログを有効にしよう。AWSを使っているなら、CloudTrail だけでなく、Systems Manager (SSM) のセッションマネージャーを使用して、実行されたコマンドを全ログ記録する設定（S3バケットへの転送）が必須だ。

以下は、NGINXでPowerShellのエンコードコマンドを含む不審なリクエストをブロックする設定例である。

# Nginx設定ファイル: 不審なBase64エンコードコマンドをブロック
location / {
    # PowerShellの難読化によく使われるパターンを正規表現で弾く
    if ($args ~* "(encodedcommand|-e\s+[A-Za-z0-9+/]{20,})") {
        return 403;
    }
    try_files $uri $uri/ /index.php?$query_string;
}

最後に：エンジニアとして持つべき視点

フォレンジックとは、単なる「事後の死体検分」ではない。システムがどのような状態であれば攻撃者が攻撃しにくいか、あるいは攻撃したとしても「隠し場所がない」状態を作れるか。それを逆算して設計することだ。

メモリ上に痕跡を残さないことは不可能だ。ならば、その痕跡を解析される前提で、「機密情報を含めない」「引数をリストで渡す」「不審なプロセス起動を即座にアラートする」という多層防御こそが、あなたを、そしてあなたの守るシステムを最強の盾にする。

次にコードを書くとき、「この引数はメモリにダンプされたらどう見えるか？」を一度自問してほしい。その一瞬の思考が、将来のインシデントを未然に防ぐ最大のセキュリティ対策になるはずだ。