Chasing Eddies: CAPTCHA キャンペーンで使用される新しい Rust ベースの InfoStealer

前文

Elastic Security Labsは、Fake CAPTCHAキャンペーンを通じて配布される新しいRustベースのインフォスティーラーを発見しました。このマルウェアは、敵対者が制御する複数のWebプロパティでホストされています。このキャンペーンは、ユーザーを騙して悪意のあるPowerShellスクリプトを実行させ、最終的にインフォスティーラーを展開し、資格情報、ブラウザ情報、暗号通貨ウォレットの詳細などの機密データを収集させる、欺瞞的なCAPTCHA検証ページを利用しています。このマルウェアをEDDIESTEALERと呼んでいます。

このようにマルウェア開発にRustが採用されるようになったのは、従来の分析ワークフローや脅威検出エンジンに対して、ステルス性、安定性、レジリエンスを強化するために最新の言語機能を活用しようとする脅威アクターの間で増加している傾向を反映しています。Rustで書かれた一見単純なインフォスティーラーは、ゼロコストの抽象化、Rustの型システム、コンパイラの最適化、メモリセーフなバイナリの分析における固有の困難さなどの要因により、C/C++の対応物と比較して、より専門的な分析作業を必要とすることがよくあります。

重要なポイント

• 偽のCAPTCHAキャンペーンはEDDIESTEALERをロードします
• EDDIESTEALER は、Windows ホストを対象とする新たに発見された Rust インフォスティーラーです
• EDDIESTEALERは、ターゲットとするデータを特定するタスクリストをC2サーバーから受け取ります

初期アクセス

概要

偽のCAPTCHAは、正規のCAPTCHAシステムの外観と機能を再現する悪意のある構築物であり、人間のユーザーと自動化されたボットを区別するために使用されます。正規のCAPTCHAとは異なり、偽のCAPTCHAはマルウェアのゲートウェイとして機能し、ソーシャルエンジニアリングを利用してユーザーを欺きます。多くの場合、「人間であることを確認してください」や「私はロボットではありません」などのプロンプトとして表示され、侵害されたWebサイトやフィッシングキャンペーンにシームレスに溶け込みます。また、2024年後半には 、同様のキャンペーンでGHOSTPULSE を配布するキャンペーンにも遭遇しています。

EDDIESSTELERの提供に至るまでのテレメトリ分析から、最初のベクトルは、偽の「私はロボットではありません」という検証画面を表示する難読化されたReactベースのJavaScriptペイロードを展開する侵害されたWebサイトでした。

GoogleのreCAPTCHA検証インターフェースを模倣して、マルウェアは document.execCommand("copy") 方法を使用してPowerShellコマンドをユーザーのクリップボードにコピーし、次に、Windows + R(Windowsの実行ダイアログボックスを開くため)、次にCtrl + Vを押してクリップボードの内容を貼り付けるようにユーザーに指示します。

このコマンドは、攻撃者が制御するドメイン hxxps://llll.fit/version/ から第 2 段階のペイロード (gverify.js) をサイレントにダウンロードし、ユーザーのDownloads フォルダーに保存します。

最後に、マルウェアは隠しウィンドウでcscriptを使用してgverify.jsを実行します。

gverify.js は、オープンソースの ツールを使用して難読化を解除できる別の難読化されたJavaScriptペイロードです。その機能は非常に単純です: hxxps://llll.fit/io から実行可能ファイル(EDDIESTEALER)を取得し、ユーザーの Downloads フォルダの下に疑似ランダムな12文字のファイル名でファイルを保存します。

渦を奪う

概要

EDDIESTEALERは、斬新なRustベースのコモディティインフォスティーラーです。その悪意のある意図を示す文字列の大部分は暗号化されています。このマルウェアには、ビヘイビアフィンガープリントに対する堅牢なアンチサンドボックス/VM保護がありません。ただし、新しい亜種では、アンチサンドボックス/VMチェックがサーバー側で発生している可能性があることが示唆されています。比較的簡単な機能で、特定のデータをターゲットにする構成の一部としてC2サーバーからタスクリストを受け取り、指定されている場合は実行後に自己削除できます。

ストリップされたシンボル

