今年もはや6月になりましたが、年始から毎月絶えず、警視庁・警察庁からマルウェア添付不審メールに対する注意喚起がSNSなどを通して日々行われています。

今回我々は、それら注意喚起されている不審メールのうち、今年4月から5月中頃に全国的に広く配布された不審メールを一つ選定し、今一度どのような感染が行われるのか調査しました。

調査対象とした不審メールを経由してユーザーが最終的に感染するのは「DreamBot（Ursnif/Gozi）」(ドリームボットまたはアースニフ／本記事では以降DreamBotで統一記載)と呼ばれるマルウェアであり、長年オンラインバンキングに関する認証情報を狙ったマルウェアとしてその名を轟かせてきたメジャーなマルウェアの一つです。

オンラインバンキングの取引におけるマルウェア感染による国内ユーザーの被害額は非常に大きく、毎年絶えず攻撃が国内においても広く継続しているため、「DreamBot」に関する調査レポートや解析情報は、それなりに多くのセキュリティベンダーや機関から様々な観点による分析結果が公開されています。しかし、それらのレポートを見てもわかるとおり、「DreamBot」は日々着々とその挙動を逐一変化させており、数ヶ月も経過するとマルウェアの挙動はもはや多かれ少なかれ当時の分析結果通りではなくなってくるという現状があります。

我々は、現時点（本記事調査時点）でユーザーが感染しうる最新のオンラインバンキングマルウェアの動きはどうなっているのか、「DreamBot」の今を追ってみました。また加えて、本記事においては、他であまり触れられていない「DreamBot」の各々のテクニックの詳細についてもいくつか少し深掘りして解説します。

■１）メールの開封から「DreamBot」の感染まで

我々が対象として選定した不審メールは、件名に「【楽天市場】注文内容ご確認（自動配信メール）」と記載されており、大手インターネットショッピングサイトからの注文確認を装ったものでした。

この不審メールはHTML形式のメール本文を持っており、本文中のハイパーリンクの殆どが以下のZIPファイルを指すように作られています。つまり、本メールを開いたユーザーがメールの本文中に多数貼られたいずれかのリンクをクリックすると、以下のZIPファイルが規定のブラウザでダウンロードされるように細工されています。

上記の接続先URLからは「もっと詳しくの情報はこちら.zip」というファイル名のZIPファイルがダウンロードされます。「もっと詳しくの情報はこちら.zip」のZIPファイルには、ランダムなファイル名が付与されたJSファイルが格納されています。

• ＜ランダムな文字列＞.JS ・・・「もっと詳しくの情報はこちら.zip」の中に圧縮されたJSファイル

ダウンロードしたZIPから解凍されたJSファイルは複雑に難読化されており、復号すると以下のような可読可能なJSスクリプトの文字列（コード）が出現します。

これまでの流れをプロセスの関連図として示したものが以下の図となります。

JSファイルからは最終的に「TempPhT52.exe」というファイル名のEXEファイルがダウンロードされ実行されることがわかりました。これが冒頭でコメントした「DreamBot」本体のEXEとなります。

■２）「DreamBot」の詳細解析

ここからは「DreamBot」の動きの詳細を追っていきます。

「DreamBot」は実行されると、煩雑なコード遷移の後に、EnumFontsAというWin32APIをコールします。このEnumFontsAは端末で利用可能なフォントの一覧を取得する関数ですが、第三引数に任意のコールバック関数を指定することができるという仕様があります。「DreamBot」はこの関数の仕様を悪用し、あらかじめ不正な関数を書き込んでおいたメモリアドレスをEnumFontsAの第三引数に指定することでコールバック関数として指定します。これにより、「DreamBot」がEnumFontsAを実行した際、それに紐付いてコールバック関数として指定されたアドレス先の不正コードが実行されます。

その後「DreamBot」は、多重にメモリ領域の確保とジャンプを繰り返す複雑なコード遷移の処理をしばらく実行し、最終的にExplorer.exeにインジェクションします。ここでの複雑なコード遷移は、手動解析によりコードを追う作業が非常に煩雑になることから、一種の解析妨害であると考えられます。

その複雑な遷移の中で、「DreamBot」はいくつかの耐解析機能（アンチデバッグ機能）を利用しています。

