Malware Android usa IA, rouba seu PIN pelo toque e se reinstala sozinho depois que você o apaga

Introdução

Um novo malware bancário para Android, rastreado como RatHat, foi descoberto pelo laboratório zLabs da Zimperium (empresa especializada em segurança mobile). A ameaça combina quatro inovações preocupantes: auto-pareamento com o Android Debug Bridge (ADB) local para obter acesso shell, um agente Go persistente que sobrevive à desinstalação do app, captura de PIN e padrão de desbloqueio por coordenadas de toque em nível de hardware, e o uso de IA generativa para navegar dinamicamente pela interface do dispositivo.

Os operadores do RatHat têm indícios de atuação a partir da China, segundo a Zimperium. A distribuição ocorre por campanhas de smishing (phishing via SMS), malvertising (publicidade maliciosa) e fóruns de terceiros que hospedam APKs fraudulentos.

Contexto: bancos no radar

O RatHat mira aplicativos bancários, carteiras de criptomoedas e serviços de pagamento. Embora não haja vítimas brasileiras confirmadas até o momento, o modus operandi — uso de acessibilidade para automação, overlays de captura de credenciais e persistência agressiva — segue o padrão de outras famílias que já afetaram o Brasil, como o Mantax Otax e o KREMLIN.

A relevância para o cenário BR está na técnica: o malware não depende de exploits de dia zero, mas de abusar de recursos legítimos do Android — Accessibility Service e Wireless Debugging — que usuários comuns e corporativos mantêm ativados sem supervisão.

Cadeia de ataque: do smishing ao shell

A infecção começa com um APK baixado fora da Google Play Store. O usuário é levado a instalar o aplicativo por uma página de phishing, geralmente disfarçada de app de streaming ou utilitário. Ao abrir o app, a primeira tela solicita permissão de Accessibility Service com uma justificativa genérica — "necessário devido a restrições de rede", exibida em uma página HTML local.

Concedida a acessibilidade, o RatHat executa uma sequência automatizada de toques. O primeiro passo é ativar as Developer Options, tocando sete vezes no "Número da versão" nas configurações. Em seguida, habilita o Wireless Debugging — navega até o menu de opções do desenvolvedor e ativa a depuração sem fio. Com o debugging aberto, o serviço de acessibilidade extrai o código de pareamento: lê os dígitos do código de 6 caracteres e a porta dinâmica gerada pelo Android diretamente dos elementos de texto na tela. Por fim, o malware auto-pareia com o ADB local usando uma biblioteca ADB embarcada (libadb-android), autenticando contra 127.0.0.1 na porta exibida.

Esse processo dá ao RatHat acesso shell ao dispositivo — um nível de privilégio que aplicativos Android normais jamais alcançam. Uma vez no shell, o malware copia dois componentes disfarçados para /data/local/tmp/.

A mesma técnica de abuso do Wireless Debugging foi observada anteriormente no RedHook Android RAT, que usava ADB para controle remoto.

Os componentes persistentes: agente Go e túnel FRP

O RatHat implanta dois binários nativos no diretório do sistema:

• liblocal-service.so — um agente escrito em Go, executado fora do ciclo de vida do app Android. Ele gerencia permissões, executa comandos shell, concede privilégios de sistema ao app principal (como isenção do modo Doze) e mantém a comunicação com o servidor C2 via HTTP em 127.0.0.1:7910.

• libmedia_codec.so — disfarçado de biblioteca de codec de mídia, é na verdade um cliente Fast Reverse Proxy (frp, projeto de código aberto fatedier/frp). Ele estabelece um túnel reverso persistente para o servidor do operador, expondo o dispositivo à internet mesmo atrás de NAT e firewalls. A configuração (IP, porta e token) é baixada do C2 pelo agente Go.

Esses dois componentes operam independentemente do APK. O agente Go roda como daemon do sistema e não é removido quando o aplicativo é desinstalado pela interface do Android.

Persistência pós-uninstall

O RatHat implementa duas camadas de persistência que tornam a remoção trivial impossível:

