Androidベースの車載ヘッドユニットファームウェアにマルウェアが感染

目次 ヘッドユニットファームウェアの概要 TWCoreアプリ ステージ1: JarServiceドロッパー ステージ2: ローダー ステージ3: クリッカー/リバースプロキシローダー 帰属 結論 侵害の兆候 ステージ1: JarService ステージ2: ローダー ステージ3: ローダー/クリッカー zhimaモジュール ドメインとIPアドレス JarServiceのダウンロードに使用されたアドレス TWCore（JarServiceの配布に使用された正規ソフトウェア）のハッシュ 著者 Dmitry Kalinin 2026年6月にAndroidの脅威を監視していた際、新しいAndroidマルウェアを発見しました。特筆すべきは、それが通常のユーザーアプリのようにインストールされるにもかかわらず、正規ソフトウェアを装う試みを一切行わず、ユーザーインターフェースが全くなかったことです。これにより、アプリがユーザーの知らないうちにデバイスに到達している可能性が疑われました。さらなる調査でその仮説が確認され、感染チェーン全体を再構築することができました。 主な発見事項: 新しいAndroidマルウェアを特定しました。これは多段階ダウンローダーであり、最終的な目的は広告詐欺とプロキシボットネットの構築です。 マルウェアは、Androidベースの車載ヘッドユニットファームウェアの組み込みアップデーターを通じて拡散していました。 これは、そのタイプのデバイスに特化した感染チェーンを持つ車載ヘッドユニットで発見された初のマルウェア事例です。 この活動は、BADBOXボットネットに関連する攻撃者であるMoYuグループに、高い確度で帰属されます。 Kasperskyソリューションは、以下のような検出名で説明されている脅威を検出します。 HEUR:Trojan-Dropper.AndroidOS.Agent.vu HEUR:Trojan-Downloader.AndroidOS.Agent.ov HEUR:Trojan-Proxy.AndroidOS.Zhima.* HEUR:Trojan.AndroidOS.Vo1d.* ヘッドユニットファームウェアの概要 ヘッドユニットとは、マルチメディア機能と特定の車両機能の制御を組み合わせたシステムです。ヘッドユニットは、車の工場出荷時の装備として、またはアフターマーケットのアップグレードとして提供される場合があります。これらのシステムに対する主な攻撃ベクトルは、物理アクセスによる侵害と、ヘッドユニットのOSまたはコンポーネントの脆弱性ですが、これらについては以前にも取り上げています。 一部のヘッドユニットはAndroid上で動作します。これは主にメーカーにとって便利だからです。Androidのソースコードは、車載ヘッドユニットでの使用例をすでに考慮に入れています。また、Androidはメーカーがビルドプロセス中に独自のシステムアプリケーションを追加することを可能にし、UIのカスタマイズ、ベンダーのニーズに合わせたシステムコンポーネントの追加など、さまざまな目的で使用できます。 Androidデバイス向けに開発されたほとんどのアプリは、Androidベースのヘッドユニットでも実行可能であり、マルウェアも同様です。とはいえ、特定のカテゴリのスマートフォン向けマルウェアがヘッドユニットを攻撃するために使用されるとは想像しにくいです。バンキングトロイの木馬が良い例です。モバイルバンキングはほぼスマートフォン専用であるため、ヘッドユニットをバンキングトロイの木馬に感染させることは、攻撃者のリソースの無駄遣いになるでしょう。 ヘッドユニットにはSIMカードスロットが含まれており、インターネットに接続できるため、ナビゲーションやソフトウェアアップデートなどの機能が有効になることに注意する価値があります。ヘッドユニットには通常、攻撃者にとって価値のあるものは含まれていないため、「古典的な」Androidマルウェアを使用したより可能性の高い攻撃シナリオの1つは、IoTデバイスへの攻撃と同様に、ボットネットにリクルートするためにデバイスを感染させることです。今回の調査で、まさにそのようなマルウェアを発見しました。 DoFunヘッドユニットのファームウェア設計により、攻撃者はマルウェアを配布することができました。ベンダーに配布スキームについて通知したところ、その後、セキュリティ問題が修正されたと報告がありました。以下に、感染チェーン全体を示します。 ヘッドユニット感染スキーム これらのヘッドユニットがどのように感染したかを詳しく見てみましょう。 TWCoreアプリ TWCoreは、分析データの収集とヘッドユニットソフトウェアの更新を担当する正規のシステムアプリケーションです。アップデート機能がどのように機能するかを詳しく見てみましょう。 プロセスは非常にシンプルです。サブドメインcardoor[.]cnでホストされているMQTTメッセージブローカーは、ヘッドユニットにダウンロードおよびインストールする必要があるAPKファイルに関する情報を含むメッセージを送信します。注目すべきは、このメッセージを記述するオブジェクトにinstallNotExistsフィールドが含まれていることです。これはtrueまたはfalseに設定できるブールフラグです。このフラグにより、TWCoreはデバイスに元々存在しなかったアプリをインストールできます。 installNotExists = false の場合のみ、TWCoreはアプリが既にデバイスにインストールされているかを確認します。 APKファイルは、インストール用に<TWCore external cache dir>/push/apk/にダウンロードされます。 TWCoreがAPKファイルをダウンロードするパス 私たちのテレメトリにより、これらのファイルパスで未知のマルウェアが明らかになりました。さらに、観測されたすべてのケースで、マルウェアはcom.tw.coreというパッケージ名を持つアプリによってインストールされており、これはTWCoreのパッケージ名と一致することがデータから示唆されています。次に、TWCoreによってインストールされたマルウェア、すなわちJarServiceドロッパーを分解します。 ステージ1: JarServiceドロッパー 前述のように、JarServiceはUIを一切持たない小さなドロッパーアプリです。トロイの木馬のコード内に暗号化されたブロックとして格納されているデータを復号します。各ブロックは、ブロックごとに線形にシフトする単一バイトキーでXOR暗号化されています。復号されたデータには、ペイロードのバージョンとエントリーポイントに関するシリアライズされた情報と、さらなるロードのためのマルウェア自体のコードが含まれています。 ステージ2のペイロードに関する情報の復号とデシリアライズ 分析したJarServiceのバージョンでは、次のステージのペイロードのエントリーポイントは、com.c.j.qbhクラスのwaメソッドでした。 ステージ2: ローダー このステージのペイロードは悪意のあるローダーです。そのコードには、後でリフレクションメカニズムを使用してステージ3のペイロードを実行するためのクラス名として使用される暗号化された文字列が含まれています。 ローダーは、攻撃者のサーバーの1つにPOSTリクエストを介して、インプラント情報を送信します。 C2サーバーへのリクエスト例: { "userId": "REDACTED", "dexVersion": "1.7", "dexType": 1, "channelId": "2039", "packageName": "com.tw.jar1", "appVersion": 12, "appName": "JarService" } POSTリクエストへの応答として、C2サーバーはステージ3のペイロードをダウンロードするためのリンクを返します。C2応答の例を以下に示します。 { "code": 200, "data": { "dexUrl": "hxxp://144.217.243[.]201/vr34der34/dex3.68.png", "dexVersion": 3.680, "status": 0 } } トロイの木馬は、データオブジェクトのdexUrlフィールドのリンクを使用して、次のステージをロードするためのシリアライズされたデータをダウンロードします。このデータは、文字列を復号するためのキーである単一バイト整数で始まります。この数値の直後には、ステージ3のペイロードをXOR復号するために使用される4バイトの浮動小数点値があり、ステージ3のペイロード自体はこれらのキーの後に配置されています。 ステージ3のペイロードの復号 復号されたペイロードでは、エントリーポイントはcom.ast.sdk.BillingMainクラスのinitメソッドであり、以下のスクリーンショットに示されています。 ステージ3ペイロードのエントリーポイント このステージを分析している際、次のステージのペイロードのダウンロードリンクにバージョン番号が含まれていることに気づきました。他のバージョン番号を試して異なるペイロードバージョンを取得しようとしたところ、最終的に7つの異なるバリアントを取得しました。これらはレポートの最後にある「侵害の兆候」にリストされています。最も初期のバージョンである3.57は、上記で説明したものとは異なるデコードアルゴリズムを使用しています。これは、感染チェーンの以前のバージョンがJarServiceとステージ3ペイロードの間に異なるローダーを使用していた可能性を示唆している可能性があります。 ステージ3: クリッカー/リバースプロキシローダー このステージでは、マルウェアはデフォルトで90分ごとに/cpc/api/taskにPOSTリクエストを送信します。このリクエストには、感染したデバイス（ディスプレイ解像度、デバイスモデル、接続されているWi-FiネットワークのSSID、MACアドレスなど）に関する情報と、トロイの木馬の設定バージョンが含まれています。設定が古い場合、C2サーバーは新しいC2アドレスと送信パスの更新された設定を返します。