在監控 2026 年 6 月的 Android 威脅時，我們發現了一款新的 Android 惡意軟體。令人意外的是，它像普通使用者應用程式一樣安裝，卻不偽裝成合法軟體，完全沒有使用者介面。這讓我們懷疑該應用程式可能在使用者不知情的情況下進入了他們的設備。進一步調查證實了這一假設，並使我們能夠重建整個感染鏈。

Kaspersky 的解決方案將以下描述的威脅偵測為：

車載娛樂系統（Head Unit）是結合了多媒體功能與部分車輛功能控制的系統。車載娛樂系統可能是汽車的原廠配備，也可能是售後升級。這些系統的主要攻擊途徑包括實體存取入侵以及車載娛樂系統作業系統或元件中的漏洞，這些我們先前都已涵蓋。

在某些情況下，車載娛樂系統運行 Android，主要是因為對製造商而言很方便：Android 的原始碼已經考慮到汽車車載娛樂系統的使用情境。Android 也允許製造商在建置過程中加入自己的系統應用程式，用於各種目的：自訂使用者介面、加入符合供應商需求的系統元件等。

大多數為 Android 裝置開發的應用程式也能在基於 Android 的車載娛樂系統上運行，惡意軟體也不例外。也就是說，很難想像某些類型的智慧型手機惡意軟體會被用於攻擊車載娛樂系統。例如銀行木馬：由於行動銀行幾乎只在智慧型手機上使用，感染車載娛樂系統的銀行木馬將是攻擊者資源的浪費。

值得注意的是，車載娛樂系統通常包含 SIM 卡插槽並能連接網路，啟用導航和軟體更新等功能。由於車載娛樂系統通常不包含對攻擊者有價值的東西，使用「經典」Android 惡意軟體的較可能攻擊情境是感染設備以將其招募到機器人網路中——類似於對物聯網設備的攻擊。

在我們的研究中，我們發現了正是這種惡意軟體。DoFun 車載娛樂系統韌體的設計使得攻擊者能夠散佈惡意軟體。我們已通知供應商有關散佈方案，他們隨後回報已修復安全問題。

以下是完整的感染鏈：

讓我們來看看這些車載娛樂系統是如何被感染的。

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 投放器。

如前所述，JarService 是一個小型投放器應用程式，沒有任何使用者介面。它會解密儲存在木馬程式碼內的加密區塊中的數據。每個區塊都使用單位元組金鑰進行 XOR 加密，該金鑰從一個區塊線性移動到下一個區塊。解密後的數據包含關於酬載版本和進入點的序列化資訊，以及惡意軟體本身的程式碼，用於進一步載入。

解密和序列化第二階段酬載的資訊

在我們分析的 JarService 版本中，下一階段酬載的進入點是 com.c.j.qbh 類別的 wa 方法。

此階段的酬載是一個惡意載入器。其程式碼包含加密字串，稍後將使用反射機制作為類別名稱來執行第三階段酬載。載入器透過 POST 請求將植入程式資訊發送到攻擊者的伺服器之一。C2 伺服器請求範例：

回應 POST 請求，C2 伺服器會返回一個下載第三階段酬載的連結。C2 回應範例如下所示。

木馬程式使用數據物件中的 dexUrl 欄位中的連結來下載用於載入下一階段的序列化數據。這些數據以單一位元組整數開頭，這是用於解密載入器程式碼中字串的金鑰。緊隨此數字之後的是一個四位元組浮點值，用於 XOR 解密第三階段酬載，而第三階段酬載本身位於這些金鑰之後。

在解密的酬載中，進入點是 com.ast.sdk.BillingMain 類別的 init 方法，如下圖所示。

在分析此階段時，我們注意到下一階段酬載的下載連結包含版本號。我們決定嘗試其他版本號以檢索不同的酬載版本，並最終獲得了七個不同的變體，我們在報告末尾的「入侵指標」下列出了它們。最早的版本，編號 3.57，使用的解碼演算法與上述不同。這可能表明感染鏈的早期版本在 JarService 和第三階段酬載之間使用了不同的載入器。

在此階段，惡意軟體預設每 90 分鐘向 /cpc/api/task 發送一次 POST 請求，其中包含受感染設備的資訊（顯示解析度、設備型號、連接的 Wi-Fi 網路的 SSID、MAC 位址等）以及木馬程式的組態版本。如果組態過時，C2 伺服器將返回更新的組態，其中包含新的 C2 位址和用於發送 HTTP 請求的新路徑。回應範例如下所示。請注意，在我們研究時，最新的組態版本是 3.82。

