Malware Midnight Mimosa chega instalado no firmware de telemóveis Android e alcança mais de 150 países

Um telemóvel comprometido antes da primeira ligaçã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 telemóveis antes de os compradores os ligarem pela primeira vez. A Bitdefender identificou pelo menos 32 aplicações dissimuladas utilizadas pela operação, além de 13 aplicações da Google Play que continham o mesmo código de fraude publicitária e comunicavam com a sua infraestrutura de controlo.

As conclusões, publicadas a 8 de outubro de 2026 e atualizadas a 9 de outubro, descrevem uma operação observada ao longo de cerca de dois anos. Entre os dispositivos afetados encontram-se telemóveis baratos com plataformas MediaTek, produtos contrafeitos que usavam nomes de modelos da Apple e da Samsung e dispositivos que se identificavam como Doogee S200 X e Cubot KINGKONG X.

A principal conclusão do relatório técnico da Bitdefender é que a infeção não depende de o comprador descarregar uma aplicação suspeita. Um componente malicioso do sistema vem instalado no dispositivo, dispõe de permissões poderosas no sistema operativo e pode instalar software adicional sem pedir autorização ao proprietário.

Esta característica torna a ameaça particularmente difícil de remover. Apagar uma aplicação de meteorologia indesejada ou um bloqueador de aplicações pode eliminar uma parte visível da operação, deixando intacto o componente que a instalou. Os investigadores encontraram cargas maliciosas que apareciam e desapareciam repetidamente nos mesmos dispositivos.

Há também limites para o que a investigação conseguiu apurar. Não identificou quem inseriu o malware no firmware. Os investigadores encontraram código capaz de encaminhar tráfego através de telemóveis infetados, mas o dispositivo de teste não recebeu instruções de encaminhamento. Os operadores dispunham de permissões sensíveis, embora os investigadores não tenham observado a sua utilização durante a análise.

O componente oculto que controla as instalações

A investigação começou quando a tecnologia de deteção comportamental da Bitdefender assinalou o com.android.system.lite. O nome e a designação genérica System sugeriam um componente Android normal, mas o seu comportamento era diferente: instalava e removia aplicações sem relação entre si, sem avisar o utilizador, e ativava repetidamente acessos sensíveis.

O componente não tinha um ícone visível no ecrã inicial. Estava assinado para a plataforma Android, era executado como utilizador do sistema e estava configurado para persistir. As suas permissões incluíam a instalação e remoção de pacotes, a concessão de permissões a outras aplicações e a alteração de definições seguras. São poderes muito superiores aos normalmente disponíveis para uma aplicação descarregada pelo proprietário do telemóvel.

Os investigadores encontraram posteriormente o mesmo núcleo malicioso com outros nomes, incluindo com.android.sys.prot, com.android.sys.gmsprot e com.android.sys.bcprot. Outro pacote mencionado por proprietários de telemóveis, com.android.non.szcz, foi identificado como pertencendo à mesma família. Diferentes versões usavam nomes distintos e, em alguns casos, certificados de assinatura diferentes.

Este aspeto é relevante para a deteção e remoção: um único nome de pacote não define toda a ameaça. Um telemóvel sem com.android.system.lite pode ainda conter outra versão do mesmo mecanismo. O comportamento comum e o código subjacente são indicadores mais úteis do que o nome apresentado na lista de aplicações do Android.

Como o código remoto altera o comportamento do telemóvel

Grande parte da lógica maliciosa estava oculta numa biblioteca nativa chamada libeasy.so, em vez de estar exposta no código normal da aplicação do sistema. Na inicialização, a biblioteca usava encriptação RC4 para ocultar e, em seguida, recuperar uma estrutura incorporada com cerca de 142 KB.

Essa estrutura obtinha configurações de um servidor de comando e controlo, ou seja, um serviço remoto através do qual os operadores dirigem os dispositivos infetados. Podia descarregar e carregar ficheiros DEX e JAR, formatos usados para empacotar código executável para Android e Java. Isto permitia aos operadores alterar o comportamento do dispositivo depois de este ter sido vendido.

