Alkanet
におけるシステムコールの呼出し元動的リンクライブラリの
特定手法
大月 勇人
†
瀧本 栄二
†
齋藤 彰一
‡
毛利 公一
†
†立命館大学
525-8577滋賀県草津市野路東1-1-1
[email protected],{takimoto, mouri}@cs.ritsumei.ac.jp
‡名古屋工業大学 466-8555愛知県名古屋市昭和区御器所町 [email protected] あらまし 近年，マルウェアの脅威が問題となっているが，その対策には，マルウェアの挙動を調 査する必要がある．そこで，我々は，仮想計算機モニタ BitVisorをベースとし，システムコール トレースによってマルウェアを解析する Alkanet を開発している．本論文では，これまで提供し てきたシステムコールトレースに加え，スタックトレースを行うことで，システムコール発行ま でに経由したAPI や呼出し元の動的リンクライブラリを特定する手法について述べる．本手法に より，DLLとして動作するマルウェアや動的に生成されたコードなどを，動的リンクライブラリ やメモリ領域単位でその挙動を解析することが可能となる．
A Method for Identifying System Call Invoker in Dynamic Link
Library
Yuto Otsuki
†
Eiji Takimoto
†
Shoichi Saito
‡
Koichi Mouri
†
†Ritsumeikan University1-1-1 Nojihigashi, Kusatsu, Shiga 525-8577 Japan
[email protected],{takimoto, mouri}@cs.ritsumei.ac.jp
‡Nagoya Institute of Technology
Gokiso-cho, Showa-ku, Nagoya, Aichi, 466-8555 Japan [email protected]
Abstract Recently, malware has become a major security threat to computers. Responding to
threats from malware requires malware analysis and understanding malware behavior. We are developing Alkanet, a system call tracer for malware analysis that uses a virtual machine monitor based on BitVisor. In this paper, we describe a method for identifying system call invoker in dynamic link library by using stack tracing. The method make it possible to identify the system call invoker in dynamic link library or memory area. It is effective to analyze malware such as executable codes generated in runtime, or malicious libraries mapped in a legitimate application.
Computer Security Symposium 2013 21 - 23 October 2013
1
はじめに
近年，マルウェアの脅威が問題となっている が，その対策には，マルウェアの挙動を調査する 必要がある．そこで，我々は，仮想計算機モニタ BitVisor [3] をベースとし，システムコールト レースによってマルウェアを解析するAlkanet[1] を開発している． これまでの Alkanet では，システムコール を発行したプロセスやスレッドを識別し，マル ウェアの挙動をシステムコールの種類や引数な どを元に解析してきた．しかし，マルウェアに は動的リンクライブラリ (DLL)や動的に生成 したコードを他のプロセスへ挿入するものも多 い．これまでの手法では，特定のDLLやメモリ 領域から行われる挙動を他の挙動と区別できず， そういったマルウェアの解析が困難であった． この問題を解決するためには，システムコー ルを呼び出した実行ファイルやコードを識別す る必要がある．そのための技術的課題として， システムコールを発行するまでのコントロール フローの取得方法と，フロー内で経由したファ イルやコードの情報の取得方法が挙げられる． 本論文では，この課題を解決し，正規のプロセ ス内部に潜むマルウェアの解析を可能にする手 法を述べる． 以下，本論文では，2章で Alkanet の概要と 構成について述べる．3章ではコントロールフ ローを取得する方法について述べ，4章ではフ ロー内で経由したファイルやコードの情報を取 得する手法について述べる．5章では解析した マルウェアについて個別に結果と考察を述べ，6 章で関連研究について述べる．最後に，7章で 本論文をまとめる．2
Alkanet
の概要
Alkanet は VMM ベースのマルウェア動的 解析システムである．VMM ベースとすること で，多くのマルウェアに搭載されているアンチ デバッグを回避できるという特徴を有している． また，Alkanetは， マルウェアが多く出回って いる Windowsのシステムコールをトレースす る[2]．システムコール単位とすることにより， Kernel- mode WindowsVM
User- mode SystemCall LogAnalyzer ロギング用PC IEEE1394 BitVisor Alkanet SystemCall Analyzer� マルウェア観測用PC 保存 Logger Log ログ分析 挙動抽出 図1: Alkanet の全体構成 マルウェアの挙動を機能単位で抽出し，挙動の 理解を容易にしている．取得したシステムコー ルトレースのログからは，分析ツールを用いて 特徴的な挙動を抽出したレポートを得ることが できる． Alkanet の全体構成を図1に示す．Alkanet は，VMM であるBitVisor[3]の拡張機能とし て実装している．BitVisorは，ホストOSを必 要とせず，ハードウェア上で直接動作するハイ パーバイザ型のVMMである．Intel製CPUの仮想化支援機能であるIntel VT (Intel
Virtual-ization Technology)を利用しており，Windows
を修正なしで実行することができる．
マルウェアの実行環境であるゲストOSには，
32bit版Windows XP Service Pack 3を用いて
いる．この環境におけるシステムコールは，通 常sysenter命令によってカーネルモードへ遷移 し，sysexit命令によってユーザモードへ復帰す る．システムコールのフックは，これらの命令 にハードウェアブレイクポイントを設定するこ とで実現している．フック後に，レジスタやメ モリ内容を解析することでシステムコールの種 類や引数を取得し，ログに保存する． Alkanetのログは，ロギング用PCからIEEE 1394 を用いて取得することができ，その後に 分析することができる．
3
コントロールフローの取得
3.1
スタックトレース
DLLとして動作するマルウェアや動的に生成 されたコードの挙動を，本来のアプリケーションの挙動と区別するためには，システムコール を呼び出した実行ファイルやメモリ領域を識別 する必要がある．そこで，システムコールの発 行までのコントロールフローを取得する．具体 的には，システムコールフック時にスタックト レースを行う． スタックトレースは，スタックに記録された ベースポインタを辿りつつ，同時に関数の戻り アドレスを得ていく手法である．これにより， 実行中の関数が呼ばれるまでに呼び出された関 数の履歴を取得し，コントロールフローを把握
できる．Windows APIで使用されるstdcall[4]
呼び出し規約において，FPO (Frame-Pointer Omission)が無効である場合，呼び出された関 数は最初にスタックフレームを作成する．この とき，EBPの指す先には，前のベースポインタ の値が存在し，その4バイト後には戻りアドレ スが積まれている．同様に，前のベースポイン タが指す先には，さらに前のベースポインタが 存在し，その4バイト後には戻りアドレスが積 まれている．このようにベースポインタを辿っ ていくことで，これまでに積まれた戻りアドレ スを取得していくことができる．
なお，Windows XP Service Pack 2 以降で
は，WindowsのすべてのDLLと実行可能ファ イルにおいてFPOは無効になっている[5]．こ のため，たとえマルウェアのコードに FPOが 有効であっても，Windows API を経由してシ ステムコールを発行した場合には，スタックト レースを行うことでその API の呼出し元のア ドレスを取得することが可能である．
3.2
システムコール発行時のスタック
システムコール発行時におけるスレッドのス タックの状態を図2に示す．Windowsでは，シ ステムコールは ntdll.dll 内に実装されている 各システムコールに対応したスタブと，スタブ から呼び出されるntdll.dll内の KiFastSystem-Callを用いて発行される．図2は，関数C，関 数B，関数A，スタブ，KiFastSystemCall を 経由してシステムコールが発行された時点での， 関数Bのスタックフレーム(図2の(1))より上 を示している． (5)� スタブへの戻りアドレス (4)� 関数Aへの戻りアドレス システムコールへの第1引数� システムコールへの第2引数� … システムコールへの最後の引数� … 関数Aのローカル変数 ベースポインタ 関数Bへの戻りアドレス 関数Aへの第1引数 … 関数Aへの最後の引数 … ベースポインタ 関数Cへの戻りアドレス … スタックの先頭アドレス sysenter 時: EDX sysexit 時: ECX� EBP� 関 数A ー 関 数B ー 成 長 方 向 (1) (3) (2) (6) (7) 図2: システムコールフック時のスタック 関数Aは，スタブを呼び出す前に，自身のス タックフレーム(図2の(2))の上に，スタブに 与える最後の引数から順にスタックに積む(図 2の(3))．このスタブへ与えられる引数は，そ のままシステムコールの引数となる．その後， call命令でスタブを呼び出す．このとき，関数 A の戻りアドレスがスタックに積まれる(図2 の(4))．スタブは，発行するシステムコールの 番号を EAX にセットし， KiFastSystemCall をcall命令を用いて呼出す．このとき，スタブ への戻りアドレスがスタックに積まれる(図2の(5))．KiFastSystemCall は，EDX にESP
の値をセットし，sysenter命令を実行する．こ のとき，sysenter命令は戻りアドレスをスタッ クに積まないため，KiFastSystemCall への戻 りアドレスは保持されない．
3.3
戻りアドレスの取得
Alkanetは，システムコールフック時にシス テムコールの引数およびスタックトレースを取 得するために，スレッドのスタックの位置を特 定する．システムコール発行時には，KiFast-SystemCallがESPの値をEDXレジスタに格
納する．sysexit命令は，ECX レジスタの値を
ESPにロードする．したがって，システムコー
ルを発行したスレッドのスタックの位置は，
ク時は ECXから特定できる(図2の(6))． 3.2節で述べたように，システムコールフッ ク時におけるスタックの状態は，図2のように なっている．したがって，スタックの先頭から スタブへの戻りアドレス(図2の(5))，および 続く関数Aへの戻りアドレス(図2の(4))を取 得する．図2の(3)の引数についても，システ ムコールの解析に用いるために別途取得する． システムコールの引数の後には，スタブを呼 出した関数 A，B のスタックフレームが続く．
sysenter命令およびsysexit命令ともに，EBP
を変更しない．したがって，フック時の EBP は，スレッドがシステムコールを発行したとき のEBPであり，関数Aのスタックフレームの ベースポインタとなっている(図2の(7))．EBP が示すアドレスには，一つ前の関数Bのスタッ クフレームのベースポインタの値が保持されて いるため，ベースポインタを辿ることで，関数 B, C への戻りアドレスを取得してくことがで きる．このようにして，システムコールが発行 されるまでのコントロールフローを呼び出され た関数単位で得ることができる．
4
戻り先の識別
3章で述べた手法で取得した戻りアドレスに ついて，VADツリー(後述)およびページテー ブルエントリ(PTE)から，実行ファイルがマッ ピングされているか，書込み可能な領域かどう かなどの情報を取得する．これにより，DLLタ イプのマルウェアやマルウェアが動的に生成し たコードをシステムコール発行時に経由したか どうかを区別可能にする．4.1
マッピングされた実行ファイル
Windowsは，VAD (Virual Address
Descrip-tor)と呼ばれるデータ構造を用いて，プロセス が確保したメモリ領域を管理している[6]．VAD は，プロセスがメモリを確保するときやファイ ルをマッピングするときに作成される．VADが 保持する情報は，管理する範囲や，その範囲の デフォルトのページ保護属性，ファイルがマッ ピングされているかどうか，マッピングされて いる場合はそのファイルの情報などがある． Windows は，デマンドページングを採用し ているため，プロセスが確保したアドレスに対 して，実際にアクセスしたときにページを割り 当てる．Windows は，ページフォルトが発生 した時に，そのアドレスを範囲に含むVAD の 持つ情報を元にPTEを作成する． 各VADは，同じプロセスのアドレス空間の 一部を管理する他の VAD と連結され，平衡 二部探索木を構成する．そして，プロセスオブ ジェクトは，自身のアドレス空間を表す VAD ツリーのルートノードへのポインタを持つ．し たがって，VAD ツリーを辿ることで，戻りア ドレスを含むメモリ領域にマッピングされてい るファイルの情報を得ることができる．これに よって，フックしたシステムコールが，特定の DLL を経由して発行されたものであるかを判 別することができる．さらに，マッピングされ た実行ファイルのエクスポートテーブルやシン ボル情報などを用い，戻りアドレスがどのAPI のものであるかも取得できる．
4.2
動的に生成されたコード
マルウェアが動的にコードを生成する場合， NtAllocateVirtualMemory システムコールな どを用いて，生成先のメモリ領域を確保する．こ のとき，対応するVADも生成される．その領域 は，実行可能かつ書込み可能である必要がある ため，必要に応じて，NtProtectVirtualMemory システムコールを用いて保護属性を変更する． 動的に生成されたコードからのシステムコー ルである場合には，戻りアドレスの領域にファ イルがマッピングされておらず，書込み可能で あるという特徴を有すると考えられる．ファイ ルがマッピングされいるか否かは，VAD から 取得が可能である．一方，VAD の保持する保 護属性は，あくまでPTE を作成するときに用 いられるデフォルト値であるため， NtProtect-VirtualMemoryによって個々のページの保護属 性を変更しても反映されない．そこで，保護属 性は，戻りアドレスを含むページのPTE から 取得する．なお，ここで述べるPTEの各ビットの名称はWindowsにおける名称に準ずる．書 込み可能かどうかは，Writable ビット(1 ビッ ト目)から判定でき，実際に書き込まれたかど うかについても Dirty ビット(6 ビット目)に よって判定できる．また，マルウェアがコード 生成後に書込み可能属性を取り除くことが考え られる．この場合でも，メモリの保護属性を変 更するには，NtProtectVirtualMemoryを発行 する必要があるため，Alkanetでこの挙動を捕 捉することができる．
5
評価
実際にマルウェアを用いて，システムコール の呼出し元を判別可能であるかを評価した．本 章では，その内容と結果について述べる．5.1
ログエントリ
図3 は， 5.2節で述べる Conficker.dll の解 析で得たログの一部である．この図を用いてロ グの各項目の意味について述べる．以下のNo. からNoteまでの詳細については文献[2]を参照 されたい．本論文では新たに追加された Stack-Traceについて述べる． No. ログの通し番号 Time 記録を取った時点での CPU 時間 Cid システムコールを発行したスレッドのプロ セス ID とスレッドID の組 Name プロセスのイメージ名Type sysenter 時か sysexit時かを示す．
Ret 戻り値(sysexitのログのみ) SNo. システムコールの番号とその名前 Note 引数を解析した結果などの付加情報 StackTrace スタックトレースで得た情報 StackTraceの項目の1行目のSPはシステム コールフック時のスレッドのスタックポインタ， StackBase とStackLimit はそれぞれスタック の下限と上限を示す．これらの値は，各スレッ
ドが持つ TIB (Thread Information Block) と
いうデータ構造から取得した．2行目以降は， 取得した戻りアドレスと，それを含むスタック フレームのベースポインタについての情報であ る．“[]”内の数字はスタックフレームの階層を 示す．ただし，3章で述べたように，システム コールのスタブはEBPをスタックに積まない． したがって，“[00]”はスタックの先頭から取得 したスタブへの戻りアドレス，“[01]”はスタッ クの先頭から4バイトの位置に積まれたスタブ を呼び出した関数への戻りアドレスとなってい る．これらについては，ベースアドレスの代わ りに戻りアドレスを取得したスタックポインタ の値となっている． 戻り先については，以下の情報を出力する． API マッピングされているファイルのエクポー トテーブルおよびシンボル情報から得たAPI 名とその API の先頭アドレスからのオフ セット．シンボル情報が存在しない場合に は“-”を表示する． Writable 戻りアドレスを含むページが書込み 可能か否か． Dirty 戻りアドレスを含むページが既に書き込 まれているか否か．
VAD 戻りアドレスを含むVADの情報．VAD
の管理範囲，実行ファイルをマッピングし ているか否か，マッピングしている場合は そのファイル名を出力する． 図3の StackTrace の2∼3行目にある[00] のエントリでは，戻りアドレスが 0x7c94d6dc で，この値はスタック内の0x7ed40から取得し た．戻り先のページには，書込み可能属性はな く，0x7c940000から0x7c9dc000の範囲を管理 するVADに属する．この領域には，実行ファイ ルがマッピングされており(ImageMap: 1)，そ のファイルは\WINDOWS\system32\ntdll.dll である．そして，この戻りアドレスは，ntdll.dll 内の NtProtectVirtualMemoryという API の 先頭アドレスから+0xc の位置である．
5.2
Conficker
CCC Dataset 2013[7] に活動が記録されて いるマルウェアのうち，DLL になっているも のを選び，解析を行った．マルウェアのファイ ル名は，アンチウイルスソフトでの検出名からNo. : 14335 Time: 516777148
Type: sysexit Ret : 0 (STATUS_SUCCESS) SNo.: 89 (NtProtectVirtualMemory)
Cid : 1a4.1a8 Name: rundll32.exe Note:
Pid: 1a4, Name: rundll32.exe
NewProtect: PAGE_EXECUTE_READWRITE, OldProtect: PAGE_READWRITE BaseAddress: 992000, AllocationSize: 0xe000 (Range: 992000--9a0000) StackTrace:
SP: 7ed40, StackBase: 80000, StackLimit: 74000
[00]7c94d6dc (API: NtProtectVirtualMemory+0xc, Writable: 0, Dirty: 0,
VAD:{7c940000--7c9dc000, ImageMap: 1, File: "\WINDOWS\system32\ntdll.dll"}), SP: 7ed40 [01]7c801a81 (API: VirtualProtectEx+0x20, Writable: 0, Dirty: 0,
VAD:{7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), SP: 7ed44 [02]7c801aec (API: VirtualProtect+0x18, Writable: 0, Dirty: 0,
VAD:{7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), BP: 7ed64 [03]1000220e (API: -, Writable: 0, Dirty: 0,
VAD:{10000000--10018000, ImageMap: 1, File: "\...\My Documents\Conficker.dll"}), BP: 7ed80 [04]1000401b (API: -, Writable: 0, Dirty: 0,
VAD:{10000000--10018000, ImageMap: 1, File: "\...\My Documents\Conficker.dll"}), BP: 7f184 [05]7c94118a (API: LdrpCallInitRoutine+0x14, Writable: 0, Dirty: 0,
VAD:{7c940000--7c9dc000, ImageMap: 1, File: "\WINDOWS\system32\ntdll.dll"}), BP: 7f1a4 ...
[10]7c80aeec (API: LoadLibraryW+0x11, Writable: 0, Dirty: 0,
VAD:{7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), BP: 7f888 [11]1001792 (API: -, Writable: 0, Dirty: 0,
VAD:{1000000--100b000, ImageMap: 1, File: "\WINDOWS\system32\rundll32.exe"}), BP: 7f89c ... 図 3: Conficker.dllから発行されたシステムコールとスタックトレースの結果 Conficker.dllとした．本評価では，rundll32.exe にConficker.dllをロードさせ，rundll32.exeの 挙動からConficker.dllの挙動を分離できるかを 確認した．ただし，このマルウェアを解析中に NtLoadDriverが発行された．Alkanetは，カー ネルモードマルウェアは解析の対象外であるた め，NtLoadDriverが発行されるまでの挙動を 今回の評価対象とした． 図3のログは，rundll32.exeによって発行され たNtProtectVirtualMemoryにより，0x992000 から 0x9a0000 の範囲のページの保護属性が
PAGE EXECUTE READWRITEに変更され
たことを示す．従来のAlkanetのログでは， Stack-Traceの項目がないため，このシステムコール が Conficker.dll によって行われたのか， Con-ficker.dllとは関わりのないrundll32.exeの挙動 であるか区別することができなかった．今回追加 したStackTraceの項目によって，rundll32.exe がConficker.dllをLoadLibraryW によって読 込み(図3の[10]，[11])，Conficker.dll 内の 初期化用関数を呼び出した先から発行されたこ とがわかる(図3の[05]から上のエントリ)．こ のように，既存のシステムコールトレースにス タックトレースを追加することで，感染元のプ ロセスの挙動とマルウェアのDLL の挙動を区 別することができた．これにより，正規のプロ セスにロードされたDLL タイプのマルウェア を解析可能である． 図4では，rundll32.exeが，NtCreateThread システムコールを用いて，別のプロセスの svc-host.exeに対して，スレッドID 1a8のスレッド を作成している．このスレッド挿入の挙動も，図 4の[08]∼[14]より，Conficker.dllをロードし たrundll32.exeからすれば，Conficker.dllの初 期化中である．[05]の戻りアドレスは，図3の システムコールで保護属性を変更した領域内で ある．VADの情報から実行ファイルはマッピン グされていない(ImageMap: 0)．そして，戻り アドレスを含むページは書込み可能(Writable: 1)であり，既に書き込まれている(Dirty: 1)． [02]∼[04]の戻りアドレスを含む領域も同様 に，動的に確保し，実行属性を付与された領域 であり，書込み可能でかつ既に書き込まれてい る．これらのことから，図4のシステムコール は，Conficker.dllが動的に生成した実行コード によって発行されたものであることがわかる． このように，動的に生成されたコードの挙動も 区別し，解析することが可能となった．
No. : 14509 Time: 516811998
Type: sysexit Ret : 0 (STATUS_SUCCESS) SNo.: 35 (NtCreateThread)
Cid : 1a4.1a8 Name: rundll32.exe Note:
Cid: 434.1b0, Name: svchost.exe, EIP: 0x7c8106e9, Suspended: 0x1 StackTrace:
SP: 7e640, StackBase: 80000, StackLimit: 74000
[00]7c94d19c (API: NtCreateThread+0xc, Writable: 0, Dirty: 0,
VAD:{7c940000--7c9dc000, ImageMap: 1, File: "\WINDOWS\system32\ntdll.dll"}), SP: 7e640 [01]7c810585 (API: CreateRemoteThread+0xc9, Writable: 0, Dirty: 0,
VAD:{7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), SP: 7e644 [02]98bd46 (API: -, Writable: 1, Dirty: 1, VAD:{980000--9a1000, ImageMap: 0}), BP: 7ea94 [03]987500 (API: -, Writable: 1, Dirty: 1, VAD:{980000--9a1000, ImageMap: 0}), BP: 7eb00 [04]987c5f (API: -, Writable: 1, Dirty: 1, VAD:{980000--9a1000, ImageMap: 0}), BP: 7ed38 [05]99721c (API: -, Writable: 1, Dirty: 1, VAD:{980000--9a1000, ImageMap: 0}), BP: 7ed64 [06]10002639 (API: -, Writable: 0, Dirty: 0,
VAD:{10000000--10018000, ImageMap: 1, File: "\...\My Documents\Conficker.dll"}), BP: 7ed84 [07]1000401b (API: -, Writable: 0, Dirty: 0,
VAD:{10000000--10018000, ImageMap: 1, File: "\...\My Documents\Conficker.dll"}), BP: 7f184 [08]7c94118a (API: LdrpCallInitRoutine+0x14, Writable: 0, Dirty: 0,
VAD:{7c940000--7c9dc000, ImageMap: 1, File: "\WINDOWS\system32\ntdll.dll"}), BP: 7f1a4 ...
[13]7c80aeec (API: LoadLibraryW+0x11, Writable: 0, Dirty: 0,
VAD:{7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), BP: 7f888 [14]1001792 (API: -, Writable: 0, Dirty: 0,
VAD:{1000000--100b000, ImageMap: 1, File: "\WINDOWS\system32\rundll32.exe"}), BP: 7f89c ... 図4: 動的に生成されたコードから発行されたシステムコールとスタックトレースの結果
5.3
検体
D3M Dataset 2013[7]のマルウェア検体の中 からPDF のものを選び，Alkanet で解析した． 本評価では，PDF 内に含まれるシェルコード の挙動を解析できることを確認した． 図5は，PDFを開いたAcroRd32.exeが Nt-ProtectVirtualMemoryを発行したときのログ である．このログでは，スタックポインタの位置 がスレッドのスタックの範囲であるStackBase から StackLimit の範囲にない．これは，シェ ルコードが用意した領域をスタックとして使用 していると考えられる．また，[03]の戻りア ドレスには，実行ファイルがマッピングされて おらず，書込み可能で既に書き込まれた領域に 存在する．すなわち，[03]の戻り先には，動 的に生成されたコードが存在する．そして，こ の NtProtectVirtualMemory は，この領域の保護属性をPAGE EXECUTE READWRITE
に変更している. これは，生成されたシェル コードに対して実行権限を与える挙動と考えら れる．この後，0x4270000 から 0x4271000 の 領域に存在するコードからさまざまなシステム コールが発行された．このように，PDFを開い たAcroRd32.exeから発行されたシステムコー ルの中から，シェルコードが発行したシステム コールを区別できた．これによって，シェルコー ドの挙動を解析することが可能となった．
6
関連研究
プロセスがロードした実行ファイルの情報を 取得する手法として，VADツリーを用いる手法 の他にPEB LDR DATA[8]の持つリストを用 いる手法がある．メモリフォレンジックフレーム ワークであるVolatility Framework[9]のdlllist コマンドは，この方法で実現されている．また， シェルコード内でAPIのアドレスを解決する際 にも使用される．ただし，このリストは，ユー ザ空間に存在するためにマルウェアに改竄され る恐れがある．一方で，VADツリーはカーネル 空間に存在する．そのため，Alkanet では，マ ルウェアから改竄される可能性の低いVAD ツ リーを用いた．MAT (Module-based Analysis Tool) [10]は， スタックトレースを用いてシステムコールを発
行したDLL を区別している．MATの本体は，
No. : 39277 Time: 1195072803
Type: sysexit Ret : 0 (STATUS_SUCCESS) SNo.: 89 (NtProtectVirtualMemory)
Cid : 220.510 Name: AcroRd32.exe Note:
Pid: 564, Name: AcroRd32.exe
NewProtect: PAGE_EXECUTE_READWRITE, OldProtect: PAGE_EXECUTE_READWRITE BaseAddress: 4270000, AllocationSize: 0x1000 (Range: 4270000--4271000) StackTrace；:
SP: f601ff8, StackBase: 130000, StackLimit: 11d000
[00] 7c94d6dc (API: NtProtectVirtualMemory+0xc, Writable: 0, Dirty: 0,
VAD:{7c940000--7c9dc000, ImageMap: 1, File: "\WINDOWS\system32\ntdll.dll"}), SP: f601ff8 [01] 7c801a81 (API: VirtualProtectEx+0x20, Writable: 0, Dirty: 0,
VAD: {7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), SP: f601ffc [02] 7c801aec (API: VirtualProtect+0x18, Writable: 0, Dirty: 0,
VAD:{7c800000--7c933000, ImageMap: 1, File: "\WINDOWS\system32\kernel32.dll"}), BP: f60201c [03] 42700c7 (API: -, Writable: 1, Dirty: 1, VAD:{4270000--4271000, ImageMap: 0}), BP: f602038
図5: PDF 内のシェルコードから発行されたシステムコールとスタックトレースの結果 のドライバとして実装されている．Alkanetは， マルウェアに検出されることを防ぐために， Win-dows には手を加えず，VMM のレイヤで実現 している．また，MATでは，ファイルおよびプ ロセス単位でテイント解析を行うが，別のプロ セスに挿入されたスレッドや動的に生成された コードは想定していない．Alkanet では，これ らの挙動についても追跡を行ことが可能である
7
おわりに
本論文では，システムコールフック時にスタッ クトレースを行い，それまでに経由したAPIや 呼出し元を特定する手法について述べた．これ により，システムコール呼出し元が識別できる ようになり，DLLとして動作するマルウェアや 動的に生成されたコードの解析が可能となる． 今後の課題として，スタックトレースを回避す る挙動[11]や，既にマッピングされているファ イルを上書きされた場合について検討を行う．参考文献
[1] Y. Otsuki at el.: “Alkanet: A Dynamic Mal-ware Analyzer based on Virtual Machine Mon-itor,” In World Congress on Engineering and Computer Science 2012 (WCECS 2012), Vol. 1, pp. 36–44 (2012).
[2] 大月 他: “マルウェア挙動解析のためのシステム
コール実行結果取得法,” コンピュータセキュリ ティシンポジウム 2011 論文集, 第 2011 巻, pp. 95–100 (2011).
[3] T. Shinagawa at el.: “BitVisor: a thin hyper-visor for enforcing i/o device security,” In Pro-ceedings of the 2009 ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, pp. 121–130 (2009) [4] Microsoft: “ stdcall,” http://msdn. microsoft.com/en-us/library/zxk0tw93. aspx (2013). [5] A. Glaister: “シ ン ボ ル を 使 用 し た デ バ ッグ,” http://msdn.microsoft.com/ja-jp/ library/bb694540(v=vs.85).aspx (2007). [6] B. Dolan-Gavitt: “The VAD tree: A
process-eye view of physical memory,” Digital Investi-gation, Vol. 4, pp. 62–64 (2007).
[7] 神薗 他: “マルウェア対策のための研究用データ
セット ∼MWS Datasets 2013∼,” マルウェア対 策研究人材育成ワークショップ 2013 (MWS2013) (2013).
[8] Microsoft: “PEB LDR DATA structure (Windows),” http://msdn.microsoft. com/en-us/library/windows/desktop/ aa813708(v=vs.85).aspx (2013).
[9] “volatility - An advanced memory forensics framework - Google Project Hosting,” https: //code.google.com/p/volatility/ (2013). [10] F. Jianming at el.: “Malware Behavior
Cap-turing Based on Taint Propagation and Stack Backtracing,” In Trust, Security and Privacy in Computing and Communications (TrustCom), 2011 IEEE 10th International Conference on, pp. 328–335 (2011).
[11] J. Butler at el.: “Bypassing 3rd Party Win-dows Buffer Overflow Protection,” Phrack 62, Volume 0x0b, Issue 0x3e, Phile #0x05 of 0x10, http://www.phrack.org/issues. html?issue=62&id=5#article (2004).
