車載ヘッドユニットが通信の中継点に：BADBOX関連マルウェアが悪用した正規のOTA更新

BADBOXに関連するマルウェアが、DoFunのソフトウェアを搭載したAndroidヘッドユニットに配布されていました。攻撃者はMQTTの保護の弱さと正規のOTA更新の仕組みを悪用し、利用者に気づかれないまま端末に残り続けるマルウェアを導入していました。VicOneの解析をもとに、その手口を解説します。

このブログのポイント

• BADBOXは出荷前のAndroid端末に不正なコードを組み込み、遠隔から操作できる状態にしておく攻撃活動です。この活動が自動車のシステムにも及んでいます。攻撃者はDoFunのソフトウェアを搭載したAndroidヘッドユニットに組み込まれた正規のアップデート機能を経由して、HUMAN Securityが2025年に明らかにしたBADBOX 2.0のエコシステムにつながるマルウェアを配布していました。
• アップデートの仕組みに十分な保護がなく、ゼロデイ脆弱性の悪用も利用者の操作もないまま、マルウェアがインストールされていました。MQTTの認証情報がアプリに直接書き込まれ、通信は暗号化されず、ダウンロードしたファイルの確認はMD5だけで、インストール処理には広すぎる権限が与えられていました。
• 感染した機器は、広告詐欺や通信を中継するプロキシとして使われていました。そこに至る侵入を成立させたのがアップデートの経路であり、自動車でもこの経路を保護することが対策の中心になります。

BADBOX関連の活動が車載ヘッドユニットに及んだ経緯

2025年3月、HUMAN SecurityのSatori Threat Intelligenceチームがレポート「BADBOX 2.0: The Sequel No One Wanted」を公開しました。BADBOXはAndroid端末が利用者の手に渡る前の段階で不正なコードを組み込み、出荷後に攻撃者が遠隔から操作できる状態にしておく攻撃活動です。最初の活動は2023年に公表されており、このレポートはその続編にあたります。

同レポートによると、中国を拠点とする攻撃者はスマートTVやタブレット、アフターマーケットの車載インフォテインメント（IVI）システムを含む100万台を超えるノーブランドのAndroid端末にこの不正なコードを組み込んでいました。攻撃者は世界各地で使われているこれらの端末を通信の経由地として利用できる状態を作り、大規模なレジデンシャルプロキシ（家庭の回線を第三者の通信の経路として貸し出す仕組み）のサービスと広告詐欺の基盤を築いていました。

2026年8月に公開されたKasperskyのレポート「The Invisible Passenger in Your Car」は、多段構成のマルウェアが車載ヘッドユニットに配布されていたことを報告しています。対象となったのは、車載ヘッドユニット向けのソフトウェアを手がけるベンダーDoFunのソフトウェアを搭載したAndroidヘッドユニットです。マルウェアの配布に使われたのは、これらのヘッドユニットに標準で組み込まれているソフトウェアの更新と端末管理を担う正規のアプリでした。Kasperskyはこの活動を、BADBOXのマルウェアに関連する攻撃者グループMoYu Groupによるものと高い確度で判断しています。

図1. BADBOXに関する調査から、車載ヘッドユニットでのマルウェア発見に至る主な経緯

VicOneのCyberThreat Research Labは、Kasperskyの公表を踏まえて追加の解析を行いました。対象は、JarServiceと呼ばれるドロッパーの2種類の亜種と、その配布に使われたTWCoreの製品版ビルドです。ドロッパーは、端末に入り込んだ後に本体となるマルウェアをダウンロードして導入するプログラムを指します。TWCoreは、ヘッドユニットに標準で組み込まれている正規のアプリで、OTA（無線経由）によるソフトウェアの更新と端末の管理を担っています。VicOneはこれらを入手し、リバースエンジニアリングによって動作を解析しました。

TWCoreを経由した感染の流れ

VicOneの解析から、TWCoreの設計にはKasperskyが指摘した以外の弱点も残っていたことが分かりました。また、感染の起点に典型的なゼロデイ脆弱性の悪用はありませんでした。システムの署名を持つTWCoreは認証情報がプログラムに直接書き込まれ、しかも複数の端末で同じものが使われていました。攻撃者はこの認証情報を使い、TWCoreに最初から備わっている遠隔インストールの命令を呼び出しています。VicOneは、この経路で配布された2種類のJarServiceを解析しました。

表1. TWCoreを経由した配布の経路と、確認されたJarServiceのペイロードの亜種

図2. 不正なMQTT命令の送信からJarServiceの展開、収益化までの流れを再構成したTWCore経由の感染の流れ