Os investigadores identificaram três famílias de módulos. Uma, associada a com.wz.sdk.DxFactory, tratava de impressões e cliques publicitários falsos. As outras, associadas a com.earnsdk.lib.DxFactory e com.gogo.third.lib.DxFactory, permitiam instalar e remover silenciosamente outras aplicações, e a última incluía também funcionalidade 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 o componente de descarregar outra amanhã. A combinação do carregamento de código remoto com a concessão de permissões privilegiadas significava também que as suas capacidades potenciais iam além do comportamento observado durante a investigação.

Disfarçadas de aplicações comuns, transformavam cliques falsos em receitas

O objetivo aparente da operação era gerar receitas. Os investigadores encontraram pelo menos 32 aplicações maliciosas distintas, disfarçadas de utilitários de meteorologia, bloqueadores de aplicações, gestores de ficheiros, ferramentas de ícones, aplicações de reconhecimento de texto e editores de áudio. Algumas ofereciam funcionalidades; outras não executavam de forma significativa a tarefa sugerida pelo nome.

Um exemplo, com.mobile.applock.wt, apresentava-se como uma ferramenta para bloquear aplicações, mas não tinha a interface nem o código necessários para o fazer. Ficava oculto do utilizador e funcionava como mais um instalador de malware, isto é, um programa que distribui software malicioso adicional. Entre outras cargas identificadas estavam com.dmstudio.weather, com.dl.guard.lock e picturetranslate.extractor.text.lite.

As aplicações de disfarce incluíam kits de desenvolvimento de software (SDK) legítimos para publicidade. São ferramentas que permitem a uma aplicação apresentar anúncios e receber pagamentos pela atividade publicitária. A sua presença dava ao tráfego fraudulento um identificador de aplicação e de publicidade ao qual as receitas podiam ser atribuídas.

Os investigadores de segurança da Bitdefender Adrian Mihai Gozob e Alex Baciu descreveram a divisão de tarefas entre o componente persistente do sistema e as aplicações de disfarce:

A própria aplicação do sistema não regista as impressões e os cliques fraudulentos.

O controlador fornecia instruções, temporização e interações artificiais, enquanto os identificadores de publicidade pertenciam às aplicações de disfarce. As aplicações comunicavam através de serviços partilhados e transmitiam o mesmo identificador de dispositivo à infraestrutura, que incluía um serviço de controlo disfarçado de API de meteorologia. Isto ligava utilitários aparentemente distintos numa única operação publicitária coordenada.

A análise técnica detetou cliques automáticos sem intervenção do utilizador, alvos publicitários aleatórios, limites diários e intervalos entre interações fabricadas. Identificou também o registo automático de conversões após um temporizador de 60 segundos. Estes controlos permitiam dosear a atividade falsa, em vez de gerar um fluxo ininterrupto de eventos idênticos.

A Google Play é simultaneamente um alvo de evasão e um canal de distribuição

Antes de instalar uma carga maliciosa, o malware desativava temporariamente o com.android.vending, a aplicação da Google Play Store. Depois, reativava-a e incluía uma salvaguarda para o fazer quando o utilizador estava presente. A Bitdefender considerou que se tratava provavelmente de uma tentativa de evitar a deteção do Play Protect, e não de prova de que todas as instalações escaparam à análise.

Algumas variantes também manipulavam os registos de instalação do Android para fazer parecer que o software instalado pelo malware vinha da Google Play. Esse disfarce podia fazer com que uma aplicação desconhecida parecesse menos suspeita quando o proprietário verificava a sua origem.

O mecanismo publicitário recorria a superfícies que incluíam atividades abertas sem solicitação do utilizador e sobreposições colocadas sobre outras aplicações. Uma das superfícies publicitárias estava assinalada como segura, impedindo que aparecesse em capturas de ecrã ou gravações de ecrã. O relatório descreve tanto atividade publicitária oculta como anúncios intrusivos; por isso, a operação não deve ser entendida como exclusivamente invisível.

A Google Play era também um canal de distribuição independente. Os investigadores identificaram 13 aplicações publicadas que continham o mesmo código de fraude publicitária e comunicavam com a infraestrutura do Midnight Mimosa. Usavam 13 certificados de assinatura distintos e pelo menos duas contas de programador, com os nomes fivedev e CPS Developer.

