Malware Midnight Mimosa vem instalado no firmware de celulares Android e chega a mais de 150 países

Um celular comprometido antes da primeira inicialização

Milhares de dispositivos Android em mais de 150 países foram afetados pelo Midnight Mimosa, uma campanha de malware que instala software malicioso no firmware dos celulares antes de os compradores ligarem os aparelhos. A Bitdefender identificou pelo menos 32 aplicativos disfarçados implantados pela operação, além de 13 aplicativos da Google Play que continham o mesmo código de fraude publicitária e se comunicavam com sua infraestrutura de controle.

As descobertas, publicadas em 8 de outubro de 2026 e atualizadas em 9 de outubro, descrevem uma operação observada ao longo de cerca de dois anos. Entre os dispositivos afetados estão celulares baratos com plataformas MediaTek, produtos falsificados que usam nomes de modelos da Apple e da Samsung e aparelhos identificados como Doogee S200 X e Cubot KINGKONG X.

A principal conclusão do relatório técnico da Bitdefender é que a infecção não depende de o comprador baixar um aplicativo suspeito. Um componente malicioso do sistema vem instalado no aparelho, conta com permissões poderosas do sistema operacional e pode instalar outros softwares sem pedir autorização ao proprietário.

Isso torna a ameaça especialmente difícil de remover. Excluir um aplicativo de previsão do tempo ou de bloqueio de apps indesejado pode eliminar uma parte visível da operação, mas deixar intacto o componente que o instalou. Os pesquisadores encontraram cargas maliciosas que apareciam e desapareciam repetidamente nos mesmos dispositivos.

Também há limites para o que a investigação conseguiu determinar. Ela não identificou quem inseriu o malware no firmware. Os pesquisadores encontraram código capaz de encaminhar tráfego por celulares infectados, mas o dispositivo de teste não recebeu nenhuma instrução de encaminhamento. Os operadores tinham acesso a permissões sensíveis, embora os pesquisadores não tenham observado seu uso durante a análise.

O componente oculto que controla as instalações

A investigação começou quando a tecnologia de detecção comportamental da Bitdefender sinalizou o com.android.system.lite. O nome e o rótulo genérico System sugeriam um componente comum do Android, mas suas ações eram diferentes: ele instalava e removia silenciosamente aplicativos sem relação entre si e ativava repetidamente acessos sensíveis.

O componente não tinha ícone visível na tela inicial. Era assinado para a plataforma Android, executava como usuário do sistema e estava configurado para permanecer ativo. Suas permissões incluíam instalar e excluir pacotes, conceder permissões a outros aplicativos e alterar configurações seguras. São poderes muito além dos normalmente disponíveis para um aplicativo baixado pelo proprietário de um celular.

Posteriormente, os pesquisadores encontraram o mesmo núcleo malicioso com outros nomes, incluindo com.android.sys.prot, com.android.sys.gmsprot e com.android.sys.bcprot. Outro pacote relatado por proprietários de celulares, com.android.non.szcz, foi identificado como parte da mesma família. Diferentes versões usavam nomes distintos e, em alguns casos, certificados de assinatura diferentes.

Isso é importante para a detecção e a remoção: o nome de um pacote não define toda a ameaça. Um celular sem o com.android.system.lite ainda pode conter outra versão do mesmo mecanismo. O comportamento compartilhado e o código subjacente são identificadores mais úteis do que o rótulo exibido na lista de aplicativos do Android.

Como o código remoto altera o funcionamento do celular

Grande parte da lógica maliciosa estava escondida em uma biblioteca nativa chamada libeasy.so, em vez de ficar exposta no código comum do aplicativo do sistema. Na inicialização, a biblioteca usava criptografia RC4 para ocultar e depois recuperar um framework incorporado de aproximadamente 142 KB.

Esse framework buscava configurações em um servidor de comando e controle, ou seja, um serviço remoto pelo qual os operadores direcionam dispositivos infectados. Ele podia baixar e carregar arquivos DEX e JAR, formatos usados para empacotar código executável para Android e Java. Isso permitia aos operadores alterar o comportamento do dispositivo depois de vendido.

Os pesquisadores identificaram três famílias de plugins. Uma delas, associada a com.wz.sdk.DxFactory, lidava com impressões e cliques publicitários forjados. As outras, associadas a com.earnsdk.lib.DxFactory e com.gogo.third.lib.DxFactory, permitiam instalar e remover outros aplicativos silenciosamente; a última também incluía funcionalidade de WebView.

