Ursnif(Dreambot, Gozi)の静的解析レポート~インジェクションされた不正コードからIATフックまで~(2019年4月15日ばらまき分)

前回の記事に続いて再びUrsnifの静的解析について記載していこうと思います。

前回の記事ではUrsnifのExplorerへのプロセスインジェクションの手法について解説しました。今回はExplorerにインジェクションされた不正コードの解析およびIATフック(Import Adderess Table)によって実行される不正コードについて、解析していこうと思います。

 

■解析対象と解析環境(再掲)

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ビット環境では動きが異なることが分かったので、ご注意ください。また、今回の解析のために、キャプチャをとりながら再起動を繰り返しています。そのため、アドレス等について、前項のキャプチャと整合性が合わない部分もありますので、ご容赦ください。なお、もし本記事を参考にして解析する場合は、必ず仮想マシンなど、解析が終わったらすぐに戻せる環境で行い、ネットワークからも隔離した状態で行ってください。

 

Explorerにインジェクションされた不正コードの追跡

・端末のバージョン情報を摂取

下記の通り、GetVersion、GetCurrentProcessId等のAPIを利用して端末やプロセス情報を取得。のちに%temp%に出力。

f:id:bankingmalware:20190628173651p:plain

バージョン情報やプロセス情報を取得し、のちに%temp%配下に出力

 

・Torモジュールのダウンロードおよびレジストリに書き込み

UrsnifはTorClientのDLLモジュールをダウンロードし、C&Cサーバとの通信の隠ぺいを試みます。今回は下記のキャプチャの通り、hxxp://h33a7jzovxp2dxfg[.]onionにアクセスし、またTorClientのモジュール情報がレジストリに書き込まれたことが確認。

f:id:bankingmalware:20190628175235p:plain

Torドメインへのアクセスを試みる様子

 

f:id:bankingmalware:20190628175439p:plain

TorClient追加前のレジストリ

f:id:bankingmalware:20190628175453p:plain

TorClient追加後のレジストリ

キーロガー

キーロガーを実装するためにはいくつかの手法がありますが、本検体ではExplorer.exeにインジェクションされた不正スレッドがGetAsyncKeyState関数を利用して、キーロガーの機能を実装していることが確認されました。

f:id:bankingmalware:20190628175909p:plain

GetAsyncKeyState関数を利用して、キーロガーを実装。キーボードを入力するたびに、本APIが呼び出されることを確認。

 

・CreateProcessWのIATフック

UrsnifはExplorerをインジェクションしたのちに、Explorer及び各DLLのCreateProcess APIをIATフック(Import Address Table)することで、この後Explorer経由で呼び出されるプロセスに対して、インジェクションを試みます。まず、実際にIATがフックされた様子を下記に記載します。

 

f:id:bankingmalware:20190628180937p:plain

Ursnif起動前のIAT。起動前のCreateProcessの開始アドレスは0x76C9204D。

 

f:id:bankingmalware:20190628181151p:plain

Ursnif起動後のIAT。起動後のCreateProcessの開始アドレスは0x76D58000に変更されたことがわかる。

 

・CreateProcessWのIATフックの手法

前項でCreateProcessWのIATフックが行われたことが確認されました。そのIATフックを行う手法についてですが、呼び出し側のプロセスのコミット済みページ領域に対するアクセス権限を変更するVirtualProtect APIを用いて実装されていることがわかりました。下記キャプチャの通り、CreateProcessWの開始アドレスが書き込まれたアドレスから4バイトだけアクセス権限を変更してIATフックが行われていました。

f:id:bankingmalware:20190628183040p:plain

VirtualProtectを呼び出している様子。第1引数にCreateProcessのIATが書かれた先頭アドレス、第2引数が対象のバイト数、第3引数がアクセス権限。本件では0x40でPage_ExecutionReadWriteとしている。

 

f:id:bankingmalware:20190628183559p:plain

CreateProcessWの開始アドレスが書き換えられる直前。本来は0x7598204Dとなっている。

f:id:bankingmalware:20190628183710p:plain

CreateProcessWの開始アドレスが0x7598204Dから0x75A48000に書き換えられた

 

f:id:bankingmalware:20190628183925p:plain

再びVirtualProtectを呼び出している様子。アクセス権限を0x20として、元の値であるPAGE_READとしていることがわかる。

 

