CARBANAK 第 1 週: まれな出来事

carbanak-week-banner news

carbanak-week-banner

大量に使用され、個人的に開発されたバックドアを FLARE が分析した後、ソース コードとオペレータ ツールが私たちの手に渡ることは非常にまれです。しかし、これは、この投稿から始まる 4 部構成のブログ シリーズである CARBANAK ウィークの舞台を設定する異常な状況です。

CARBANAK は、最も多機能なバックドアの 1 つです。これは、主にFIN7として追跡しているグループによって、何百万ドルもの金融犯罪を実行するために使用されました。 2017 年、Tom Bennett と Barry Vengerik は、数年にわたる CARBANAK サンプルと FIN7 アクティビティの詳細かつ広範な分析の成果であるBehind the CARBANAK Backdoorを公開しました。その出版物に続いて、同僚の Nick Carr が、CARBANAK ソース コード、ビルダー、およびその他のツールを含む 2 つの RAR アーカイブを発見しました (どちらも VirusTotal で入手可能です: kb3r1pおよびapwmie )。

FLARE マルウェア分析リクエストは通常、多くても数十ファイルに制限されています。しかし、CARBANAK のソース コードは 20 MB で、755 ファイル、39 のバイナリと 100,000 行のコードで構成されていました。私たちの目標は、以前の分析で見逃していた脅威インテリジェンスを見つけることでした。アナリストは、このような広範で制限のない範囲の要求にどのように対応するのでしょうか?そして、私たちは何を見つけましたか?

友人の Tom Bennett と私は、2018 年の FireEye Cyber Defense Summit の講演で、このことについて簡単に話しました。Hello, Carbanak!このブログ シリーズでは、バイナリ コードのリバース エンジニアリングに基づく以前の公開分析で引き出された推論について詳しく説明し、書面による振り返りを共有します。この第 1 部では、ロシア語の問題、翻訳された CARBANAK ツールのグラフィカル ユーザー インターフェイス、およびソース コードの観点から見た分析防止戦術について説明します。また、ソース コードの分析が驚くべきことに、バイナリの分析と同じかそれ以上に困難であることが判明した興味深いひねりについても説明します。ここにはたくさんあります。シートベルトを締める!

ファイルのエンコードと言語に関する考慮事項

この分析の目的は、脅威インテリジェンスのギャップを発見し、お客様をより適切に保護することでした。最初に、ソース コード ファイルと特定の関心のある概念の相互参照を組み立てたいと思いました。

ソース コードを読むには 2 つの手順が必要でした。ファイルを正しいエンコーディングで表示することと、危険なロシア語を十分に学習することです。図 1 は、正しいエンコーディングを認識しないテキスト エディター内の CARBANAK ソース コードを示しています。

適切にデコードされていないファイル
図 1: 適切にデコードされていないファイル

2 つの適切なファイル エンコーディングの推測は、UTF-8 とコード ページ 1251 (キリル文字) です。図 2 に示すように、ファイルの大部分はコード ページ 1251 でした。

コード ページ 1251 (キリル文字) のソース コード
図 2: コード ページ 1251 (キリル文字) のソース コード

図 2 は、バックドア コマンドの実行に関連するエラー値を定義する C++ ヘッダー ファイルです。ほとんどの識別子は英語でしたが、一部は特に説明的ではありませんでした。したがって、より困難な 2 番目のステップは、ソース コードのコメントによって提供されるコンテキストから利益を得るためにロシア語を学ぶことでした。

FLARE には流暢なロシア語を話す人がいますが、他の分析担当者の時間を最小限に抑えるために自分自身で取り組みました。この目的のために、私はスクリプトを作成して、ファイルを分割し、優先語彙リストを作成しました。 Mandiant vocab_scraper GitHub リポジトリで入手できるこのスクリプトは、ソース ディレクトリをたどって、印刷可能な下位 ASCII 範囲外のすべての文字シーケンスを見つけます。このスクリプトは、各単語を Python のdefaultdict_に追加し、そのカウントをインクリメントします。最後に、スクリプトはこの辞書を出現頻度順に並べ替え、ファイルにダンプします。