EDDIESTEALER サンプルには、Rust のデフォルトのコンパイル オプションを使用している可能性が高い、削除された関数シンボルが含まれていました。これは、静的解析の前にシンボルを復元する必要がありました。私たちは、特定のRust/コンパイラ/依存関係のバージョンに基づいてRust標準ライブラリとクレートの署名を生成する rustbinsignを使用しました。rustbinsign検出したのはhashbrownとrustc-demangleだけで、外部クレートはほとんど使用されていなかったことを示唆していますが、新しい変異株ではtinyjsonやtungsteniteなどのクレートを特定することができませんでした。これは、明確なストリング アーティファクトがないために発生しました。一意の文字列を見つけてGitHubでリポジトリを検索することで、クレートを手動で識別し、 download_sign モードを使用してそれらの署名をダウンロード、コンパイル、ビルドすることは可能です。使用されているクレートの正確なバージョンがわからない場合は、少し面倒です。ただし、標準ライブラリとランタイム シンボルを復元するだけで、静的解析プロセスを進めることができます。

文字列の難読化

EDDIESTEALER は、ほとんどの文字列を単純な XOR 暗号で暗号化します。復号化には2つの段階があります:まず、XORキーは、いくつかのキー派生関数の1つを呼び出すことによって導出されます。次に、暗号化解除は、文字列を使用する関数内でインラインで実行されます。

次の例はこれを示しています。ここで、 sub_140020fd0 はキー派生関数、 data_14005ada8 は暗号化された BLOB のアドレスです。

各復号化ルーチンは、独自の個別のキー導出関数を利用します。これらの関数は、バイナリ内のアドレスと 4 バイトの定数値の 2 つの引数を一貫して受け取ります。次に、これらの引数に対していくつかの基本的な操作が実行され、XOR キーが存在するアドレスが計算されます。

Binary Ninja には User-Informed Data Flow (UIDF) と呼ばれる便利な機能があり、これを使用して変数を既知の値に設定し、定数伝搬分析をトリガーし、式を簡略化できます。それ以外の場合は、 Unicorn のようなCPUエミュレータとスクリプト可能なバイナリ解析ツールを組み合わせると、バッチ解析にも役立ちます。

共有リソースのスレッドセーフで遅延初期化の一般的なパターンがあり、モジュール名の暗号化文字列、C2ドメインとポート、サンプルの一意の識別子など、一度だけ復号化され、実行時に何度も参照されます。各特定の getter 関数は、そのリソースのステータス フラグをチェックします。初期化されていない場合は、共有の低レベル同期関数を呼び出します。この同期ルーチンは、アトミック操作と OS 待機プリミティブ (WaitOnAddress/WakeByAddressAll) を使用して、 dyn Trait オブジェクトの vtable 内の関数ポインターを介して間接的に呼び出される実際の初期化ロジックを 1 つのスレッドのみが実行するようにします。

APIの難読化

EDDIESTEALER は、ほとんどの API 呼び出しでカスタム WinAPI ルックアップ メカニズムを利用します。まず、ターゲット モジュールと関数の名前を復号化します。解決を試みる前に、ローカルに保持されているハッシュテーブルをチェックして、関数の名前とアドレスが既に解決されているかどうかを確認します。見つからない場合は、カスタム LoadLibrary ラッパーを使用して必要なモジュールをプロセスのアドレス空間に動的に読み込み、 GetProcAddressの既知の実装 を呼び出して、エクスポートされた関数のアドレスを取得します。その後、API の名前とアドレスがハッシュテーブルに挿入され、今後の検索が最適化されます。

ミューテックスの作成

EDDIESTEALER は、まずミューテックスを作成して、マルウェアのインスタンスが一度に 1 つだけ実行されるようにします。ミューテックス名は、復号化されたUUID文字列 431e2e0e-c87b-45ac-9fdb-26b7e24f0d39 (サンプルごとに一意)であり、後でC2サーバーとの最初の接続時に再度参照されます。

サンドボックス検出

EDDIESTEALER は、物理メモリの合計量が ~4.0 を超えているかどうかを評価するためのクイック チェックを実行しますGBは弱いサンドボックス検出メカニズムとして使用されています。チェックに失敗すると、ディスクから自身が削除されます。