Assim, o componente do sistema funcionava como um controlador persistente, e não como uma peça única e fixa de malware publicitário. Remover a carga maliciosa de hoje não impediria que ele baixasse outra amanhã. A combinação de carregamento remoto de código e concessão de permissões privilegiadas também significava que suas atividades potenciais eram mais amplas do que o comportamento registrado durante a investigação.

Disfarces de aplicativos comuns transformam cliques falsos em receita

O principal objetivo aparente da operação era ganhar dinheiro. Os pesquisadores encontraram pelo menos 32 aplicativos distintos disfarçados de utilitários de previsão do tempo, bloqueadores de apps, gerenciadores de arquivos, ferramentas de ícones, ferramentas de reconhecimento de texto e editores de áudio. Alguns ofereciam funcionalidades, enquanto outros não realizavam de forma significativa a tarefa sugerida pelo nome.

Um exemplo, com.mobile.applock.wt, se apresentava como uma ferramenta de bloqueio de aplicativos, mas não tinha a interface nem o código necessários para oferecer essa função. Ficava oculto para o usuário e atuava como mais um instalador de malware, um programa que distribui outros softwares maliciosos. Entre as outras cargas maliciosas identificadas estavam com.dmstudio.weather, com.dl.guard.lock e picturetranslate.extractor.text.lite.

Os aplicativos de fachada traziam kits de desenvolvimento de software, ou SDKs, legítimos para publicidade. Essas ferramentas permitem que um aplicativo exiba anúncios e receba pagamentos por atividade publicitária. Sua presença fornecia ao tráfego fraudulento um aplicativo e um identificador publicitário aos quais a receita podia ser creditada.

Os pesquisadores de segurança da Bitdefender Adrian Mihai Gozob e Alex Baciu descreveram a divisão de funções entre o componente persistente do sistema e os aplicativos de fachada:

O próprio aplicativo do sistema não registra as impressões e os cliques fraudulentos.

O controlador fornecia instruções, horários e interações artificiais, enquanto os identificadores publicitários pertenciam aos aplicativos de fachada. Os aplicativos se comunicavam por serviços compartilhados e enviavam o mesmo identificador de dispositivo para uma infraestrutura que incluía um serviço de controle disfarçado de API de previsão do tempo. Isso conectava utilitários aparentemente distintos em uma única operação publicitária coordenada.

A análise técnica encontrou cliques automáticos sem interação do usuário, alvos de anúncios aleatórios, limites diários e intervalos entre interações forjadas. Também identificou o envio automático de registros de conversão após um cronômetro de 60 segundos. Esses controles podiam dosar a atividade falsa, em vez de gerar um fluxo ininterrupto de eventos idênticos.

A Google Play é alvo de evasão e também canal de distribuição

Antes de instalar uma carga maliciosa, o malware desativava temporariamente o com.android.vending, o aplicativo da Google Play Store. Depois, restaurava o aplicativo e incluía uma proteção para reativá-lo quando o usuário estivesse presente. A Bitdefender avaliou que isso provavelmente era uma tentativa de evitar a detecção pelo Play Protect, e não uma prova de que todas as instalações escaparam da verificação.

Algumas variantes também manipulavam os registros de instalação do Android para fazer parecer que os softwares instalados pelo malware vinham da Google Play. Esse disfarce podia fazer um aplicativo desconhecido parecer menos suspeito quando o proprietário verificasse sua origem.

A estrutura publicitária usava recursos que incluíam atividades abertas sem solicitação do usuário e sobreposições exibidas sobre outros aplicativos. Um dos recursos publicitários foi marcado como seguro, o que impedia sua aparição em capturas de tela ou gravações de tela. O relatório descreve tanto atividade publicitária oculta quanto exibições intrusivas; portanto, não se deve entender que a operação era exclusivamente invisível.

A Google Play também era um canal de distribuição independente. Os pesquisadores identificaram 13 aplicativos publicados que continham o mesmo código de fraude publicitária e se comunicavam com a infraestrutura do Midnight Mimosa. Eles usavam 13 certificados de assinatura distintos e pelo menos duas contas de desenvolvedor, chamadas fivedev e CPS Developer.