まず、GetCursorPos関数を用いてマウスカーソル座標の移動をチェックすることによる耐解析機能が挙げられます。これはマルウェアのコードの処理の継続をマウスの移動というユーザー動作に紐づけることで、マウスのカーソルが移動しないとコードの処理が進まないため、マウス操作がない（マウスが移動しない）環境では不正動作が行われません。これは主にサンドボックスなどの自動解析を考慮したものと考えられます。

「DreamBot」は、このGetCursorPosによるマウス座標の移動チェックを利用した耐解析処理を複数箇所で利用しています。具体的にはこの後に行う自身の「.bss」セクションの復号処理においても、この仕組みを組み合わせ、マウスカーソルの移動に紐付いて復号処理の流れが遷移します。（マウスが移動しない場合、復号処理が実質的に待機状態になり、マウス移動が発生しない限り無限ループになります。）

GetCursorPosで座標を比較する際、ある程度の時間間隔を設けるため（マウス座標の移動が発生しうる程度の時間だけコードの遷移を遅延させる必要があるため）にWaitForSingleObjectのタイムアウトの仕組みを利用します。WaitForSingleObject に紐づけるイベントはCreateEventで生成するものの使用しないため、ダミーのイベントであると推測されます。

上記の一連処理が終わると、「DreamBot」はさらに、メールスロットと呼ばれる仕組みを利用する耐解析機能を呼び出します。

メールスロットとは一般的にプロセス間通信で利用される古くから存在する技術であり、以下の図のように、メールスロットと呼ばれる疑似ファイルのようなオブジェクトを利用し、複数のプロセス間で情報をやりとりすることが可能なWindowsの仕組みです。

メールスロットは一般的にプロセス間通信で利用されますが、「DreamBot」はこの仕組みを自身の内部に作成した2つの子スレッドに応用し、スレッド間通信として利用します。

具体的には、「DreamBot」は２つの子スレッドA、Bを作成し、4,096バイトのサイズを持つメールスロットを作成した後、それぞれのスレッドで4,096バイトずつ交互に作成したメールスロットへ読み書きを行います。つまり、子スレッドAが4,096バイト書き込むと、子スレッドBが4,096バイト読み込む、という動作を繰り返します。

このメールスロットを用いたスレッド間通信の処理を行う背景は、上でも述べたとおり、複数スレッド間を短時間に頻繁に行き来する処理を挟むことで手動デバッグを煩雑にさせる手動解析の妨害目的が一つ考えられます。

なお、上記図にもあるとおり、受信側の子スレッドがメールスロットで受け取ったデータはメモリ上に構築されていき、DLLファイル（メモリ上にのみ存在）となります。ただし、このDLLファイルはMZおよびPEヘッダのマジックナンバーそれぞれ２バイトが0x00で埋められています。加えて、このDLLファイルには「.bss」という名前が付けられたセクションが存在し、以降で使用する不正コードがこの「.bss」セクション内に暗号化されて保存されています。

「DreamBot」は次に、この「.bss」セクションの復号処理に取り掛かりますが、この際の復号処理に上記で説明したマウスカーソルの移動距離を元にした復号ルーチンを使用します。

具体的には、ある２点間のマウスカーソルの座標の差異を独自の計算式で算出し、算出された差異値をもとに復号キーを生成し「.bss」セクションの復号を行います。当然、現実におけるマウスカーソルの座標位置は様々な差異値となり、複数回の復号を試行することになります。正しく復号できない場合は復号できるまで繰り返し処理を行います。つまり、一種のブルートフォース（総当たり）にあたる処理により復号が行われます。ブルートフォースであればむしろ復号できないケースがあるのではないかと感じますが、64msのうちに1/32（下位５ビットしか利用されないため2^5= 32通り）の確率で正しいキーが応答されます。つまり、1秒間における成功割合は４８％であり、人の操作が行われた場合２～３秒あればかなりの割合で復号が成功するものと想定されます。これはランダムとなる人間の操作で成功率があがりやすく、一方で変化がないか単純な変化になりがちな自動解析（サンドボックス）では成功率が低くなる効果的な耐解析機能の一つと想定することができます。

それらを図示したものが以下となります。

以下は、「DreamBot」が復号関数へ引数として渡す値を算出する際に使用するマウスの座標を処理している際の実際の様子（デバッガでの動作様子）です。

また、上記のロジックで算出したマウス座標の差異「0x9」の場合における復号キーの生成ロジックは以下となります。

