Reverse Engineering Rootkits, その１
先日の Black Hat で受けたトレーニングの内容を簡単にまとめておきます。受講したコースはこれ。
Reverse Engineering Rootkits by Greg Hoglund, HBGary & Rich Cummings, HBGary
概要
講師：Greg Hoglund, Rich Cummings (www.hbgary.com)
日時：2008年8月4日〜8月5日
まずタイトルが紛らわしいのだが、このトレーニングコースはリバースエンジニアリングのコースではない。インシデントレスポンスのコースだと思ったほうがいい。主要なテーマは次の2つ。
- Live Memory Forensics
- Binary and Runtime Forensics
メインは2つめのバイナリ解析で、これをいかに早く（5分〜30分くらいで）行うか、という点に主眼がおかれている。そしてそれをサポートするツールとして、HBGary の Responder を使用する。本格的な調査については、その後時間をかけて IDA Pro でも使ってリバースしてね、という感じ。
またメモリ解析についても、実際にインシデントが発生したシステムのメモリイメージを取得して解析するという通常のパターン以外に、VMware 上でマルウェアを実行し、そのときのメモリイメージを取得して解析するという方法も用いている。というかむしろこちらがメインかも。
メモリイメージの取得
以前は FAU（Forensics Aquisition Utilities) に含まれている dd.exe くらいしか選択肢はなかったが、今ではメモリイメージ取得に対応したツールが多数ある。
（注）最新バージョンのFAUでは、\\.\PhysicalMemory を入力デバイスとしてサポートしていない。そのため古いバージョンを使う必要がある。（例えば Helixに付属しているものとか。）
ManTech Memory DD（mdd）
Win32dd
Agile Risk Management Nigilant32
Guidance WinEn
EnCase v6.11 以降に付属している。
HBGary FastDump
http://www.hbgary.com/download_fastdump.html
Responder Pro に付属している。上記からダウンロードも可。まだ Vista に対応していないが、来月出る予定の次期バージョンで対応予定。
これらはターゲットシステム上での実行時に複数のシステムDLLをロードする。これはマルウェア等によってシステムが改ざんされている状況を想定した場合、あまり望ましくない。FastDumpはこの点を考慮して作られているようで、上記ツールの中ではロードする DLL が最も少ない。（kernel32.dllだけ）
それでもカーネルモードの rootkit が仕込まれている環境では、メモリイメージが正しく取得できているという保証はない。
Responder によるメモリ解析
まず新規プロジェクトを作成し、ケース名やケース番号などを記述したあと、メモリイメージファイルをインポートする。ddで作成したイメージファイルの他に、EnCaseで作成したイメージや、VMwareのスナップショットのメモリイメージも解析することができる。
左側のペインにツリー表示される項目は次のとおり。
- Hardware
- Interrupt Table (IDT)
- Operating System
- All Analyzed Strings => 最初は空、解析が進むと結果が反映される
- All Analyzed Symbols => 最初は空、解析が進むと結果が反映される
- All Open Files => File Name, Path, Process
- All Open Network Sockets => src, dst, type(tcp/udp), process
- All Open Registry Keys => Key Name, Path, Process
- Drivers => ドライバファイルの一覧が表示される
- Processes => プロセスの一覧が表示される
- System Call Table (SSDT)
Drivers と Processes はさらに下位のツリーが表示され、ドライバ名、プロセス名毎に詳細な解析を行うことができる。
プロセス単位でツリーに表示される項目は次のとおり。
- Memory Map
- Modules => ロードされているモジュール一覧が表示される
- Open Files
- Open Network Sockets
- Open Registry Keys
- Threads
Modules にはそのバイナリ自身も含めてロードされているモジュール一覧がさらに下位のツリーで表示される。
モジュール単位でツリーに表示される項目は次のとおり。(ドライバ単位の表示項目と同じ)
- Bookmarks
- Global => 逆アセンブルされたコードが表示される
- Strings
- Symbols
Responder によるバイナリ解析
トレーニングでは、Responder の基本的な使い方についての説明があった後は、演習中心の内容となる。マルウェアの解析では、以下の 6つのカテゴリ("factors")についてそれぞれ調査していく。
- Development Factors
- どの国で作られたのか、作ったのはプロか、など
- Communication Factors
- どこに接続するか、外部からの接続は可能か、暗号化しているか、など
- Command and Control Factors
- どのようなコマンドが実装されているか、どのように外部からコントロールされているか、など
- Installation and Deployment Factors
- レジストリを使うか、ファイルを作成するか、他のマシンに感染するか、など
- Information Security Factors
- どのような情報が漏洩したか、キーロガーはあるか、データを破壊したか、など
- Defensive Factors
- 検知されたり、解析されるのを回避する仕組みがあるか
また Responder では直接バイナリファイルを読み込んで解析することもできるが、より詳細な解析を行うためには、VMware などの仮想環境内においてマルウェアを実行し、その際のメモリイメージを取得して解析する。トレーニングでは、この方法を解説していた。使用するツールは次のとおり。
- VMware Workstation (Guest OS: Windows XP SP2)
- Sysinternals Debug View
- HBGary Flypaper
Flypaper は解析支援ツールとでもいうもので、実行されるとその環境内でマルウェアがプロセスやスレッドを終了したり、メモリ内のデータを削除したりすることをブロックする働きがある。そのためメモリイメージによるマルウェアの解析が容易になる。なお Debug View は Flypaper のデバック出力をキャプチャするために使用する。
解析手順はこんな感じ。
- VMware のゲストOSを起動する (当然クリーンな状態で)
- Debug View と Flypaper を VM内にコピーする
- スナップショット(1)を作成する
- 解析対象のマルウェアを VM内にコピーする
- Debug View を起動する
- Flypaper を起動する
- マルウェアを実行して少し様子を見る
- スナップショット(2)を作成する
- Debug View のログをホストOSにコピーする
- Responder でスナップショット(2)のメモリイメージをインポートして解析する
VM実行時の注意点として、事前にネットワーク接続の設定で、「Microsoft ネットワーク用クライアント」と「Microsoft ネットワーク用ファイルとプリンタ共有」を無効に（アンインストール）しておくことがあげられていた。
力尽きたので、続きはまた。