Estas aplicações da loja não tinham os privilégios elevados dos componentes de sistema pré-instalados. A diferença é substancial: descarregar uma delas não lhe concedia automaticamente os mesmos poderes de instalação silenciosa que um componente de firmware comprometido. Ainda assim, podiam apresentar anúncios fora da própria interface, incluindo quando o proprietário não estava a usar ativamente o telemóvel.

Segundo as notícias sobre o caso, pelo menos algumas aplicações associadas continuavam disponíveis na altura; a Google ainda não tinha respondido de imediato a um pedido de comentário. Não foi estabelecido qualquer calendário confirmado para a sua remoção. As conclusões sobre a Play mostram que a exposição não se limitava a hardware contrafeito ou a telemóveis já comprometidos de fábrica.

Foi observada a inscrição em redes proxy, mas não o encaminhamento de tráfego

Outra carga maliciosa, com.mobile.applock.en, incluía um componente de proxy TCP. Um proxy encaminha o tráfego da Internet em nome de terceiros. Quando a ligação pertence a um utilizador comum, esse tráfego pode parecer ter origem no endereço de Internet do utilizador, em vez de na entidade que o está realmente a dirigir.

O componente registava dispositivos num servidor remoto e podia receber instruções para se ligar a destinos específicos e encaminhar tráfego. Estas capacidades poderiam permitir criar uma rede de dispositivos controlados remotamente, ou botnet, e gerar outra fonte de receitas através da venda de acesso a essas ligações.

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

O mesmo cuidado se aplica aos ataques distribuídos de negação de serviço, que sobrecarregam um alvo com tráfego proveniente de muitos dispositivos. Os investigadores referiram a participação numa botnet e este tipo de ataques como utilizações possíveis. As conclusões não demonstram que os telemóveis com Midnight Mimosa tenham realizado um ataque específico, nem identificam clientes que tenham comprado acesso às suas ligações.

Que dispositivos e países surgem nas conclusões?

O México, a França e a Itália lideravam a distribuição geográfica, seguidos pelos Estados Unidos, pela Alemanha, pelo Brasil e por Espanha. Os totais abrangiam milhares de dispositivos únicos ao longo de cerca de dois anos, mas não foi indicado um total exato da campanha. São deteções, não um recenseamento de todos os telemóveis infetados vendidos.

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

As 15 principais marcas de telemóveis representavam 35,8% dos dispositivos infetados. Cerca de 64% foram agrupados na categoria «outros», um valor arredondado referido no relatório. A distribuição sugere um mercado afetado fragmentado, em vez de uma operação limitada a uma única marca reconhecível.

Entre as designações de modelos contrafeitos estavam i17 Pro Max, i16_Pro_Max, 17_Pro_Max, S25 Ultra, S24 Ultra e Note 18 Ultra. Também surgiu o nome de modelo de tablet iPadAirPro. Estas designações foram comunicadas por dispositivos Android baratos e não devem ser confundidas com provas de que produtos genuínos da Apple ou da Samsung continham o malware.

Os identificadores de modelo são, por si só, provas imperfeitas, porque o software pode apresentar uma identidade falsa para o dispositivo. A deteção em determinados modelos também não demonstra que todas as unidades vendidas com esses nomes estivessem infetadas. As conclusões técnicas dizem respeito a dispositivos e versões de firmware afetados, não a todos os produtos MediaTek nem a todos os telemóveis das marcas referidas.

Os certificados de firmware não provam quem é responsável

Parte do firmware afetado estava assinado com certificados que tinham o nome Shenzhen Zediel. Esta evidência de assinatura é importante porque associa o componente malicioso a firmware em que o dispositivo confia. Por si só, não prova quem inseriu o malware nem se o titular do certificado sabia que este estava presente.

Gozob e Baciu limitaram explicitamente aquilo que a investigação podia concluir sobre essa atribuição de responsabilidades:

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

