Tinba―銀行の認証情報をハッカーに送り込む巧妙なボットネット

• 本文はフォーティネット セキュリティ ブログの抄訳です。
  執筆者：Collin Tam
  2015年5月14日

情報は常に誰かの役に立っています。他のボットネットの多くと同様に、「Tinba」にとって役立つ情報は、閲覧データ、ログインIDやパスワード、あるいは銀行預金の情報であると考えられます。ボットネットマスターは、手に入れたい情報を決定し、盗んだ情報を意のままに改ざんしてしまいます。手際よく情報を収集するためにTinbaがとる手法として、次の特徴が挙げられます。

• 疑惑と検知を避けるために、ホストに自らの活動を隠し、
• ホスト環境に潜在し続けながら、
• 情報を収集し、集めた情報をボットネットマスターのサーバにアップロードします。

Tinbaに関する今回の分析レポートでは、Tinbaの巧妙なパフォーマンスを実現する、上記3つの特徴の基本的な仕組みについて考察します。

今回のレポートでは、まず、最も標的にされるプロセスの1つである「explorer.exe」にコードを注入し、ホストに自らの存在を隠すTinbaの手法について見ていきます。次に、Tinbaの主要な3つのスレッドを分析し、これらのスレッドの目的と仕組みを明らかにします。また、TinbaのDomain Generation Algorithm（DGA）、およびAPI 注入の手法についても解説します。そして最後に、Tinbaが使用する、メッセージとペイロードの暗号化および構造について述べていきます。

Tinba独自のバイナリ

現在のほとんどのマルウェアと同様に、Tinbaは通常、複数レイヤーの専用パッカーによって圧縮されています。 解凍されると、Tinbaは自身の復号されたコンテンツを作成し、「winver.exe」プロセスに注入します。「winver.exe」は、Windows オペレーティングシステム用に開発されたプログラムで、system32フォルダにあります。次にTinbaは、「69523B60」という名前のハードコーディングされたミューテックス（mutual exclusive:排他制御）の作成をチェックします。このミューテックスが作成されると、「explorer.exe」プロセスの感染が成功したことを知らせ、もとのプロセスは停止します。

ただし、Tinbaが20回チェックしても該当するミューテックスが見つからない場合は、Tinba自身が「explorer.exe」プロセスを探し、注入を試みます。

Winver

コードが注入されると、「winver.exe」は「FindWindowA」APIを呼び出し、「Shell_TrayWnd」の名前で「explorer.exe」を探します。 成功すると、「winver.exe」は「explorer.exe」プロセスにハンドルを返します。「winver.exe」はTinbaのコードを「explorer.exe」に注入したのち、プロセスを停止します。

このようにTinbaは、ターゲットに対して、仲介するプロセスにコードを注入させる手法をとることにより、自らの疑わしい性質を隠し、検知を回避するのです。

Explorer

コードが「explorer.exe」に到達すると、Tinbaのコードを実行するために次の3つのスレッドが作成されます。

スレッド 1 インジェクター

このスレッドの目的は、ホストで実行中のプロセスにコードを注入することですが、その手法は極めて単純です。すなわち、Createtoolhelper32Snapshot APIを呼び出してプロセスIDのリストを取得し、プロセス内に仮想的に割り当てられたメモリを開いたり作成したりし、自らのコードで新しいメモリに書き込みます。Tinbaには、メモリに保存されたプロセスIDのブラックリストがあり、このブラックリストを使用することで、重要なプロセスにはコードが注入されないようにしています。リストを一巡すると、このスレッドは短期間休止した後、再びルーティンを繰り返します。

コードが注入されると、プロセス内にリモートスレッドが作成されます。このリモートスレッドは、Tinbaが標的にするプロセス、つまりWebブラウザを見つけたかをチェックするために、GetModuleFileName APIにファイルパスを取得します。次に「iexplore.exe」の文字列のファイルパスをチェックし、この文字列が見つからない場合は、WebブラウザFirefoxが使用する「NSS3.dll」ライブラリのプロセスを調べます。「NSS3.dll」ライブラリがロードされていない場合は、「opera.exe」の文字列をチェックします。一致する文字列が見つからなかった場合は「ChromeMain」の文字列を調べ、すべて失敗した場合には、リモートスレッドは短期間休止したのち終了します。