図では感染の流れを一続きの順序として示しています。VicOneの解析では、同じMQTTで制御される端末管理の経路が、次の操作にも使える状態にあることが分かりました。

• アプリケーションの遠隔でのアンインストール
• 既定のHOMEランチャーの差し替え
• 他社のSIMの無効化と、そのSIMに関連する情報の取得
• 端末からのAPKファイルの取り出し
• 遠隔操作によるlogcatの出力の収集

JarServiceドロッパーがインストールされた後の段階は、Androidの多段構成のローダーによく見られる流れをたどります。影響が最も大きいのは、それより前の段階です。権限を与えられたインストール処理が信頼された更新の経路を使い、利用者の操作を必要とせずに最初のマルウェアを導入できる状態にありました。

VicOneがTWCoreとJarServiceで確認したこと

これまでの公開情報では、配布に使われたアプリがTWCoreであり、第1段階のドロッパーがJarServiceであることが示されていました。VicOneはここから踏み込み、TWCoreの製品版ビルド（V7.3.0.240119、versionCode 81）と2種類のJarServiceを対象に静的解析を行いました。その結果、TWCoreの設計そのものにいくつかの弱点があることが分かりました。いずれも攻撃者が狙える範囲を広げるもので、このアプリが悪用された場合の影響が今回確認されたマルウェアのインストールだけにとどまらない理由もここにあります。

TWCoreは、DoFunのソフトウェアを搭載したAndroidヘッドユニットに組み込まれている正規のシステム構成要素です。メーカー側でソフトウェアの更新と端末管理を担うプログラムとして動作し、端末の稼働データの収集、MQTTを通じた基幹システムからの指示の受信、APKパッケージの遠隔でのダウンロード・更新・インストールを行います。このインストールの対象には、その端末にそれまで入っていなかったアプリも含まれます。

確認された弱点

• 過剰な権限と、外部から呼び出せる内部の窓口：解析したTWCoreのビルドはandroid.uid.systemの権限で動作していました。加えて、path="."を指定したFileProviderを外部に公開しており、外部ストレージ全体にアクセスできる状態にありました。外部に公開されたMessengerServiceを通じて、端末内の他のアプリが任意のシステム権限の命令を送れる状態にもなっていました。
• 任意のAPKの、利用者に気づかれないインストール：TWCoreは外部から与えられたURLからAPKをダウンロードできますが、その際にサーバー証明書を検証していません。ダウンロードしたファイルの確認はMD5だけで行っています。MD5ではファイルが途中で壊れていないかは分かるものの、そのソフトウェアが誰の手によるものでどこから来たのかは確かめられません。さらに中国向け以外のビルドでは、Androidのパッケージ検証機能を無効化し非公開のMainActivityを呼び出して、利用者の目に触れないまま用意したAPKをインストールします。
• 通信と端末管理の経路の保護の不足：TWCoreは、1883番ポートを使うMQTTで暗号化のない通信を行い、複数の端末で共通の認証情報をプログラムに直接書き込んでいます（d****／d************）。通信処理ではTLS／HTTPSの証明書の検証も無効化されていました。加えて、ワイルドカードを使った購読の設定により、署名のない一斉配信の命令が同じソフトウェアを搭載した全端末に届く状態にありました。

JarServiceの2つの亜種の変化

VicOneがJarServiceのv1.10とv1.12を比較したところ、ペイロードの扱い、端末に残る痕跡、通信の仕組みに変更が加えられていました。後から出たv1.12では、更新処理の保護と埋め込まれた鍵の扱いが強化されています。

表2. JarServiceのv1.10とv1.12の技術的な比較

まとめ

Kasperskyの公表とそれを踏まえたVicOneの解析から分かるのは、メーカーが正規に用意したアップデートの仕組みがそのままマルウェアの配布経路になるおそれがあるということです。今回確認された感染では、不正なアップデート命令を受けたTWCoreが自らに備わっている遠隔インストールの機能を使い、BADBOXに関連するJarServiceを利用者に気づかれないままインストールしていました。

複数の端末で同じ認証情報を使い、命令の送り主を確かめず、インストール処理に広すぎる権限を与える。こうした設計が重なることで、正規のOTA管理の機能が侵入の経路に変わります。

自動車メーカーとサプライヤーには、アップデートを担うプログラムを無条件に信頼せず、そこに届く命令を検証する前提で設計することが求められます。相互TLS、命令とペイロードへの署名による認証、MQTTブローカーへの接続制限、証明書の検証、必要最小限の権限に絞った分離がいずれも必要になります。

静的な認証情報を使い続け、インストールできるパッケージを制限しないIVIプラットフォームは、マルウェアの種類や攻撃者が誰であるかに関わらず今後の攻撃活動でも同じように狙われるでしょう。