Ursnif(Dreambot, Gozi)の静的解析レポート(2019年4月15日ばらまき分)

ブログやTwitterでも発信している通り、今年も不審メールのばらまきが引き続き行われています。我々が解析している中で最もばらまきが多いのはUrsnifです。そこで今回、2019年4月15日にばらまかれたUrsnif検体について、初めて静的解析を実施してみました。この解析が他のセキュリティ解析者の方々に少しでも参考になれば幸いです。

 

■1.1 Ursnifとは

Ursnifは別名Gozi、Dreambotとも呼ばれるバンキングマルウェアで、主に下記の機能を持つことが確認されています。

Explorerへのプロセスインジェクション

・バージョン情報やIPアドレス情報等を窃取

キーロガー

・ブラウザインジェクション(今回の検体では未確認)

・ディスプレイの録画機能(今回の検体では未確認)

今回の解析では上の3つの機能を確認できたため、本記事で解析結果を記載しようと思います。

 

■1.2 解析対象と解析環境

2019年4月15日にばらまかれたUrsnifで、jsファイルを経由してread.binというUrsnifをダウンロード・実行するものでした。動的解析結果は以前の記事をご参照ください。

https://bankingmalware.hatenablog.com/entry/2019/04/15/165434

ハッシュ値Sha1)45762C39DE64AB7ACECA9D6367129EC0CE37433D

・ファイル名 read.bin 

解析環境としてはWindows7の32ビットを使用。32ビットと64ビット環境では動きが異なることが分かったので、ご注意ください。 なお、もし本記事を参考にして解析する場合は、必ず仮想マシンなど、解析が終わったらすぐに戻せる環境で行い、ネットワークからも隔離した状態で行ってください。
 

■2.1 プロセスインジェクションの全体像

今回解析した検体では下記のような流れでExplorerにプロセスインジェクションすることが確認されました。主な概要図は下記の通りとなっております。以降でその詳細について、キャプチャを交えて記載していこうと思います。

 

f:id:bankingmalware:20190626192954p:plain

プロセスインジェクションの概要

※今回の解析のために、キャプチャをとりながら再起動を繰り返しています。そのため、プロセスハンドルのIDやアドレスについて、前項のキャプチャと整合性が合わない部分もありますので、ご容赦ください。また、以降のキャプチャではreadOriginal.binとreadUnpacked.binというファイル名も登場しますが、すべてread.binと同一ファイル(正確にはreadUnpacked.binはUPXでアンパックしたファイル)です。

 

■2.2 ①OpenProcessでexplorerのプロセスハンドル取得

まず、UrsnifはOpenProcess APIを利用してExplorerのプロセスハンドルを取得します。

以降、このExplorerのプロセスハンドルを各APIに引数として渡すことで、Explorerと共有する領域Sectionオブジェクトを作成し、インジェクションを試みます。

 

f:id:bankingmalware:20190626193632p:plain

OpenProcessの引数にexplorerのプロセスID(1368=0x558)を指定し、 Explorerのプロセスハンドルを取得

f:id:bankingmalware:20190626193820p:plain

Explorerの引数は1368(0x558)となっている

f:id:bankingmalware:20190626193947p:plain

Explorerへのプロセスハンドルが作成される


■2.2 ②CreateRemoteThreadでexplorer内にスレッド作成

CreateRemoteThread APIの引数に先ほどのexplorerへのプロセスハンドルを渡し、explorer内にSuspend状態のスレッドを作成する(0x4がSuspendであるフラグ)。

f:id:bankingmalware:20190627103012p:plain

CreateRemoteThreadに先ほどのexplorer.exeのプロセスハンドルを渡して、explorer内にスレッド作成

f:id:bankingmalware:20190627103122p:plain

Explorer内にスレッドID200のスレッドが生成され、Ursnfi(read.bin)からは0xecというハンドルになった

■2.2 ③NtCreateSectionにより、Sectionオブジェクト作成
 続いてExplorerと共有する領域を作成するために、NtCreateSectionを用いてSectionを作成します(この段階ではまだUrsnif内部にある状態のため、共有はしていません)。

f:id:bankingmalware:20190627105713p:plain

NtCreateSectionにより、この後Explorerと共有するためのSection領域を作成する

■2.2 ④ZwMapViewOfSectionによりリモートビューを作成

ZwMapViewOfSectionを呼び出す際、第1引数に先ほど作成したSection、第2引数にexplorerのプロセスハンドルを渡すことで、explorerに先ほどのSectionをマッピングする(共有メモリとする)。これにより以降本Sectionに書き込みを行うことで、Explorerプロセスに悪意のあるコードを書き込むことが可能となる。

