マルウェア作者がサンドボックスを検出する新たな手段を発明したのなら、当然のことながらそこで一服したりしない。サンドボックスは非常に便利なシステムで、昨今では数百万のサンプルを自動的に分析する。Seculert は最近、Dyre/Dyrezaマルウェアで採用している、前例のないサンドボックス検出方法を明らかにした。我々は、これと類似する対サンドボックス手段が悪評高いバンキング型トロイの木馬Tinbaで使われていることを確認した。サンドボックス技術の向上の一助となることを期して、この発見について論じたいと思う。Joe Securityも同社のサンプルの1つから、Tinbaで見られたものと同じ回避手段を見つけ出している。

ユーザインタラクションを組み合わせた検出
 最新のTinbaのサンプルで我々が発見したのは、GetCursorPos APIを用いてマウスの動きを確認する回避手段を採用していたことだ。加えて、このマルウェア作者はGetForeGroundWindow APIを使う新しいサンドボックス検出方法も導入した。このAPIを使うと、ユーザが現在操作をしているアクティブウィンドウをマルウェアが確認できるようになる。

 一般に、自動化されたサンドボックスシステムは同一ウィンドウのままになる。マルウェアが実行された場所という観点からすると、これはデスクトップとなることもある。当該マルウェアではこの状況を利用しようとして、GetForeGroundWindow APIを2回連続でコールし、返された値を確認する。2回のコールの間には数秒の間隔があり、実際のユーザインタラクションを模倣している。この最新サンプルをサンドボックス環境で実行した場合、2回のGetForeGroundWindow APIのコールにより返される値は、常に同じものになるだろう。このことは、このサンプルを実行して以来、アクティブウィンドウが同一のままであること示すことになる。このケースでは、アクティブウィンドウが変化し、なおかつマウスカーソルが移動するまでメインルーチンは実行されず、コードはループし続ける。

tinba_user_interaction_detection (135k image)

物理マシンであることを期待
 ユーザインタラクションの検出後、メインルーチンを実行する前に、Tinbaはもう1つささやかな回避手段を採用している。これはDyre/Dyrezaが行っているCPUコア数の検出に少々似ている。Tinbaの場合、実行中のマシン上で得られるディスクシリンダーの数を探す。基本的には、これはディスク容量の確認と同等だ。おそらくは実装を簡単にする目的で、ディスクの物理容量を調べる代わりに、ioctlコードのIOCTL_DISK_GET_DRIVE_GEOMETRY_EXを使ってディスクのシリンダー数のみを確認しているのだろう。特に今回のケースでは、ディスクに少なくとも5,000個(0x1388)のシリンダー、つまり約11GBあるかどうかを判定し、なければこのサンプルは終了する。CPUコアの数の検出とまったく同じく、ディスク容量の確認も効果的な検出回避手法となり得る。なぜなら最近の通常のコンピュータ機のコア数やディスク容量はもっと大きいはずだからだ。

tinba_i_hope_im_a_real_machine (81k image)

 ウィンドウのユーザインタラクションのテストおよびマシン上のディスク容量の確認により、容易にサンドボックスを検出し得ることをTinbaは実証している。マルウェアの作者らは検出回避のための新しい方法を絶え間なく追い求めている。故に、彼らに遅れずついて行くには適切に調整を行わなければならないのだ。サンドボックス技術を強固にする際は、このことをサンドボックス提供業者は心に留めておかなければならない。

 今回の分析で用いたTinbaのサンプル:5c42e3234b8baaf228d3ada5e4ab7e2a5db36b03