一致する文字列が見つかった場合、スレッドは2次スレッドを作成します。2次スレッドの目的は、Tinbaが標的にするURL と文字列のリストを更新することです。2次スレッドは「grb.dat」および「web.dat」ファイルを探します。これらのファイルはいずれも「explorer.exe」の通信スレッドによってダウンロードされ、Tinbaが追跡しログに記録するための、更新されたターゲットを含んでいます。 いずれかのファイルが見つかった場合、ファイルは開かれ、メモリにロードされます。どちらのファイルも見つからなかった場合は、Tinbaのメモリからターゲットのデフォルトリストが検索されます。2次スレッドは休止したのち、再び作動を繰り返します。

最初のスレッドは、2次スレッドを作成したのちTCP接続に関連するAPIをフックします。フックされた APIを介して、Tinbaが狙う情報（銀行預金情報、ソーシャルメディアのアカウント情報、ウェブメールの認証情報など）が追跡され、ログに記録されます。これらの情報はTinbaのペイロードである「log.dat」ファイルに保存されます。

スレッド 2 パーシステンシー（持続性）

このスレッドの目的は、ファイルを安全に保存する隠しフォルダを作成し、Tinbaのバイナリファイルが起動時に実行するようにすることです。隠しフォルダは「%APPDATA%/69523B60」に作成されますが、このフォルダ名は、「独自のバイナリ」の項で前述したミューテックスと同じ名前です。

Tinba独自のバイナリは隠しフォルダにコピーされ、これをWindows起動時に自動的に実行するためのレジストリキーが作成されます。このスレッドの機能は1回だけ実行され、その後スレッドは永久に休止する点が特徴的です。

スレッド 3 コミュニケーション（通信）

このスレッドは、C&C（C2）サーバへの接続を成立し、サーバにペイロードを送り、サーバから更新とコマンドを受け取るために設計されています。接続するドメイン名は、ハードコーディングされたシードを用いてDomain Generation Algorithm（DGA）により生成されます。 接続が成立すると、インターネットのトラフィックを軽減して疑惑を回避するために、Tinbaは5分に1回だけC&Cサーバにメッセージを送信します。

Domain Generation Algorithm（DGA）

このサンプルで使用されているDGA は、キー文字列をキーにハッシュすることで始まっています。これは、キーの文字列の初めの16 バイトを結合することで実現します（文字列の長さは16 バイト以上であると考えられます）。 キー文字列がハッシュされると、ハードコーディングされたURLによってDGAの最初の反復が行われ、続いて新たに生成されたURL によって反復が行われます。12バイトのドメイン名が形成されるまで、以下のステップが繰り返されます。

キーは、「XOR」オペレーションで、ドメイン名の現在のインデックス値を用い、ドメイン名の最初の文字で始まるように変更されます。次に、ドメイン名の次のインデックス値がこの結果に追加されます。キーの最下位バイトがアルファベットの「a」から 「y」までの文字である場合、そのバイトはドメイン名の現在のインデックス値を更新し、インデックスは1ずつインクリメント（増加）されます。それ以外の場合は、キーが1ずつインクリメントされ、反復が繰り返されます。

DGAで使用されるハードコーディングされたURLには、「elitocool.ru」、「elitiorecfreetoo.cc」などが挙げられます。また、このDGAで生成されたドメインには、「ljjskttqximu.com」、「fovcpylsiqvv.in」、「ptuvwkjgwleu.in」などがあります。

メッセージの構造

TinbaとC&Cサーバ間の通信において、Tinbaが送信したメッセージではヘッダとデータの構造が観測されていますが、C&Cサーバが送信するメッセージでは、ヘッダの構造しか観測されていません。

送信メッセージ ヘッダ

更新された Tinba ボットの復号されたヘッダ

旧型Tinbaボットのメッセージの、復号されたヘッダ

struct  Send_Hdr

