【テクニカル・上級編】 メモリダンプにおける文字列検索とYARAルールの活用 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

現場の泥臭さとメモリフォレンジックの真実

インシデントレスポンスの現場において、揮発性メモリの取得ほど緊張感を伴うフェーズはない。ディスクフォレンジックが「犯行後の現場検証」だとすれば、メモリフォレンジックは「犯人がまだ室内に潜んでいる状態での息遣いの聴取」に等しい。プロセスインジェクション、ファイルレスマルウェア、難読化されたPowerShellスクリプト、そしてカーネルモードのルートキット――これらはすべて、静的なストレージの上では綺麗に身を隠し、動的なRAMの宇宙でのみその正体を暴かれる。

しかし、数ギガバイト、あるいは数十ギガバイトに及ぶメモリダンプを前にして、我々アナリストが直面するのは「情報の海」という絶望的な現実だ。すべてのプロセス空間を人海戦術で追うことなど不可能であり、効率的なシグネチャマッチングの自動化が不可欠となる。ここで真価を発揮するのが、文字列検索の拡張としての YARAルール である。

今回は、単なるツールの使い方という初歩的な解説にとどまらない。攻撃者がメモリ上でいかに身を隠そうとするかという低レイヤの挙動を踏まえ、実践的なメモリダンプ解析と高度なYARAルール設計の極意を、現場の知見を交えて徹底的に解説する。

—

1. メモリ空間におけるアノマリーと文字列検索の限界

サイバー犯罪者や高度な持続的標的型攻撃（APT）グループは、もはや古典的なマルウェアのバイナリをそのままディスクに保存しない。彼らが好むのは、初期侵入後にメモリ上でコードを組み立て、ディスクに一切痕跡を残さずに実行する「Living off the Land（LotL）」手法やメモリインジェクションである。

プロセスインジェクションの低レイヤ挙動

例えば、一般的な CreateRemoteThread や NtCreateThreadEx を用いたDLLインジェクション、あるいはプロセスHollowking（プロセス置換）では、標的となる正当なプロセス（explorer.exe や svchost.exe など）の仮想アドレス空間にリモート領域が割り当てられ、そこにペイロードが書き込まれる。

この時、メモリダンプを単純な strings コマンドで全検索すると、以下のような問題に直面する。

  • ノイズの多さ: 数千万行に及ぶASCIIおよびUnicodeの文字列が出力され、真のインジケーター（IoC）が埋もれる。
  • 文脈の喪失: 文字列がどのプロセス、どの仮想アドレス範囲、あるいはどのVAD（Virtual Address Descriptor）ノードに属していたかのコンテキストが失われる。
  • エンコードと難読化: 現代のマルウェアは、単純な文字列を平文で持たず、スタックストリングス、XORエンコード、あるいはAES等の暗号化を用いてメモリ上でも難読化を試みる。

したがって、単に「文字列を探す」のではなく、「構造化されたメモリイメージに対し、特定のパターン（バイト列、正規表現、条件分岐）を高速にスキャンする」ためのフレームワークが必要となる。それがYARAだ。

—

2. Volatility 3 と YARA の統合による高度なハンティング

メモリフォレンジックのデファクトスタンダードである Volatility Framework（特に Volatility 3）は、YARAスキャンを直接サポートしている。これにより、物理メモリダンプ全体の生データに対してだけでなく、特定のプロセスヒープやカーネル空間に対して、ターゲットを絞ったYARAスキャンを実行できる。

実務において最も強力なアプローチの一つは、不審なプロセス空間のダンプ、あるいはメモリ上のすべての実行可能領域（PAGE_EXECUTE_READ や PAGE_EXECUTE_READWRITE）を抽出し、そこにYARAを適用することだ。

実践：Volatility 3 によるYARAスキャンのワークフロー

以下は、不審なプロセス（例えば、親プロセスが不自然な cmd.exe であるプロセスなど）のメモリ空間を特定し、そこにYARAルールを適用してインジェクションされたコードをあぶり出す際の実践的なコマンドラインの思考プロセスである。

まず、プロセスのリストを取得し、怪しいPIDを特定する。

# プロセス一覧を取得し、ツリー構造とVAD（仮想アドレス記述子）の状態を確認する
python3 vol.py -f memdump.raw windows.pslist

不審なPID（例: 4104）が特定できたら、そのプロセスのメモリマップ（VAD）を精査し、特にアクセス権が PAGE_EXECUTE_READWRITE（RWX）になっている不自然な領域を探す。さらに確実な方法として、Volatilityのプラグインを用いてプロセス全体のメモリダンプを切り出すか、直接YARAプラグインを使用する。

# Volatility 3 の yara.YaraScan プラグインを使用してメモリイメージ全体をスキャンする
python3 vol.py -f memdump.raw -o /path/to/output windows.yanscan.YaraScan --yara-file /path/to/custom_rules.yar

しかし、実戦経験豊富なアナリストであれば知っている通り、生イメージ全体への単純な YaraScan は膨大な時間がかかる。そのため、あらかじめ不審なプロセスのヒープや仮想アドレス範囲を絞り込むか、次節で解説する「文脈を考慮したカスタムYARAルール」を設計する必要がある。

—

3. 誤検知をゼロにし、脅威を逃さないYARAルールの設計哲学

オープンソースのYARAルール（Cuckoo SandboxやLokiなどが提供する著名なルールセット）をそのままメモリフォレンジックに適用すると、大抵の場合、正当なサードパーティ製アプリケーション（ブラウザやセキュリティソフトのドライバなど）にヒットしてアラートの嵐（ノイズ）に見舞われる。