Esses aplicativos da loja não tinham os privilégios elevados dos componentes do sistema pré-instalados. A diferença é significativa: baixá-los não lhes dava automaticamente os mesmos poderes de instalação silenciosa de um componente de firmware comprometido. Ainda assim, eles podiam exibir anúncios fora da própria interface, inclusive quando o proprietário não estava usando o celular ativamente.

Pelo menos alguns aplicativos associados ainda estavam disponíveis quando as descobertas foram divulgadas, e o Google não havia respondido imediatamente a um pedido de comentário. Não há aqui um prazo confirmado para sua remoção. As descobertas na Play mostram que a exposição não se restringia a aparelhos falsificados ou a celulares já comprometidos durante a fabricação.

Foi observado o registro em proxy, mas não o encaminhamento ativo

Outra carga maliciosa, com.mobile.applock.en, continha um componente de proxy TCP. Um proxy encaminha o tráfego de internet em nome de terceiros. Quando a conexão pertence a um proprietário comum de celular, esse tráfego pode parecer vir do endereço de internet do proprietário, e não de quem realmente o direciona.

O componente registrava dispositivos em um servidor remoto e podia receber instruções para se conectar a destinos especificados e encaminhar tráfego. Esses recursos poderiam sustentar uma rede de dispositivos controlados remotamente, ou botnet, e criar outra fonte de receita por meio da venda de acesso a essas conexões.

A Bitdefender confirmou que a infraestrutura de proxy aceitou o registro do dispositivo de teste. No entanto, o dispositivo não recebeu destinos de retransmissão durante os testes. Portanto, a investigação demonstrou a capacidade de registro e encaminhamento, não o encaminhamento ativo nesse teste.

A mesma cautela se aplica a ataques de negação de serviço distribuído, que sobrecarregam um alvo com tráfego de muitos dispositivos. Os pesquisadores descreveram a participação em botnets e ataques desse tipo como usos potenciais. As descobertas não comprovam que celulares infectados pelo Midnight Mimosa tenham realizado um ataque específico nem identificam clientes que compraram acesso às conexões.

Quais dispositivos e países apareceram nas descobertas?

México, França e Itália lideraram a distribuição geográfica, seguidos por Estados Unidos, Alemanha, Brasil e Espanha. Os totais abrangeram milhares de dispositivos únicos ao longo de cerca de dois anos, mas nenhum número exato para a campanha foi divulgado. São detecções, não um levantamento de todos os celulares infectados vendidos.

Mais de 11% dos dispositivos comprometidos identificavam-se como KINGKONG X, nome de modelo associado à Cubot, enquanto mais de 4% identificavam-se como S200 X, associado à Doogee. Juntos, esses dois grupos de modelos representavam mais de 15% das detecções. O Cubot Kingkong 9 também foi identificado em reportagens sobre a investigação.

As 15 principais marcas de celulares representavam 35,8% dos dispositivos infectados. Aproximadamente 64% foram agrupados como outros, um valor arredondado informado no relatório. A distribuição sugere um mercado afetado fragmentado, e não uma operação restrita a uma única marca reconhecível.

Entre as identificações de modelos falsificadas estavam i17 Pro Max, i16_Pro_Max, 17_Pro_Max, S25 Ultra, S24 Ultra e Note 18 Ultra. Também apareceu o nome de tablet iPadAirPro. Essas identificações foram informadas por aparelhos Android baratos e não devem ser confundidas com evidências de que produtos genuínos da Apple ou da Samsung continham o malware.

Identificadores de modelo, por si sós, são evidências imperfeitas porque o software pode representar incorretamente a identidade de um dispositivo. A detecção em determinados modelos também não comprova que todas as unidades vendidas com esses nomes foram infectadas. As descobertas técnicas dizem respeito a dispositivos afetados e versões de firmware, não a todos os produtos MediaTek nem a todos os celulares das marcas citadas.

Certificados de firmware não comprovam responsabilidade

Parte do firmware afetado foi assinada com certificados que traziam o nome Shenzhen Zediel. Essa evidência de assinatura é importante porque vincula o componente malicioso a um firmware considerado confiável pelo dispositivo. Por si só, porém, ela não comprova quem inseriu o malware nem se o titular do certificado sabia que ele estava presente.

Gozob e Baciu limitaram explicitamente o que a investigação conseguia determinar sobre essa atribuição:

Só podemos confirmar que certificados com o nome Shenzhen Zediel foram usados para assinar o firmware de dispositivos afetados.