{   dword    key1;               / key used to decrypt header; low order 32bit from rdtsc/
    dword    time;                / time stamp; high order 32bit return value from rdtsc/
    dword    magic1;            /  bot id or campaign id /
    dword    magic2;            / version number /
    qword    string;              / string /
};

送信メッセージのヘッダのCスタイル構造

ヘッダのサイズは0x18h バイトで、5つの要素（復号化のためのキー、タイムスタンプカウンター、2つのマジックナンバー、8バイトの文字列）から成ります。XORオペレーションでキーによりヘッダが暗号化された場合、復号化キーは、プレーンテキスト形式でキーのスペースに自らをコピーします。このキーは、「RDTSC （リードタイムスタンプカウンター）」インストラクションを呼び出し、EAXレジスタの値を検索することでランダムに生成されます。 次の「タイム」値については、「RDTSC」インストラクションを呼び出し、（EAXレジスタではなく）EDXレジスタの値を検索することで生成されます。EAX と比較してEDX のインクリメント（増加）は遅いため、サーバにとって、EDXは、追跡するタイムスタンプの役目を果たしています。タイムスタンプで非同期やタイム値の繰り返しなどの異常が発生した場合、サーバは問題を検知します。次に2つのマジックナンバーですが、1つ目のマジックナンバーはボットIDやキャンペーンIDの働きをし、2つ目のマジックナンバーはTinbaのバージョンを表示します。最後の要素としては8バイトの文字列が挙げられます。フォーティネットは、Tinbaのすべてのバージョンにおいて、この文字列が ドメインのシードの文字列と部分的に一致することを観測しています。この8バイトの文字列は、1つ目のマジックナンバーに対応する機能を果たすと考えられますが、現時点では特定できていません。

送信メッセージ データ

Tinbaボットメッセージのデータブロック例

struct  Send_Data Block {
    byte    type;     / Used to determine what kind of data is proceeding /
    dword     size;    / size of data /
    uchar[size]    data;    / data block of length "size", to be decrypted by server /    };

送信メッセージ用の、データのCスタイル構造

データブロックの構造は、3つの要素（データ型のフラグ、データのサイズ値、データ）から成ります。まず、データ型のフラグですが、こちらはTinbaが送信したデータやペイロード（文字列、プロセスリスト、インターネットのトラフィックなど）を、C&Cサーバが見極めるために使用されます。次にデータのサイズ値は、サーバがデータを復号する際に使用されます。3つ目のデータとは、サーバに送信されるデータやペイロードのことです。

Tinbaが送信するメッセージには、複数のデータブロックが含まれていると考えられていますが、これらのデータブロックは直前のデータブロックに直接添付されており、ヘッダを含んでいません。

受信メッセージ ヘッダ

C&Cサーバのメッセージのヘッダ例

struct  Recv {
    dword    magic;    / value = 0x08300d0f /
    byte    flag;    / command flag /
    dword    size;    / size of the data block; excludes header size /    };

受信メッセージ用の、ヘッダのCスタイル構造

C&Cサーバが送信するすべてのメッセージには復号されたヘッダが含まれており、これらは3つの要素で構成されています。1つ目は、Tinbaが発信するメッセージの構造にも見られたマジックナンバーです。このマジックナンバーは、ホストのインターネットトラフィックから、C&Cサーバのメッセージをふるい分けるために使用されます。2つ目はコマンドフラグですが、こちらはバイトサイズの値で、Tinbaがすべきこと（ファイルのダウンロードなど）を伝達するために使用されます。最後に、3つ目の要素として、更新されたウェブサイトリストやTinbaのアップグレードなど、メッセージに残っているデータのサイズがあります。

暗号化

Tinbaで暗号化が行われる場所は3か所です。すなわち、TinbaとC&Cサーバ間で送信されるメッセージのヘッダとデータの2か所、そして残り1か所は、C&Cサーバから新規ファイルのダウンロードに失敗した場合にTinbaが使用する、ターゲットのデフォルトリストです。

メッセージのヘッダ

メッセージの構造のところで復号化のキーについて述べましたが、ヘッダの暗号化に使用されるキーも、「RDTSC」インストラクションを呼び出し、低次32ビットのリターン値を検索することでランダムに生成されます。暗号化のルーティンは、それぞれの書き込みの後の、キーの8 ビットの「ROR」による、単純な「XOR」バイトです。