自己削除

LATRODECTUS で観察された同様の 自己削除技術 に基づいて、EDDIESTEALERはNTFS代替データストリームの名前変更を通じて自分自身を削除し、ファイルロックをバイパスすることができます。

マルウェアは、 GetModuleFileName を使用して実行可能ファイルのフルパスを取得し、 CreateFileW ( jy::ds::OpenHandleでラップ)して、適切なアクセス権で実行可能ファイルへのハンドルを開きます。次に、新しいストリーム名を持つ FILE_RENAME_INFO 構造体が SetFileInformationByHandle に渡され、デフォルトのストリーム $DATA の名前が :metadataに変更されます。ファイル ハンドルを閉じて再度開きます。今回は、FILE_DISPOSITION_INFO.DeleteFile フラグを TRUE に設定したハンドルの SetFileInformationByHandle を使用して、"ハンドルを閉じると削除" フラグを有効にします。

追加の構成要求

初期設定データは、バイナリ内に暗号化された文字列として格納されます。復号化されると、このデータは URI パターン ( <C2_ip_or_domain>/<resource_path>/<UUID>) に従って要求を作成するために使用されます。resource_pathは api/handlerとして指定されます。ミューテックスを作成するために以前に使用した UUIDは、ビルド追跡の一意の識別子として使用されます。

その後、EDDIESTEALERは、構築されたURIを使用してHTTP GETリクエストを送信することでC2サーバーと通信し、マルウェアが実行するタスクのリストを含む第2段階の構成を取得します。

第 2 段階の構成データは、AES、CBC、暗号化、Base64 エンコードされます。Base64 でエンコードされた IV は、メッセージの先頭にコロン (:) が付加されます。

Base64(IV):Base64(AESEncrypt(data))

サーバーからクライアントへのメッセージを復号化するための AES キーは、暗号化されずに UTF-8 エンコードで .rdata セクションに格納されます。これは、ゲッター関数を通じて取得されます。

このサンプルの復号化された設定には、JSON 形式で次のものが含まれています。

• セッション ID
• タスクのリスト(ターゲットとするデータ)
• クライアントからサーバーへのメッセージ暗号化のためのAESキー
• 自己削除フラグ

{
    "session": "<unique_session_id>",
    "tasks": [
        {
            "id": "<unique_task_id>",
            "prepare": [],
            "pattern": {
                "path": "<file_system_path>",
                "recursive": <true/false>,
                "filters": [
                    {
                        "path_filter": <null/string>,
                        "name": "<file_or_directory_name_pattern>",
                        "entry_type": "<FILE/DIR>"
                    },
                    ...
                ]
            },
            "additional": [
                {
                    "command": "<optional_command>",
                    "payload": {
                        "<command_specific_config>": <value>
                    }
                },
                ...
            ]
        },
        ...
    ],
    "network": {
        "encryption_key": "<AES_encryption_key>"
    },
    "self_delete": <true/false>
}

この特定のサンプルについて、分析中にサーバーから受信したタスクに基づいて、ファイルシステムベースの流出ターゲットのリストを以下に示します。

• 暗号ウォレット
• ブラウザー
• パスワードマネージャー
• FTP クライアント
• メッセージング・アプリケーション

対象となるブラウザ拡張機能のリストは、 こちらでご覧いただけます。

これらのターゲットは、C2オペレーターが設定できるため、変更される可能性があります。

次に、EDDIESTEALER は、CreateFileW、 GetFileSizeEx、 ReadFile、 CloseHandleなどの標準 kernel32.dll 機能を使用して、対象のファイルを読み取ります。

後続の C2 トラフィック

タスクを正常に取得すると、EDDIESTEALER はシステムプロファイリングを実行して、感染したシステムに関する情報を収集します。

• 実行可能ファイルの場所 (GetModuleFileNameW)
• ロケール ID (GetUserDefaultLangID)
• ユーザー名 (GetUserNameW)
• 物理メモリの合計量 (GlobalMemoryStatusEx)
• OSバージョン(RtlGetVersion)

