Autores
Em junho de 2026, o monitoramento de ameaças para Android permitiu identificar um novo malware para esse sistema. Um detalhe nos chamou a atenção: o malware se instalava como um aplicativo comum de usuário (user app), mas não se disfarçava de software legítimo e não possuía interface. Isso levantou a suspeita de que o aplicativo estava sendo instalado nos dispositivos sem o conhecimento dos usuários. A investigação posterior confirmou essa hipótese e permitiu reconstruir toda a cadeia de infecção.
Resumo dos achados:
- Identificamos um novo malware para Android: um loader multiestágio cujo objetivo final é a fraude publicitária e a criação de uma botnet de proxy.
- A propagação do malware ocorria por meio dos mecanismos de atualização de software integrados ao firmware de centrais multimídia (head unit) baseadas em Android. Este é o primeiro caso documentado de malware detectado em uma central multimídia automotiva com uma cadeia de infecção específica para esse tipo de dispositivo.
- Atribuímos essa atividade, com alto grau de confiança, ao ator MoYu Group, associado à botnet BADBOX.
As soluções da Kaspersky detectam as ameaças descritas neste relatório com os seguintes veredictos:
- HEUR:Trojan-Dropper.AndroidOS.Agent.vu
- HEUR:Trojan-Downloader.AndroidOS.Agent.ov
- HEUR:Trojan-Proxy.AndroidOS.Zhima.*
- HEUR:Trojan.AndroidOS.Vo1d.*
O que é uma central multimídia?
A central multimídia (head unit) é um sistema que integra recursos de entretenimento a funções de controle veicular. Esses equipamentos podem vir de fábrica ou ser instalados após a compra. Os principais vetores de ataque nesses ecossistemas englobam o acesso físico não autorizado e a exploração de vulnerabilidades no sistema operacional ou em módulos específicos da central, conforme analisado anteriormente.
Em alguns casos, as centrais multimídia são controladas pelo sistema Android, o que ocorre principalmente pela praticidade para os fabricantes, já que o código-fonte original da plataforma já contempla cenários de uso em uma central multimídia automotiva. Além disso, durante o processo de build, o Android permite adicionar aplicativos de sistema próprios, recurso que os fabricantes podem usar para diversas finalidades, como personalização da interface ou inclusão de componentes de sistema conforme as necessidades do fornecedor.
A grande maioria dos aplicativos desenvolvidos para Android também pode ser executada em centrais multimídia baseadas nesse sistema operacional. Isso vale também para aplicativos maliciosos. No entanto, é improvável que a maioria dos malwares voltados a smartphones seja utilizada em ataques contra centrais multimídia. Um exemplo disso são os trojans bancários: o mobile banking costuma ser usado principalmente em smartphones, e infectar centrais multimídia com esse tipo de malware seria um desperdício de recursos para os invasores.
Vale destacar que muitas centrais multimídia possuem suporte a cartão SIM e conectividade à internet, o que permite, por exemplo, o uso de navegação por GPS e a atualização de software. Como esses sistemas geralmente não armazenam informações valiosas para um invasor, um dos cenários de ataque mais prováveis com malwares “clássicos” para Android é a infecção da central para conectá-la a botnets, em uma dinâmica semelhante à observada em ataques contra dispositivos IoT.
Durante nossa pesquisa, encontramos uma ameaça com essas características. A estrutura do firmware das centrais multimídia do fabricante DoFun permitia que invasores distribuíssem malware. Notificamos o fornecedor sobre o mecanismo de distribuição, e a empresa informou que corrigiu as vulnerabilidades.
O esquema completo de infecção é o seguinte:
Esquema de infecção das centrais multimídia
A seguir, mostramos como as centrais multimídia dessa fabricante eram infectadas por malware.
Aplicativo TWCore
O TWCore é um aplicativo de sistema legítimo, responsável por coletar dados analíticos e atualizar o software da central multimídia. Analisemos em detalhe a implementação da função de atualização de software.
O processo de atualização de software é realizado de forma relativamente simples. Um broker de mensagens baseado no protocolo MQTT, hospedado no subdomínio cardoor[.]cn, envia uma mensagem com informações sobre os arquivos APK que devem ser baixados e instalados na central multimídia. Cabe destacar que o objeto que descreve esta mensagem tem um campo installNotExists (uma flag que assume o valor true ou false), o que permite que o TWCore instale aplicativos que não estavam originalmente presentes no dispositivo.
O TWCore verifica a presença do aplicativo no dispositivo somente quando installNotExists = false
O arquivo APK a ser instalado é baixado no diretório <TWCore external cache dir>/push/apk/.
Caminho usado pelo TWCore para baixar o APK
Os dados da nossa telemetria mostram que, nesses caminhos, havia um malware até então desconhecido. Além disso, nossos dados indicam que, em todos os casos, o malware era instalado pelo aplicativo cujo nome de pacote era com.tw.core, o que corresponde ao nome de pacote do TWCore.
Analisaremos, a seguir, o malware instalado pelo TWCore (o dropper JarService).
Estágio 1: dropper JarService
O JarService é um pequeno aplicativo dropper sem interface, como mencionado anteriormente. Ele descriptografa os dados armazenados no código do trojan como blocos criptografados. Cada bloco usa XORing com uma chave de um byte que varia linearmente a cada bloco. Os dados descriptografados contêm informações serializadas sobre a versão do payload, seu ponto de entrada e o próprio código do malware a ser carregado na sequência.
Descriptografia e desserialização das informações do payload do segundo estágio
Na versão analisada do JarService, o ponto de entrada do payload do estágio seguinte era o método wa da classe com.c.j.qbh.
Estágio 2: loader
O payload desse estágio é um loader malicioso. Seu código contém strings criptografadas usadas posteriormente como nomes de classes para executar o payload do terceiro estágio por meio de reflection. O loader envia informações sobre o implante em uma solicitação POST para um dos servidores dos invasores. Exemplo de solicitação ao C2:
|
1 2 3 4 5 6 7 8 9 |
{ "userId": "REDACTED", "dexVersion": "1.7", "dexType": 1, "channelId": "2039", "packageName": "com.tw.jar1", "appVersion": 12, "appName": "JarService" } |
Em resposta à solicitação POST, o servidor de comando e controle retorna um link para o download do payload do terceiro estágio. Um exemplo desta resposta do C2 é apresentado a seguir:
|
1 2 3 4 5 6 7 8 |
{ "code": 200, "data": { "dexUrl": " hxxp://144.217.243[.]201/vr34der34/dex3.68.png", "dexVersion": 3.680, "status": 0 } } |
A partir do link do campo dexUrl no objeto data, o trojan faz o download de dados serializados para o carregamento do próximo estágio. No início desses dados, há um número inteiro de um byte (a chave para descriptografar as strings criptografadas no código do loader). Logo após esse número, há um número de ponto flutuante de quatro bytes, usado para a descriptografia XOR do payload do terceiro estágio, que, por sua vez, vem logo após essas chaves.
Descriptografia do payload do terceiro estágio
No payload descriptografado, o ponto de entrada é o método init da classe com.ast.sdk.BillingMain, apresentado na captura de tela a seguir.
Ponto de entrada do payload do terceiro estágio
Ao analisar esse estágio, notamos que o link para o download do payload continha o número da versão. Após testar outras versões para obter diferentes variantes do payload, encontramos sete versões distintas (a lista consta na seção “Indicadores de comprometimento”). A versão mais antiga era a 3.57, porém ela utiliza um algoritmo de decodificação diferente do descrito acima, o que sugere que, anteriormente, existia outro loader entre o JarService e o payload do terceiro estágio.
Estágio 3: clicker/loader de proxy reverso
No terceiro estágio, o malware envia, por padrão, uma solicitação POST a cada 90 minutos para o caminho /cpc/api/task, com informações sobre o dispositivo infectado (resolução da tela, modelo do dispositivo, SSID da rede Wi-Fi conectada, endereço MAC etc.) e a versão de configuração do trojan. Se a configuração estiver desatualizada, o servidor de comando e controle retorna uma configuração atualizada com novos endereços de C2 e novos caminhos para o envio de solicitações HTTP. Um exemplo desta resposta é apresentado a seguir. Cabe ressaltar que, no momento da pesquisa, a versão de configuração 3.82 era a mais recente.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "code": 100, "data": { "configVersion": 3.820, "hosts": [" hxxp://t2.kshahnd[.]sbs", " hxxp://t2.mdsjhd[.]sbs", " hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"], "interval": 5500000, "reportApi": "/cpc/api/report", "tagName": "config", "taskApi": "/cpc/api/task", "updates": [" hxxp://a2.kshahnd[.]sbs", " hxxp://a2.mdsjhd[.]sbs", " hxxp://a2.nmnsny[.]sbs", " hxxps://a2.nmnsny[.]sbs"], "vn": 1.010 } } |
Se a versão de configuração não precisar de atualização, o servidor de comando e controle retorna identificadores numéricos de comandos, que os invasores chamam de productId. O trojan associa a cada identificador as informações do comando, salvas por meio do mecanismo SharedPreferences em formato de objeto JSON serializado. Além disso, cada identificador tem sua própria versão (um timestamp em formato UNIX time). Se a resposta do C2 contiver um productId desconhecido ou com versão desatualizada, o malware envia uma solicitação GET ao servidor dos invasores no caminho /cpc/api/xml para obter o conteúdo do comando referente a todos esses identificadores. Em resposta, o C2 retorna as informações do comando para cada identificador desconhecido. Um exemplo desta resposta é apresentado a seguir.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "code": 200, "data": [{ "productId": 979, "script": "{\n \"loadType\": 1,\n \"reload\": true,\n \"method\": \"start\",\n \"url2\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md52\": \"de77c3303e93c9450424759f1741441c\",\n \"name\": \"zhima\",\n \"className\": \"com.miyc.transfer.Client\",\n \"thread\": true,\n \"tagName\": \"loadlib2\",\n \"params\": [\n {\n \"type\": \"Context\"\n },\n {\n \"type\": \"String\",\n \"value\": \" 107.151.248[.]132\"\n },\n {\n \"type\": \"String\",\n \"value\": \"1002\"\n },\n {\n \"type\": \"int\",\n \"value\": 1337\n },\n {\n \"type\": \"int\",\n \"value\": 7777\n },\n {\n \"type\": \"int\",\n \"value\": 8888\n },\n {\n \"type\": \"int\",\n \"value\": 15000\n }\n ],\n \"url\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}", "version": 1778650942 }, { "productId": 1019, "script": "{\n \"loadType\": 1,\n \"reload\": true,\n \"method\": \"start\",\n \"url2\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md52\": \"de77c3303e93c9450424759f1741441c\",\n \"name\": \"zhima\",\n \"className\": \"com.miyc.transfer.Client\",\n \"thread\": true,\n \"tagName\": \"loadlib2\",\n \"params\": [\n {\n \"type\": \"Context\"\n },\n {\n \"type\": \"String\",\n \"value\": \" 128.14.210[.]58\"\n },\n {\n \"type\": \"String\",\n \"value\": \"1002\"\n },\n {\n \"type\": \"int\",\n \"value\": 9999\n },\n {\n \"type\": \"int\",\n \"value\": 7777\n },\n {\n \"type\": \"int\",\n \"value\": 8888\n },\n {\n \"type\": \"int\",\n \"value\": 15000\n }\n ],\n \"url\": \" hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}", "version": 1766001509 }, { "productId": 3505, "script": "{\n\"tagName\":\"http\",\n\"url\":\" hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}", "version": 1776656317 }], "msg": "" } |
As informações do comando contêm o campo tagName, que corresponde ao nome do comando. No código, cada nome está associado às respectivas classes de execução.
Lista de comandos para execução
No momento da pesquisa, os invasores haviam implementado nove comandos. Os nomes dos comandos, uma breve descrição e os respectivos argumentos estão apresentados na tabela abaixo. De acordo com a funcionalidade dos comandos implementados, o malware pode ser usado para exibir anúncios, cometer fraude publicitária (funcionalidade de clicker) e fazer download de outros códigos maliciosos.
| Nome do comando | Descrição | Argumentos |
return |
Retorna um valor do SharedPreferences. | key – chave cujo valor deve ser retornado |
copy |
Define o conteúdo da área de transferência. | text – chave cujo valor, salvo no SharedPreferences, é retornado como conteúdo da área de transferênciaurl – link de onde são baixados dados compactados com gzip (opcional). Esses dados são então concatenados ao valor da chave text usando como separador |
http |
Realiza uma solicitação HTTP POST/GET para o recurso especificado e, se indicado, salva a resposta no SharedPreferences na chave especificada. | url – endereço do recursomethod – nome do método HTTP (opcional)startLabel – marcador de início dos dados a serem salvos no recurso (opcional)endLabel – marcador de fim dos dados a serem salvos no recurso (opcional)valueLabel – chave na qual o valor deve ser salvo (opcional)header – dicionário com os cabeçalhos da solicitação HTTP (opcional)content – conteúdo da solicitação POST (opcional) |
web |
Abre um link no WebView e executa nele um código JavaScript arbitrário. | url – link a ser aberto no WebViewjs – código JavaScript codificado em base64 a ser executado no WebView, usado quando o parâmetro url está vazio ou ausentecorejs – código JavaScript a ser executado ao carregar o recurso no WebView (opcional)param – dicionário de strings com os parâmetros para iniciar o WebViewclient – se essa chave estiver presente, o WebViewClient será usado para resolver manualmente o redirecionamentotime – tempo limite (timeout) da tarefa |
loadlib |
Até a publicação deste relatório, o comando não estava totalmente implementado. | – |
loadlib2 |
Baixa e executa código arbitrário. | url – endereço para baixar o payloadname – nome do módulo a ser baixadomd5 – hash MD5 do payloadclear – lista de nomes de payloads a serem removidos, separados por vírgula (opcional)params – array de parâmetros com os quais o payload deve ser executadoclassName – nome da classe do ponto de entrada do payloadmethod – nome do método virtual do ponto de entrada do payloadcmethod – nome do método estático para instanciar a classe do ponto de entrada (opcional)thread – flag: se não estiver definida, o payload é executado em uma thread separadareload – flag que, quando definida, reinicia os módulos já carregados |
loadlib3 |
Até a publicação deste relatório, o comando não estava totalmente implementado. | – |
deeplink |
Abre um recurso usando o navegador. | url – link do recurso |
traceroute |
Verifica a disponibilidade de um recurso usando ICMP ping. | host – recursos a verificar, separados por vírgula |
O payload baixado pelo comando loadlib2 é o módulo de proxy reverso “zhima”, que também foi identificado e descrito por pesquisadores do Nokia Deepfield Emergency Response Team em dispositivos TV box. No entanto, nem todos os comandos são utilizados pelos invasores em ataques reais. Como mostra o exemplo de resposta do C2 apresentado acima, até o momento da publicação deste relatório os invasores usavam apenas os comandos loadlib2 e http. Assim, o objetivo final dos invasores é criar uma botnet de proxy.
Durante a análise dessa etapa da cadeia de ataque, notamos que o link para o download do zhima também tem um número de versão. Da mesma forma que na etapa anterior, testamos outras versões possíveis e encontramos oito variantes do módulo zhima, sendo a mais antiga a versão 57. A lista completa dos módulos zhima identificados consta na seção “Indicadores de comprometimento”.
Atribuição
Ao analisar toda a cadeia de infecção, notamos que o loader do segundo estágio criava uma thread com um nome revelador: mosdk-host-loader. A investigação do significado de mosdk nesse contexto permitiu identificar um aplicativo malicioso com o nome de pacote com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98), instalado em diversas TV boxes. Ele consiste em vários componentes (incluindo um dropper semelhante ao JarService), utilizados pelos invasores para monetizar de forma oculta o poder de processamento do dispositivo. Cada componente malicioso do aplicativo corresponde a um serviço próprio. O serviço que contém o código para executar o dropper semelhante ao JarService chama-se AdmoyuService. Com base nisso e no nome da thread maliciosa no código do payload, presumimos que moyu no nome do serviço faz referência ao MoYu Group, um dos atores associados à plataforma maliciosa BADBOX, descrita por pesquisadores da HUMAN. Essa hipótese também é reforçada pela expressiva sobreposição entre a infraestrutura de rede do malware e a infraestrutura de rede do MoYu Group, identificada de forma independente por pesquisadores do Nokia Deepfield Emergency Response Team. Com base nos padrões de nomenclatura semelhantes e na sobreposição de infraestrutura entre o MoYu Group e a atividade descrita neste relatório, atribuímos, com alto grau de confiança, essa atividade ao mesmo threat actor.
Durante a análise do malware baixado pelo TWCore, notamos que o domínio admin.uipoxy[.]com resolvia para o endereço IP 128.14.210[.]58, um dos servidores de comando e controle do módulo de proxy reverso “zhima”. As evidências indicam que o link hxxp://admin.uipoxy[.]com/proxy/u/login corresponde ao painel de administração do zhima. Esse painel permite que qualquer usuário se cadastre, desde que possua um código de convite.
Página de registro do operador do malware
No momento do cadastro, o usuário também é convidado a ler os termos de uso do serviço e a política de privacidade. Ambos os documentos estão hospedados em links sob o domínio pxyedge[.]com, pertencente ao provedor PXYEDGE, especializado na venda de proxies residenciais (residential proxy).
Também na página de cadastro hospedada no domínio admin.uipoxy[.]com, encontramos a string
copyright © 2020 proxyforu[.]com all rights reserved, que redirecionava ao site hxxps://proxyforu[.]com. Trata-se do site do provedor ProxyForU, que também oferece serviços de proxies residenciais.
Identificamos algumas semelhanças na API de autorização de todos esses sites:
- A página de autorização estava no subdomínio
admin.* - A página de autorização estava no caminho
/proxy/u/login - A página de registro estava no caminho
/proxy/register?channelKey=<invitation code>
Com base nisso, consideramos que os serviços citados estão associados ao MoYu Group.
Conclusão
Apesar dos esforços de especialistas em segurança cibernética e de autoridades policiais para desarticular a botnet BADBOX, threat actors vinculados ao grupo mantêm suas atividades maliciosas, comprometendo dispositivos globalmente. Os vetores de infecção desse tipo de malware podem variar bastante: desde downloads feitos por backdoors pré-instalados no sistema até a instalação de builds comprometidas de aplicativos de IPTV. O caso analisado demonstrou um método ainda mais sofisticado de entrega do malware, por meio da funcionalidade legítima de atualização de software em um aplicativo de sistema. Além disso, os invasores estão explorando ativamente novas plataformas. Esse malware foi o primeiro aplicativo malicioso identificado em centrais multimídia, evidenciando que esse tipo de plataforma também requer soluções de proteção contra malwares.
Indicadores de comprometimento
Estágio 1: JarService
ba27951b4ee1c341f4415d033369ecd3
d63bacd6d6709dd68a10ef9d374c7835
6c2e34b30da42085240ede53ab6107d4
8b5e513144a6138a966ea59e68bf9da2
e119845877089d6f4b0a70dc7388f316
Estágio 2: loader
e9f3a0dab6949ce2cddab9e0aa80ae1a
Estágio 3: loader/clicker
0fbaa7092204f4b1494e0b840b014774
1dcf031c40ce456b6a36a00b0acf3d11
44b6b213a6a3f299eaf88e078de95ecb
67dc78e544ebce16b85dc7c195dfbc58
9642ae619b3165d23c6349002d1abe24
b067d5b0dbecbd6498bcdfba45dba77e
f0e3f7eba2cde91e2dedb921bab47422
Módulo zhima
412e9243f2981bbea3894254d105b3b8
71ab5517f71866279d0d87d37f2ae320
89ef78f716a75964539f2db6520be362
a4223ce4288a230d1e6c3ff2c7639045
bd4d81cd27125ad3d9a114922d468499
c6bfb1643ac7474ed8a7b4f96a187fdb
de77c3303e93c9450424759f1741441c
f8cf8c23ff597700d471fb7767df8bac
Domínios e endereços IP
xmsae[.]sbs
ishano456[.]sbs
xshaon123[.]sbs
kshahnd[.]sbs
mdsjhd[.]sbs
nmnsny[.]sbs
kookjar[.]com
ty54fgd435[.]my
ue886578433[.]online
ty4523[.]space
144.217.243[.]201
107.151.248[.]132
128.14.210[.]58
Endereços de origem a partir dos quais o JarService foi baixado
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk
Hashes do TWCore (software legítimo utilizado na distribuição do JarService)
2a64c3efc11bf224aa54f24e876446c9
7a4d3ba2dacccfdda55859a5dfee2671
ea24487996eb70c1780922fb3063bcc5
O passageiro invisível do seu carro