Tablets Android já estão chegando às mãos dos usuários com uma porta dos fundos embutida diretamente no sistema. A ameaça, batizada de Keenadu, é considerada uma das campanhas mais avançadas já vistas em dispositivos móveis justamente porque não depende da instalação de apps suspeitos: o código malicioso vem incluído no próprio firmware e, em alguns casos, é distribuído por meio de atualizações OTA (Over-The-Air) assinadas digitalmente e, portanto, aparentemente legítimas.
A análise realizada por pesquisadores de segurança identificou o Keenadu em firmwares de diferentes fabricantes, incluindo o modelo Alldocube iPlay 50 mini Pro. Há registros de dispositivos infectados ao menos desde agosto de 2023. Em todas as amostras examinadas, o firmware comprometido estava corretamente assinado, como se fosse uma atualização oficial do sistema. Esse detalhe torna o cenário extremamente preocupante, pois quebra a confiança do usuário no mecanismo de atualização, que deveria ser um dos pilares de segurança na plataforma Android.
O ponto crítico é que a contaminação não ocorre depois da compra, mas sim na própria cadeia de produção. O backdoor é inserido durante o processo de build do firmware, muito antes de o aparelho sair da fábrica. Em algumas situações, o pacote malicioso também foi distribuído mais tarde, via atualização OTA genuína, vinda dos servidores responsáveis pelas atualizações do dispositivo. Ou seja, mesmo quem comprou o tablet “limpo” poderia ser infectado mais adiante, apenas ao aceitar uma atualização do sistema.
Tecnicamente, o Keenadu é integrado a um componente central do Android: a biblioteca libandroid_runtime.so. Essa biblioteca é carregada logo na inicialização do sistema operacional, o que garante que o malware seja executado desde o boot. Em seguida, o código malicioso é injetado no processo Zygote, responsável por criar praticamente todos os aplicativos que rodam no Android. Como consequência direta, cada app iniciado acaba carregando uma cópia do backdoor na sua própria memória.
Na prática, isso significa que o Keenadu passa a operar dentro do contexto de todos os aplicativos instalados. O isolamento entre apps – um dos principais mecanismos de segurança do Android, conhecido como sandboxing – torna‑se ineficaz, porque o malware está “por dentro” do próprio processo. O resultado é um nível de acesso e persistência que raramente é visto em ameaças para dispositivos móveis.
O Keenadu foi desenvolvido como um carregador (loader) em múltiplos estágios, com duas peças principais: o módulo AKServer e o módulo AKClient. O AKServer atua como o núcleo da operação, concentrando a lógica de comunicação com o servidor de comando e controle (C2), recebendo instruções e distribuindo tarefas maliciosas. Já o AKClient é injetado em cada aplicativo iniciado no sistema, funcionando como um “agente” local que intermedeia a interação entre aquele app e o módulo principal.
Esse desenho modular e distribuído permite à botnet entregar payloads específicos para determinados aplicativos ou cenários. O malware consegue, por exemplo, conceder ou remover permissões de forma arbitrária, coletar a localização do dispositivo, monitorar atividades do usuário e extrair dados sensíveis. Como o backdoor roda com privilégios altos e está profundamente embutido no sistema, há poucas barreiras técnicas que limitem o que ele pode fazer.
Para aumentar ainda mais a furtividade, o Keenadu traz uma série de mecanismos de evasão. Se o idioma configurado no sistema for chinês e o fuso horário estiver ajustado para a China, o malware interrompe sua execução automaticamente, provavelmente para evitar atenção de autoridades locais. Ele também deixa de operar quando detecta a ausência da Google Play ou dos Google Play Services, um comportamento comum em malwares que tentam fugir de ambientes de teste e análise.
Outro recurso sofisticado é o atraso intencional na ativação das cargas maliciosas. O Keenadu pode esperar cerca de 2,5 meses após a infecção antes de começar a realizar ações visíveis, o que dificulta a detecção por ferramentas automatizadas e análises em sandbox, que geralmente observam o comportamento do software por um período menor. Além disso, a distribuição dos payloads é feita por meio de infraestrutura em nuvem, usando serviços de CDN para mascarar o tráfego malicioso.
Entre os principais módulos maliciosos associados ao Keenadu estão componentes voltados a fraude publicitária e manipulação de tráfego. Um módulo focado no Google Chrome é capaz de sequestrar pesquisas do usuário e redirecioná‑las para mecanismos alternativos, gerando cliques e impressões fraudulentas. Já o Clicker Loader automatiza interações com anúncios em plataformas como YouTube e Facebook, simulando visualizações e toques que nunca aconteceram de fato.
Outro componente, chamado Install Monetization, é especializado em simular instalações legítimas de aplicativos, manipulando dados de telemetria e relatórios de conversão para inflar métricas usadas em campanhas de marketing digital. Há também um módulo mais novo, conhecido como Nova Clicker (Phantom), que utiliza técnicas de machine learning e recursos como WebRTC para interagir com anúncios de maneira ainda mais convincente e difícil de detectar pelos sistemas antifraude.
Um módulo adicional relacionado à Google Play coleta o Advertising ID, identificador utilizado para rastreamento e personalização de anúncios. Com isso, os operadores do Keenadu conseguem construir perfis detalhados de comportamento das vítimas, o que não só potencializa a fraude publicitária, mas também pode abrir portas para campanhas de espionagem direcionada no futuro.
Embora a principal finalidade hoje pareça ser a monetização ilícita – inflando cliques, acessos e instalações para gerar lucro -, especialistas alertam que a arquitetura do Keenadu é flexível o suficiente para evoluir rapidamente. O mesmo mecanismo que hoje serve para fraude pode, com modificações relativamente simples, ser adaptado para roubo de credenciais bancárias, interceptação de mensagens, espionagem corporativa ou vigilância em larga escala.
Dados de telemetria indicam que, até o momento, pelo menos 13.715 usuários já foram impactados, com maior incidência na Rússia, Japão, Alemanha, Brasil e Holanda. O volume pode parecer modesto diante do total de dispositivos Android no mundo, mas o detalhe crucial é a qualidade da infecção: trata‑se de um comprometimento de baixo nível, com acesso privilegiado e alta capacidade de persistência. Em termos de risco individual, o cenário é grave.
Há ainda sinais de que o Keenadu não atua de forma isolada. Foram observadas semelhanças e possíveis integrações com outras famílias de malware conhecidas, como Triada, BADBOX, Dwphon e Vo1d. Esses vínculos sugerem a existência de um ecossistema de botnets que compartilham infraestrutura, componentes de código ou até equipes de desenvolvimento, criando uma rede coordenada capaz de ampliar impacto e reduzir custos para os criminosos.
Além da infecção via firmware, três aplicativos distribuídos oficialmente na loja Android foram identificados como vetores associados à campanha: Eoolii, Ziicam e Eyeplus. Esses apps, aparentemente legítimos, serviam como porta de entrada ou elemento complementar no ecossistema do Keenadu. Após a descoberta, foram removidos da loja e versões conhecidas da ameaça passaram a ser bloqueadas por mecanismos de proteção do próprio ecossistema Android, desde que o dispositivo seja devidamente certificado e a proteção nativa esteja habilitada.
Do ponto de vista de segurança, o Keenadu representa um cenário quase “perfeito” para o atacante e desastroso para o usuário: um backdoor pré-instalado no firmware, com privilégios máximos, escondido em uma biblioteca crítica do sistema e capaz de contornar o modelo tradicional de permissões do Android. Ao operar em um nível tão profundo, ele obtém acesso silencioso a praticamente todos os dados armazenados ou processados no aparelho, neutraliza o isolamento entre aplicativos e permite controle remoto amplo sobre o dispositivo.
A análise técnica indica que os responsáveis pelo Keenadu possuem conhecimento detalhado da arquitetura interna do Android, dos mecanismos de inicialização (boot), do funcionamento do Zygote e da forma como o sistema aplica e gerencia permissões. Não se trata de um malware amador, criado às pressas, mas de um projeto sofisticado, de longo prazo, que provavelmente envolve uma equipe com experiência em engenharia reversa, desenvolvimento de firmware e exploração de cadeias de suprimento.
Para os usuários, a grande questão é: como se proteger de uma ameaça que já vem “de fábrica”? Em muitos casos, não há solução simples. Se o firmware de um tablet já sai comprometido da linha de produção, antivírus tradicionais podem até detectar alguns comportamentos suspeitos, mas dificilmente conseguirão remover completamente o backdoor sem acesso ao código-fonte ou a uma imagem limpa do sistema. A reinstalação de ROMs oficiais também não resolve se a própria ROM fornecida pelo fabricante estiver contaminada.
Diante desse tipo de cenário, a escolha do dispositivo torna‑se uma decisão de segurança, não apenas de custo-benefício. Comprar tablets de marcas pouco conhecidas, sem histórico de atualizações transparentes ou garantia de certificação, aumenta o risco de receber um aparelho já vulnerável. Empresas e usuários finais precisam começar a considerar a procedência do firmware, a política de atualizações e a reputação do fabricante como critérios tão importantes quanto hardware ou preço.
Para quem já possui um dispositivo potencialmente afetado, alguns cuidados adicionais podem reduzir danos. Evitar o armazenamento de informações altamente sensíveis nesses aparelhos, limitar o uso para atividades de baixo risco, desabilitar permissões desnecessárias e monitorar consumo de dados e bateria podem ajudar a perceber comportamentos anômalos. Em ambientes corporativos, a segregação desses dispositivos em redes isoladas e o uso de soluções de gerenciamento de endpoints podem mitigar parte da exposição.
Do lado dos fabricantes, o caso Keenadu expõe fragilidades profundas na cadeia de suprimentos de software. É fundamental implementar processos rigorosos de auditoria de firmware, revisar o uso de componentes de terceiros, aplicar assinaturas e verificações independentes em cada etapa e monitorar continuamente a integridade das imagens distribuídas. Parcerias com empresas especializadas em análise de código e threat intelligence tornam‑se praticamente obrigatórias para qualquer marca que pretenda ser levada a sério em segurança.
Também é necessário um esforço maior de transparência. Publicar changelogs detalhados, esclarecer a origem dos componentes utilizados no sistema, oferecer canais para reporte de vulnerabilidades e responder de forma rápida e clara quando há suspeita de comprometimento são passos essenciais para reconstruir a confiança do público. Em um cenário de ameaças cada vez mais avançadas, fingir que nada aconteceu é a pior estratégia possível.
Para o ecossistema Android como um todo, a lição é clara: não basta proteger apenas o que está na camada de aplicativos. A segurança precisa começar no firmware e na cadeia de produção, com validação independente, criptografia robusta e monitoramento constante de anomalias. Ataques como o Keenadu mostram que, quando o inimigo consegue infiltrar‑se no próprio processo de construção do sistema, todo o modelo de proteção baseado em permissões, sandboxing e loja oficial fica ameaçado.
Em última análise, o caso Keenadu marca mais um capítulo na evolução das ameaças móveis: saímos da época dos simples apps maliciosos e entramos no terreno dos backdoors de nível de firmware, inseridos na fábrica e distribuídos por meio de atualizações aparentemente confiáveis. A partir de agora, discutir segurança em dispositivos Android significa, obrigatoriamente, falar de cadeia de suprimentos, integridade de firmware e responsabilidade de cada ator envolvido na produção de um único tablet.