その結果、図 3 に部分的に示されている 3,400 以上の単語の語彙リストが作成されました。

CARBANAK ソース コードの上位 19 のキリル文字シーケンス
図 3: CARBANAK ソース コードの上位 19 のキリル文字シーケンス

キリル文字とロシア語の単語の発音を勉強するために、ロシア語学習ウェブサイトに数時間費やしました。次に、上位 600 以上の単語を調べて、小さな辞書を作成しました。ロシア語入力を分析 VM に追加し、Microsoft のオンスクリーン キーボード ( osk.exe ) を使用して、キリル文字のキーボード レイアウトをナビゲートし、定義を検索しました。

キリル文字の発音を学ぶことの効果の 1 つは、英語の借用語 (英語から借用され、キリル文字に音訳された単語) を新たに認識したことです。私の少ない語彙のおかげで、何も調べなくても多くのコメントを読むことができました。表 1 は、私が遭遇したいくつかの英語の借用語の短いサンプルを示しています。

キリル

英語の音声

英語

発生

ランク

ファイル

f ah y L

ファイル

224

5

サーバ

サーバ

サーバ

145

13

住所

住所

住所

52

134

コマンド

指図

指図

110+

27

ボット

ボタ

ボット

130

32

プラグイン

pl ah g ee n

プラグイン

116

39

サービス

サービス

サービス

70

46

処理する

利益

処理する

130っぽい

63

表 1: CARBANAK ソース コード内の英語の外来語のサンプリング

ソース コードのコメントは別として、キリル文字の読み方と入力方法を理解することは、ソース コード ダンプで見つけた CARBANAK グラフィカル ユーザー インターフェイスを翻訳するのに役立ちました。図 4 は、私が翻訳した CARBANAK のコマンド アンド コントロール (C2) ユーザー インターフェイスを示しています。

翻訳された C2 グラフィカル ユーザー インターフェイス
図 4: 翻訳された C2 グラフィカル ユーザー インターフェイス

これらのユーザー インターフェイスには、それぞれ図 5 と図 6 に示すように、ビデオ管理と再生アプリケーションが含まれていました。 Tom は、このブログ シリーズの後続の部分で、これらを使って行った興味深い作業を共有します。

翻訳されたビデオ管理アプリケーションのユーザー インターフェイス
図 5: 翻訳されたビデオ管理アプリケーションのユーザー インターフェイス
翻訳されたビデオ再生アプリケーションのユーザー インターフェイス
図 6: 翻訳されたビデオ再生アプリケーションのユーザー インターフェイス

図 7 は、オペレータ ツールの RAR アーカイブに含まれていたバックドア ビルダーを示しています。

翻訳されたバックドア ビルダー アプリケーションのユーザー インターフェイス
図 7: 翻訳されたバックドア ビルダー アプリケーションのユーザー インターフェイス

オペレータの RAR アーカイブには、すべてのバックドア コマンドのセマンティクスを説明するオペレータ マニュアルも含まれていました。図 8 に、このマニュアルの最初のいくつかのコマンドをロシア語と英語 (翻訳済み) で示します。

取扱説明書 (左: ロシア語原本、右: 英語に翻訳)
図 8: 取扱説明書 (左: オリジナルのロシア語、右: 英語に翻訳)

うさぎの穴を下る: ソースコードが役に立たない場合

単純なバックドアでは、単一の関数が C2 サーバーから受信したコマンド ID を評価し、正しい関数に制御をディスパッチしてコマンドを実行します。たとえば、バックドアが C2 サーバーにコマンドを要求し、コマンド ID 0x67を持つ応答を受信する可能性があります。バックドアのディスパッチ機能は、コマンド ID を0x67を含むいくつかの異なる値と照合します。たとえば、C2 サーバーにリバース シェルをシャベルする関数を呼び出す可能性があります。図 9 は、IDA Pro で表示されたこのような関数の制御フロー グラフを示しています。コードの各ブロックは、コマンド ID に対してチェックし、制御を適切なコマンド処理コードに渡すか、次のコマンド ID のチェックに進みます。