・CreateProcessAsUseWのIATフック

上記の処理部分にブレイクポイントを張り、処理を進めた結果CreateProcessAsUseWのIATフックも行われていることが確認された。

f:id:bankingmalware:20190630095004p:plain

Ursnif起動前のCreateProcessAsUseWのIAT。開始アドレスが77787B07となっている。

f:id:bankingmalware:20190630095025p:plain

Ursnif起動後のCreateProcessAsUseWのIAT。開始アドレスが7781800Aに変更された。

 

■CreateProcessのIATフックにより、行われる不正コードの追跡

 ・起動プロセスへのインジェクション

基本的にExplorerにインジェクションしたときと同様の手法(Process Hollowing)で起動プロセスへのインジェクションを行われることが確認できた。ただし、Explorerの際はすでに起動しているプロセス(Explorer)にインジェクションするためOpenProcessでExplorerのプロセスハンドルを得るが、今回はCreateProcessでまずSuspend状態でプロセスを起動し、その後ZwMapViewOfSection等を利用して不正コードを注入する。

それ以外はExplorerと同様のため、詳細な手順は省略します(詳細な手順は前記事を参照。 

f:id:bankingmalware:20190630114251p:plain

CreateProcessを呼び出すときの流れ。第1引数がアプリケーション名であり、今回はIEのパスが格納されている。 第6引数がdwCreationFlagsであり、今回は0x4080414となっている。0x4がサスペンド状態で起動するフラグである(CREATE_SUSPEND)。 参考として、0x400000はCREATE_DEFAULT_ERROR_MODE、0X80000はCREATE_STARTUPINFO_PRESENT、0X400はCREATE_UNICODE_ENVIRONMENTである。 (0X10は不明)

 

f:id:bankingmalware:20190630120455p:plain

ZwMapViewOfSectionの呼び出し。第1引数に不正コード用のSection、第2引数にiexplorerを指定することでSectionをiexplorerにマッピング

 

f:id:bankingmalware:20190630120731p:plain

ZwSetContextThreadの呼び出し。第1引数にiexplorerのスレッドハンドル、第2引数にContextの構造体のアドレスにしてEIPを変更している。iexplorerのスレッドのEIPが左下の赤枠の部分(0x0c0218)に変更される。

このiexplorerに注入された不正コードも簡単に解析してみましたが、explorerに注入された不正コードとほとんど同じ動きが見受けられました。explorerとiexplorerに注入されたRWXの領域のメモリを比較してみましたが、一部の部分は異なりましたが、それ以外は同じバイトだったため、基本的には同じ動きをすると思われます。また、試しにメモ帳や電卓を開いて、iexplorer, calc, notepadに注入された不正コードを比較してみましたがすべて同じでした(この傾向は私の解析環境でブラウザインジェクションも行われた2019年6月17日にばらまかれたUrsnifでも同様でした)。個人的にはブラウザインジェクションを行うため、iexplorerと他のプロセスで注入される不正コードは違うのではと勝手に推測していたため、意外な結果でした。

f:id:bankingmalware:20190630171505p:plain

Explorer(左)とiexplorer(右)に注入された不正コードの比較。本キャプチャのオレンジの部分を除けばすべて同じ。

f:id:bankingmalware:20190630171638p:plain

ixplorer(左)とcalc(右)に注入された不正コードの比較。前半の一部を除けばすべて同じ。

 

■(参考)自動起動設定

%temp%配下にadmkadp.exeという名前で自分自身をコピーし、自動起動となるようにレジストリを修正することが確認された。

f:id:bankingmalware:20190630095441p:plain



 ■まとめ

今回のUrsnifの静的解析により、プロセスインジェクションの手法及びIATフックの手法についてより詳しく理解することができました。逆にブラウザインジェクションの手法及びC&Cとの通信については、今回の検体では動作が観測できなかった(C&Cに関してはすでに落ちた)ため、十分に解析できませんでした。現在、諸事情でIDA Proを現在使えなくなってしまったので、またIDA Proが使えるようになれば時間があるときに解析してみようと思います。

 

■筆者について

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

 

■参考文献
今回の解析に当たり、多くのサイトを参考にさせていただきましたが、その中でも特に参考にさせていただいたページを記載させていただきます。
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