CARBANAK ウィーク パート 3: CARBANAK バックドアの裏側

CARBANAK Week ブログ シリーズのパート 1とパート 2で多くのことを取り上げました。ここで、以前の分析のいくつかを振り返り、それがどのように維持されているかを見てみましょう。

2017 年 6 月、私たちはブログ投稿を公開し、CARBANAK バックドアに関する斬新な情報を共有しました。これには、技術的な詳細、インテル分析、および数百の CARBANAK サンプルの自動分析の結果から形成された操作に関するいくつかの興味深い推論が含まれます。これらの控除の一部は、CARBANAK のツールセットとビルド プラクティスに関する主張でした。ソース コードとツールセットのスナップショットが得られたので、これらの推論を再検討し、それらに新たな光を当てるまたとない機会があります。

ビルドツールはありましたか?

まず、CARBANAK のビルド ツールに関する推論を見てみましょう。

「これらの攻撃者は、オペレーターが C2 アドレス、C2 暗号化キー、キャンペーン コードなどの詳細を構成できるビルド ツールを使用している可能性があります。このビルド ツールは、バイナリの文字列をビルドごとに新しいキーで暗号化します。」

私たちは、次の証拠からこの推論に至りました。

「CARBANAK の文字列のほとんどは、分析をより困難にするために暗号化されています。すべての暗号化された文字列のキーと暗号文は、同じコンパイル時間のサンプル間でも、遭遇したサンプルごとに変更されていることがわかりました。 HTTP プロトコルに使用される RC2 キーも、同じコンパイル時間のサンプル間で変化することが確認されています。設定が必要なキャンペーン コードの使用と組み合わせたこれらの観察結果は、ビルド ツールが存在する可能性が高いことを示しています。」

図 1 は、CARBANAK の文字列をデコードするために使用される 3 つのキーを示しています。それぞれが異なる CARBANAK サンプルから抽出されています。

私たちはこの控除にぴったりだったことがわかりました。 CARBANAK のソース ダンプでビルド ツールが発見されました (図 2 に英語の翻訳が示されています)。

このビルド ツールを使用して、一連の構成オプションをテンプレート CARBANAK バイナリと共に指定すると、構成データがバイナリに焼き付けられ、配布用の最終ビルドが生成されます。プレフィックス テキスト フィールドにより、オペレータはキャンペーン コードを指定できます。管理者ホスト テキスト フィールドは C2 アドレスを指定するためのもので、管理者パスワード テキスト フィールドは、CARBANAK の疑似 HTTP プロトコルを介した通信を暗号化するための RC2 キーを導出するために使用される秘密です。これで推論の一部がカバーされます。ビルド ツールが存在し、ビルド用のキャンペーン コードと RC2 キーなどを構成するために使用されるという事実がわかりました。しかし、エンコードされた文字列はどうでしょうか?これは舞台裏でシームレスに発生するものであるため、ビルド ツールの GUI でその証拠が見つからないことは理にかなっています。詳細を知るには、バックドアとビルド ツールの両方のソース コードにアクセスする必要がありました。

図 3 は、CARBANAK バックドア ソース コードで定義された ON_CODE_STRING という名前のプリプロセッサ識別子を示しています。これを有効にすると、プログラマがバイナリでエンコードしたいすべての文字列をラップするマクロが定義されます。これらの関数は、エンコードする文字列を文字列「BS」と「ES」で挟みます。図 4 は、BEG_ENCODE_STRING を「BS」として定義し、END_ENCODE_STRING を「ES」として定義する、ビルド ツール ソース コードのヘッダー ファイルからの小さなコード スニペットを示しています。ビルド ツールは、テンプレート バイナリでこれらの「BS」および「ES」マーカーを検索し、それらの間の文字列を抽出し、ランダムに生成されたキーでエンコードして、バイナリ内の文字列をエンコードされた文字列に置き換えます。たまたまビルド ツールで使用されるテンプレート バイナリの 1 つであった bot.dll という名前の実行可能ファイルを見つけました。このバイナリで文字列を実行すると、図 5 に示すように、CARBANAK バックドアの動作に固有の最も意味のある文字列は、実際には「BS」と「ES」の間に挟まれていることが明らかになりました。

ソースコードへのオペレーターのアクセス

私たちのブログ投稿から、さらに 2 つの関連する控除を見てみましょう。

「私たちが観察した情報に基づいて、CARBANAKのオペレーターの少なくとも一部は、ソースコードを変更する方法についての知識を持ってソースコードに直接アクセスできるか、開発者と密接な関係を持っていると考えています。」

「一部のオペレーターは、バックドアの独自のビルドを独自にコンパイルしている可能性があります。」

