RatHat: o malware Android que usa ADB e IA para controle total do dispositivo

Artigo

RatHat: o malware Android que usa ADB e IA para controle total do dispositivo

Rodrigo ColissiRodrigo Colissi
28 de setembro de 202612 min de leitura—
MalwareMobilePhishing

O RatHat é um malware Android que combina auto-pareamento ADB (Android Debug Bridge) com IA generativa para navegar a interface do dispositivo em tempo real. Descoberto pelo Zimperium zLabs, ele opera fora do sandbox do Android, executa daemons independentes com privilégios shell e persiste mesmo após a desinstalação do APK original. Este artigo analisa sua arquitetura, cadeia de infecção e mecanismos de defesa.

Introdução

O cenário de ameaças móveis ganhou um novo patamar com a descoberta do RatHat, um malware bancário Android identificado pelo Zimperium zLabs (laboratório de pesquisa em segurança mobile) com indícios de operação por atores chineses. Diferente de trojans bancários convencionais, o RatHat introduz duas inovações técnicas: o auto-pareamento ao ADB sem interação humana e o uso de IA generativa para controle da interface do dispositivo em tempo real.

Distribuído via campanhas de smishing (phishing por SMS) e malvertising (propaganda maliciosa), o malware convence a vítima a instalar um APK fora da Play Store e, a partir daí, executa uma cadeia de infecção automatizada que concede ao operador acesso shell persistente — algo raro em malware mobile.

Arquitetura do malware

O RatHat é composto por três componentes principais que operam de forma coordenada:

  • Aplicativo Android — responsável pela interação com o usuário, aquisição de permissões e inicialização da cadeia de infecção.
  • Agente Go (liblocal-service.so) — binário escrito em Go, executado em contexto shell após o auto-pareamento ADB. Atua como cérebro de comando e controle.
  • Cliente FRP (libmedia_codec.so) — Fast Reverse Proxy baseado no projeto fatedier/frp (framework de tunelamento reverso), que estabelece um túnel persistente para o servidor C2.

Cadeia de infecção passo a passo

Entrega e instalação

O primeiro contato ocorre por smishing ou malvertising, levando a vítima a portais de download fraudulentos que hospedam o APK malicioso. O instalador é um dropper (aplicativo que carrega o payload real em recursos criptografados) com quatro camadas anti-análise e uma camada anti-debug.

Camadas anti-análise do dropper:

A primeira camada manipula o container ZIP, declarando alguns arquivos como diretórios — o Android ignora essa inconsistência, mas ferramentas como unzip e apktool falham ao processá-lo. A segunda é um manifest bomb: o AndroidManifest.xml tem 61 MB, com 99% composto por chunks de tipo desconhecido 0x9999 — o runtime do Android simplesmente os ignora, enquanto analisadores estáticos estouram memória ou travam. A terceira camada envenena o bytecode DEX com pseudo-instruções de element_width inválido, fazendo disassemblers falharem no cálculo do payload. A quarta camada aplica dupla criptografia de strings (StringFog + StringCrypto com troca de pares de bytes e XOR por chave de 16 bytes).

O dropper também implementa seis verificações anti-debug em tempo de execução: detector de depurador JDWP, attach via ptrace (leitura de /proc/self/status), flag FLAG_DEBUGGABLE, verificação de propriedades do sistema (ro.debuggable, ro.secure), detecção do Frida (porta 27042 + scan de /proc/self/maps), e verificações de root, Xposed e emulador.

Aquisição de permissões por engenharia social

Uma vez instalado, o aplicativo exibe uma página HTML local com justificativa personalizada por país — em alguns casos alega "restrições de rede" para solicitar o serviço de acessibilidade. Depois de concedida, a SystemHelperService assume o controle e executa cliques sintéticos para ativar as Opções de Desenvolvedor (sete toques no número da versão) e habilitar a Depuração Wireless.

Auto-pareamento ADB

Este é o diferencial técnico central do RatHat. Com o serviço de acessibilidade ativo, o malware:

  1. Navega até a tela de pareamento ADB Wireless.
  2. Extrai o código de 6 dígitos e a porta dinâmica da interface (via IDs de recurso ou varredura de todos os TextViews).
  3. Usa uma biblioteca libadb-android embutida para autenticar contra o daemon ADB local em 127.0.0.1.
  4. Após o pareamento bem-sucedido, obtém acesso shell ao dispositivo — sem jamais precisar de um computador host.

Com o shell, o malware faz o stage dos binários auxiliares em /data/local/tmp/: o agente Go (liblocal-service.so) e o cliente FRP (libmedia_codec.so).

IA generativa como mecanismo de navegação

O RatHat serializa a árvore de acessibilidade do dispositivo para XML e a envia a um assistente de IA generativa comercial. O prompt instrui a IA a:

  • Resolver as coordenadas centrais de botões nomeados na tela (para direcionar cliques sintéticos).
  • Extrair o texto exibido na interface sem traduzi-lo.
  • Sinalizar comandos de navegação como SCROLL_DOWN.

