注目の調査：Qbot の復活
この投稿の執筆者：Ben Baker
Qbot（Qakbot とも呼ばれます）は、少なくとも 2008 年には出回っていましたが、最近になって開発や使用が急増しています。現在の Qbot の主なターゲットは、銀行取引のクレデンシャルのような機密情報になりつつあります。このブログでは、一般にはまだ知られていないこのマルウェアの最近の変化について報告します。
Qbot の主な感染手段は、ブラウザのエクスプロイト キット内のペイロードの形を取ることです。Web サイトの管理者は自分のサーバへのアクセスに FTP を使用する場合が多く、Qbot は FTP のクレデンシャルを盗み、これらのサーバにマルウェアをホスティングするインフラストラクチャを追加しようと試みます。Qbot は SMB を使用して拡散する場合もあります。このため、保護されていないネットワークから Qbot を除去するのは非常に難しくなります。
パッカー
Qbot は、各サンプルを大幅に変更できるパッカーを使用します。このパッカーの文字列およびコード ブロックは、検出シグニチャの作成が困難な方法でランダム化されています。ファイル名、ドメイン名、および暗号化キーがランダムに生成されることから、ランダム化は Qbot における共通のテーマです。
幸いなことに、このようにコードが難読化されていても、パッカーのコードの動作が複雑になるわけではありません。解凍コードは常に PE ファイル全体をメモリ内に作成しており（おそらく MD5 は元の圧縮されていない実行可能ファイルと一致します）、カスタムのローダを使用して、解凍したファイルを実行していました。このローダが Windows API VirtualProtect を呼び出すと、解凍された実行ファイルが信頼されたものとして展開される可能性がありました。解凍コードでは、解凍されたメモリ セクションの実行を可能とするために VirtualProtect が使用されていることから、解凍されたコードが実行され、VM が感染する前に、このコードをダンプすることができます。
私たちは、それぞれのパックされたファイルのデバッグに Pykd スクリプトを使用することで、パッカーの予測可能性を活用しました。 VirtualProtect にブレークポイントを設定し、解凍された実行ファイルをダンプするために、プロセスのメモリをスキャンしました。解凍されたコードが実行される前にプロセスを停止させるため、サンプルごとに VM を復帰させる必要はありません。このスクリプトは複数のサンプルを秒単位で解凍するため、多数のサンプルを解凍することが可能です。
私たちは 618 個のパックされたサンプルを分析しました。これらを解凍した結果、73 種類のサンプルが取得されました。各サンプルは複数の異なる方法で圧縮されており、ハッシュシグニチャの効果が低下していました。
インストール
パッカーが解凍された実行可能ファイルをメモリにロードすると、Qbot は、すでにインストールされている Qbot があるかどうかを確認します。「%appdata%\Microsoft\[RandomName]\ [RandomName].exe」から実行されている Qbot がなければ、Qbot はこの場所に自身をコピーし、そのコピーを実行します。
Qbot はメルセンヌ ツイスタ乱数生成器に文字列の CRC32 チェックサムや SHA1 ハッシュをシーディングして、ランダムな文字列を生成します。そして、ランダムな整数を生成し、文字を選択する際のアルファベット配列内のインデックスとして使用します。インストール フォルダの名前は、ProductId （HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId）、コンピュータの名前 （Windows API GetComputerNameA 経由）、ハードドライブのシリアル番号（Windows API GetVolumeInformationA 経由）のシードを使用して生成されています。
Qbot は確定的な文字列生成器を使用するので、サンプルが同じコンピュータで実行される場合、サンプルは常に同じファイル名とミューテックスを生成します。たとえば、サンドボックスが静的な製品 ID、コンピュータ名、およびボリュームのシリアル番号を使用している場合、ファイル名も静的になります（ただし、別のコンピュータでは別の名前になります）。そのため、顧客向けに、一般的な侵入の痕跡（IOC）を示すことは難しいのですが、Qbot を識別するためのサンドボックス用の IOC の作成は簡単です。
一度 Qbot がインストール ディレクトリで実行されると、Qbot は「Explorer.exe」という Windows 実行ファイルの新しいインスタンスを実行します。このプロセスにより、悪意のある DLL が含まれた「IDB_BITMAP1」というリソースがロードされます。このリソースは、最初の 20 バイトを RC4 キーとして使用して復号されます。復号されたデータには圧縮された形式の DLL が含まれています。このデータの先頭には圧縮されたデータの SHA1 ハッシュが記載されています。
圧縮はカスタムの方式で行われているように見えますが、LZSS と似ており、オフセットと長さの組み合わせをバイト数で示し、既存の解凍済みデータをディクショナリとして使っています。 ファイルは圧縮されたブロックに分割されています。各ブロックは、次のような形式の 24 バイトのヘッダーで始まります。
Magic Bytes[8]: “\x61\x6C\xD3\x1A\x00\x00\x00\x01”
Compressed Data Size[4]
Compressed Data CRC32[4]
Decompressed Data Size[4]
Decompressed Data CRC32[4]
この DLL は 3 つの圧縮されたブロックに分割されています。つまり、Qbot は最初の復号時の SHA1 ハッシュに沿って、6 つの CRC32 チェックサムをチェックするということです。1 つの DLL をロードするだけで、多数のエラーのチェックが行われます。
ロギング
Qbot は、インストール パスにある暗号化されたファイルにログを記録します。このログ ファイルの拡張子は dll であり、ファイル名は Qbot がインストールされている場所のディレクトリ名より 1 文字短くなっています。たとえば Qbot が「%appdata%\Microsoft\Oykyjxjx」にインストールされている場合、ログ ファイルは「%appdata%\Microsoft\oykyjxjx\oykyjxj.dll」になります。このログ ファイルは、フォルダ名を小文字に変換し、その結果の文字列の SHA1 ハッシュ値を RC4 キーとして用いて、暗号化されています。
私たちは、このログ ファイルを復号するための短い Python スクリプトを作りました。このスクリプトを使用して、インシデントの対応者は感染についての追加情報を入手することができます。 このスクリプトの出力には、最初の感染時刻や FTP サーバの漏えい情報などが含まれています。
アップデータ
Qbot は、難読化されたスクリプト（拡張子は「.wpl」）を使用して自身をアップデートします。このスクリプトは、「http[:]//<maliciousdomain.com>/viewtopic.php」のような URI で示される多数のドメインでホストされる、暗号化された実行ファイルをダウンロードしようと試みます。スクリプトはサーバの応答を 16 進デコードし、最初の 20 バイトを RC4 キーとして用いて、残りのバイトを復号します。復号されたバッファには 20 バイトの SHA1 ハッシュが含まれており、その後に、アップデートされたバージョンの Qbot 実行可能ファイルが続いています。
情報の盗難
Qbot の主なターゲットは、銀行取引のクレデンシャルのような機密情報です。そのために、Qbot は保存された Cookie やクレデンシャルを盗んだり、Web ブラウザにコードを挿入してライブのブラウンジング セッションを操作したりします。Qbot により、悪意ある者が被害者のブラウジング セッションをピギーバックし、セキュリティとして二要素認証がシンプルなものに実装されている場合などに、それをバイパスすることが可能となります。
最近の Qbot では、盗難技術のひとつとして Webinject が使用されるようになっています。Webinject は Zeus や Spyeye などで共通して使用されています。Webinject を使用することで、悪意のあるJavaScript をブラウザ セッションに挿入し、被害者のアクティビティの記録やリダイレクトをすることが容易にできるようになります。Webinject は、ユーザからのインタラクションを一切介さずに自動で大規模な銀行トランザクションを行えるほど強力です。
Qbot には、自動送金などの高度な Webinject をパースするコードが含まれていますが、私たちが分析した 618 の Qbot のサンプルでは、被害者がオンライン バンキング ページからログアウトしようとした際に単にブラウザをリダイレクトするだけでした。盗まれた Cookie およびセッション トークンは、そのユーザがターゲットのサイトをログアウトできない場合は、さらに長い間アクティブのままになります。
サンプルの Qbot Webinject の設定は次のとおりです。
「set_url https://*.<BankDomain>.com/*logoff* GPR http://<MaliciousSite>/fakes/onlineserv_cm_logoff.html」
この Webinject の例では、対象となったブラウザがターゲットの銀行のログオフ ページへのナビゲートを試行すると、それが傍受されます。「GPR」フラグは GET や POST が傍受され、悪意のある URL へとリダイレクトされることを示しています。この R のフラグは Webinject をサポートする他のマルウェアではほとんど使用されていないようです。Webinject に関するマルウェア フォーラムの投稿は主に、悪意のあるコードの挿入や、クレデンシャルのような HTTPS パラメータを単に記録することに集中しています。
コマンド ＆ コントロール
FTP による漏えい
Qbot は、FTP を使用して、設定ファイルにハードコードされた一連のサーバへとデータを漏えいさせます。この漏えいファイルは圧縮され、実行ファイル内でリソースが暗号化されるのと同様に、ランダムに生成されたキーを使用して RC4 暗号化されています。これらのファイルの復号方法については意図的に割愛します。この方法を開示すると、Qbot によって盗まれた機密情報が誰にも取得できるようになってしまうためです。
漏えいファイルは、「article_covezh618946_1450458170.zip」のような名前で FTP サーバにアップロードされます。「article」はハード コード、「covezh618946」はランダム生成されたもので、1450458170 は Linux のエポックタイムの秒数です（この場合は 2015 年 12 月 18 日）。
復号された漏えいファイルには被害者のマシンに関する多数の情報が含まれています。その一部は、以下のような形式の文字列を使用した、wvnsprintf 関数への呼び出しで形成されています。
「ext_ip=[%s] dnsname=[%s] hostname=[%s] user=[%s] domain=[%s] is_admin=[%s] os=[%s] qbot_version=[%s] install_time= %s] exe=[%s]」
qbot_version と言う文字列は、wvnsprintf への直前の呼び出しによって生成されており、「%04x.%u」という文字列書式とパラメータを使っています。このパラメータは、データ セクション内の最初の 2 つの DWORD までトレース バックできます。これらの DWORD を直接抽出するのは容易であり、かつ、Qbot を実行せずにそのバージョン情報を抽出するのに一貫して使用できることが明らかになっています。
HTTP DGA
Qbot の DGA は、「2.mar.2016.00000001」のような文字列を生成します。00000001 は不変であり、最初の桁はその月の日付の 10 の桁を示します（ただし、30 日と 31 日の場合も 2 が使用されます）。つまり、各月に使用される DGA のシードは 3 つのみということになります。Qbot は、無害を装った HTTP 要求を Google に送信し、HTTP 301 応答を解析することでこの日付を取得します。
この日付の文字列は CRC32 でチェックサムが計算されており、メルセンヌ ツイスタ乱数生成器のシードとして使用され、Qbot が予測可能なドメインのリストを作成するのに用いられます。Qbot は一度に 5 つのドメインのリストを生成し、アクティブなドメインが見つかるまで、それらのドメインからランダムに選択を続けます。ドメインの最初のセットがいずれもアクティブではなかった場合、Qbot は新しいセットを生成し、必要に応じてこれを繰り返します。
Qbot は、「sinkhole」または「csof.net」という文字列が含まれた DNS の応答をすべてチェックし、これらの結果をスキップします。さらに、Wireshark のようなモニタリング ツールもチェックし、見つかった場合はシードを変更します。変更されたシードにより、マルウェアが偽のドメインリストを生成することが可能となります。
進化
私たちは Pykd を使用して 618 の Qbot サンプルの解凍を自動で行い、埋め込まれたリソースを復号し、解凍するための Python スクリプトを作成しました。さらに DLL と設定データを抽出し、加えて Qbot のバージョン情報と各ファイルのコンパイル時間も抽出しました。コンパイル時間は悪意のあるアクティビティの判別によく使用されます。ただし、コンパイル時間は操作できるということを念頭に置いておくことが重要です。
Qbot のコンパイル時間は、アクティビティが急増したのが 1 月から 2 月であることを示しています。当時、開発者はこの期間のうち少なくとも 4 日間は毎日複数のバージョンをリリースしています。Qbot の作成者たちは 2016 年 3 月 8 日に開発を止めたようですが、作成者たちのサーバでは、パックされた最新の日付が 2016 年 3 月 25 日となっている Qbot の実行ファイルが引き続きホストされていました。
このグラフでは、コンパイルのタイムスタンプが 132 個表示されており、各バイナリにコンパイルの時刻が示されています。解凍されたバイナリのコンパイル時間は、すべて GMT の午前 6 時から午後 8 時の間でした。このような時間の分散状況からは、これが片手間のプロジェクトではなく、フルタイムの仕事のように行われていたことが推測されます。パックされたバイナリのコンパイル時間にはもっと大きなばらついており、パッキング作業が作成者ではなく、もっとスケジュールが柔軟な人員によって行われたか、何らかの自動化ので補われて行われた可能性を示唆しています。ソース コードの開発にはパッキング ツールの実行よりも経験が必要とされるため、パッキング作業はチーム メンバーの中でも技術知識の少ない者が担当した可能性があります。
パックされたファイルのコンパイル時間は多くが GMT の午前 8 時から午後 10 時の間であり、解凍されたサンプルの平均的なコンパイル時間から 2 時間ほどずれていました。パッキングのプロセスが完全に自動化されていたとすると、コンパイル時間のばらつきは、もっとランダムになるか（一部のバイナリは深夜から午前 6 時の間にコンパイルされていました）、特定の時間に 1 日 1 回実行されるなど、予測しやすいスケジュールになると思われます。
パックされたバイナリの 55 % では、コンパイル時間は解凍されたバイナリのコンパイル時間の 2 時間 3 分または 2 時間 6 分後になっていました。このような一定のずれがあるということは、作業時間がちょうど 2 時間の、非常に一貫したプロセスでファイルが圧縮されていたか、圧縮作業をしたコンピュータのシステム クロックが 2 時間ずれていたということが考えられます。
このグラフでは、日曜との日数の差異という形式で曜日を表現しています（例：1 = 月曜日、2 = 火曜日とし、以下同様）。解凍されたバイナリのコンパイル時間は、作業期間の月曜日から金曜日の間に収まっています。この 17 週間で週末にコンパイルされたバイナリ セットは 1 つのみでした。
パックされたバイナリのコンパイル時間はここでもばらつきがかなり大きくなっており、土曜日に 6 つのバイナリがコンパイルされています。また、1 月 27 日から 2 月 6 日の間には、少なくとも 1 日に 1 つは圧縮されたバイナリがコンパイルされています。つまりこの期間は連続 11 日で作業が行われたことになります。
私たちはまた、Qbot のバイナリに関連付けられた Rich ヘッダーの分析もおこないました。Rich ヘッダーは、Visual Studio の実行ファイルの詳細が記されていないセクションであり、その実行ファイルの作成に使用されたコンパイラおよびリンカのバージョンに関する情報が含まれています。Rich ヘッダーは、似たように見える開発環境同士のものでも大幅に異なっている可能性があります。そのため、このヘッダーは、開発プロジェクトで使用されたコンピュータ数の推定に役立つ場合があります。
解凍された 154 個のバイナリにはわずか 6 つの Rich ヘッダーしか含まれていないうえ、一部はほぼ同一（同じコンピュータで、軽微なアップデートが実行されたことが差異の原因だと思われます）でした。これらのヘッダーから、解凍されたバイナリは、3 つの固有の環境（おそらく、異なるコンピュータか仮想マシン）でコンパイルされたと推察されます。パックされたバイナリには 44 個の一意の Rich ヘッダーが含まれており、そのうち 35 個では差異がごくわずかでした。パックされたバイナリは 9 つの固有の環境でコンパイルされたものと思われます。これらのいずれも、解凍されたバイナリの 3 つの Rich ヘッダーには一致しませんでした。
これらの Rich ヘッダーの差異は、パッキング作業が主要な Qbot ソース コードを開発したコンピュータとは別のコンピュータで行われた可能性をさらに強く裏付けるものです。この Rich ヘッダーのデータは、バイナリのコンパイルとパッキングには 12 個の固有の環境が使用された可能性を示しています。これは、Qbot の開発およびパッキング チームの大きさを推測するためのヒントになります。
マルウェアや悪意のあるインフラストラクチャを開発し、維持するには多くの時間と労力が必要です。Qbot のような大規模なクライムウェアの背後には、チームとして作業し、不正な作業をフルタイムの仕事としてこなしている多くの悪意ある者が存在するのです。
カバレッジ
最新のルールの詳細については、Firepower Management Center、FireSIGHT Management Center、または Snort.org を参照してください。
Advanced Malware Protection（AMP）は、これらの脅威の攻撃者によるマルウェア実行を阻止するのに最適です。
CWS や WSA の Web スキャンは、悪意のある Web サイトへのアクセスを阻止し、それらの攻撃に使用されたマルウェアを検出します。
IPS のネットワーク セキュリティ保護や NGFW には、脅威の攻撃者による悪意のあるネットワーク アクティビティを検出する最新のシグニチャが備わっています。
Tags:本稿は 2016年4月28日に Talos Group