クライアントからサーバーへのメッセージと同じデータ形式(Base64(IV):Base64(AESEncrypt(data)))に従って、初期ホスト情報は、追加の設定から取得したキーを使用して AES 暗号化され、HTTP POST 要求を介して <C2_ip_or_domain>/<resource_path>/info/<session_id>に送信されます。その後、完了したタスクごとに、収集されたデータも暗号化され、各タスクが完了した直後に個別のPOSTリクエストで <C2_ip_or_domain>/<resource_path><session_id>/<task_id>に送信されます。この手法では、複数のタスク固有のPOSTリクエストを特徴とする明確なC2トラフィックパターンが生成されます。このマルウェアファミリは、C2通信を主にHTTPSではなくHTTPに依存しているため、このパターンは特に簡単に特定できます。

私たちの分析では、パニックメタデータ文字列に復号化する暗号化された文字列が明らかになり、次のような内部Rustソースファイルパスが明らかになりました。

• apps\bin\src\services\chromium_hound.rs
• apps\bin\src\services\system.rs
• apps\bin\src\structs\search_pattern.rs
• apps\bin\src\structs\search_entry.rs

C2サーバーに送信されたエラーメッセージには、エラーの発生源である正確なソースファイル、行番号、列番号などの文字列が含まれていることを発見し、マルウェア開発者はデバッグフィードバックを組み込むことができました。

Chromium 固有の機能

アプリケーションバウンド暗号化 の導入 以来、マルウェアの開発者は、この保護を回避し、Cookieなどの暗号化されていない機密データにアクセスするための代替方法に適応してきました。ChromeKatz は、マルウェアの実装が見られた中で最も好評を博しているオープンソースソリューションの1つです。EDDIESTEALER も例外ではなく、マルウェアの開発者は Rust に再実装しました。

以下は、 %localappdata%\<browser_specific_path>\\User Data\\Last Versionからバージョン情報を取得した後の、COOKIEKATZ と同様のブラウザのバージョンチェックロジックのスニペットです。

COOKIEMONSTER インスタンスを検出するための COOKIEKATZ 署名パターン :

CookieMonster インスタンスを検出するための CredentialKatz 署名パターン :

次に、COOKIEKATZ の FindPatternの正確なコピー&ペーストロジックの例を示します。ここで、 PatchBaseAddress がインライン化されています。

開発者は、対象のChromiumブラウザが実行されていない場合を処理するための変更を導入しました。非アクティブの場合、EDDIESTEALER は --window-position=-3000,-3000 https://google.comのコマンドライン引数を使用して新しいブラウザインスタンスを生成します。これにより、新しいウィンドウが画面から外れて配置され、ユーザーには見えなくなります。目的は、マルウェアが必要な子プロセス(--utility-sub-type=network.mojom.NetworkServiceフラグで識別されるネットワークサービスプロセス)のメモリ(ReadProcessMemory)を引き続き読み取れるようにすることです。このブラウザプロセスの相互作用の詳細については、 MaaSインフォスティーラーに関する以前の調査を参照してください。

バリアントとの違い

分析後、より新しいサンプルが追加の機能で同定されました。

被害者のマシンで収集される情報には、次のものがあります。

• Running processes
• GPU情報
• CPU コアの数
• CPU名
• CPU ベンダー

C2 の通信パターンが若干変更されました。このマルウェアは、復号化された設定を要求する前に、ホストシステム情報をサーバーに先制的に送信しています。被害者のマシンがC2サーバーにアクセスできたが、空のタスクリストを受け取ったいくつかの例では、開発者はクライアント環境をプロファイリングし、サンドボックスまたは分析システムが検出された場合にメイン設定を保留するためのサーバー側のチェックを導入した可能性が高いという回避戦術が示唆されています。

クライアントからサーバー間通信の暗号化キーは、C2サーバーから動的に受信されなくなりました。代わりに、バイナリにハードコードされています。クライアントがサーバー間メッセージを復号化するために使用するキーもハードコーディングされたままです。

新しくコンパイルされたサンプルでは、関数のインライン展開が広範に使用されており、多くの関数 (ユーザー定義の関数と標準ライブラリやクレートの両方) が呼び出し元に直接インライン化される頻度が高くなり、関数が大きくなり、ユーザー コードの分離が困難になっています。この動作は、LLVM のインライナーを使用した結果である可能性があります。一部の関数はインライン化されていないままですが、インライン化が広まっているため、分析がさらに複雑になります。

