【実務・中級編】メモリ上のファイルレスマルウェアの特定 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

メモリの「亡霊」を捕まえろ：ファイルレス攻撃の実態と防御の極意

現場でインシデント対応をしていると、ディスクフォレンジックだけでは「何も見つからない」ケースに頻繁に遭遇する。ログは消され、ディスク上には怪しいファイル一つ落ちていない。しかし、被害は確実に拡大している。

これがファイルレスマルウェアの恐ろしさだ。彼らはディスクという「物理的な足跡」を残さず、OSの正規機能（PowerShellやWMIなど）を悪用してメモリ空間で直接コードを実行する。今回は、この「メモリの亡霊」をどう特定し、そしてどう防ぐか、現場の視点で語ろう。

なぜファイルレス攻撃が厄介なのか

攻撃者は、ディスクに書き込まないことで、シグネチャベースのアンチウイルスや、単純なファイルスキャンをすり抜ける。彼らが使うのは Invoke-Expression のようなPowerShellのコマンドレットや、難読化された Base64 エンコード文字列だ。

メモリダンプからこれらを抽出する際、我々が注目するのは「実行プロセスがメモリ上に展開した非対称な文字列」や「不審なネットワーク接続を行っているプロセスのメモリ領域」だ。Volatility 3のようなツールを使って解析すると、本来実行されるはずのない動的に確保されたメモリセグメントに、難読化されたスクリプトの断片が浮かび上がってくる。

攻撃の「盲点」を突く：PowerShellの悪用

例えば、攻撃者は以下のようなコマンドをWebサーバの脆弱性（RCE等）経由で送り込む。

# 攻撃者が実行する典型的なファイルレスコードの例
powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -EncodedCommand <難読化されたBase64文字列>

これを受けたシステムは、メモリ上で即座にペイロードを復号し、メモリ内だけで通信用のバックドアを構築する。ディスクには一切残らない。

防御の要：攻撃を「封じ込める」設定

「防ぐ」ためには、攻撃者が悪用する正規機能を「必要最小限」に制限することだ。これが防御の鉄則だ。

1. PowerShellの制限（Constrained Language Mode）

PowerShellは最強のツールだが、セキュリティの観点からは最大の脅威だ。実行環境を厳格に制限する Constrained Language Mode を有効にする。

# 管理者権限で実行し、環境変数を設定して制限をかける
[Environment]::SetEnvironmentVariable('__PSLockdownPolicy', '4', 'Machine')

2. WAFによるペイロードの遮断

Webアプリケーションの入り口で、難読化された Base64 文字列や、powershell.exe を含むリクエストを拒否する。

Nginx + ModSecurity (OWASP CRS) の例:

# 特定の危険なパターンを検知してブロックする設定
SecRule ARGS "@rx (?i)(powershell|base64|invoke-expression)" \
    "id:10001,phase:2,deny,status:403,msg:'Fileless Attack Pattern Detected'"

開発者が実装すべき「防御の盾」

Webアプリケーション側でも、OSコマンドを直接実行するような脆弱なコードは論外だ。しかし、どうしても外部コマンドが必要な場合は、入力を完全にサニタイズし、シェル経由の実行を避けること。

PHPでの安全なコマンド実行（シェル経由を避ける）:

<?php
/**
 * ファイルレス攻撃を防ぐためのセキュアな実装例
 * exec() や shell_exec() は使用せず、引数を配列として渡す proc_open を推奨
 */

function secure_execute($command, $args) {
    // 実行可能なコマンドをホワイトリストで制限する
    $allowed_commands = ['/usr/bin/convert', '/usr/bin/git'];
    if (!in_array($command, $allowed_commands)) {
        throw new Exception("許可されていないコマンドです。");
    }

    $descriptorspec = [
        0 => ["pipe", "r"], // stdin
        1 => ["pipe", "w"], // stdout
        2 => ["pipe", "w"]  // stderr
    ];

    // proc_openはシェルを経由しないため、インジェクションに強い
    $process = proc_open(array_merge([$command], $args), $descriptorspec, $pipes);

    if (is_resource($process)) {
        fclose($pipes[0]);
        $output = stream_get_contents($pipes[1]);
        fclose($pipes[1]);
        proc_close($process);
        return $output;
    }
}
?>

最後に：エンジニアが持つべき「疑心暗鬼」

メモリフォレンジックは、最後の手札だ。しかし、そこに頼らざるを得ない状況を作らないことこそが、真のインシデントレスポンスである。

1. ログを信じすぎない: プロセス起動ログだけではファイルレス攻撃は見抜けない。EDRによる「メモリダンプの定期取得」と「プロセスツリーの監視」を導入せよ。
2. 正規機能の悪用を監視する: powershell.exe がWebサーバのプロセスから起動されること自体が異常だ。これをアラートの最優先項目に設定しておくこと。

技術は常に攻撃者に有利に働く。だが、防御側には「環境を掌握している」という優位性がある。その優位性を活かすために、OSの挙動を深く理解し、常に「もしメモリ上にマルウェアがいたら？」という視点を持ってほしい。君たちのコードが、次なるインシデントを防ぐ最後の砦になるのだから。