最初の推論は、次の証拠に基づいていました。

「ビルド ツールの可能性にもかかわらず、サンプル セットで 57 の固有のコンパイル時間が見つかりました。コンパイル時間のいくつかは非常に近いものでした。たとえば、2014 年 5 月 20 日、2 つのビルドが約 4 時間間隔でコンパイルされ、同じ C2 サーバーを使用するように構成されました。繰り返しますが、2015 年 7 月 30 日に、2 つのビルドが約 12 時間間隔でコンパイルされました。」

さらに調査するために、コンパイル時間が非常に近い 2 つの CARBANAK サンプルの diff を実行して、コードで何が変更されたかを確認しました。図 6 は、そのような違いの 1 つを示しています。

POSLogMonitorThread 関数はサンプル Aでのみ実行され、blizkoThread 関数はサンプル Bでのみ実行されます ( Blizkoは PayPal に似たロシアの送金サービスです)。 POSLogMonitorThread 関数は、特定の POS ソフトウェアのログ ファイルに加えられた変更を監視し、解析されたデータを C2 サーバーに送信します。 blizkoThread 関数は、レジストリ内の特定の値を検索することによって、コンピューターのユーザーがBlizkoの顧客であるかどうかを判断します。これらのわずかな違いを知って、ソース コードを検索したところ、プリプロセッサ パラメーターが使用されていることが再びわかりました。図 7 は、3 つのコンパイル時パラメーターのどれが有効になっているかによって、この関数がどのように変化するかを示しています。

これは、オペレーターがソース コードにアクセスできたという決定的な証拠ではありませんが、確実にその可能性が高くなります。オペレーターは、Visual Studio でプリプロセッサ パラメーターを追加および削除する方法に関する簡単なガイダンスだけで、特定のターゲットのニーズを満たすようにビルドを微調整するためにプログラミングの知識を必要としません。

2 番目の推論の証拠は、バイナリ C2 プロトコルの実装と、それが時間の経過とともにどのように進化してきたかを調べることで見つかりました。以前のブログ投稿から:

「このプロトコルは何年にもわたっていくつかの変更を受けており、各バージョンは何らかの形で以前のバージョンに基づいています。これらの変更は、既存のネットワーク シグネチャを無効にし、シグネチャの作成をより困難にするために導入された可能性があります。」

図 8 に示すように、バイナリ C2 プロトコルの 5 つのバージョンがサンプル セット内で発見されました。この図は、サンプル セット内で各プロトコル バージョンが見つかった最初のコンパイル時間を示しています。新しいバージョンごとに、プロトコルのセキュリティと複雑さが改善されました。

CARBANAK プロジェクトが中央に配置され、テンプレート バイナリのみがオペレーターに配信された場合、サンプルのコンパイル時間は、バイナリ プロトコルの進化に合わせて短縮されることが期待されます。プロトコルの「バージョン 3」と呼ばれるものを実装する 1 つのサンプルを除いて、タイムラインは次のようになります。バージョン 3 の日付が一致しない理由として考えられるのは、サンプル セットがこのバージョンの最初のサンプルを含めるのに十分な幅がなかったということです。これは、古いプロトコルがサンプルに実装されていることを発見した唯一のケースではありません。図 9 は、この別の例を示しています。

この例では、実際に発見された CARBANAK サンプルはプロトコル バージョン 4 を使用していましたが、新しいバージョンが少なくとも 2 か月間利用可能になっていました。ソース コードが 1 つの中央の場所に保管されていれば、このようなことは起こりそうにありません。プリプロセッサ パラメータを使用したテンプレート バイナリの迅速な微調整と、古いバージョンのプロトコルを実装している野生の CARBANAK のいくつかのサンプルとの組み合わせは、CARBANAK プロジェクトがオペレータに配布され、中央に保持されていないことを示しています。

以前に特定されていないコマンドの名前

ソースコードから、以前は名前が特定されていなかったコマンドの名前が明らかになりました。実際、機能が無効になっているため、以前にブログで紹介したサンプルにはまったく含まれていなかったコマンドも明らかになりました。表 1 は、CARBANAK ソース コードで名前が新たに発見されたコマンドと、ブログ投稿からの分析の概要を示しています。

表 1: 以前は名前で識別されていなかったコマンド ハッシュと、以前の FireEye 分析からの説明

msgbox コマンドは、CARBANAK ソース コードで完全にコメント アウトされており、厳密にはデバッグ用であるため、公開された分析には登場しませんでした。同様に、ifobs コマンドは、私たちが分析して公開したサンプルには表示されませんでしたが、別の理由である可能性があります。図 10 のソース コードは、CARBANAK が理解できるコマンドの表を示しています。ifobs コマンド (0x6FD593) は #ifdef で囲まれており、ON_IFOBS プリプロセッサ パラメータが有効になっていない限り、ifobs コードがバックドアにコンパイルされるのを防いでいます。