Chromeのパスワードマネージャーのすべてのエントリを取得するために、EDDIESTEALERは、 --remote-debugging-port=<port_num> フラグを使用して新しいChromeプロセスを生成し、ローカルのWebSocketインターフェイスを介してChromeのDevToolsプロトコルを有効にすることにより、資格情報の盗難ルーチンを開始します。これにより、マルウェアは、目に見えるユーザーの操作を必要とせずに、ヘッドレス方式でブラウザと対話できます。

Chromeを起動した後、マルウェアは http://localhost:<port>/json/version にクエリを実行して、WebSocket経由でブラウザインスタンスと対話するためのエンドポイントを提供する webSocketDebuggerUrlを取得します。

この接続を使用して、パラメータchrome://password-manager/passwordsを指定したTarget.createTargetコマンドを発行し、Chromeに新しいタブで内部パスワードマネージャーを開くように指示します。この内部ページは、その内容を DOM や DevTools に直接公開しませんが、開くと、Chrome は保存された資格情報を復号化してメモリに読み込みます。この動作は、EDDIESTEALERがCredentialKatzそっくりなコードを通じて後続のステップで悪用し、Chromeプロセスメモリをスキャンして、ブラウザによってロードされた後にプレーンテキストの資格情報を抽出します。

復号化された文字列 os_crypt、 encrypted_key、 CryptUnprotectData、 local_state_pattern、および login_data_patternに基づくと、EDDIESTEALERバリアントは下位互換性があるようで、DPAPI暗号化を引き続き使用するChromeバージョンをサポートしています。

VirusTotalのコードとインフラストラクチャの類似性を通じて、EDDIESTEALERの追加サンプルを 15 個特定しました。観測テーブルには、検出されたサンプル、関連するC2 IPアドレス/ドメイン、およびEDDIESTEALERをホストしているインフラストラクチャのリストが含まれます。

分析のヒント

トレーシング

制御フローをよりよく理解し、大きなコードブロック内の間接的なジャンプや呼び出しの正確な目的地を特定するために、バイナリトレース技術を活用することができます。TinyTracerのようなツールでは、APIトレースをキャプチャして.tagファイルを生成し、選択したAPI呼び出しを記録対象としてアセンブリ内の実行中の行にマッピングできます。Rustの標準ライブラリ関数は、内部でWinAPIを呼び出し、標準ライブラリの抽象化をバイパスして、 WinAPI 関数を直接呼び出すコードもキャプチャします。その後、タグファイルを逆コンパイラツールにインポートして、次のようなプラグインを使用してコードブロックを自動的にマークアップ IFL。

コード セグメンテーションの Panic メタデータ

パニックメタデータ (埋め込みソースファイルパス(.rsファイル)、行番号、およびパニック位置に関連付けられた列番号)は、バイナリのさまざまな部分をセグメント化して理解するための貴重な手がかりを提供します。ただし、これは、そのようなメタデータがバイナリから削除されていない場合に限ります。apps\bin\src\services\chromium.rs、 apps\bin\src\structs\additional_task.rs などのパスや、カスタム プロジェクトの一部であるように見えるパスは、通常、アプリケーション固有のロジックを指しています。library<core/alloc/std>\src\で始まるパスは、Rust標準ライブラリのコードを示します。クレートの名前とバージョンを含むパス ( hashbrown-0.15.2\src\raw\mod.rs など) は、外部ライブラリを指しています。

マルウェアプロジェクトのコードベースがある程度整理されている場合、panic stringsのファイルパスは論理モジュールに直接マッピングできます。たとえば、復号化された文字列 apps\bin\src\utils\json.rs:48:39 は sub_140011b4cで参照されます。

関数への着信呼び出しの呼び出しツリーを調べると、それらの多くは sub_14002699dにまでさかのぼります。この関数(sub_14002699d)は、既知の C2 通信ルーチン(jy::C2::RetrieveAndDecryptConfig)内で、JSON 形式であることがわかっている追加の設定データを復号化した直後に呼び出されます。