マウスカーソルの差異が「0x9」の場合と、正しい復号キーが生成できる差異「0xE」の場合のメモリ上への復号結果の比較の様子が以下となります。正しい復号キーが生成できる差異「0xE」であれば可読できる文字列が復号できていることがわかります。

では上記にて復号されたデータが「正しく」復号されたかどうかの判断はどのように行うのでしょうか。

以下は、具体的に復号キーが正常かどうかを確認する「DreamBot」の確認ルーチン部分となります。

「Explorer.exe」へのインジェクション

次に「DreamBot」は、Explorer.exeという名前のプロセスを検索し、コードインジェクションを行います。

この際、より詳細には以下の図示のとおり、ZwMapViewOfSectionの第二引数に相手のプロセスハンドルを指定し、自身のメモリセクションをマッピングオブジェクトとして扱うことで不正コードをリモートでインジェクションするセクションマッピングインジェクションを行います。相手のプロセスメモリ空間に主たる不正コードを直接書き込むことなくリモートでのコード注入を実現できるため、不正挙動の監視回避策としても効果的なテクニックと言えるでしょう。

また「DreamBot」は、CreateRemoteThreadを呼び出す際、RtlExitUserThreadというスレッド終了関数に意図的に開始アドレスを指定しており、さらにその先頭コードの４バイトをEB FE CC CC（EB FEで無限ループ）に自ら書き換えるという処理をおこなっています。

この処理については、「DreamBot」は後述の新規プロセスへのインジェクション時にも同様の手法を利用しますが、新規プロセスへのインジェクション時にはそのままだとプロセスの初期化が行われていないためインジェクションを遂行するために必要な前準備を実施する目的が主と考えられ、これを「Explorer.exe」を含む既存プロセスへのインジェクションの際にもそのまま流用しているものと思われます。また、一般的（初歩的）なCreateRemoteThreadによる不正コードの実行ロジックを解析する場合、この時点でデバッガによりアタッチしがちですが、本ケースにおける実際の不正コードの注入は更にこの後のため、この時点ではExplorerに不正コードはなく、また、EB FEの無限ループを書き戻すことでRtlExitUserThreadが呼び出されるため、すぐにスレッドが終了しデバッガによる解析を継続することができません。つまり、一種の簡易的な耐解析機能としての役割も併せて考えられるかもしれません。

Explorerへのインジェクションが終了した後、本体のTempPhT52.exeは自身を終了します。

その際、DeleteFileWによる自身のファイルの直接的な削除を試みますが、当然自身が起動しているため失敗し、その後、MoveFileExWにMOVEFILE_DELAY_UNTIL_REBOOTフラグを指定して実行することで、システムが次回起動した際に削除を実行するようにシステムに登録します。

※なお、上記の処理において、Explorerへのインジェクションが正しく完了できなかった場合、以下のプロセスを代わりに起動し、同じくインジェクションの対象として処理を継続します。（本記事では省略します）

「Explorer.exe」（不正コード注入後）の主な不正動作

続いて、「Explorer.exe」（不正コード注入後）は、以下のファイルを作成します。このEXEファイルは、初回の実行ファイルであった「TempPhT52.exe」のコピーであり同一ハッシュのファイルです。

また、上記のファイルを以下のレジストリに登録することで、システムの起動時に自動起動するように設定します。

その後、端末における以下のような情報を収集します。

「DreamBot」は、盗んだ情報を%temp%に「XXXX.bin」（実際はZIPファイル形式）のファイル名で一時保存する特徴があります。

これらのZIPファイルはその後C&Cサーバへアップロードされます。

以下は例として、感染端末で作成されたZIP内の情報を閲覧した様子です。

以下の情報がまとまって一つのテキストファイルに保存されていることがわかります。

一般的に、ブラウザのタイトルにはアクセス中のサイトの名称（オンラインバンキングの場合は銀行名）が表示されることが多いため、結果的にキー入力したIDとパスワードとそのサイト名のセットを盗まれることになります。

また、以下のように認証情報を入力している際の様子を録画し動画として保存する仕組みも持ち合わせています。これはソフトウェアキーボードなどの対策に対する認証情報窃取手段の一つとして考えられます。

以下は、「.bin」という拡張子を「.zip」に変換したものを解凍し、中身を確認した様子です。

「DreamBot」は、Torモジュールをダウンロードする動作があり、C&Cサーバへの接続はTorのモジュールをダウンロードできた場合、Tor経由で行います。

また、Torが利用できなかった場合、以下のC&Cサーバに接続します。