ただし、より興味深いコマンドの 1 つは tinymet です。これは、ソース コードがどのように役立ち、誤解を招く可能性があるかを示しているためです。

tinymet コマンドと関連するペイロード

最初の CARBANAK 分析の時点で、コマンド 0xB0603B4 (その時点では名前は不明) がシェルコードを実行できることを示しました。ソース コードは、コマンド (実際の名前は tinymet) が非常に特殊なシェルコードを実行することを意図していたことを示しています。図 12 は、tinymet コマンドを処理するためのコードの簡略化されたリストを示しています。コードをよりコンパクトな形式で表示するために、行番号を黄色で示し、選択した行を非表示 (灰色) で示しています。

1672 行目から始まるコメントは、次のことを示しています。

1710 行目で、tinymet コマンド ハンドラーは、1 バイトの XOR キー 0x50 を使用してシェルコードをデコードします。注目すべきは、1734 行目でコマンド ハンドラが 5 バイトを余分に割り当て、1739 行目で 5 バイトの mov 命令をそのスペースにハードコードすることです。 mov 命令の 32 ビットの即値オペランドに、シェルコードを取得したサーバー接続のソケット ハンドル番号を入力します。この mov 命令の暗黙のデスティネーション オペランドは、edi レジスタです。

tinymet コマンドの分析は、met.plug という名前のバイナリ ファイルが発見されるまで、ここで終了しました。図 12 の 16 進ダンプは、このファイルの終わりを示しています。

ファイルの末尾は、タスク ソース コード内の動的にアセンブルされた mov edi プリアンブルに対応する 5 つの欠落バイトによってずれています。ただし、ソース コードで見つかった 1 バイトの XOR キー 0x50 は、このファイルのデコードに成功しませんでした。混乱とさらなる分析の後、このファイルの最初の 27 バイトは、 call4_dword_xorに非常によく似たシェルコード デコーダーであることが判明しました。図 13 は、シェルコード デコーダーと、エンコードされた metsrv.dll の先頭を示しています。シェルコードが使用する XOR キーは 0xEF47A2D0 です。これは、5 バイトの mov edi 命令、デコーダ、および隣接する metsrv.dll がメモリ内に配置される方法に適合します。

デコードすると、オフセット 0x1b から始まる metsrv.dll のコピーが生成されました。シェルコードの実行によってデコーダー ループが終了すると、Metasploit の実行可能な DOS ヘッダーが実行されます。

皮肉なことに、ソース コードを所有しているとバイナリ分析が間違った方向に偏り、実際には 4 バイトの XOR キーを使用する 27 バイトのデコーダ プリアンブルが存在するのに、1 バイトの XOR キーが提案されました。さらに、tinymet というコマンドの名前は、 TinyMet Meterpreter ステージャーが関与していることを示唆しています。一時はそうであったかもしれませんが、ソース コードのコメントとバイナリ ファイルは、開発者と運用者がコマンドの名前を変更せずに直接 Meterpreter をダウンロードする方法に移行したことを示唆しています。

結論

CARBANAK のソース コードとツールセットにアクセスできることで、以前の分析を再検討するまたとない機会が得られました。不足している分析と文脈を埋め、いくつかのケースでは推論を検証し、別のケースではさらなる証拠を提供して、それらに対する信頼を強化しましたが、それらが真実であることを完全に証明することはできませんでした.この演習は、ソース コードにアクセスしなくても、十分な量のサンプル セットと十分な分析があれば、ソース コードを超えた正確な推論に到達できることを証明しています。また、tinymet コマンドの場合のように、適切なコンテキストがないと、特定のコード片の完全かつ明確な目的を理解できない場合があることも示しています。ただし、一部のソース コードは、付随するバイナリと矛盾しています。ブルース リーがマルウェア アナリストだったら、ソース コードは月を指す指のようなものだと言ったかもしれません。指に集中しないでください。バイナリのグラウンド トゥルースをすべて見逃してしまいます。ソース コードは非常に豊富なコンテキストを提供できますが、アナリストはそのコンテキストをバイナリまたはフォレンジック アーティファクトに誤って適用しないように注意する必要があります。

次の最後のブログ投稿では、CARBANAK キットの一部である興味深いツールの詳細を紹介します。これは、バックドアによってキャプチャされたデスクトップ録画を再生するように設計されたビデオ プレーヤーです。