単純なコマンド処理関数の制御フロー グラフ
図 9: シンプルなコマンド処理関数の制御フロー グラフ

この点で、CARBANAK はまったく別物です。バックドアの制御下にあるすべてのスレッド、プロセス、およびプラグイン間の通信および調整の手段として、名前付きパイプと呼ばれる Windows メカニズムを利用します。 CARBANAK タスク コンポーネントがコマンドを受信すると、名前付きパイプを介してコマンドを転送し、そこでメッセージを処理するいくつかの異なる関数を通過し、場合によっては 1 つ以上の追加の名前付きパイプにメッセージを書き込み、指定されたコマンドが送信された宛先に到着するまで待ちます。最終的に処理されます。コマンド ハンドラーは、独自の名前付きパイプを指定して、C2 サーバーから追加のデータを要求することさえできます。 C2 サーバーがデータを返すと、CARBANAK は結果をこの補助的な名前付きパイプに書き込み、コールバック関数がトリガーされて応答データを非同期的に処理します。 CARBANAK の名前付きパイプ ベースのタスク コンポーネントは、固有のコマンド ハンドラーとプラグインの両方を制御できるほど柔軟です。また、ネットワークを使用せずに、ローカル クライアントがコマンドを CARBANAK にディスパッチできるようにします。実際、分析とテストを支援するためにそのようなクライアントを作成しただけでなく、 botcmd.exeという名前のそのようなクライアントもソース ダンプに存在していました。

トムの視点

バイナリの観点から、CARBANAK 内のこのコマンド処理メカニズムを分析することは、確かに困難でした。逆アセンブリへのさまざまなビューのタブを維持する必要があり、コマンド ID と名前付きパイプ名の一種のテキスト マップを使用して、着信コマンドが目的地に到着する前にさまざまなパイプと関数を通過する過程を説明する必要がありました。図 10 は、7 つの名前付きパイプ メッセージ処理関数の制御フロー グラフを示しています。バイナリ リバース エンジニアリングの観点からこれを分析することは困難でしたが、IDA Pro などの優れた逆アセンブラーが提供する機能と組み合わされたコードをコンパイルしたことで、Mike の経験ほど悲惨なものではなくなりました。バイナリ パースペクティブのおかげで、複数のソース ファイルを検索してあいまいな関数名を処理する必要がなくなりました。逆アセンブラー機能により、関数とグローバル変数の相互参照を簡単にたどり、コードに関連する複数のビューを開くことができました。

名前付きパイプ メッセージ処理関数の制御フロー グラフ
図 10: 名前付きパイプ メッセージ処理関数の制御フロー グラフ

マイクの視点

ソース コードがあるということは、マルウェア分析のチート モードのように聞こえます。実際、ソース コードには、コンパイルとリンクのプロセスで失われる多くの情報が含まれています。それでも、CARBANAK のタスキング コンポーネント (C2 サーバーから送信されたコマンドを処理するため) は反例として機能します。使用される C2 プロトコルと処理されるコマンドに応じて、制御フローは異なる機能を通る分岐パスをたどり、後で再び収束して同じコマンドを実行する場合があります。分析には、5 つのファイルに含まれるほぼ 20 の関数の間を行き来する必要があり、多くの場合、18 ものレイヤーから渡された関数ポインターとパラメーターに関する情報を復元するためにバックトラックが必要でした。分析には、C++ クラスの継承、スコープのあいまいさ、オーバーロードされた関数、および名前付きパイプの使用時の制御フローの終了の問題の解決も伴いました。全体的な影響として、これはソース コードであっても分析が困難でした。

驚きを探すために、私はこの上から下への旅に一度だけ乗り出しました。この取り組みにより、著者が難読化または柔軟性のために構築したバロック様式の機械に感謝することができました。これは、関係をあいまいにし、タイムリーな分析を妨げるために、少なくとも部分的に行われたように感じました.

ソース コードの分析防止メカニズム

CARBANAK の実行可能コードには、同じ関数に 16 進数をプッシュし、その後に戻り値に対する間接呼び出しを行うロジックが埋め込まれています。これは、難読化された関数のインポート解決として簡単に認識できます。CARBANAK は、PJW (作成者である PJ Weinberger にちなんで名付けられました) と呼ばれる単純な文字列ハッシュを使用して、名前を公開せずに Windows API 関数を見つけます。 PJW ハッシュの Python 実装を参照用に図 11 に示します。