接続の際、以下のUserAgentを利用します。

従来のUrsnif、DreamBotと同じく、/images/というURLオプション文字列とともにjpeg、bmpなどの画像ファイルの拡張子となる末尾を持ったURLへ接続を行い、それぞれ必要な設定情報を取得します。

ブラウザへのインジェクション

「DreamBot」の大きな目的の一つは、WebInjectionによるブラウザの監視を通した認証情報の窃取です。

「DreamBot」を含むオンラインバンキングマルウェアの多くが、このWebInjectionによるMITB（Man In The Browser）の仕組みを持っています。

単に概要を述べると、「DreamBot」を含むオンラインバンキングマルウェアに感染したPC上のブラウザで、オンラインバンキングやクレジットカードサイトなど、認証情報を必要とするページにアクセスした際、(そのサイトがマルウェアの監視サイトであった場合)、マルウェアがブラウザの処理に無理矢理割り込むことで、まるで本物のページのような偽の認証情報入力欄や画面を、実際の本物のサイトに重ねるように表示させられます。ここで入力した情報は全て攻撃者の手元に送信されることとなります。

上記、WebInjecitonを行うための一般的な最初のステップが、ブラウザプロセスへのインジェクション（不正コード注入）となるのですが、「DreamBot」はブラウザのプロセスにインジェクションを行うためのいくつかの手段を用意しています。

一つはプロセス名（のハッシュ比較）による既存プロセスへの一般的なインジェクションですが、もう一つは我々が追従インジェクションと呼ぶ手法です。

追従インジェクションとは、自身がインジェクションしたプロセスから起動する全ての子プロセスを監視し、子プロセスの起動タイミングから隙間なく追従して繰り返しインジェクションしていく方法です。

具体的に述べると、「DreamBot」はExplorerに感染すると、Explorerがプロセス起動を行うためのAPI（CreateProcessA等）をフックすることで、Explorerからの全てのプロセス起動を捉えます。そして、Explorerから起動しようするプロセスがInternet Explorerなどのブラウザプロセスであった場合、プロセス生成における初期ルーチンからインジェクションを行うことで、ブラウザプロセスの全ての挙動を支配下に置くことができます。

以降、「DreamBot」がExplorerのフックを行う詳細の流れを解説します。

「DreamBot」はまずExportAddressTable(EAT)のフックを行ったのち、ImportAddressTable(IAT)のフックを行います。「DreamBot」がEATフックを行う理由は、IATフックのみだと動的なDLLロードのAPIフックに対応できないためであると想定されます。

まず、ExportAddressTableフックの一般的な仕組みおよび概念を以下の図に示します。

次に、「DreamBot」が実際に行うEATフックの流れを図示したものが以下となります。CreateProcessを始めとするいくつかのAPIに対し、以下のような仕組みでAPIフックを行います。（なお、以下の図に記載したフック対象APIは一部であり全てではありません）

以下は、「DreamBot」により実際に書き換られたEATの比較の様子となります。

「DreamBot」は上記の流れでEATフックを行った後、次に示すようにIATフックを行います。（※ImportAddressTableのフックに関する概念説明は省略します）

実際に、「DreamBot」に感染した端末におけるExplorer.exeのIATを、感染前後で比較した様子が以下となります。上記で示したとおり、アドレスが書き換えられていることがわかります。

なお、「DreamBot」のCreateProcessのフック関数の内部で行っている追加処理の一つに、Explorerから起動されようとするプロセスをサスペンド状態で起動するようCREATE_SUSPENDEDのフラグを意図的に追加する挙動があります。これは、プロセスの開始タイミングからインジェクションが行えるようにするための前段階の処理であると考えられます。

「DreamBot」はこうした仕組みを利用してブラウザに感染し、その後のWebInjectionに繋げます。

なお、WebInjectionにおけるフックについても上記で示した手法を介し独自の不正処理を追加します。

具体的には、「DreamBot」はiexplore.exeをサスペンド状態で起動した後、前述のセクションマッピングインジェクションを行うことで、iexplore.exeの本来の処理が行われる前にWebInjectionに必要なAPIをフックし、iexplore.exe本来の処理に遷移します。

攻撃者サーバで確認したクレジットカード会社へのWebInjection設定ファイル

我々の調査の結果、「DreamBot」がブラウザプロセスにWebInjectionを行う際に動的に外部からダウンロードする不正JSスクリプトが配置された不正サーバのURLを辿ることで、用意された攻撃JSスクリプトの一覧を得ることができました。

