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にプロセスインジェクションすることが確認されました。主な概要図は下記の通りとなっております。以降でその詳細について、キャプチャを交えて記載していこうと思います。
※今回の解析のために、キャプチャをとりながら再起動を繰り返しています。そのため、プロセスハンドルのIDやアドレスについて、前項のキャプチャと整合性が合わない部分もありますので、ご容赦ください。また、以降のキャプチャではreadOriginal.binとreadUnpacked.binというファイル名も登場しますが、すべてread.binと同一ファイル(正確にはreadUnpacked.binはUPXでアンパックしたファイル)です。
■2.2 ①OpenProcessでexplorerのプロセスハンドル取得
まず、UrsnifはOpenProcess APIを利用してExplorerのプロセスハンドルを取得します。
以降、このExplorerのプロセスハンドルを各APIに引数として渡すことで、Explorerと共有する領域Sectionオブジェクトを作成し、インジェクションを試みます。
■2.2 ②CreateRemoteThreadでexplorer内にスレッド作成
CreateRemoteThread APIの引数に先ほどのexplorerへのプロセスハンドルを渡し、explorer内にSuspend状態のスレッドを作成する(0x4がSuspendであるフラグ)。
■2.2 ③NtCreateSectionにより、Sectionオブジェクト作成
続いてExplorerと共有する領域を作成するために、NtCreateSectionを用いてSectionを作成します(この段階ではまだUrsnif内部にある状態のため、共有はしていません)。
■2.2 ④ZwMapViewOfSectionによりリモートビューを作成
ZwMapViewOfSectionを呼び出す際、第1引数に先ほど作成したSection、第2引数にexplorerのプロセスハンドルを渡すことで、explorerに先ほどのSectionをマッピングする(共有メモリとする)。これにより以降本Sectionに書き込みを行うことで、Explorerプロセスに悪意のあるコードを書き込むことが可能となる。
■2.2 ⑤memcpyにより先ほどマッピングしたSection
先ほどのSectionにmemcpy関数を複数回呼び出し、不正コードの書き込みを行う。
■2.2 ⑥ZwAllocateVirtualMemoryにより書込権限・ 実行可能領域を確保
⑤まででexplorerに悪意のあるコードを書き込むことができた。続いてその悪意のあるコードをCallするのシェルコードを書き出す。まずはexplorer内に書き込み・実行可能領域を確保する。
■2.2 ⑦ZwWriteVirtualMemoryでシェルコードを書き込み
ZwWriteVirtualMemoryで先ほど確保したRWXの領域に書き込みを行う。第1引数がexplorerのハンドル、第2引数が書き込み先のアドレス、第3引数が書き込み元のアドレス(左下の赤枠)である。書き込み元のアドレスが左下の赤枠部分であり、Call命令等が書かれているシェルコードとなっている。
■2.2 ⑧⑨SetContextThreadでEIPをシェルコードに変更
⑤まででexplorerに悪意のあるコードを書き込み、⑦まででそれを呼び出すシェルコードを書き込むことができた。最後にSetContextThreadを用いてEIP(エントリポイント、実行ファイルにおいて最初に実行されるコードのアドレス)をそのシェルコードに設定する。
下記の通り、SetContextThreadの第1引数にexplorerのプロセスハンドル(0xe8)、第2引数が各レジスタの値を保持するContext構造体のアドレス(lpcontext)となる。lpcontextの先頭から0xb8バイト目の値がEIPのため、今回の場合、explorer.exeのEIPを0x02470218に変更している(リトルエンディアンのため、逆から読むことに注意)。
最後に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