def pjw_hash:
中央値 = 0
for i in range(len(s)):
ctr = 0xffffffff & ((ctr << 4) + ord(s[i]))
ctr & 0xf0000000 の場合:
ctr = (((ctr & 0xf0000000) >> 24) ^ ctr) & 0x0ffffffff

返品率

図 11: PJW ハッシュ

これは、CARBANAK のサンプルで数百回使用されており、マルウェアの機能の理解を妨げています。幸いなことに、図 12 に示すように、リバーサーは、 flare-ida スクリプトを使用して、難読化されたインポートに注釈を付けることができます。

FLARE のシェルコード ハッシュ検索で注釈が付けられた難読化されたインポート解決
図 12: FLARE のシェルコード ハッシュ検索で注釈が付けられた、難読化されたインポートの解決

CARBANAK の作成者は、C プリプロセッサ マクロとコンパイル前のソース コード スキャン手順を使用して関数ハッシュを計算することで、バックドア全体でこの難読化されたインポートの解決を比較的簡単に実現しました。図 13 は、関連するAPIマクロと関連する機構の定義を示しています。

インポート解決の API マクロ
図 13: インポート解決の API マクロ

APIマクロを使用すると、作成者はAPI(SHLWAPI, PathFindFileNameA)(…)と入力し、それをGetApiAddrFunc(SHLWAPI, hashPathFindFileNameA)(…)に置き換えることができます。 SHLWAPIは、定数 3 として定義されたシンボリック マクロであり、 hashPathFindFileNameAは、逆アセンブリで観察される文字列ハッシュ値0xE3685D1です。しかし、ハッシュはどのように定義されたのでしょうか?

CARBANAK ソース コードには、 APIマクロの呼び出しについてソース コードをスキャンして、コードベース全体で検出されるすべての Windows API 関数名の文字列ハッシュを定義するヘッダー ファイルを作成するユーティリティ (想像を絶する名前のtool ) があります。図 14 は、このユーティリティのソース コードとその出力ファイルapi_funcs_hash.hを示しています。

文字列ハッシュ ユーティリティのソース コードと出力
図 14: ソース コードと文字列ハッシュ ユーティリティの出力

難読化されたマルウェアをリバース エンジニアリングするとき、作成者が難読化をどのように実装するかについて理論化を試みずにはいられません。 CARBANAK のソース コードは、マルウェア作成者が強力な C プリプロセッサとカスタム コード スキャンおよびコード生成ツールを使用して、開発者に過度の負担をかけることなく難読化する方法を示す別のデータ ポイントを提供します。これは、マルウェア作成者が将来何を期待するかという観点から将来の見通しを提供する可能性があり、将来のプロジェクトで潜在的なコードの再利用の単位を特定し、それらの重要性を評価するのに役立つ可能性があります。これを新しいプロジェクトに適用するのは簡単ですが、ソース コードが VirusTotal にあるため、このレベルのコード共有は共有された作成者を表していない可能性があります。また、ソース コードは、マルウェアが関数を解決するために整数とハッシュをプッシュする理由をわかりやすく説明しています。整数は、事前に開かれ、これらの事前定義された整数に関連付けられているモジュール ハンドルの配列へのインデックスであるためです。

結論

CARBANAK のソース コードは、これらのマルウェアの作成者が難読化に関する実際的な問題にどのように対処したかを示しています。タスク コードと Windows API 解決システムの両方が、マルウェア アナリストをこのバックドアの匂いから解放するための多大な投資を表しています。 このシリーズのパート 2 をチェックして、ウイルス対策の回避、エクスプロイト、シークレット、キー マテリアル、作成者のアーティファクト、およびネットワーク ベースのインジケーターのまとめを確認してください。 パート3パート4も利用可能です!

参照: https://www.mandiant.com/resources/blog/carbanak-week-part-one-a-rare-occurrence

Comments

Copied title and URL