ヘッダの暗号化アルゴリズム

これはキーローテーションでDWORD 「XOR」としても表示されます（ただし4で分割できるサイズのヘッダに限る）。暗号化が完了すると、ヘッダの最初と最後のDWORD両方から、キーをプレーンテキスト形式で見たり検索したりすることができます。

メッセージのデータ

Tinbaが送受信するデータはすべて、バグを含んだRC4アルゴリズムによって暗号化されます。このRC4アルゴリズムは、バグのために、入力されるキーの文字列の長さに関係なく、一律16バイトのキー長を使用しています。キーはハードコーディングされた20バイトの長さのアスキーコード（ASCII）文字列で、Tinbaのバイナリコードにあります。ただし、RC4の鍵スケジューリングアルゴリズム（KSA）や擬似乱数生成アルゴリズム（PRGA）は、一切変更されません。

WebブラウザやエクスプローラーからTinbaによってキャプチャされたペイロードデータは、RC4アルゴリズムによって暗号化されてからファイルに保存され、エクスプローラーの通信スレッドからC&Cサーバに送信されます。C&CサーバからTinbaに送られたデータも、変更された同一のRC4アルゴリズムとキーにより暗号化されますが、この場合、暗号化されたデータは、一般的なパッカー「aPLib」によって圧縮されます。復号後、Tinbaは自らのコード内の「aPLib」ライブラリから解凍機能を使用して、プレーンテキスト形式のデータを検索します。

ターゲットとするURLのデフォルトリスト

Tinba がペイロード情報をキャプチャするには、まずターゲットリストの文字列が一致する必要があります。ターゲットとするURLのデフォルトリストと注入スクリプトの両方が、Tinbaのコード内で暗号化されます。 C&Cサーバから新規ターゲットリストのファイルをダウンロードできなかった場合、Tinbaはデフォルトリストの復号・解凍を行い、 更新されたリストがダウンロードされるまではそのリストを使用します。

ペイロード

Tinbaの目的は、ターゲットとするWebブラウザやWebサイトから安全なトラフィック情報を収集し、その情報をC&Cサーバにアップロードすることです。Tinbaが標的とする主なWebブラウザとしては、Firefox、Internet Explorer、Google Chrome、Operaが挙げられます。

またTinbaが狙う主なURLは、金融機関のホームページ、Google、Facebook、Microsoftです。

Tinbaがキャプチャしたペイロードデータ例

Tinbaは、パケット盗聴（packet sniffing）によってデータを収集すると、ターゲットに一致する有用な情報をすべて記録し、ペイロードファイル「log.dat」に保存します。 Tinbaはコマンドサーバとの接続を成立させると、ホストのシステムからペイロードをアップロードし、その後削除します。

追加の最新情報

Tinbaの0x1B010105hバージョンが生成するC&Cサーバドメインの大半は、書き込み時に、あらかじめ用意されたシンクホール（Sinkhole）に振り向けられています。しかし、Tinbaの最新バージョン0x1B010106は、新しいドメインシード、RC4 アルゴリズムの復号化キー、ボットIDおよびキャンペーンIDを備えており、最新バージョンが生成するC&Cサーバドメインの一部は、現在もなお活動中です。

まとめ

ボットネットTinbaの狙いは単純明快です。つまり、ホストから価値ある情報を最大限収集し、その情報をボットネットマスターに送信することです。Tinba は成功率を高めるために、発見・解析されにくい手法をとっています。すなわち、ターゲットに対して、仲介するプロセスにコードを注入させる手法をとることで、解析のスピードを遅らせようと試みるほか、隠しフォルダにTinbaのファイルを隠し、TinbaとC&Cサーバ間のインターネット通信を5分に1回の頻度に制限している点がTinbaの特徴です。しかし、TinbaのDGAとシードに関する徹底的な調査・分析の結果、疑わしいドメインはシンクホールに振り向けられ、Tinbaを阻止できる可能性は大きく高まっています。