メモリフォレンジックにおけるYARAルールは、ディスク上の静的ファイルスキャンとは異なり、以下の特性を考慮して設計されなければならない。

1. アライメント（境界）の考慮: メモリ上のデータはページの境界（通常4KB）や特定のオフセットに配置されるため、広範すぎるワイルドカードはパフォーマンスを著しく低下させる。
2. PEヘッダの欠如: インジェクションされたペイロードやシェルコードは、通常のPEファイル（MZヘッダ）を持たないことがある。そのため、ヘッダに依存しない「コードの断片（プロローグ・エピローグ）」や「特定APIのハッシュ値・インポート文字列」をターゲットにする必要がある。
3. エントロピーと構造: 難読化・パッキングされた領域はエントロピーが高くなる傾向がある。

実践的なカスタムYARAルールの例

以下に、メモリ上で巧妙に隠匿されたシェルコードや、リバースシェルを展開するペイロードの共通パターンを検出するために最適化されたYARAルールのサンプルを示す。

rule Detect_Memory_Injected_Shellcode_Advanced {
    meta:
        author = "SOC Lead Analyst"
        description = "Detects common x64 reverse shell stub patterns and API hashing loops in memory dumps"
        reference = "Internal Incident Response Case #202X-089"
        severity = "Critical"
        date = "202X-10-15"

    strings:
        // Windows x64でAPIハッシング（Dynamic API Resolution）によく見られるWin32 APIのハッシュ値計算ルーチンや特徴的なバイト列
        // 例: gs:[0x60] によるPEB（Process Environment Block）へのアクセス
        $peb_access_x64 = { 65 48 8B 04 25 60 00 00 00 }
        
        // よくあるリバースシェルやペイロードで見られるソケット作成関連のAPI名文字列（スタックストリングス対策として部分一致）
        $api_ws2_32 = "WSAStartup" ascii wide
        $api_socket = "WSASocketA" ascii wide
        $api_connect = "connect" ascii wide

        // 難読化されていない単純なIPv4アドレスやポートバインドの痕跡（例: ポート4444のHEX表現: 0x115C -> 5C 11）
        // 実際の運用では動的なC2IPに書き換えられるため、プレースホルダー的なパターンを使用
        $common_port_bind = { 66 C7 44 24 ?? 5C 11 }

    condition:
        // PEヘッダを持たないメモリ領域（シェルコード等）を想定し、
        // PEBへのアクセスと、ネットワーク関連APIの文字列または特徴的命令が同時に存在する場合にヒットとする
        uint16(0) != 0x5A4D and 
        $peb_access_x64 and 
        (2 of ($api_*)) or
        $common_port_bind
}

このYARAルールにおける最大のポイントは、uint16(0) != 0x5A4D という条件にある。0x5A4D はお馴染みの MZ ヘッダの魔法定数（Magic Number）である。もしスキャン対象のメモリ領域が正当なPEファイルの先頭であれば、この条件によって除外される。逆に、プロセス空間のヒープやスタック、あるいはインジェクションされた無名のメモリ領域に展開された「ファイルレスシェルコード」のみをピンポイントで狙い撃つことができる。

—

4. チーフホワイトハッカーが実践する効率的なトリアージ戦略

実際のインシデント対応において、限られた時間の中で最大の成果を上げるためには、ツールを回す順番と判断基準が命運を分ける。筆者が現場で指揮を執る際に行っている、メモリダンプにおけるYARA活用のベストプラクティスを共有しよう。

1. ベースラインの確立とノイズの排除:
同一環境の健全な端末から取得したメモリダンプをあらかじめスキャンし、組織特有の業務アプリケーションが発する既知のアラート（False Positive）をYARAの condition 句の除外条件（ not (filesize < 10MB and ...) や特定のシグネチャ除外）に組み込んでおく。
2. カーネルメモリとユーザースペースの分離:
RootkitやDirect Kernel Object Manipulation (DKOM) を疑う場合は、ユーザースペースのプロセスダンプではなく、カーネル空間（kernel memory）をターゲットにした専用のYARAルール（例：カーネルドライバの隠蔽パターンやSSDTフック）を適用する。
3. タイムスタンプとVADプロパティの相関分析:
YARAがヒットした仮想アドレスが得られたら、必ずそのアドレスが属するVADの保護属性（保護フラグが PAGE_EXECUTE_READWRITE に変更されていないか）、およびその領域を割り当てた親プロセスの挙動をタイムライン上で逆算する。文字列やバイト列の合致だけでなく、「なぜそこにそのコードが存在しているのか」という文脈（Context）の検証こそが、フォレンジックの質を決定づける。

—

5. 結びにかえて

メモリフォレンジックにおける文字列検索とYARAの活用は、単に「既知のマルウェアを見つけるための作業」ではない。それは、複雑化・高度化する攻撃者の手法――ディスクを汚さず、OSの正当な機能を悪用してシステム内部に溶け込む影――を、極限まで低レイヤの視点から暴き出すための「論理的メス」である。

教科書通りのコマンドを実行するだけでは、現代の巧妙なインシデントを解決することはできない。メモリの構造、CPUアーキテクチャの挙動、そして攻撃者が描くシナリオの裏を読み解きながら、自ら精度の高いYARAルールを紡ぎ出す。その執念と技術力こそが、真のインシデントレスポンスエンジニアの武器となるのだ。

スポンサーリンク

コメント

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