Primeira camada: quando o usuário tenta desinstalar o app, o malware intercepta a tela de confirmação e sobrepõe um overlay falso estilizado como Google Play, simulando uma falha na desinstalação. Isso engana a maioria dos usuários, que acreditam que a remoção não funcionou.

Segunda camada: mesmo que o usuário consiga desinstalar o APK, o agente Go (liblocal-service.so) continua executando fora do ciclo de vida do pacote. Ele verifica periodicamente se o pacote do app está presente. Se não estiver, executa:

pm install -r -g -i com.android.packageinstaller /data/local/tmp/app.apk
settings put secure enabled_accessibility_services '%s'
settings put secure accessibility_enabled 1

O APK é reinstalado a partir de /data/local/tmp/app.apk com todas as permissões de runtime concedidas automaticamente e o Accessibility Service reativado — sem que o usuário precise aprovar nada. O agente também reescaneia as portas do Wireless Debugging e reabilita as configurações se necessário.

IA generativa na navegação da interface

Um dos aspectos mais inovadores do RatHat é o uso de IA generativa para navegar pela interface do dispositivo. O malware serializa a árvore de acessibilidade ao vivo em XML e a envia para um assistente de IA popular (não identificado nominalmente pela Zimperium).

A IA é consultada para três tarefas específicas:

• Localizar um botão pelo nome — a IA retorna as coordenadas centrais do elemento na tela, permitindo toques sintéticos precisos.
• Ler texto exibido na tela — sem traduzir, apenas extraindo o conteúdo textual do XML de acessibilidade.
• Decidir quando rolar a tela — comandos como SCROLL_DOWN são emitidos pela IA quando o elemento alvo não está visível.

Essa abordagem substitui coordenadas fixas (frágeis a mudanças de versão e resolução) por um entendimento semântico da interface. O malware se adapta a diferentes idiomas, versões de apps e tamanhos de tela sem intervenção manual do operador.

É importante notar: a IA é assistiva, não autônoma. Ela resolve tarefas de navegação específicas, mas o controle da cadeia de ataque permanece com o operador. Não se trata de um agente de ataque independente.

Roubo de credenciais: overlays, toque e interceptação

O RatHat coleta credenciais por três mecanismos simultâneos:

Overlays de injeção WebView. Quando um app bancário ou de criptomoedas alvo é aberto em primeiro plano, o malware sobrepõe uma tela HTML fornecida pelo servidor C2 sobre a interface legítima. A página falsa captura login, senha e PIN. Os templates de overlay são distribuídos via endpoint /api/v2/dev/inj/global-configs.