Os prompts encontrados pela Zimperium contêm instruções em chinês e fazem referência a horários no fuso UTC+8, corroborando a atribuição a atores baseados na China. Essa abordagem difere da automação scriptada tradicional: a IA se adapta a variações de interface, versões de sistema operacional e até mesmo a aplicativos atualizados, sem exigir ajustes manuais no malware.

Componentes em execução

Após o pareamento, o agente Go opera como servidor HTTP local em 127.0.0.1:7910. Ele executa comandos que o aplicativo Android não pode rodar por estar no sandbox:

  • dumpsys deviceidle whitelist +<pacote> — exclui o app do modo Doze (economia de bateria).
  • am set-standby-bucket <pacote> active — prioriza execução em segundo plano.
  • pm disable-user --user 0 <pacote> — desabilita aplicativos de segurança arbitrários.
  • pm uninstall -k --user 0 <pacote> — desinstala completamente apps de segurança.

O cliente FRP estabelece um túnel reverso para o servidor C2, expondo o daemon ADB local (porta 7910) à internet, contornando NAT e firewalls. O operador então tem acesso irrestrito ao dispositivo.

Keylogging em nível de hardware

O agente Go implementa três mecanismos de captura de teclas, sendo o mais avançado deles um keylogger em nível de hardware:

  1. Accessibility text-event keylogger — o UniversalInputMonitor consome eventos de texto do serviço de acessibilidade e reconstrói o que foi digitado, classificando campos por palavras-chave localizadas (senha, PIN).

  2. Captura de URLs de navegadores — o KeystrokeCapture lê a barra de endereços de oito navegadores diferentes (Chrome, Brave, Opera, DuckDuckGo, Samsung Internet, entre outros) por ID de recurso.

  3. Keylogger raw /dev/input (agente Go) — o AdbTouchCapture usa a ferramenta getevent para ler o arquivo bruto de dispositivo de entrada que o kernel escreve. Aplicativos comuns não podem ler /dev/input/*, mas o shell UID 2000 pode — essa é uma das razões principais para o auto-pareamento ADB. Os dados são coordenadas (X, Y, timestamp), mas o malware também carrega locateValues.json com os layouts de teclado numérico de cada marca de smartphone, permitindo reconstruir PINs, senhas e padrões de desbloqueio a partir da geometria do toque.

Essa técnica contorna todas as proteções convencionais: FLAG_SECURE (bloqueia captura de tela mas não atinge o driver de entrada), teclados customizados (o texto nunca passa pelo sistema mas os dedos tocam a tela) e a proteção de tela de bloqueio (que oculta os dígitos do PIN da acessibilidade).

Persistência pós-desinstalação

O RatHat implementa um mecanismo de persistência incomum: mesmo que o usuário desinstale o APK original, o agente Go (liblocal-service.so) roda fora do ciclo de vida do pacote e não é removido. Se detectar a ausência do aplicativo, o agente o reinstala automaticamente:

pm install -r -g -i com.android.packageinstaller /data/local/tmp/app.apk
settings put secure enabled_accessibility_services '&lt;pacote&gt;'
settings put secure accessibility_enabled 1

Isso reinstala o APK, concede automaticamente todas as permissões de runtime e reativa o serviço de acessibilidade — tudo sem qualquer interação com o usuário. Paralelamente, enquanto o app está ativo, um heartbeat redeploya o agente Go caso ele pare de responder e rescaneia a porta ADB.

Comunicação C2

A comunicação com o servidor de comando e controle ocorre por múltiplos canais:

  • O aplicativo Android registra-se via HTTP e mantém um WebSocket aberto com heartbeats. As requisições são autenticadas com HMAC-SHA256 sobre uma chave de dispositivo derivada de um salt.
  • O agente Go mantém canais HTTP independentes para tarefas, logs, upload de vídeo, configuração FRP e listas de evasão.
  • O túnel FRP expõe o shell ADB ao operador como canal de acesso geral, independente das features do malware.

Endpoints notáveis incluem: /api/data/credentials (credenciais capturadas por overlay), /api/data/messages (SMS interceptados), /api/adbk/upload (certificados ADB do dispositivo), /api/v2/dev/tasks (fila de tarefas para o agente) e /api/tun/config (configuração do túnel FRP).

Overlays de injeção bancária

O RatHat monitora o aplicativo em primeiro plano. Quando detecta um pacote financeiro alvo, dispara um overlay HTML malicioso (fornecido dinamicamente pelo atacante) sobre o aplicativo legítimo. Os alvos incluem bancos globais, carteiras digitais (WeChat Pay, Alipay) e aplicações de criptomoedas. Os overlays são capazes de capturar credenciais, PINs e códigos 2FA.

Como se proteger

Instale aplicativos apenas da Google Play Store. O RatHat é distribuído exclusivamente por canais laterais (portais de download falsos, links em SMS e anúncios maliciosos). A Play Store tem camadas de proteção (Play Protect) que detectam comportamentos suspeitos como os do dropper.

Desative as Opções de Desenvolvedor se não as utilizar ativamente. O malware depende da ativação programática das opções de desenvolvedor e da Depuração Wireless. Manter essas configurações desativadas elimina o vetor principal de escalada de privilégios.

Revise periodicamente os aplicativos com serviço de acessibilidade ativo. Vá em Configurações > Acessibilidade > Serviços instalados e verifique se há aplicativos desconhecidos com permissão de acessibilidade. O RatHat depende dessa permissão para navegar pelas telas de configuração.

Desconfie de solicitações de permissão de acessibilidade com justificativas genéricas. Mensagens como "devido a restrições de rede" ou "para melhorar sua experiência" são os gatilhos de engenharia social usados pelo malware.

Soluções Mobile Threat Defense (MTD). Produtos como o Zimperium MTD detectam o RatHat por comportamento dinâmico (não por assinatura), identificando ativação anômala do serviço de acessibilidade, manipulação de Opções de Desenvolvedor e tentativas de pareamento ADB loopback.

Para instituições financeiras: soluções de proteção em tempo de execução (como Zimperium zDefend) detectam overlays fraudulentos, cliques sintéticos e ambientes comprometidos por scraping de acessibilidade ou captura de tela, permitindo encerrar sessões sensíveis antes do vazamento de credenciais.

Conclusão

O RatHat representa um salto qualitativo no malware mobile. A combinação de auto-pareamento ADB (que quebra o sandbox do Android sem necessidade de computador host) com IA generativa para navegação adaptativa da interface cria um cenário onde a automação maliciosa não é mais rígida e scriptada, mas sim flexível e resistente a mudanças de versão ou interface.

A capacidade de persistir fora do ciclo de vida do aplicativo (o agente Go reinstala o APK mesmo após desinstalação manual) e a captura de teclas em nível de hardware via /dev/input (que contorna todas as proteções de tela do Android) tornam este um dos malwares mobile mais sofisticados já documentados publicamente. Até o momento, não há confirmação de vítimas no Brasil, mas o modelo de distribuição via smishing pode atingir qualquer região.

O que torna o RatHat diferente de outros malwares Android?

Duas inovações principais: o auto-pareamento ADB sem interação humana (quebra o sandbox do Android) e o uso de IA generativa para navegar a interface do dispositivo em tempo real, em vez de automação scriptada rígida.

Como o RatHat consegue acesso shell sem um computador?

Ele usa o serviço de acessibilidade para ativar programaticamente as Opções de Desenvolvedor e a Depuração Wireless, extrai o código de pareamento da tela e autentica contra o daemon ADB local usando uma biblioteca ADB embutida no próprio APK.

O RatHat funciona mesmo depois que desinstalo o aplicativo?

Sim. O agente Go (liblocal-service.so) roda fora do ciclo de vida do pacote, em /data/local/tmp. Se detectar que o APK foi removido, ele o reinstala automaticamente com todas as permissões, incluindo o serviço de acessibilidade.

Como a IA generativa é usada pelo RatHat?

O malware serializa a árvore de acessibilidade do dispositivo para XML e a envia a um assistente de IA comercial. A IA retorna coordenadas exatas de botões na tela, identifica textos e sinaliza comandos de navegação como SCROLL_DOWN, permitindo que o malware se adapte a diferentes versões de apps e SO.

Quais tipos de dado o RatHat consegue roubar?

Credenciais bancárias (via overlays de injeção HTML), PINs e senhas (via keylogger de hardware que lê coordenadas de toque), códigos 2FA/OTP (via interceptação de SMS e notificações), URLs de navegação e o padrão de desbloqueio da tela.

O RatHat afeta dispositivos no Brasil?

Não há confirmação pública de vítimas brasileiras até o momento. Os alvos documentados incluem bancos e carteiras digitais globais com foco no mercado asiático (WeChat Pay, Alipay). Porém, o modelo de distribuição via smishing pode atingir qualquer região.

O que é o mecanismo de keylogging por hardware?

O agente Go usa a ferramenta getevent para ler /dev/input/* — arquivos brutos do kernel que registram coordenadas de toque (X, Y). Combinado com um dicionário de layouts de teclado numérico por marca de celular, o malware reconstrói PINs e senhas a partir da posição geométrica dos toques.

Como o malware contorna o FLAG_SECURE das janelas?

FLAG_SECURE bloqueia captura de tela e leitura por acessibilidade, mas não atinge o driver de entrada (/dev/input). O keylogger raw do RatHat opera nesse nível, sendo imune a essa proteção.

O que é o cliente FRP e qual seu papel?

FRP (Fast Reverse Proxy) é um framework de tunelamento que permite expor servidores internos à internet. O RatHat usa um cliente FRP disfarçado de libmedia_codec.so para criar um túnel persistente entre o dispositivo infectado e o servidor C2, contornando NAT e firewalls.

Há IOCs públicos disponíveis?

Sim. A Zimperium publicou os indicadores de comprometimento (IOCs) do RatHat em seu repositório oficial no GitHub: github.com/Zimperium/IOC/tree/master/2026-09-RatHat.

Fontes e leituras adicionais

Gostou? Receba novos conteúdos por e-mail.

Entre na comunidade

Discussões técnicas e novidades em primeira mão.