json.rsパスとその呼び出しコンテキストに基づいて、sub_14002699d が JSON データの解析を担当していると推測されます。関数呼び出しをステップオーバーすることで確認できます。案の定、関数呼び出しへの参照として渡されるスタック構造体を調べると、解析された構成フィールドが入力されたヒープ アドレスを指すようになりました。

標準ライブラリおよびオープンソースのサードパーティクレートの場合、ファイルパス、行番号、および(利用可能な場合は)rustcコミットハッシュまたはクレートバージョンを使用すると、正確なソースコードをオンラインで検索できます。

スタックスロットの再利用

最適化機能の 1 つは、タイムラインが重複しない変数/スタック構造体のスタック スロットを再利用することです。同時に「ライブ」ではない変数は、同じスタックメモリ位置を共有できるため、全体的なスタックフレームサイズが削減されます。基本的に、変数は、値が割り当てられた瞬間から、その値にアクセスできる最後のポイントまでライブです。これにより、同じメモリ オフセットが異なるポイントで異なる型または値を保持する可能性があるため、逆コンパイルされた出力が混乱します。

これを処理するために、関数内で同じメモリオフセットを共有するすべての可能な型を包含する共用体を定義できます。

Rust のエラー処理と列挙型

Rust 列挙型は、複数のバリアントを持つ型を定義するタグ付き共用体であり、それぞれがオプションでデータを保持し、成功や失敗などの状態をモデル化するのに理想的です。バリアントは、判別式 (タグ) によって識別されます。

エラー処理コードはバイナリ全体に見られ、逆コンパイルされたコードのかなりの部分を占めています。Rustのエラー処理の主なメカニズムは、 Result<T, E> ジェネリック列挙型です。これには、成功を示す Ok(T)とタイプ Tの値を含む Err(E)と、失敗を示し、タイプ Eのエラー値を含む の 2 つのバリアントがあります。

次のスニペットの例では、判別値 0x8000000000000000 を使用して、 CreateFileW API の解決結果が区別されています。CreateFileWが正常に解決されると、reuse変数型に API 関数ポインターが含まれ、else 分岐が実行されます。それ以外の場合は、 if 分岐が実行され、エラー情報文字列が から reuse に割り当てられます arg1。

他の一般的なRustタイプがメモリ内でどのように見えるかについての詳細は、この チートシート とCindy Xiaoによるこの素晴らしい トーク をチェックしてください。

マルウェアと MITRE ATT&CK

Elasticは、 MITRE ATT&CK フレームワークを使用して、脅威がエンタープライズネットワークに対して使用する一般的な戦術、手法、手順を文書化します。

戦術（Tactics）

• 初期アクセス（Initial Access）
• 実行
• 防御回避
• 抽出
• 認証情報アクセス
• ディスカバリ
• 収集

手法

手法は、敵対者がアクションを実行することによって戦術的な目標を達成する方法を表します。

• フィッシング
• コンテンツインジェクション
• コマンドおよびスクリプティングインタープリター
• パスワードストアからの認証情報
• User Execution
• ファイルまたは情報の難読化
• C2チャネルを介した流出
• 仮想化/サンドボックス回避

検出

ヤラ

Elasticセキュリティは、この調査に関連して以下のYARAルールを作成しました。

• Windows.Infostealer.EddieStealer

行動防止ルール

• Suspicious PowerShell Execution
• PowerShell によるイングレス ツール転送
• 潜在的なブラウザ情報の検出
• Potential Self Deletion of a Running Executable

観測

この研究では、次の観測量について議論しました。

参照資料

上記の研究を通じて、以下のことが参照されました。

• https://github.com/N0fix/rustbinsign
• https://github.com/Meckazin/ChromeKatz
• https://github.com/hasherezade/tiny_tracer
• https://docs.binary.ninja/dev/uidf.html
• https://www.unicorn-engine.org/
• https://github.com/LloydLabs/delete-self-poc/tree/main
• https://cheats.rs/#memory-layout
• https://www.youtube.com/watch?v=SGLX7g2a-gw&t=749s
• https://cxiao.net/posts/2023-12-08-rust-reversing-panic-metadata/