As notícias descreveram de formas diferentes a empresa por detrás do nome, incluindo como fabricante de dispositivos Android e como aparentemente ligada a um fabricante de placas-mãe. Essas descrições não esclarecem quem é responsável. A Bitdefender também encontrou telemóveis afetados sem certificados de firmware com o nome Zediel, pelo que essa identidade de assinatura não constitui uma explicação completa nem um indicador universal.

Os possíveis pontos de inserção incluem um fabricante original de equipamento, um integrador de firmware, um parceiro logístico ou outro interveniente na distribuição. O relatório não apontou nenhum em particular. A conclusão confirmada foi que o malware chegou no firmware antes de os telemóveis afetados serem vendidos.

Os relatos dos proprietários mostram por que não basta apagar as aplicações

Proprietários de telemóveis Cubot e Doogee descreveram aplicações suspeitas que voltavam a instalar-se após serem removidas. Um proprietário de um Doogee Fire 3 Max afirmou que uma atualização oficial de firmware introduziu a infeção, que regressar a uma versão anterior a removeu e que reinstalar a atualização a trouxe de volta. São relatos de utilizadores, não um histórico estabelecido de forma independente para todas as versões de firmware afetadas.

Alguns proprietários afirmaram que atualizações posteriores dos fabricantes resolveram as infeções. Os fabricantes não explicaram publicamente como o código malicioso entrou no firmware afetado. Em conjunto, estes relatos sustentam que as versões de firmware devem ser consideradas essenciais na investigação e na reparação, em vez de se presumir que apagar uma aplicação descarregada resolve o problema.

A sequência principal estabelecida pela investigação e por notícias posteriores é a seguinte:

• Ao longo de cerca de dois anos, a Bitdefender observou milhares de dispositivos afetados em mais de 150 países.
• A 8 de outubro de 2026, a Bitdefender publicou a sua investigação sobre o Midnight Mimosa.
• A 9 de outubro de 2026, o relatório técnico foi atualizado.
• Nas notícias publicadas a 12 de outubro, as aplicações associadas na Google Play e a responsabilidade pelo firmware afetado continuavam por esclarecer.

A Bitdefender afirma que a remoção exige intervir no firmware ou desativar o componente malicioso através do Android Debug Bridge, geralmente designado ADB. O ADB é uma ferramenta que permite a um computador 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 um comando de remoção universal nem uma lista confirmada de firmware limpo. Os proprietários devem procurar uma solução comprovada ou a substituição do dispositivo junto do vendedor ou do fabricante, em vez de presumirem que uma atualização é segura apenas por ser designada oficial. Enquanto a situação não estiver esclarecida, é prudente evitar usar um dispositivo sabidamente afetado para operações bancárias, autenticação de contas sensíveis ou armazenamento de informações importantes.

A preocupação inclui acessos sensíveis que os investigadores não observaram serem utilizados. As permissões de acessibilidade e de acesso às notificações eram concedidas e revogadas repetidamente, e estavam disponíveis permissões para SMS. Se código fornecido remotamente as ativasse, estas capacidades poderiam expor o conteúdo do ecrã, as notificações ou as mensagens de verificação. Trata-se de um risco demonstrado, não de prova de que o Midnight Mimosa tenha roubado esses elementos durante a análise.

Principais conclusões

• O Midnight Mimosa foi encontrado incorporado no firmware Android antes de os dispositivos afetados chegarem aos compradores.
• Ao longo de cerca de dois anos, a Bitdefender observou milhares de dispositivos afetados em mais de 150 países.
• A operação distribuiu pelo menos 32 aplicações maliciosas disfarçadas; 13 aplicações da Google Play partilhavam o seu código e a sua infraestrutura de fraude publicitária.
• Os privilégios de sistema permitiam instalações silenciosas, concessão de permissões e carregamento de código remoto.
• Foi confirmada a inscrição em redes proxy, mas não se observou encaminhamento ativo de tráfego no dispositivo de teste.
• Os certificados de assinatura do firmware não permitiram estabelecer quem inseriu o malware nem se os seus titulares estavam envolvidos.
• Apagar apenas as aplicações de disfarce não remove o componente persistente. A remoção exige intervir no firmware ou desativar esse componente.