如果組態版本不需要更新，C2 伺服器將返回整數命令識別碼，攻擊者稱之為 productId。木馬程式將每個識別碼映射到命令資訊，並使用 SharedPreferences API 將其儲存為序列化 JSON 物件。每個識別碼也有自己的版本，以 UNIX 時間戳表示。如果 C2 回應包含未知的 productId 或版本過時的識別碼，惡意軟體將向攻擊者的伺服器發送 GET 請求至 /cpc/api/xml 以檢索所有此類識別碼的命令內容。C2 伺服器會回應每個未知識別碼的命令資訊。回應範例如下所示。

命令資訊包含一個 tagName 欄位，這是命令名稱。程式碼將每個名稱映射到負責執行它的相應類別。

在我們研究時，攻擊者已實施了九個命令。下表列出了命令名稱、簡要描述和參數。這些命令的功能表明，惡意軟體可用於顯示廣告、進行廣告詐騙（充當點擊器）以及下載額外的惡意程式碼。

然而，攻擊者在實際攻擊中只使用了一小部分這些命令。如上述 C2 回應範例所示，在發布本報告時，攻擊者正在使用 loadlib2 和 http 命令。透過 loadlib2 命令下載的酬載是一個名為「zhima」的反向代理模組，Nokia Deepfield 緊急響應團隊的研究人員與我們同時獨立發現了它，並在其報告中進行了描述。這證實了攻擊者的最終目標是建立一個代理機器人網路。

在分析此攻擊鏈的階段時，我們注意到 zhima 下載連結也包含版本號。與前一階段一樣，我們嘗試了其他可能的版本號，並找到了 zhima 模組的八個變體，其中最早的版本是 57。已識別的 zhima 模組的完整列表在下面的「入侵指標」中提供。

在分析完整的感染鏈時，我們注意到第二階段載入器創建了一個具有有意義名稱 mosdk-host-loader 的執行緒。我們決定調查 mosdk 在該名稱中指的是什麼。這引導我們發現了一個安裝在各種電視機上盒上的惡意應用程式，其套件名稱為 com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98)。它由幾個元件組成（包括一個類似 JarService 的投放器），攻擊者利用這些元件秘密地將設備的計算能力貨幣化。應用程式中的每個惡意元件都對應自己的服務，包含類似 JarService 投放器啟動程式碼的服務名為 AdmoyuService。考慮到這一點以及在酬載程式碼中發現的惡意執行緒名稱，我們得出結論，服務名稱中的 moyu 指的是 MoYu Group，這是與 BADBOX 惡意軟體平台相關的參與者之一，HUMAN 的研究人員曾對此進行過描述。這一評估進一步得到了惡意軟體網路基礎設施與 MoYu Group 網路基礎設施之間廣泛重疊的支持，Nokia Deepfield 緊急響應團隊的研究人員與我們同時獨立識別了這一點。基於這些相似的命名模式以及 MoYu Group 活動與本報告中所述攻擊之間顯著的基礎設施重疊，我們有高度信心將其歸因於同一參與者。

在調查 TWCore 下載的惡意軟體時，我們注意到網域 admin.uipoxy[.]com 解析到 IP 位址 128.14.210[.]58，這是 zhima 反向代理模組的 C2 伺服器之一。看來 URL hxxp://admin.uipoxy[.]com/proxy/u/login 託管了 zhima 管理面板。有趣的是，只要有有效的邀請碼，任何人都可以註冊。

惡意軟體操作員註冊頁面

我們在所有這些網站的身份驗證 API 中發現了幾個相似之處：

基於此，我們認為這些服務與 MoYu Group 有關。

儘管網路安全專業人員和執法部門努力關閉 BADBOX 機器人網路，但與其相關的個別參與者仍在繼續其惡意活動，感染全球設備。此類惡意軟體的傳播方式差異很大，從透過預先安裝的後門下載到受感染的 IPTV 應用程式建置。本文檢視的案例展示了一種更複雜的傳播方法：透過合法系統應用程式的更新功能進行散佈。攻擊者也在積極擴展到新平台。此惡意軟體是首款針對車載娛樂系統的惡意應用程式，這意味著這些平台現在也需要針對惡意軟體進行防護。