Malware infecta firmware de central multimídia Android em carros pela primeira vez

Pesquisadores da Kaspersky documentaram, em relatório publicado em 21 de agosto de 2026 no Securelist, o que descrevem como o primeiro caso registrado de malware em uma central multimídia automotiva com uma cadeia de infecção específica para esse tipo de dispositivo. O ponto de entrada não foi acesso físico nem uma vulnerabilidade explorada de fora: o código malicioso chegou pelo próprio atualizador embutido no firmware de head units da marca DoFun.

O alvo final da campanha, segundo a análise, é fraude de anúncios (ad fraud) e a criação de uma botnet de proxy reverso. A empresa atribui a atividade, com alta confiança, ao MoYu Group, ator ligado à botnet BADBOX.

O que é uma head unit e por que ela vira alvo

Uma head unit é o sistema que combina funções multimídia com controle parcial de funções do veículo. Ela pode vir de fábrica ou ser instalada como upgrade aftermarket. Boa parte desses sistemas roda Android↳Android46 conteúdosAndroid push notifications com Quasar Framework, Firebase e integração com WordPressDev (Back & Front) · mai 2019O X do Xamarin Forms – O guia das funcionalidades nativas - Parte 02: AndroidDev (Back & Front) · abr 2019Modularização de AndroidDev (Back & Front) · ago 2019Ver tudo em Dev (Back & Front) →, porque o código-fonte da plataforma já contempla casos de uso automotivos e permite que fabricantes adicionem aplicativos de sistema durante o build.

O detalhe que interessa a quem trabalha com embarcados: quase todo app feito para Android roda também numa head unit, e isso vale para malware. A diferença é que uma central de carro raramente guarda algo de valor direto (não faz sentido, por exemplo, plantar um trojan bancário ali). O cenário lógico de ataque é outro: infectar o dispositivo para recrutá-lo numa botnet, exatamente como se faz com equipamentos de IoT. Head units costumam ter slot de SIM e conexão à internet para navegação e atualização, o que as torna nós de rede convenientes.

Como o firmware distribuiu o malware

O vetor foi o TWCore, um app de sistema legítimo (pacote com.tw.core) responsável por coletar analytics e atualizar o software da central. O mecanismo de update funciona via um broker MQTT hospedado no subdomínio cardoor[.]cn, que envia mensagens descrevendo quais APKs baixar e instalar.

O problema está num campo booleano dessa mensagem: installNotExists. Quando definido como true, ele permite ao TWCore instalar apps que nem estavam presentes no dispositivo sem checar nada. O APK é baixado para /push/apk/. A telemetria da Kaspersky encontrou malware inédito exatamente nesse caminho, e em todos os casos observados a instalação partiu de um app com o pacote do TWCore. A Kaspersky notificou o fabricante, que informou ter corrigido as falhas.

Uma cadeia de três estágios

O que chamou atenção dos pesquisadores foi um app que se instala como qualquer outro, mas sem nenhuma interface e sem tentar se disfarçar de software legítimo, sinal de que chega ao usuário sem que ele saiba.

• Estágio 1, o dropper JarService: um app minúsculo, sem UI, que decifra blocos embutidos no próprio código. Cada bloco usa XOR com chave de um byte que muda linearmente de bloco em bloco. Os dados decifrados descrevem versão e ponto de entrada do próximo payload.
• Estágio 2, o loader: envia informações do implante para o C2 via POST (com campos como userId, dexVersion, packageName e appName). O servidor responde com um dexUrl apontando para o payload seguinte, disfarçado de imagem .png. Testando números de versão na URL, os pesquisadores obtiveram sete variantes distintas.
• Estágio 3, clicker / carregador de proxy reverso: envia um POST para /cpc/api/task a cada 90 minutos por padrão, com resolução de tela, modelo do dispositivo, SSID da rede Wi-Fi e endereço MAC. O C2 devolve tanto configurações atualizadas (novos endereços e caminhos) quanto identificadores de comando que os atacantes chamam de productId.

O arsenal de comandos e a botnet zhima

No momento da pesquisa, o estágio 3 tinha nove comandos implementados, entre eles http (requisições GET/POST), web (abrir link em WebView e executar JavaScript arbitrário), deeplink, traceroute e loadlib2 (baixar e executar código arbitrário). Isso confere ao malware capacidade de exibir anúncios, cometer fraude de cliques e baixar código adicional.

Na prática, porém, os atacantes usavam só um subconjunto: essencialmente http e loadlib2. O payload entregue pelo loadlib2 é um módulo de proxy reverso chamado zhima (classe com.miyc.transfer.Client), que a equipe de resposta a emergências da Nokia Deepfield identificou de forma independente em set-top boxes de TV na mesma época. A convergência dos dois achados confirma o objetivo final: construir uma botnet de proxy, com o carro infectado atuando como saída de tráfego para terceiros.

O que isso muda para quem constrói embarcados no Brasil

O caso não é sobre um carro específico, e sim sobre uma classe de risco que atinge diretamente quem desenvolve para dispositivos Android fora do smartphone: TV boxes, centrais automotivas, painéis, quiosques. O elo fraco aqui foi um mecanismo de atualização OTA mal desenhado, capaz de instalar qualquer APK silenciosamente por causa de uma flag booleana sem validação de origem ou assinatura.

Para equipes que mantêm firmware ou apps de sistema, os pontos concretos a revisar:

• Nunca confiar em canal de update sem validação forte: verificação de assinatura do pacote e do próprio servidor, não apenas transporte. Vários endpoints da campanha usavam http puro.
• Cuidado com flags que permitem instalar apps ausentes: um installNotExists=true sem controle é uma porta aberta.
• Dispositivos IoT/embarcados são recrutáveis mesmo sem dado valioso local: o valor para o atacante é a conectividade e o IP, não o conteúdo.

O mercado brasileiro de centrais aftermarket é grande e depende fortemente de firmware importado com pouca visibilidade sobre a cadeia de build. Ficam em aberto quantos dispositivos foram afetados globalmente e se o modelo específico chegou ao país, mas os indicadores de comprometimento (hashes, domínios e IPs como 144.217.243[.]201) estão publicados no relatório da Kaspersky para quem quiser cruzar com seus próprios logs.

Fonte: Hacker News