Captura de coordenadas de toque em nível de hardware. O agente Go executa o comando getevent — uma ferramenta padrão do Android que lê o arquivo de dispositivo bruto /dev/input/*. Aplicativos comuns não têm permissão para isso, mas o shell UID 2000 (alcançado via ADB) sim. O malware combina as coordenadas (X, Y) com o arquivo locateValues.json, que mapeia o layout do teclado numérico e da grade de padrão para cada marca de celular. Um toque em (540, 1624) em um Samsung se traduz no dígito "5". O mesmo método reconstrói padrões de desbloqueio pela sequência de toques contra a grade 3x3.

Essa técnica burla proteções que Android implementou para outros vetores: FLAG_SECURE em janelas (bloqueia screenshot mas não o input driver), teclados customizados (o app nunca recebe o texto, mas o dedo ainda toca a tela) e a ocultação de dígitos na tela de bloqueio.

Interceptação de SMS e notificações. Um receiver de SMS e um listener de notificações trabalham em conjunto para capturar códigos OTP e 2FA enviados por SMS ou push.

Anti-análise e indicadores de comprometimento

O RatHat emprega quatro camadas de anti-análise estática e seis verificações anti-debug em tempo de execução.

Camadas anti-análise:

Container tampering. Arquivos declarados como diretórios no ZIP e flags de criptografia marcadas enganam ferramentas como unzip e apktool, mas são ignoradas pelo Android (libziparchive).

Manifest bomb. O AndroidManifest.xml tem 61 MB, dos quais 99% são chunks de tipo desconhecido 0x9999 que o runtime nativo apenas ignora, mas que fazem analisadores automáticos estourarem memória.

DEX bytecode poisoning. Pseudo-instruções com element_width inválido quebram disassemblers sem afetar a execução no ART.

String encryption em duas camadas. StringFog (base64 XOR key) sobreposta por StringCrypto que troca pares de bytes adjacentes e XOR com chave de 16 bytes.

Verificações anti-debug:

Depurador conectado. O malware verifica Debug.isDebuggerConnected() e Debug.waitingForDebugger().

Ptrace attach. Lê /proc/self/status em busca do campo TracerPid — detecta gdb, lldb e qualquer attach nativo.

FLAG_DEBUGGABLE. Verifica se o APK foi repackeado com a flag de debuggable ativa.

Propriedades do sistema. Checa ro.debuggable == "1" e ro.secure == "0".

Frida. Sonda TCP na porta 27042, busca pelo processo "frida" no ps e varre /proc/self/maps por libfrida-agent.so.

Root, Xposed e emulador. Testa 20 caminhos de root, 3 pacotes do Xposed, a prop persist.sys.xposed.enable, o Build fingerprint e device nodes do QEMU.

Indicadores de comprometimento (IoCs)

Os IoCs completos estão disponíveis no repositório da Zimperium no GitHub.

Como se proteger

A defesa contra o RatHat começa antes da instalação.

Use apenas a loja oficial. APKs baixados de sites de terceiros, links em SMS não solicitados ou anúncios são o principal vetor de entrada. A Google Play Store, apesar de não ser infalível, tem camadas de verificação que bloqueiam a maioria dos droppers.

Nunca conceda Accessibility Service sem propósito claro. Esta é a permissão mais crítica do Android. App de banco não precisa de acessibilidade. App de streaming não precisa de acessibilidade. Se um app pedir, desconfie.

Desative o Wireless Debugging. A menos que você seja um desenvolvedor depurando ativamente, mantenha "Depuração sem fio" desligada. Vá em Configurações > Opções do desenvolvedor > Depuração sem fio e desative.

Não confie apenas em SMS como segundo fator. O RatHat intercepta notificações e mensagens SMS com OTPs. Prefira autenticadores baseados em TOTP (Google Authenticator, Authy) ou chaves de segurança físicas.

Monitore apps em ambientes corporativos. Bancos e provedores de pagamento devem monitorar sessões originadas de dispositivos com acessibilidade ativa, overlays em execução ou serviços de debug ativos. Soluções como o Wazuh podem ser configuradas para alertar sobre alterações em configurações de desenvolvedor.

Conclusão

O RatHat representa um salto qualitativo no malware bancário para Android. A combinação de auto-pareamento ADB (que quebra o sandbox do Android), componentes Go fora do ciclo de vida do app (que garantem persistência mesmo após desinstalação), captura de toque em nível de hardware (que burla as proteções de tela do sistema) e IA generativa para navegação dinâmica de interface forma uma cadeia de ataque difícil de detectar e remover.

Para o usuário comum, a mensagem é clara: desconfie de todo app que pede acessibilidade sem motivo, mantenha o Wireless Debugging desligado e não baixe APKs fora da loja oficial. Para bancos e empresas de segurança mobile, o RatHat é mais um sinal de que a proteção baseada apenas em assinaturas e permissões tradicionais já não basta.

Nota de honestidade: a análise foi conduzida pela Zimperium zLabs sobre uma amostra real. Não há vítimas brasileiras confirmadas. O uso de IA é assistivo (navegação de interface), não autônomo. A ameaça não corresponde a uma CVE, mas a uma campanha ativa.

Perguntas frequentes

Fontes e leituras adicionais

• Cyber Security News — New Android Malware Steals Banking PINs and Reinstalls Itself After Users Delete It — 17/09/2026
• Zimperium zLabs — RatHat: AI-powered mobile threat is here for your credentials & bank accounts — 15/09/2026
• GitHub / Zimperium — RatHat IOCs repository — 15/09/2026