Uma nova família de malware para Android, batizada RatHat, está a chamar a atenção dos investigadores por juntar duas peças que raramente aparecem no mesmo pacote: automação assistida por inteligência artificial generativa e uma forma de persistência que sobrevive à desinstalação da aplicação maliciosa. A equipa zLabs da Zimperium descreve o RatHat como uma nova estirpe de malware Android associada a agentes de ameaça que aparentam operar a partir da China, distribuída sobretudo através de campanhas dirigidas de smishing e de malvertising que conduzem a portais de descarregamento de terceiros, e que combina o abuso dos serviços de acessibilidade com o emparelhamento autónomo com o ADB local para escapar à sandbox das aplicações e executar componentes nativos com privilégios de shell. O relatório foi publicado a 16 de setembro de 2026.
Resposta rápida: O RatHat é um trojan bancário para Android analisado pela Zimperium zLabs que recorre a um serviço de IA generativa para navegar no ecrã do telemóvel e a um emparelhamento local com o Android Debug Bridge para obter privilégios de shell. Rouba credenciais bancárias, códigos OTP/2FA e reconstrói PINs e padrões de desbloqueio a partir dos toques no ecrã. A infeção depende sempre de o utilizador instalar um APK fora da Google Play e conceder acessibilidade. Não instale aplicações fora das lojas oficiais, recuse pedidos de acessibilidade sem justificação e mantenha o Google Play Protect ativo.
O que muda quando o malware deixa de seguir um guião fixo
A maioria dos trojans bancários para Android funciona com sequências programadas: tocar em coordenadas conhecidas, procurar botões em posições esperadas, assumir um determinado idioma. Basta o fabricante mudar o interface ou a aplicação bancária alterar o ecrã de login para a automação falhar. Segundo a análise da zLabs, o RatHat usa um serviço de IA em tempo real com acesso à árvore de acessibilidade do Android: a IA avalia os elementos presentes no ecrã e decide onde tocar, quando deslizar ou que texto introduzir durante o ataque, o que dificulta a deteção por produtos de segurança móvel convencionais. Na prática, em vez de codificar cada toque para cada modelo de telemóvel, o operador pede ao serviço que localize um determinado controlo no interface ativo e traduz a resposta em toques ou gestos sintéticos — o que torna a automação mais portável, mas não dispensa a vítima de atravessar primeiro a fronteira de segurança.
A BleepingComputer, citando a zLabs, refere que a atribuição a agentes de ameaça chineses assenta, entre outros elementos, em prompts para modelos de linguagem escritos em chinês encontrados no código. Nem todos os detalhes foram divulgados: o reporte público não identifica qual o assistente de IA utilizado, nem revela a escala da campanha, e a análise da Zimperium não apresenta números de vítimas nem uma lista de países visados. É um ponto a reter antes de se interpretar o caso como uma vaga massiva de infeções.
A cadeia de ataque, passo a passo
| Fase | O que acontece |
|---|---|
| 1. Isco | Sites de phishing promovidos por malvertising, campanhas de smishing e fóruns de terceiros levam a vítima a descarregar manualmente um APK que aparenta ser uma aplicação legítima. |
| 2. Disfarce | Num dos exemplares analisados, o malware fazia-se passar por um serviço de streaming conhecido e alterava dinamicamente o ícone e o nome visível, incluindo um alias de atividade «Chrome». |
| 3. Acessibilidade | Já instalado, pressiona o utilizador a ativar o serviço de acessibilidade, exibindo falsos avisos sobre restrições de rede ou alegando que a permissão é necessária para receber benefícios financeiros. |
| 4. Fuga à sandbox | O componente SystemHelper usa toques sintéticos para abrir as Opções de programador, ativar a Depuração sem fios, abrir o interface de emparelhamento e ler o código de seis dígitos apresentado no ecrã. |
| 5. Shell local | O emparelhamento é concluído localmente, sem qualquer computador externo, e passa a correr um processo nativo persistente com privilégios de shell (UID 2000), independente da aplicação principal. |
| 6. Monetização | Agentes escritos em Go executam comandos e mantêm um túnel inverso para os atacantes, enquanto sobreposições HTML falsas em aplicações bancárias e de criptoativos capturam credenciais e intercetam códigos únicos por SMS. |
Do ecrã ao PIN: como são roubados os dados
O RatHat monitoriza a aplicação em primeiro plano e, ao detetar um pacote alvo, dispara o mecanismo de injeção HTML correspondente. De acordo com os indicadores divulgados, as sobreposições visam aplicações bancárias, de criptoativos, de pagamentos e de mensagens, capturando utilizadores, palavras-passe, dados de cartão e PINs; interceta SMS e notificações para obter OTP e códigos de dupla autenticação; um keylogger baseado em acessibilidade regista texto introduzido, incluindo campos de palavra-passe mascarados; e monitoriza URL em navegadores como Chrome, Brave, Opera, Edge, DuckDuckGo e Samsung Internet.
A técnica mais invulgar é a recolha de toques em bruto. O agente em Go invoca o utilitário getevent do Android para monitorizar eventos em /dev/input e capturar coordenadas de toque com marcação temporal — algo que uma aplicação Android normal não consegue fazer, e que só é possível graças ao contexto de shell obtido através da Depuração sem fios. Comparando essas coordenadas com esquemas conhecidos de teclados numéricos e grelhas de padrão, o malware reconstrói PINs e padrões de desbloqueio, contornando proteções pensadas para impedir a leitura direta de informação sensível no ecrã.
Desinstalar pode não ser suficiente
Este é o ponto operacionalmente mais relevante para quem responde a incidentes. O agente em Go é armazenado sob o nome enganador liblocal-service.so e pode executar comandos, obter isenções de gestão de bateria, recolher dados de entrada e sustentar a persistência; a Zimperium refere que o agente verifica se a aplicação maliciosa continua instalada e a repõe quando necessário, e que a aplicação também consegue restaurar o agente caso este desapareça, enquanto um segundo componente nativo, libmedia_codec.so, funciona como cliente de proxy reverso. Se a vítima tentar desinstalar, o malware pode interferir no processo exibindo um falso erro da Google Play e, mesmo que a remoção resulte, o componente persistente pode voltar a instalar a aplicação e a repor as permissões.
À camada de persistência junta-se uma barreira anti-análise pouco comum. O APK pode incluir inconsistências no contentor ZIP que o Android tolera mas as ferramentas de desempacotamento não, um manifesto Android de 61 MB preenchido com blocos não documentados 0x9999, pseudo-instruções DEX malformadas que perturbam a desmontagem e vários métodos de ofuscação de strings; em execução, procura ainda depuradores JDWP, ligações ptrace, Frida, Xposed, artefactos de root, emuladores, propriedades de compilação alteradas e sinais de reempacotamento.
Indicadores e pistas de deteção
| Indicador | Observação |
|---|---|
liblocal-service.so | Payload nativo identificado pela Zimperium; os domínios e IP de comando e controlo foram publicados de forma neutralizada (defanged). |
libmedia_codec.so | Componente nativo que atua como cliente de Fast Reverse Proxy. |
getevent / /dev/input | Utilizado para capturar coordenadas de toque com marcação temporal. |
| Deteção AV | O Malwarebytes for Android identifica a família como Android/Trojan.Exploit.RatHat. |
Para equipas de segurança, a recomendação prática passa por procurar dispositivos corporativos com opções de programador e serviços de acessibilidade ativos em simultâneo e por rever políticas de MDM. Em dispositivos geridos, sugere-se bloquear a instalação a partir de fontes desconhecidas, permitir serviços de acessibilidade apenas em aplicações aprovadas e desativar as opções de programador e a depuração sem fios. Do lado das instituições financeiras, foi sugerido vigiar sessões provenientes de telemóveis que apresentem sobreposições no ecrã, recolha por acessibilidade ou serviços de depuração ativos.
O que fazer, na prática
- Instalar aplicações apenas a partir de lojas oficiais, evitar ligações em mensagens não solicitadas e anúncios, e recusar acessibilidade a aplicações sem finalidade de acessibilidade evidente.
- Rever os serviços ativados e as definições de depuração sem fios, e contactar o banco a partir de um dispositivo de confiança perante ecrãs de login inesperados ou movimentos por explicar.
- Perante suspeita de infeção, assumir que a desinstalação pode não bastar: ponderar reposição de fábrica, alteração de PIN, palavras-passe e credenciais bancárias a partir de outro equipamento.
- Manter uma solução antimalware atualizada e com proteção em tempo real nos dispositivos Android.
Porque é que isto importa em Portugal
O vetor de entrada do RatHat é exatamente aquele que mais tráfego malicioso gera no ciberespaço nacional. O CNCS recorda que o phishing e o smishing têm sido dos tipos de incidentes mais registados pelo CERT.PT. O próprio Observatório de Cibersegurança já tinha sinalizado famílias Android distribuídas por smishing que aguardam que a vítima abra uma aplicação bancária ou de pagamentos para apresentar uma página falsa sobreposta, intercetando assim os dados bancários. Para cidadãos e trabalhadores, a diferença é que o telemóvel deixou de ser apenas o segundo fator: é, cada vez mais, o alvo principal.
Para as organizações, o tema tem também leitura regulatória. Um telemóvel pessoal usado para aceder a correio eletrónico corporativo, a aplicações de autenticação ou a sistemas internos torna-se um ponto de entrada; com o Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), as entidades abrangidas têm de demonstrar medidas de gestão de risco que incluem o controlo de dispositivos móveis, a gestão de acessos e a notificação de incidentes ao CNCS/CERT.PT. Se houver exfiltração de dados pessoais de clientes ou colaboradores, aplica-se ainda o dever de avaliação e eventual notificação à CNPD ao abrigo do RGPD. Para as PME, a mitigação mais barata continua a ser preventiva: política clara de BYOD, bloqueio de instalação de APK fora das lojas oficiais nos dispositivos geridos e formação de sensibilização focada em smishing.
Perguntas frequentes
O RatHat consegue infetar um telemóvel sem qualquer ação do utilizador?
Não. A técnica não significa que o RatHat invada remotamente um telemóvel Android intacto sem interação: a infeção inicial continua a depender de engenharia social, da instalação de um pacote malicioso e da concessão de permissões poderosas.
Basta desinstalar a aplicação suspeita para ficar limpo?
Não necessariamente. O aviso central para utilizadores Android é que desinstalar a aplicação suspeita pode não ser suficiente depois de o RatHat completar a sua cadeia de persistência. Em caso de suspeita, deve ponderar-se a reposição de fábrica e a alteração de credenciais a partir de outro dispositivo.
Como é que o malware descobre o meu PIN se não vê o ecrã?
Recolhe coordenadas de toque em bruto a partir do controlador de entrada do dispositivo e compara-as com esquemas conhecidos de teclados numéricos e de padrões de bloqueio, o que lhe permite reconstruir PINs e padrões de desbloqueio.
Que medidas devem tomar as empresas com frotas de telemóveis?
Em dispositivos geridos, recomenda-se bloquear a instalação a partir de fontes desconhecidas, autorizar serviços de acessibilidade apenas em aplicações aprovadas e desativar as opções de programador e a depuração sem fios. Devem ainda existir procedimentos de notificação de incidentes ao CERT.PT e de avaliação de impacto em dados pessoais.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Zimperium zLabs, pelo CNCS/CERT.PT e por investigadores de segurança que analisaram a campanha.