フォティーンフォティ技術研究所 先端技術研究部長
村上 純一
2009年11月4日から6日にかけて，京都でAVAR（Association of anti-Virus Researchers）国際会議2009が開催された。AVAR国際会議は，名称の通りウイルス対策ソフト・ベンダーが中心となり，最新のマルウエア技術，犯罪事例などについて意見交換することを目的としたカンファレンスである。
幸運なことに，このカンファレンスで研究成果の一部を発表する機会を得た。今回は，発表内容である「FFR GreenKiller - Automatic kernel-mode malware analysis system」について紹介したい（発表スライドはフォティーンフォティ技術研究所のWebサイトで公開している）。
カーネル・モードで動作するマルウエア
本連載で紹介してきたように，近年はルートキットを含め，カーネル・モードで動作するマルウエアが多数確認されている。ルートキットはシステム情報を操作・隠ぺいするタイプのマルウエアだが，中にはカーネル・モードで能動的に外部のサーバーと通信し，コマンドを受信・実行する“ボット”の存在も確認されている。
カーネル・モードで動作するマルウエアとユーザー・モードで動作するマルウエアの最大の違いは，開発および解析の難易度である。通常，Windows環境では管理者権限さえあれば実質的にはどんなことでもできるため，システムに想定される脅威はカーネル・モード，ユーザー・モードで大差はない（情報の奪取，ボット化など）。一般的に，カーネル・モードでのプログラミングには，ユーザー・モードのそれとは違った概念の理解，注意深さが要求される。ユーザー・モードで動作するプログラムは，OSという土台の上で数多く実行されるプロセスの一つであり，実行時に発生するエラーはOSが面倒を見てくれる。これに対してカーネル・モードで動作するプログラムはOSの一部であり，OSが適切にハンドルできないエラーはBSOD（Blue Screen Of Death）に直結する。このため，カーネル・モードで動作するマルウエアを開発するには相応の技術力が必要になる。
一方，対策を講じる側には，「開発の技術力＋解析の技術力」が必要となる。結局のところ，マルウエア解析は開発時のデバッグの延長線上に存在するため，開発側と同等以上の知識・技術がなければ対処できない（解析と開発時におけるデバッグの最大の違いは，ソースコードの有無である）。
上記のほかにも解析を困難にする要素がある。解析に必要なノウハウ，ツールといった環境の不足である。ユーザー・モードで動作するマルウエアは過去に数え切れないほど開発，解析されてきたため，攻撃する側にも，守る側にもノウハウ，環境が整備されている。例えばユーザー・モード・マルウエアの場合，CWSandbox，Norman Sandbox，Anubisなどの自動解析システムがあり，よく利用されている。自動解析という性質上，すべてを正確に把握することは難しいが，手動解析の足掛かりを得るためにマルウエアの動作概要を把握するのには有用である。FFRでもこうしたユーザー・モード・マルウエアを自動解析するシステムを開発，運用しているが，感覚的には9割以上のマルウエアに対して有用な解析を行うことができている。
しかしカーネル・モード・マルウエアは比較的歴史が浅く，特にツールなどの環境整備が不十分である。そこでカーネル・モード・マルウエアの自動解析を目的として開発したシステムがFFR GreenKillerである。
FFR GreenKiller
FFR GreenKillerでは，仮想化技術を利用している。具体的には，ゲストOSの下層で動作するハイパーバイザ上に解析エンジンを実装した。カーネル・モード・マルウエアがデバイス・ドライバとして実装されていることを前提としている。こうすることで，ゲストOSから透過的に解析できる（図1）。実際には，，カーネル空間へのアクセス手法はデバイス・ドライバ以外にも存在する。\\Device\\PhysicalMemoryオブジェクトを経由したメモリー・アクセスや非公開API（application programming interface）の利用などである。ただ近年は，マルウエアによる悪用を防ぐために，ユーザー側でOSの動作を制限するようになってきている。そのためデバイス・ドライバとしてマルウエアを実装し，カーネル空間にロードする手法を取ることが一般的である。
システムの動作概要はこうだ。まず，ハイパーパイザからゲストOS内のデバイス・ドライバのロードを検知する。Windows環境では，NtLoadDriver関数がこの処理に対応している。そこでハイパーバイザから，ゲストOSのメモリー上に存在する当該コードにソフトウエア・ブレークポイントを挿入し，デバイス・ドライバをロードする関数をフックする。こうすると，ゲストOS内でデバイス・ドライバのロードが発生した際に，NtLoadDriver関数が呼び出されるため，ブレークポイント例外が発生する。この例外をハイパーバイザがハンドリングするという要領である。
実際にはNtLoadDriver関数ではなく，RtlImageNtHeader関数の呼び出し部分をフックしている。これはNtLoadDriver関数が呼び出すIopLoadDriver関数の内部で使われている関数で，メモリー上にロードされている実行ファイルの属性情報などを取得する際に利用される。その引数は，実行ファイル（ここではデバイス・ドライバを装ったマルウエア）のイメージがロードされているメモリー・アドレスであるため，RtlImageNtHeader関数呼び出し時点で処理をフックすることで，ロードされているデバイス・ドライバのメモリー・イメージにアクセスできる。
FFR GreenKillerは，ここからデバイス・ドライバのエントリポイント（プログラムの実行を開始する場所）を算出し，同様にソフトウエア・ブレークポイントを挿入した後，ゲストOSの処理を再開する。これにより，デバイス・ドライバのエントリポイントで再度ハイパーバイザがゲストOSの実行を横取りできるようになる（図2）。
以降，同様にエントリポイントからデバイス・ドライバ中のコードを逆アセンブルし，jmp，callなどの分岐命令ごとに，必要に応じてゲストOSの処理を横取りする。FFR GreenKillerでは，システム初期化時にゲストOSのメモリー上に存在するOSイメージ（ntoskrnl.exeなど）を検査し，カーネル内部で利用されているカーネルAPIとそのアドレスを対応付けたデータベースを作り上げる。このため，分岐先アドレスをカーネルAPIデータベースと照合することで，デバイス・ドライバが実行過程で呼び出すAPIを把握できる。
大まかではあるが，これがFFR GreenKillerの動作概要である。従来，カーネル・モード・マルウエアの解析は，Windbgなどのカーネル・モード・デバッガを利用し，一命令ずつ処理を追っていく必要があった。FFR GreenKillerを利用すれば，カーネル・モード・マルウエアの動作概要をAPI単位で一通り記録できる（図3）。前述のように，これだけでは十分な解析とは言えない。それでも，以後の手動解析のヒントとしては有用である。スタートからゴールまで距離も経路も分からない状態から，一応の”踏み石”が見えるようになったと言える。
フォティーンフォティ技術研究所 先端技術研究部長