以下は、不正サーバ上に配置されたWebInjection用スクリプトファイルの一覧となりますが、日本国内の複数のクレジットカード会社をターゲットにしていると推測できるファイル名が付与されていることがわかります。

アップロードされたファイルの日付を見た限り、2016年4月であり古いスクリプトに見受けられますが、実際にこれらターゲットとされている全てのクレジットカード会社のサイトに対し、感染端末からログインページにアクセスし調査した結果、その多くのログインページでこれらの不正スクリプトが未だに機能していることを確認しました。つまり、それらのクレジットカード会社のログインページにアクセスした場合、実際にインジェクションが行われ、偽の認証情報入力画面が表示されるということです。なお、検体が感染時に動的にダウンロードする設定ファイルでMITBの対象とされていたのはサーバにあげられていた13社のうち11社であり、実際に攻撃が成功したのは8社でした。

※なお、誤解なきよう念押しとなりますが、これらの偽画面は決して各社のサイトが改竄されているわけではありません。これはマルウェアがローカルPC上のブラウザプロセスに感染し、正常な表示データがブラウザ上で表示される前に、情報を改ざんした上で偽の情報をブラウザに表示させている結果となります。

以下は、実際に我々が確認した偽認証画面のウインドウの様子（InternetExplorerを使用）です。

「DreamBot」に感染したPCから各クレジットカード会社のログインページにアクセスし、適当なログイン情報を入力して次ページへ進もうとボタンをクリックすると、以下のような精巧な偽の認証情報を入力する画面が表示されました。

なお、今回確認した全ての偽認証画面において、以下にあげるように特定の文字列が文字化けしているという共通点を確認しました。いずれ修正されたり、他の検体のケースではこの文字化けが起こらなかったりなどの例外はあるかと思いますが、今後しばらくは偽認証サイトの簡易的な判断方法の一つとして利用できるかもしれません。

また詳細は割愛しますが、今回サーバ上の一覧で確認できたのはあくまでクレジットカード会社の設定ファイルであり、今回の「DreamBot」が感染中にダウンロードした設定ファイルには、これまでと同様に、クレジットカードだけでなく地方銀行を含むさまざまな銀行のオンラインバンキングサイトや、国内の仮想通貨サイトがその攻撃対象となっていることを確認しています。

■３）最後に

我々がこの検体の調査結果をまとめている最中も、また異なる挙動を持った「DreamBot」が配布されはじめています。このように、攻撃者は日々着々と手を変え品を変え新しい亜種を作成しばらまいています。今回の検体は従来までの「DreamBot」と本質的に大きく異なる点はないものの、メールスロットによるスレッド間通信や、一部の接続先サーバ（マニピュレーションサーバ）の変更等、細部を見ていくと新しいと思われるテクニックや変更点が存在することがわかりました。今後は手元に届いたマルウェアが既知のマルウェアと同一ファミリ検出名であったとしても決して安心せずに、慎重に調査し対処することがまずは必要であるといえるでしょう。弊社では今後もオンラインバンキングを狙ったマルウェアの動向に着目しその変化を継続して追い続ける予定です。

■４）その他の情報　＜「DreamBot」の本体の作成先パスにおける考察＞

なお、今回のJSファイルのコードはダウンロードした「DreamBot」の本体を以下のパスに作成します。

そして、一般的なマルウェアでよく利用されるのは、以下のような%temp%のパスです。

ここで、JSコードをもう一度良く見てみると、保存場所の指定に以下のような文字列を指定しています。

実のところ、攻撃者は「%temp%\PhT52.exe」としたかったのではないでしょうか。

わざわざ%temp%という環境変数を利用していることを鑑みると、当初、攻撃者は%temp%のフォルダ内に「PhT52.exe」というファイル名で作成したかったけれど、「￥」をつけ忘れてしまい、想定外の場所に作成することになってしまった、と推測することができます。

ただし、パスが想定外だとしてもその後の不正挙動には一切影響を及ぼさないため、安心はできません。

※本記事で使用した検体のハッシュ値は以下となります。

SHA256：20b4184c27c3f6ac557fbd8c3750ee6c8581d464d118353a4ce9405d104cfb5f

DreamBot暗号鍵：s4Sc9mDb35Ayj8oO

DreamBotバージョン：216994

吉川 孝志 の他のブログ記事を読む