BADBOX 相關惡意軟體如何將車用主機變成代理節點

本文重點 

• 與 BADBOX 相關的攻擊活動已延伸至車用系統。攻擊者利用搭載 DoFun 系統的 Android 車用主機中的合法更新機制，散布與 HUMAN Security 於 2025 年揭露的 BADBOX 2.0 生態系相關惡意軟體。 

• 更新機制的安全弱點讓惡意軟體能夠直接被植入裝置。使用寫死的 MQTT 憑證、明文通訊、僅以 MD5 檢查機制驗證檔案，以及安裝程式的權限過高，讓攻擊者不需要利用零日漏洞或透過與使用者互動，就可安裝惡意軟體。 

• 強化更新機制是防範此類攻擊的關鍵。此惡意軟體利用受感染裝置進行廣告詐欺及代理服務，顯示車用更新機制一旦遭到濫用，也可能成為攻擊者入侵並控制裝置的管道。 

BADBOX 相關惡意軟體如何入侵車用主機

2025 年 3 月，HUMAN Security 的 Satori 威脅情報團隊發布「BADBOX 2.0: The Sequel No One Wanted」報告，指出一項來自中國的攻擊行動已入侵超過 100 萬台非知名品牌 Android 裝置，包括智能電視、平板電腦，以及售後市場的車載資訊娛樂（IVI）系統。這項行動延續 2023 年首次曝光的 BADBOX 攻擊，利用在供應鏈環節就遭入侵的裝置，建立大規模常駐型代理伺服器網路（residential proxy）與廣告詐欺（ad-fraud）網路，也顯示車用主機系統已成為 BADBOX 惡意活動的一環。

2026 年 8 月，Kaspersky 於「The Invisible Passenger in Your Car」報告中進一步揭露， DoFun Android 車用主機的內建更新程式遭利用，成為多階段惡意軟體的散布管道。Kaspersky 高度確信該這波攻擊活動與 MoYu Group 有關，而該威脅組織亦與 BADBOX 惡意軟體平台存在關聯。

圖 1：BADBOX 殭屍網路演變與調查時間軸

在 Kaspersky 揭露的研究基礎上，VicOne CyberThreat Research Lab 進一步取得兩個 JarService dropper 變種及 TWCore 的正式版本，並進行逆向分析。TWCore 是車用主機出廠時內建的系統組件，用於軟體安裝與更新，以及車聯網（Telematics）相關資料的蒐集與分析。

TWCore 感染路徑如何運作

VicOne 的分析進一步發現 TWCore 設計上的弱點，並確認這條感染鏈並未利用傳統的零日漏洞。相反地，攻擊者利用具備系統簽章的 OTA 更新元件，透過其內建的遠端安裝功能下達惡意指令。而此元件使用寫死且跨裝置共用的憑證，進一步擴大了被利用的風險。透過這條散布路徑，VicOne 也分析了兩個 JarService 變種。 
 

表 1：以 TWCore 為基礎的散布路徑，以及觀察到的 JarService payload 變種

圖 2：重構的 TWCore 感染鏈，從惡意 MQTT 指令散布到 JarService 部署及變現 

圖中雖以線性方式呈現感染流程，然而，VicOne 的分析發現，由同一個 MQTT 控制的裝置管理通道，實際上還可執行其他多種遠端操作，包括： 

• 遠端解除安裝應用程式

• 變更預設 HOME Launcher

• 停用其他供應商的 SIM，並存取相關資訊

• 從裝置取得 APK 檔案

• 遠端收集 logcat 紀錄

安裝 JarService dropper 後，後續攻擊便進入較典型的多階段 Android Loader 模式。然而，整條感染鏈真正關鍵的環節其實出現在更早階段：具高權限的安裝程式可透過受信任的更新機制，在不需要使用者互動的情況下，部署第一階段惡意軟體。 

VicOne 在 TWCore 與 JarService 中發現了什麼

公開研究已指出 TWCore 是惡意軟體的散布管道，而 JarService 則扮演第一階段 dropper 的角色。在此基礎上，VicOne 進一步針對 TWCore 正式版本（V7.3.0.240119，versionCode 81）及兩個 JarService 變種進行深入靜態分析。分析揭露 TWCore 架構存在多項安全弱點。這些弱點不僅擴大潛在攻擊面，也顯示 TWCore 一旦遭到濫用，其影響可能不只限於目前觀察到的惡意軟體安裝行為。 

TWCore 是內建於 DoFun Android 車用主機的合法系統元件，主要負責 OEM 端的軟體更新與裝置管理，包括負責收集裝置資訊、透過 MQTT 接收後端指令，以及遠端下載、更新與安裝 APK 套件，甚至可以安裝原先不存在於裝置上的應用程式。 

發現的安全弱點

• 系統權限過高且本機介面暴露。分析顯示，該版本 TWCore 以 android.uid.system 的高權限執行；同時，其 exported FileProvider 將 path="." 設為可存取範圍，使 TWCore 的儲存內容可能暴露給外部應用程式。此外，攻擊者可透過車載主機上已安裝的應用程式，濫用 exported MessengerService 向 TWCore 傳送指令，進而以其系統權限執行高權限操作。
• 可直接安裝任意 APK。TWCore 可從外部指定的 URL 下載 APK，但不會驗證伺服器憑證，下載後僅以 MD5 檢查檔案完整性，無法確認 APK 的來源與真實性。當車機運行於中國境外市場版本時，TWCore 還會停用 Android 的套件驗證機制，並透過隱藏的 MainActivity 在無需使用者互動的情況下安裝 APK。
• 網路通訊與車隊控制機制缺乏安全防護。TWCore 透過 1883 port 使用明文 MQTT 通訊，且不同裝置使用固定且共用的憑證（d**** / d************）。其網路機制也同時停用了 TLS/HTTPS 憑證驗證，並採用 MQTT 萬用字元主題訂閱，使後端可透過符合訂閱條件的 Topic，將未經簽章驗證的指令同時下發至大量連線中的車機，形成車隊層級的廣播式控制風險。

JarService 變種如何演進

VicOne 比較 JarService v1.10 與 v1.12 後發現，兩個版本在 payload 處理方式、裝置上的檔案，以及通訊機制方面皆有所不同。較新的 v1.12 版本也進一步強化了更新機制及內建金鑰的保護。 

表 2：JarService v1.10 與 v1.12 dropper 變種版本比較 

結論

Kaspersky 的揭露以及 VicOne 後續分析顯示，合法的 OEM 更新機制一旦遭到濫用，也可能成為惡意軟體的散布管道。在這次觀察到的感染鏈中，攻擊者透過惡意更新指令，利用 TWCore 內建的遠端安裝功能部署與 BADBOX 相關的 JarService 惡意軟體。 

此案例也顯示，共用憑證、指令驗證不足，以及過高的安裝程式權限，都可能使原本合法的 OTA 管理功能成為攻擊者入侵系統的途徑。 

汽車 OEM 與供應商應將更新程式視為關鍵的安全信任邊界。適當的防護措施包括採用雙向 TLS（mutual TLS）、對指令與 payload 進行加密簽章與授權驗證，嚴格控管 MQTT broker 存取權限、落實憑證驗證，並遵循最小權限原則限制更新程式的系統權限。 

只要車用主機上的系統更新程式持續使用固定且共用的憑證，缺乏嚴格的套件來源與完整性驗證，且未依最小權限原則限制更新程式本身的系統權限，類似的惡意程式植入與供應鏈攻擊風險仍可能再次發生。