Reportagens descreveram de maneiras diferentes a empresa por trás desse nome, inclusive como fabricante de dispositivos Android e como aparentemente ligada a uma desenvolvedora de placas-mãe. Essas descrições não esclarecem a responsabilidade. A Bitdefender também encontrou celulares afetados sem certificados de firmware identificados como Zediel, o que faz dessa identidade de assinatura uma explicação incompleta e não um indicador universal.

Os possíveis pontos de inserção incluíam um fabricante de projeto original, um integrador de firmware, um parceiro de logística ou outro agente da distribuição. O relatório não apontou nenhum deles. A conclusão confirmada foi que o malware chegou ao firmware antes da venda dos celulares afetados.

Relatos de proprietários mostram por que excluir aplicativos não basta

Proprietários de celulares Cubot e Doogee relataram que aplicativos suspeitos eram reinstalados após a remoção. Um proprietário de um Doogee Fire 3 Max afirmou que uma atualização oficial de firmware introduziu a infecção, que a volta a uma versão anterior removeu o malware e que a reinstalação da atualização o trouxe de volta. São relatos de usuários, não um histórico confirmado de forma independente para todas as versões de firmware afetadas.

Alguns proprietários disseram que atualizações posteriores dos fabricantes resolveram as infecções. Os fabricantes não haviam explicado publicamente como o código malicioso entrou no firmware afetado. Em conjunto, os relatos reforçam que as versões de firmware devem ser consideradas parte essencial da investigação e do reparo, em vez de se presumir que excluir um aplicativo baixado resolve o problema.

A sequência principal estabelecida pela investigação e por reportagens posteriores é:

• Ao longo de cerca de dois anos, a Bitdefender observou milhares de dispositivos afetados em mais de 150 países.
• Em 8 de outubro de 2026, a Bitdefender publicou sua investigação sobre o Midnight Mimosa.
• Em 9 de outubro de 2026, o relatório técnico foi atualizado.
• Nas reportagens publicadas até 12 de outubro, os aplicativos associados na Google Play e a responsabilidade pelo firmware afetado continuavam sendo questões sem solução.

A Bitdefender afirma que a remoção exige corrigir o firmware ou desativar o componente malicioso por meio do Android Debug Bridge, geralmente chamado de ADB. O ADB é uma ferramenta que permite a um computador se comunicar com um dispositivo Android para tarefas de depuração e administração. Desativar um componente não é o mesmo que substituir o firmware comprometido por uma versão comprovadamente limpa.

Não foi estabelecido nenhum comando universal de remoção nem uma lista confirmada de firmwares limpos. Os proprietários devem buscar uma solução comprovada ou a substituição do aparelho com o vendedor ou fabricante, em vez de presumir que uma atualização é segura apenas por ser identificada como oficial. Enquanto a situação não for esclarecida, é prudente evitar operações bancárias, autenticações de contas sensíveis e o armazenamento de informações importantes em um dispositivo sabidamente afetado.

A preocupação inclui acessos sensíveis que os pesquisadores não observaram sendo usados. As permissões de Acessibilidade e Acesso às notificações foram concedidas e revogadas repetidamente, e havia permissões de SMS. Se ativados por código fornecido remotamente, esses recursos poderiam expor o conteúdo da tela, notificações ou mensagens de verificação. Esse é um risco demonstrado, não uma prova de que o Midnight Mimosa tenha roubado esses itens durante a análise.

Principais pontos

• O Midnight Mimosa foi encontrado integrado ao firmware do Android antes de os dispositivos afetados chegarem aos compradores.
• A Bitdefender observou milhares de dispositivos afetados em mais de 150 países ao longo de cerca de dois anos.
• A operação implantou pelo menos 32 aplicativos disfarçados; 13 aplicativos da Google Play compartilhavam seu código e sua infraestrutura de fraude publicitária.
• Os privilégios de sistema permitiam instalações silenciosas, concessão de permissões e carregamento remoto de código.
• O registro em proxy foi confirmado, mas não se observou encaminhamento ativo de tráfego no dispositivo de teste.
• Os certificados de assinatura do firmware não comprovaram quem inseriu o malware nem se seus titulares estavam envolvidos.
• Remover apenas os aplicativos de fachada não elimina o componente persistente. A remoção exige uma ação no firmware ou a desativação desse componente.