この投稿は、Xabier Ugarte Pedrero が執筆しました。
2017 年 7 月に Talos は、Python Scriptable Reverse Engineering Sandbox（PyREBox
; Python スクリプトで操作できるリバース エンジニアリング サンドボックス）をオープン ソース ツールとして公開しました。このプロジェクトは、シスコにおけるワークフローの改善のために継続的取り組んでいる、新たなツール開発の一環として行われているものです。PyREBox は、QEMU を基盤としている多用途のインストルメンテーション フレームワークです。
このツールでは、仮想環境（エミュレータ）でオペレーティング システム全体を起動して、メモリとレジスタを実行時に検査し、変更することができます。QEMU をわずかに修正するだけで、命令の実行やメモリの読み書きなどの特定のイベントをインストルメントすることもできます。
さらに、仮想マシン イントロスペクション技術を利用して、セマンティック ギャップを埋める（プロセス、スレッド、ライブラリなどの OS 抽象化を解析する）ことも可能です。PyREBox のフレームワークと機能の詳細については、過去のブログ投稿をご覧ください。
ここ数ヵ月、Talos ではコミュニティから好意的なフィードバックをいただき、ユーザからの報告をもとにバグの修正、機能の追加を行ってきました。さらに、ゲストとして GNU/Linux のサポートを追加し、エージェント（エミュレートされたゲスト内で実行されるプログラム）を実装しました。このエージェントは、ホストとゲスト間でファイル転送を行い、オンデマンドでゲスト内のサンプルを実行するものです。
現在行っている取り組みの一環として、本日（4 月 13 日）マルウェア分析の支援を目的とした PyREBox スクリプト セット Malware monitor をリリースします。これらのスクリプトは、コード カバレッジ分析、API トレース、メモリ モニタリング、プロセスのメモリ ダンプなどのさまざまなタスクを自動化します。
新しいツールセットには、プログラムを実行して抽出した情報を視覚化するのに役立つ IDA Python スクリプトも含まれています。これらのツールはすべて JSON 設定ファイルによって設定可能であり、サンプルの実行/分析の自動化に役立ちます。
当該スクリプトは、Hack In the Box カンファレンス（アムステルダム開催）の CommSec トラックの一環として行われる、PyREBox に関する初の一般講演の際にリリースされます。 その講演の補足として、本ブログ投稿では、新しくリリースされた機能について簡単に説明します。
コード カバレッジ
リバース エンジニアリング プロセス中にバイナリで実行されるコード パスを理解することは、研究者にとって非常に有用です。静的分析によりコードの全体像をつかむことはできますが、ある特定のコード部分が実行されるかどうかは、事前にはわからないことが少なくありません。
コード パスの分析では、複雑な処理やパスの条件を予測することが必要な場合が多くあります。このような制約を受けないように、リバース エンジニアは、静的分析と、サンドボックスやデバッガなどの動的分析ツールを組み合わせて使用します。あるコード パスが実行されるかどうかを把握するには、命令単位でサンプル命令をトレースするか、ブレークポイントを設定してサンプルを実行し、実行中のある時点に設定されたブレークポイントにヒットするのを待ちます。
前者のアプローチは時間がかかる可能性があります。一方、後者は、多くの試行錯誤が必要となり、サンプルを実行してもどのブレークポイントにもヒットせず、マルウェアがシステムに完全に感染してしまうこともあります。その場合は通常、クリーンなマシンのスナップショットを復元してから分析プロセスを再開する必要があります。
このような状況においては、コード カバレッジに関する情報があると、どの命令が実行されたかを詳細に把握するのに役立ちます。Malware monitor のコード カバレッジ モジュールは、エミュレータにおける変換ブロックの実行をトレースするものです。
便宜上、変換ブロックを基本ブロックと同等なものとして定義しますが、実際には、QEMU で命令を変換ブロックと（正式な定義上の）基本ブロックに分割する方法は若干異なります。
いずれにせよ、コード カバレッジ モジュールは、2 つの異なる出力ファイル（バイナリ トレース ファイルとテキスト サマリー）を生成します。バイナリ トレースを IDA にインポートすると、エミュレータで実行されるコード ブロックを色分けして表示することができるため、ユーザは実行中にどのコード パスが使用されたか一目でわかります。
図 1. IDA のグラフ表示。実行されたブロックはオレンジ色、実行されなかった基本ブロックは白いままで表示。
テキスト サマリーでは、実行されたメモリ領域の全体的なサマリーが得られます。さらに、ある仮想アドレス記述子（VAD）領域から別の VAD 領域に実行がジャンプする場合の実行遷移が示されます。VAD は、Windows が使用する内部構造で、特定の仮想アドレス空間に予約されたさまざまなメモリ領域がツリー形式で管理されます。
プロセスのメイン モジュール、インポートされた DLL、スタック、ヒープ、その他の割り当て済みメモリ領域がすべて、独立した VAD 領域としてツリーに表示されます。したがって、このログにより、実行時にメイン モジュール外または DLL 外にあるメモリ バッファに実行がジャンプするポイントをトレース内で見つけることができます。この動作は通常、一部のランタイム パッカーで検出されます。
ログには、遷移した後に各 VAD 領域で実行される最初の命令アドレスも含まれるため、場合によっては、アンパックされたバイナリのオリジナル エントリ ポイント（OEP）を特定するのに役立ちます。
図 2. カバレッジのテキスト ログ ファイルの一部。VAD 領域間で複数回遷移していることを示している。
API トレーサ
Malware monitor の 2 番目のコンポーネントで、一般的な Windows DLL（Windows API）の関数呼び出しをトレースすることで、サンプルの動作が把握できます。ほとんどの API トレース フレームワークやサンドボックスでは、従来の API フッキングが使用されるためプロセス メモリを変更する必要があり、検出される可能性のあるアーティファクトが生成されてしまいますが、Malware monitor の API トレース機能は、完全にゲスト システム外で実行されます。
API トレーサ モジュールは、特定の命令（call/jmp など）のみを測定し、フロー制御命令のいずれかによって Windows API 関数の先頭バイトにジャンプするタイミングを検出します。
API トレーサで使用できるモードは、2 つあります（ライト モードとフル モード）。ライト モードが有効になっている場合、API 関数呼び出しがログに記録されるだけで、パラメータの検査は行われません。一方フル モードの場合は、API 関数呼び出しが発生するたびにスタックとレジスタが検査されます。
フル モードでは、API パラメータの数、その名前とデータ型に関する情報を含むデータベースが利用されています。API トレーサ モジュールでは、ポインタと入れ子構造をデリファレンスすることができます。
生成された情報は、テキスト ファイルに書き込まれるか、バイナリ ファイルに保存されるため、後で IDA で読み込んで可視化することが可能です。IDA にインポートされた情報は 2 箇所で確認できます。1 つは、検索機能を備えた専用タブで、もう 1 つは、トレースされたすべての呼び出しに関するコンテキスト メニューです。
図 3. IDA で表示される専用タブ。関数呼び出しと入出力パラメータを検査できる。
図 4. API 呼び出しトレース（テキスト ログ）の抜粋
メモリ モニタ
3 番目のコンポーネントであるメモリ モニタは、サンプルの実行中に以下のようなメモリ関連の各種イベントをトラッキングします。
- プロセス生成
- リモート プロセス メモリの読み取り/書き込み
- メモリ共有（共有メモリ領域）
- ファイルの読み取り/書き込み
- ファイルのメモリへのマッピング
- メモリの割り当て
- メモリ アクセス権限の変更
上記イベントがモニタ対象になっているため、研究者は、バッファのアンパック、プロセス生成、プロセス インジェクションなどの面に焦点を絞って、メモリに関連したサンプルの動作を把握できるようになります。このモジュールには、ファイル ドロップ イベントのモニタ機能もあります。ファイル ドロップは、分析対象のサンプルがバイナリをディスクに書き込んで実行する際に発生するイベントです。
メモリの動作に関する情報は、2 つのレポートにまとめられます。一方のレポートには上記カテゴリに関連する全イベントが含まれ、もう一方のレポートには以下のような情報を収集して要約した内容が含まれます。
- 起動されたプロセスとインジェクトされたプロセス
- 上記プロセスによって読み込まれたモジュール/DLL
- 各プロセスの VAD 領域（コード インジェクションが推測される領域含む）、通常とは異なるアクセス権限とそのアクセス権限の変更
- メモリ マップ（マップされたファイルとメモリ共有）
- メモリ インジェクション
- ファイル操作
サマリー情報は、マルウェアのブートストラップ ルーチンの概要を把握するのに役立ちます。多くのマルウェア ファミリには、システム メモリに展開する必要があるコンポーネントが含まれています。展開の一環として、1 つ以上のシステム プロセスに対するペイロードのインジェクション、他のプロセスの生成、ディスクへのファイルのドロップなどを行うマルウェアが多くみられます。
PyREBox のメモリ モニタ コンポーネントにより、展開フェーズ中のサンプルにおけるメモリ関連の動作など、初期情報をアナリストに提供することができます。
メモリ ダンパー
Malware monitor の最後のコンポーネントは、設定可能なメモリ ダンパーです。メイン モジュール、ロードされた DLL、その他のメモリ領域（ヒープ、スタック、割り当てられたバッファ）などのプロセス メモリを、実行中の特定のポイントでダンプすることができます。メモリのダンプに適切なポイントはユーザが選択し、メインの JSON 設定ファイルに設定する必要があります。以下のオプションを指定できます。
- プロセス終了時のメモリをダンプする。
- 特定の API 関数が呼び出されたときのメモリをダンプする。
- 特定のアドレスが実行されたときのメモリをダンプする。
サンプルが完全にアンパックされた時点でメモリをダンプするには、サンプルの仕組みについての知識が必要ですが、Malware monitor の他のモジュールを利用して、プロセス メモリをダンプするポイントをユーザが特定することが可能です。
メモリ ダンプ、およびプロセスのメモリ領域に関する情報が生成されたら、ダンプされたセグメントを IDA に手動で読み込み、アンパックされたプロセスを静的に分析できます。
まとめ
新しくリリースされた Malware monitor コンポーネントは、サンプルの実行情報を収集し、従来のサンドボックスやデバッガから抽出されたデータを補完するのに役立ちます。
今回は、PyREBox がマルウェア分析ワークフローに不可欠なツールであることの例を示しただけですが、ここで紹介したモジュールは、初期の情報収集分析フェーズにおいてリバース エンジニアに役立つものです。
強力で多用途に利用できる PyREBox はカスタマイズ可能なため、各ユーザが自分の研究分野に応じて独自のスクリプトを作成することをお勧めします。
本稿は 2018年4月13日に Talos Group
Authors