f:id:bankingmalware:20190627105713p:plain

第1引数にUrsnifのSection、第2引数にexplorerのプロセスハンドルを渡している。

■2.2 ⑤memcpyにより先ほどマッピングしたSection

 先ほどのSectionにmemcpy関数を複数回呼び出し、不正コードの書き込みを行う。

f:id:bankingmalware:20190628100012p:plain

memcpyを呼び出している様子。第1引数が書き込み先のアドレス、第2引数が書き込み元のアドレス。ダンプウインドウ(左下の赤枠)は書き込み元のデータを表示している。

f:id:bankingmalware:20190628100720p:plain

Ursnifでのメモリ状況。確保したSection領域に、先ほどのダンプウインドウで表示したデータが書き込まれた(一致している)ことが分かる。

f:id:bankingmalware:20190628100739p:plain

Explorerでのメモリ状況。RWXの領域が確保されており、かつ先ほどのダンプウインドウで表示したデータが書き込まれた(一致している)ことが分かる。

 

■2.2 ⑥ZwAllocateVirtualMemoryにより書込権限・ 実行可能領域を確保

⑤まででexplorerに悪意のあるコードを書き込むことができた。続いてその悪意のあるコードをCallするのシェルコードを書き出す。まずはexplorer内に書き込み・実行可能領域を確保する。

f:id:bankingmalware:20190627110802p:plain

ZwAllocateVirtualMemoryの第1引数にexplorerのプロセスハンドル(0xe8)を渡して、RWX領域(読取・書込・実行可能)を確保する

f:id:bankingmalware:20190627110954p:plain

Explorer内にRWX領域が確保された

■2.2 ⑦ZwWriteVirtualMemoryでシェルコードを書き込み

ZwWriteVirtualMemoryで先ほど確保したRWXの領域に書き込みを行う。第1引数がexplorerのハンドル、第2引数が書き込み先のアドレス、第3引数が書き込み元のアドレス(左下の赤枠)である。書き込み元のアドレスが左下の赤枠部分であり、Call命令等が書かれているシェルコードとなっている。

f:id:bankingmalware:20190627112216p:plain

 

■2.2 ⑧⑨SetContextThreadでEIPをシェルコードに変更

⑤まででexplorerに悪意のあるコードを書き込み、⑦まででそれを呼び出すシェルコードを書き込むことができた。最後にSetContextThreadを用いてEIP(エントリポイント、実行ファイルにおいて最初に実行されるコードのアドレス)をそのシェルコードに設定する。

下記の通り、SetContextThreadの第1引数にexplorerのプロセスハンドル(0xe8)、第2引数が各レジスタの値を保持するContext構造体のアドレス(lpcontext)となる。lpcontextの先頭から0xb8バイト目の値がEIPのため、今回の場合、explorer.exeのEIPを0x02470218に変更している(リトルエンディアンのため、逆から読むことに注意)。 

f:id:bankingmalware:20190627132029p:plain

SetContextThreadでEIPを変更している様子。第1引数がプロセスハンドルで、第2引数がlpcontextのアドレス。ダンプウインドウにはlpcontextのアドレスを表示しており、左下の赤枠部分がlpcontextから0xb8バイト目の部分(EIPの値)となる。

f:id:bankingmalware:20190627132601p:plain

explorerのMemory。0x2470000は2.6および2.7で作成したRWX領域のシェルコードであり、このシェルコードの中の0x0218番目のところにEIPを設定したことになる。

f:id:bankingmalware:20190627133207p:plain

(参考)0x218番地を逆アセンブラした結果。ECXをPUSHした後RETすることで、ECXの番地に戻ることになる。ECXに悪意のあるコードの番地にすることで、悪意のあるコードが実行されることになる。

 

最後にResumeThreadのAPIでスレッドを再開して、explorerプロセス内のスレッドで不正コードの実行が可能となる。以降、explorerでインジェクションされたコードの動きについて、解析していきますが、かなり長いページになったため、新しい記事として記載していこうと思います。

 

■筆者について

筆者は、あくまで最近マルウェア解析をし始めたマルウェア解析初心者です。基本的には独学によりマルウェア解析スキルを身に着けた程度のため、あくまで参考程度にとどめていただければ幸いです。ご質問・ご指摘がある場合、ご連絡いただければ幸いです。

 

■参考文献
今回の解析に当たり、多くのサイトを参考にさせていただきましたが、その中でも特に参考にさせていただいたページを記載させていただきます。
https://www.mbsd.jp/blog/20180607.html
https://www.nttsecurity.com/docs/librariesprovider3/default-document-library/jp_ursnif_20161226
https://www.iij.ad.jp/dev/report/iir/034/01_04.html